Preview | SmartThings-managed Edge Device Drivers

Awesome write up Kevin. The driver channels were designed not only for sharing drivers but also to give developers an opportunity to test things themselves before pushing changes to a wider audience exactly like you described.

The backend will only allow you to have one version of a driver installed on a hub at a time, but if you ever wanted to switch your hub from the dev channel to your “shared” channel what you can do is just go through the install step in the CLI again (smartthings edge:drivers:install) and specify that you want to install the driver from the “shared” channel. This should automatically update your hub to the version of the driver in the shared channel. Let me know if you ever try that and it doesn’t work for you though.

2 Likes

FWIW, After a week of getting used to using the channel approach to hub installs, I would very much like to see the self-published option continue, so I’m hoping you are successful with your suggestion :grin:

1 Like

8 posts were split to a new topic: [ST Edge] Device Preferences

Will we be able to create simple “virtual” device drivers using Edge, such as a virtual switch, virtual switch/contact sensor, virtual switch/motion sensor, etc?

1 Like

Eventually, yes. Right now they aren’t supported since there is no mechanism to add a virtual device to your location.

1 Like

A post was split to a new topic: [ST Edge] Issue with device history

5 posts were split to a new topic: [ST Edge] - Driver/Device timers

@TAustin @krlaframboise We have added back in some helper params to make using channels less verbose and more like the “self-published” driver flow. You can now specify a channel and hub in the package command so that the driver is “packaged”, “assigned to a channel”, and “installed to a hub” all in one command. The command would look like

smartthings edge:drivers:package --channel <channel-id> --hub <hubId>

You can also use the --assign and --install params and the CLI will prompt you to select a channel and hub. You can see additional examples here

Make sure you pull in the latest CLI version to get these changes.

The “self-published” flow as it was is unlikely to return, but let us know if there is anything we can do to make using channels easier.

6 Likes

Thanks much for the update, Caleb. During iterative development, the channels stuff just adds steps to both creation and deletion that have no value, but between this helper and setting up bash files to automate things, the nuisance factor is minimized. :+1:t3:

1 Like

A post was split to a new topic: [ST Edge] Lidl Bulb Zigbee Driver

Late night thought: the icon in the mobile app that indicates when a device is offline needs to be something other than the current ‘slashed cloud’ default when it is an edge device. :smirk:

1 Like

Hi Kevin - Can I get access to your new channel? I’d like to try out a few more devices!

I’ve added you to the PM, but the only drivers I have posted so far are for the ZSE41, ZSE42, and ZEN30.

Now that I have published a driver on a shared channel, and made updates to that driver, I have an important observation:

Any changes you make to the associated device definitions (e.g. device config/presentation, capability presentation, etc) will get propagated prior to you re-publishing your driver. This would make sense if you think about it, but it needs to be taken into consideration. But perhaps the more tricky part is that you are making commensurate changes to your driver’s device profile yaml files, and of course these changes don’t get reflected until you assign the new driver package to your shared channel and it ultimately gets installed on the hub.

So this brings up a synchronization issue: device definitions and presentations get reflected ‘immediately’, whereas your driver code updates won’t get propagated to hubs for up to 12 hours. This can create scenarios where device profiles and driver code are out of synch.

Is there any guidance/advice from the ST team for how we should manage this to avoid causing issues for our driver users?

3 Likes

This sounds like something that should ultimately be handled by versioning, but I’m not aware of any of the version numbers we see everywhere actually having gone live.

2 Likes

As @TAustin points out, users testing out the vDevice creator app were able to install 2 seperate Virtual devices offered by his Virtual device creator after an app update, however the devices did not appear in the app as that part of code had not propagated to the hub, not a real issue as things are Beta at present but this definately needs addressing

You are probably right :+1:t3: Hopefully we can find out when versioning will be all working.

9 posts were split to a new topic: [ST Edge] Iris Motion Sensor driver

After I had to reset my Hub I’m unable to enroll into the Beta channel.
It’s just stuck at the ring going around and around.
Has something changed in the last month, so its limited?

Regards

I can see how that would happen with a custom capability, but wouldn’t pretty much any noticeable change you make to a device config/profile end up generating a new VID?

If that’s the case then those changes wouldn’t have any impact on the published driver because it would still be using the old VID that hasn’t changed…

That being said, drivers, device configs, and capabilities/presentations have a field for version so I’m hoping we’ll be able to use that for these types of situations at some point in the future.

1 Like