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.