While the article has a short list of what will be and what will not be supported, is there a comprehensive list of what will not be supported (for instance is green tech one power mode a legacy device that I’ll need to chuck?). Also, for the “at risk” devices, when they are moved to being a “thing”, will the logic developed in routines be lost (meaning I need to write it down manually now)?
Not even as a basic smoke detector? If that’s the case I guess I’m left to try something in Edge on my own to at lease replicate ST’s “Zigbee Smoke Detector” driver and just add the Halo fingerprint to it.
That’s all I’m really asking. Just add the fingerprint so its joined as a simple smoke detector, and forget about all the LED light ring and other capabilities.
I should have started this a long while back but I’m wondering about converting DTHs and SmartApps since I have several. Is there a “getting started” resource that covers making the transition? I assume yes but am not sure where to look or what different types of resources are available.
Does anyone have a list of helpful “official” links?
not official links…
There are no plans to integrate these fingerprints associated with Halo.
As @mvevitsis says, it’s not that simple because that still wouldn’t bring the device into your SmartThings account.
If you really can’t imagine giving up Webcore or some other groovy smartapp, the simplest solution is likely to switch those use cases to a Hubitat hub, which will run Groovy locally.
It would be a big project, you’d need to also add a raspberry pi so SmartThings and Hubitat could talk to each other, I think you’d have to rebuild all your pistons on the new platform, but you would still have Webcore.
Might be worth it for someone who has several Samsung smart tvs and appliances or just doesn’t want to lose the ST app, is comfortable learning mqtt if they don’t know it already, and is heavily invested in being able to write new Webcore pistons or has other existing groovy projects they don’t want to give up. But way too much work and complexity for most people, I think.
Hubitat to run Webcore, MQTT to integrate back to SmartThings
Here’s how this would work.
use Hubitat to run Webcore. I believe you would have to recreate all your pistons over there, but I don’t know the details.
Use proxy virtual devices on one system or the other. If you create virtual devices on Hubitat, you could leave the actual zwave and Zigbee devices on your SmartThings hub. Or you might have some devices that need custom code not yet available in an Edge driver, so you move those devices over to hubitat to take advantage of groovy there and add a proxy virtual device for them on the ST side.
There would be a lot of code needed to synch everything up, but you wouldn’t have to reset any physical devices that worked with an Edge Driver.
- Hubitat has a built-in interface to communicate with an MQTT broker. And @taustin has written a SmartApp for the new platform that supports communications with an MQTT broker. So you could communicate between the two hubs that way.
The good news is everything would run locally. The bad news is this is obviously just for power users willing to run 3 systems. But it should be doable.
Is there an edge driver for go control/nortek z wave garage door opener? (The GDZ…one)
yes, smartthings has one
I’m using a smartapp for a integration with the netatmo weatherstation. Will this be migrated?
True, and that was the easiest way.
But SharpTools webhooks will still work. So technically still doable, but harder to set up.
One thing I’m curious about is:
I am still enrolled in the SmartThings Edge Beta channel.
If I unenroll from SmartThings Edge Beta channel will I automatically receive the production version of the same drivers I’m already using?
Am I already using the production drivers for devices that are/were using drivers from the ST Beta channel?
What about devices that are integrated but not through stock DTH?
I am talking about Wiz for example. I have plenty of those
Devices which use a cloud to cloud integration and currently show “placeholder“ in the IDE are already using the new architecture. Same with most linked services. So nothing will change because of the groovy cloud going away and you don’t need to do anything about them.
Why not? You clearly have access to the original code, so making a lua driver should be trivial.
There’s quite a few people on here still using them.
But will it in that case remain in the cloud or the integration will become local?
I have several Shelly devices as well, currently integrated via Shelly cloud. But I saw Edge drivers for Shelly being developed, which is now somewhat confusing
Most linked services will remain in the cloud.
@taustin, Who did the Shelley integration, has done some amazing things with custom edge drivers including some that can connect to local servers which then gives you integration out if desired. But I suggest you ask in the Shelly thread if you have questions about it.
I reached out to keen but no response yet.
You have 2 options for Shelly.
There is the official cloud to cloud (c2c) integration or the community written Edge Driver that runs locally. Choice is good.
I have chosen the community written Edge Driver by @TAustin which works great.
I’ve received a couple of queries asking if I’m going to set up a page in the community – created wiki which would list model by model whether there’s a stock edge driver, a community created edge driver, or nothing yet.
I’m pleased to say that one has been created thanks to the help of several other people. It’s not complete, but if you see your model there, it should be accurate. If you don’t see your model there, you’ll have to do your own research, and then, if you find one, please do add it to the table for the next person who comes along.
Lists by device class: