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.
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?
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.
One example is the preferences section in a profile. It seems that if you update that, and install the driver to your own hub for testing via a development channel, then users of that driver/profile will see those new settings fields before you’ve even re-published your driver to the shared channel.
So now I’m making it a practice to temporarily change the profile name to hopefully prevent this from happening.
Do we know for sure that these beta Edge channels and drivers will work when this goes from beta to production?
Is it acceptable to emit capability attribute updates from the added lifecycle handler? I’m finding that these device attributes are not getting updated per the mobile app. Whereas identical emit commands from the Driver that get executed ‘later’, seem to be ok…
Just got a hub firmware update (000.040.00003).
Are there Edge-related updates in this? Can anyone provide details?