I Will try it
12 posts were split to a new topic: [ST Edge] Motion sensor icon not displaying correctly
3 posts were split to a new topic: [ST Edge] Change Driver Tool in the ST App
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.
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
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?
Eventually, yes. Right now they aren’t supported since there is no mechanism to add a virtual device to your location.
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.
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.
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.
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?
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.
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 Hopefully we can find out when versioning will be all working.