On a related note, what exactly is the deal with file extensions?
I am used to using the .yaml extension with CLI on Windows and as that extension was used in the capabilities and presentation folders I used it for my profile file in the profile folder without thinking about it. It was only when I saw the examples used .yml that I changed the extension of the profile file and suddenly had some errors thrown by smartthings edge:drivers:package (I needed some quotes around certain strings in the profile file). So it presumably must have previously ignored this file. Yet, it has no issue with reading config.yaml.
For what itâs worth, Iâm on Linux and have always used .yaml for my profile files without any issues; but the capability folder stuff is new with the beta so havenât tried that yet.
I have to say I am having a complete mare at the moment. Here is a typical sequence that I just carried out (st is the name of my CLI):
st edge:channels tells me âno channels foundâ. st edge:channels:drivers agrees, definitely âno channels foundâ.
So what would you expect for st edge:channels:enrollments ? Obviously all three of my hubs on my two Locations to start with. Then what? Well if I choose the second hub which I was playing with earlier I get told the details of the channel it is subscribed to, even though I allegedly donât actually have any channels.
Oh and st edge:channels:unenroll says that there are âno channels foundâ.
I do actually have a driver. I can see that with st edge:drivers. I canât st edge:drivers:publish or st edge:channels:assign of course because I have âno channels foundâ. I can however do st edge:drivers:installed and see that the driver is installed on a hub.
It has been like that all afternoon. I enrolled the hub that is on my non-default Location onto a channel and it succeeded. I installed the driver from that channel onto the hub and it failed because the hub wasnât enrolled on the channel.
I listed my drivers and got two copies of the same driver with the same ID but different versions. Attempting to delete it revealed the same two drivers but looking identical because the version wasnât listed. Choosing one deleted both. However I could also list the drivers and get a single version of one driver, then go to delete it and get offered two copies of the driver but with different ID, the additional one having been deleted a long time previously.
I may have answered one question myself: Iâve implemented my custom capabilities as shown in the example without the presentation files and it seems to work OK.
Just FYI, you donât have to use channels. If you want to work around those problems for now, just use vanilla package and install cli commands and choose âself-publishâ when it prompts you.
I didnât have any inkling that was possible. At the moment it isnât because when I do edge:drivers:install -H <hubid> it lists the channels the hub is enrolled in (yes, in this context it knows there is a channel) but presumably if the hub isnât enrolled in a channel it would be different.
You just edge:drivers:package and edge:channels:assign and that updates all the hubs that have installed drivers from your channel. Without doing an edge:drivers:install it can take up to 12 hours before every single hub pulls the update. I think there are vague plans for more well defined rollout strategies, but I donât know if that work has even been planned yet.
Use Lua 5.3 (5.3.6 being the latest version, but any should work). Thereâs a known issue running under 5.4 at the moment. Ideally anything 5.1 or later should work, and total compatibility is a goal, just a lower priority one since thereâs a lot of other work left to do.
I definitely couldnât agree more. Again, this is another thing with vague plans. I donât know what the exact simplification will end up being, but some more ergonomics would be nice.
I will just point out that you can do all of B2-4 hitting enter just one with something like:
st edge:drivers:package . && st edge:channels:assign -C <channel-id> <driver-id> && st edge:drivers:install -H <hub-id> -C <channel-id> <driver-id>
Itâs a lot of UUIDs to get in the right places the first time, but putting in a script (or just using your shell history if youâre lazy like me) means itâs super easy. You could also use that with something like entr which will automatically run that anytime you write to a file. So you just save and a few seconds later itâs synced to your hub.
Thatâs great to hear. I didnât wait more than a few hours while testing it and then I deleted the channel and started over before sharing it with anyone which explains why I thought it wasnât workingâŠ
Thatâs not actually true for anyone one but you and internal devs. And thatâs going to stop working for you soon, sorry if no one has told you that yet. That was another quick hack to get stuff working for testing that has now been replaced by the final flows. Iâve suggested we have the self-published added back as sugar on top of channels for convenience, but no final decisions have been made on that yet.
Regarding shared channels then, I have a question:
When you accept an invitation to someoneâs channel and install a driver from that channel, the driver gets installed directly to the hub? You never see the driver package files themselves, and they donât get downloaded or copied to your own computer, correct? If thatâs true then is this not a viable path for sharing drivers that may need some customization? Device preferences, for example talks about a mechanism to provide custom parameters in the profile. Or you might alternatively have a .lua file included in the package with a configuration table that you can customize. But maybe in those cases it would be best to distribute the driver package via github?
BTW, I think a driver preferences mechanism analogous to device preferences would be useful.
I know you might tell me that a smartapp is the preferred mechanism for configuration, but Iâm trying to avoid that!
Thatâs right. The Driver Sharing mechanism is a layer that will improve the method to share our solutions and, IMO will help a lot to the way driver developers engage their âcommunitiesâ because in the past it happened that people used to share/publish DTHs which its maintenance wasnât part of the plan, and then users had to either hire someone else for customization or just give up their appliance.
Also, it doesnât replace sharing driver source code repositories but it will help a lot of those that struggle with coding or are not familiar with terminal commands to set up drivers from scratch.