Same here, two ST buttons and the Z-wave repeater side of two Iris smart plugs are the first devices I’ve seen automatically migrate, sometime in the 2-3 days since I last checked.
My Groovy Smart Lighting routines that use those two buttons seem to be broken - I get a “We’re having trouble connecting” error when I try to edit the routines. Fortunately they’re simple to recreate but not a good sign (CC @nayelyz )
SmartLighting routines that use the Iris plugs look to be intact, but they use the Zigbee plug part of the device, not the Z-wave repeater, so I wouldn’t expect them to be impacted.
Hi, @Rick_VB
Is the “Groovy thermostat” a custom Groovy SmartApp? I want to see if it’s possible to check which elements of the device were being used.
When this happens, it’s hard for the team to track down the issue if you delete and recreate the elements.
I can report the issue to see if there’s something they can I need the following info:
Routine’s name in SmartLighting. The name of the device involved.
Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
Has anybody come up with a virtual thermostat yet that I can wire up relatively simply yet with a temp sensor and a switch/on-off plug? I’m starting to get worried, as winter is coming and I have three of these that I depend on…
Could you use Mariano’s virtual thermostat tied to a sensor (ZigBee sensor version here: [Beta] ) Edge Driver Zigbee Temp Sensor and Thermostat Mc:), and then create routines to tie the actions of the virtual thermostat to turn on and off a plug?
He has a zwave sensor version of the same driver if needed.
Next devices that have moved: Sonoff / EweLink motion sensors. Associated Smart Lighting routines still exist and can be edited; I’ll check tonight whether they’re functioning normally.
Not today, and it doesn’t seem like that’s going to be added. Automigration by Samsung only, or exclude/include (zwave) or delete and re-pair (Zigbee).
@Rick_VB, if you haven’t already dived into @Mariano_Colmenarejo’s Zigbee or Z-Wave temp sensor and thermostat edge drivers, I suggest you do.
I was hesitant at first, not wanting to have a multi-piece solution (thermostat device, routine to turn on switch, routine to turn off switch) to replace a single-piece solution that I had in the old groovy virtual thermostat smartapp.
Working with @Mariano_Colmenarejo to test the Z-Wave virtual thermostat has softened my stance. Building and maintaining (in my case) the 2 SharpTools Rules is suboptimal but OK, knowing that it’s a limitation of the edge architecture that disallows the virtual thermostat device from controlling the switch device directly.
Maybe someone someday will figure out how to use a bridge service/server on the LAN to bounce a command from one edge device on the hub to another edge device on the hub.
I’m sure you have some reason that I don’t know, but I don’t understand why you have to use sharp Tools to control a switch with the operating state capability of the thermostat.
I have done it with two very simple routines and with local execution
1- If Thermostat Operating status is heating then Switch Boiler ON
Thanks, I did end up contacting Mariano to add several devices that I’m using in conjunction with those thermostats to the zigbee thermostat mvc. Very quick response, and appreciate the help!
Once I got over my own ignorance on all this newer stuff (the old stuff was humming along great), I was able to rewrite my three thermostats, and they’re running correctly, to the best of my knowledge.
Because I’m using location mode, motion, contact sensors, switches, and time to controI these thermostats, I think something like sharptools would be beneficial as I’m using at least 4 routines for each thermostat to do what could be done in a couple of complex if else rules.
So, for example, one thermostat is a space heater in my son’s room. I don’t want it to run at all when he’s not there, and weekends are different than the week, so I created a rough work schedule to control a virtual switch that I can also control if he’s gone for a night. I don’t want it to run if he’s not in his room for a while, except at night when he’s not moving. I think that one eats up 6-8 routines. The other two thermostats are slightly less complicated and use 4 and 5.
The pro is that execution can be local. And it’s more or less stock smartthings.
The con is that it’s actually slower and less responsive right now. Maybe it’s because most of the routines still aren’t running locally, either because some of the devices are still on custom groovys, or because I’m using some wifi switches.
What’s a little more frustrating is smartthings inability to get/set other devices values. So I can’t average 3 devices to get one virtual temperature. And the inability to do more complicated routines. I can try to understand how to use rules, but I have enough other stuff going on that I don’t have time right now.
Yes, my reason is that I prefer SharpTools Rules over SmartThings Routines. I would rather keep all of my rules/routines in one place, and SharpTools gives me more complex options, logs, persistency, and possibly backup-restore someday.
Backup is a big concern of mine since I’ve experienced a hardware failure of a SmartThings hub and it wasn’t pretty to rebuild on a replacement. Thankfully my webCoRE pistons could be copied and adjusted easily due to the fact that I declare all devices in my pistons as variables. SmartThings routines often completely disappear if the related device is deleted.
No ST driven changes for me in 2023, except the transition to the smart lighting app. They missed the December date, and things don’t look good for the Q1 date either…
I’ve had two Sengled bulbs auto-migrate since about Christmas. Twelve devices remaining not counting five Sonos speakers that are using the websocket integration. Don’t believe any of the remaining twelve will require additional Edge drivers beyond those already installed by previous authorization.
I feel like it’s premature to declare that a date six weeks in the future is unattainable. We’ve got no access to the big picture, just each of our own small pictures plus any random info posted on these forums by other users.
We definitely don’t know the true big picture or the details, which of course would help. I’m at 17% devices transitioned (104 devices more to go). With the exception of Ecobee transition which I’m assuming is complete if the IDE “placeholder” indication is correct, the three transitioned Edge drivers are all basic ones- with no children, no multifunction capabilities, simple implemented routines, etc. Reading between the lines, it looks like they are still addressing fixes to the currently released drivers, and by making firmware updates and thus may be holding off on the one offs that may be more complicated. Just my guess.
The good thing is that everything is still working fine once I figured out how to work around the loss of the color coordinator. Even added new logic on some of my existing routines, so far so good.
