Lutron Caseta is a cloud to cloud integration at the time of this writing. It wonât need to migrate and it wonât use an Edge Driver. Itâs a âlinked service.â
Iâm down to 16 Z-wave devicesâall switches, dimmers, and fan controls. Thatâs an easily manageable number if I was inclined to migrate manually, but now Iâm just curious to see how it all plays out.
So got a smart plug that was migrated yesterday and stopped working properly
Smart plug v6 by Aeon
I canât control the on or off from the app
Tried a couple of installed drivers on my hub (aeontec, smartthings, mc)
Noting seem to work
I had another similar plug that was still on the DTH (that was still working), I excluded it and pair it again to the hub. Doesnât work anymore
Seem a pretty basic migration, is there a way to see if there is an error somewhere ?
Does anyone happen to know if SmartThings will/still support updating (non-Hub) device firmware? My ST v2 HUB hasnât always been particularly consistent/reliable in that regard depending upon the device, but I was hoping to trigger firmware updates for same-model devices to hopefully get them all running the same firmware. (Before you say âyou donât need toâ, yes, I know⌠but my question stands.) Thank you =)
This is being discussed in the beta for new hub firmware, and the short answer seems to be that they donât know how to support it for the edge driver architecture.
Hereâs a comment from a smartthings engineer about the various issues. It at least shows that they are thinking about the issue.
The issues seems to be about 1) there is no central directory or repository for firmware; and 2) there is no way to guarantee that a firmware update is appropriate for the device and to prevent it from potentially bricking the device. This second point seems to be the more concerning.
Both of these seem orthogonal to Edge driver architecture.
Hard to say without more details, but since the old architecture could and did do Zigbee over the air device firmware updates and the new one apparently doesnât because of the issues discussed there does seem to be some correlation.
Yeah⌠the sourcing/risk aspects totally make sense to me, especially for firmware update automation. I wonder if ST might be able to at least code in a manual âside-loadâ firmware update option for users who have taken steps to properly identify and solicit/download the appropriate firmware for their devices? (Like a âproceed at your own riskâ process, as some folks do with computer BIOS updates and the like.)
There are sometimes performance/feature optimizations and annoying glitch corrections that can make a compelling case for firmware updates. Having that ability native to ST would be great, as my alternative for some devices would only be to buy the manufacturerâs official device hub, unpairing select device(s) from ST, pairing them w/ the manufacturerâs hub, updating the firmware, then unpairing from the manuf. hub, and repairing those devices back to ST. (Not to mention potentially needing to do that again, if there are bugs in the new firmware or additional fixes later on.) Yuck!
Wondering, perhaps those risks existed in the old architecture, but werenât readily apparent when it was deployed. Now that they are visiting OTA updates for Edge architecture, it could be that those risks are more obvious now than before. But then, what do I know?