I have multiple driver channels to support alpha, beta and production releases for different drivers. Being able to test with user groups before rolling out has helped a bunch, but there is still a gap when it comes to capabilities and presentations. If a capability is updated to change the way a driver works, that can be seen by all users regardless of their driver version and/or channel.
Is there a way to scope capabilities to a certain driver or version? The capability version isn’t quite working yet, so options look limited. It looks like the namespace is the only option for controlling the scope. Can we create multiple namespaces to support different driver channels? Then we can try out updates in a beta channel before pushing them to everyone at once.
Better yet would be a way to bundle the capabilities and presentations into the driver itself.
Can we create multiple namespaces to support different driver channels?
Only one capability namespace can be generated per account (you can check more about it here).
If you’re creating custom capabilities and need to test them, we strongly suggest you create virtual devices for this purpose. You can trigger events from the app and send commands directly through the API.
Also, you can create “dummy” capabilities to test a lot of different things and once you have the configuration you need, you can create the Prod-version one.
Do you think all these can help you overcome your issue? You could provide more details of your case to understand better your situation.
I don’t see how multiple namespaces alone would accomplish anything. Currently, all the config and code references must include the namespace, so you’re still looking at a (re)package. Wouldn’t that be the same as adding your own version suffix to the capability names? You could also incorporate your own prefix as a sub-namespace.
I’ve encountered similar frustration trying to pull together all the various external resources (custom capabilities, custom presentations, device-configs, etc.) I think we’re going to have to solve this problem ourselves with an external makefile and some preprocessing scripts.
At this point, I’ve begun questioning the time investment in perfecting the ST user interface. It would be so much easier to write a web-based UI that will work on any client device with the option to host on the local LAN. I guess it depends on your target audience. Personally, I have no qualms opening another app or webpage for a superior experience. This is industry standard for LAN devices.
So, my advice to anyone going down this path: Go ahead, use the ST hub as the gateway/interface for local devices. That part is fairly predictable. ST provides a ton of default functionality. Create a compliant Edge driver that offers basic functionality in the ST app. Automations will work. Voice control will work. Create capability commands for advanced functionality. Use the ST API or include LAN hooks in the driver and build your fancy UI outside the ST environment. You will control your destiny.
I wasn’t proposing to go that far. You’re just trading problems. Running within the hub environment is also a mystery and there’s no proper debugger. I would still use an external web server. I think even a dynamically-created, but otherwise-static JavaScript file might work.
Off the top of my head, could you not create additional Samsung accounts to give you the additional namespaces and add them as PATs in CLI profiles. Then you can just choose the profile you are using via environment variable or command line argument as required.
Also there is no need to think in terms of alpha, beta and production namespaces (if indeed you were). You could use them in lieu of version numbers and mix and match them. Ultimately it seems like you would be specifying which version of a capability you are using so there will always be some tweaking needed.
This is basically my issue. I would like to create a release pipeline that allows me to release these as a set. I suppose I will just need to used different capability names in each environment. Just makes it harder on testers to move up and down the pipeline with the same device. This means they will need to delete and re-create the devices when they switch channels. It’s a small enough ask for a test group, at least for alpha.
I don’t think this works since those other accounts wouldn’t be able to access the same release channels. However, I think your suggestion could work if each channel was in its own organization. This would also allow you to control access to each channel.
To be quite clear, I don’t have much of a scooby where ST are going with organizations and it isn’t encouraging that the word namespace doesn’t appear anywhere in that output, even though that is what we are used to calling those IDs.
I chose the organizations CLI command simply because I knew it would show the namespace in a short amount of vertical space. On reflection I should probably have just created a capability. The point was that simply by adding the --profile=profilename argument I could change the namespace I was working with just for that one CLI command.
Just in case anyone isn’t following this, all I did was create a Personal Access Token using a different Samsung account and added it to my CLI configuration as a profile. That makes it possible to create and edit capabilities in a different namespace. As well as having potential as a workaround pending the implementation of version numbers, it also has potential for sharing an organisational capability namespace.
Just to add to the confusion, the second account I used is actually an ‘organization’ in the Developer Workspace, and the first account is a member of it. This made sense at the time. Now, not so much …
This is true. If this was in place, I wouldn’t need to do any of the rest of this. I would just rev the version. Production users would stay on the old version until I updated that driver. I suppose the rest of this is just jumping through hoops to workaround the versioning.