Preview | SmartThings-managed Edge Device Drivers

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

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?

1 Like

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?

Thanks.

Nothing posted yet here Hub Firmware Release Notes - SmartThings Community

What hub type do you have?

hub v2, US customer Rev E

weird, maybe you’re on a special list since you were part of Edge Alpha testing?

A post was merged into an existing topic: [ST Edge] Change Driver Tool in the ST App

A post was split to a new topic: [ST Edge] Issues with the Zigbee motion driver

Is it me or is anybody else worried about the fact that there is no CONVERT tool for legacy Groovy DTH’s and SmartApps. Why is there so much attention of going toward the shiny new (even if performant) when the old faithful, open source, and MANY contributions is being abandoned. I hope that the Samsung acquisition wasn’t the death of this open platform. I just got wind of Groovy/IDE being sunset/deprecated and it scares the you know what out of me. This is multiple years of developing code for myself and the community going down the tubes. It pushes me toward jumping ship onto a hub where the platform is not pulled from under me after hundreds of hours of dedication. Please consider customers and our best interests which consists for a CONVERTER of some sort which prevents the nail on the Groovy coffin. I work for a software company that has done this many times (by really smart people) and we all know anything is possible in computing. Any way to get some attention from Samsung on my point? Just a sad few days for me as I rely on this platform and my extensive code library.

2 Likes

I am fairly relaxed about things. I’ve only been using SmartThings about three and a half years but I’ve been aware from day one that the legacy platform was going. Indeed the worry was that the new platform had an app with near zero functionality and it offered absolutely nothing to community developers at all. Fortunately my phone couldn’t run the new app as if it could I wouldn’t have used SmartThings at all simply because it couldn’t do anything. However the legacy ecosystem, though obviously not really fit for purpose, tided me over until the new ecosystem could be pointed in the right direction, so by the time I replaced my phone a couple of years ago it was possible to start bailing out of legacy.

3 Likes

I’m not sure why this is so often mentioned. This acquisition happened over 7 years ago. It’s certainly changed the direction of what SmartThings is and has grown to be, but it’s not been “the death of this open platform”.

That said, while I still run my SmartThings hub, all of my important home automation is run on a different hub platform (that focuses on local-execution) . The current SmartThings infrastructure is too unreliable and slow, and the newly emerging infrastructure has lots of teething to go through before it will even come close to being a suitable replacement. But eventually I hope their new architecture becomes a solid alternative.

3 Likes