Preview | SmartThings-managed Edge Device Drivers

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.

1 Like

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.

smartthings edge:drivers:package <projectdir>
smartthings edge:drivers:install -H <hubid>

5 posts were split to a new topic: [ST Edge] - Custom Capabilities Issue

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.

Try it without the -H parameter? It should give you a list of your hubs to choose from. Hopefully irregardless of enrolled channels.

I’ve created a channel, published a couple of drivers to it, given out the invitation link to a few users, and they’re actively using the drivers.

How do I give them a new version of the driver?

Does the official recommend which version of Lua to install? In other words, which version of Lua compiles best for the current version of the API?

I am only a few days into my Smartthings Edge Driver development, but this how I view the development steps.

Stage A

  1. Create a Channel
  2. Enroll a hub onto the Channel

STAGE B

  1. Write/Modify the Edge Driver code
  2. Upload the code
  3. Publish/Assign the driver (to the channel)
  4. Install the Driver (in the Hub)

Stage C - Test the Driver

  1. Enable logging
  2. Add a device
  3. Review the Live Logging

Go to Stage B

It would increase my productivity to have 1 command for B1-B4.

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.

1 Like

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…

1 Like

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.

Sorry; didn’t know. Thanks for the heads up.

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!

Please add your learnings to my post here: Developing for Edge - What I've Learned So Far

1 Like

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.


Check if this helps = )