I searched around and didn’t see a thread like this yet so thought I would start one where we can discuss solutions outside the end of Groovy thread {shakes fist at sky and looks frustrated} so it doesn’t get so muddled in there. I tried to put this in the right category and add relevant tags to help people find it, but any admin can feel free to move around if I didn’t stick in the right place.
So my use case is that currently I use Yves DTH running through Webcore to control 2 V3 thermostats in a group and 3 external sensors. I have a 12 pistons happily humming along with nary a hitch. . . until we reach end of life of Groovy and all my HVAC controls and notifications not built directly into Ecobee (a few schedules and a bunch of comfort settings) will come crashing down. In that other thread the ideas that have been thrown around so far are using IFTTT, SharpTools, and Alexa. I have only played around with IFTTT so far but I suspect the limiting factor is going to be on the DTH side and the functions it exposed where the stock ST<->Ecobee interface is pretty limited. Notably around hold until settings. Below I list out my current automations and trying to order higher importance at the top. I plan to try and move as much of this as I can to built in Ecobee automation. . . .basically letting it conrol the vacant offset and keep the fan cycle set constant. . . .but its the home/away that is really my priority. I don’t want to have another app on all our phones watching location and want to still run it via Google Home App (since we let Google check location for a lot already)/Virtual Switch. A complicating factor is since I used the built in ST cloud link for the Ecobee sensor and the Yves DTH for the thermostat, I am struggling to figure out which device is linked which way as I think it added the thermostats via ST at one point and I removed to avoid duplicates. The IDE doesn’t seem to sync up with the app in terms of devices. Will try to let people know what I figure out but looking for any good ideas too.
When all members leave home set all thermostats to away mode indefinitely. The ST presence really started to act up several months ago so now I have 4 people all with a Google Home “Homes” with one virtual device that is set to on/off based on when they are away. When all 4 are off I use Webcore to switch the house into away mode. Then a separate piston reads that and sets the thermostats to away. When any member comes back it sets ST to Home and that triggers another piston resume one thermostat to regular schedule and sets another to a “HomeEmpty” mode that is closer to desired temp but still has an offset.
The Upstairs thermostat reads off the Ecobee temp sensors plus several other motion sensors to determine when nobody is on the second floor. Waits 20 min then sets the thermostat to “HomeEmpty” with a small offset. This does not kick in when the thermostat is in Sleep comfort mode since people aren’t moving.
Each thermostat compares its linked external Ecobee sensor temp to each other and the main unit and if differs by >2 degrees it sets the fan on time to 10 min per hour. When temp comes back in line sets to zero per hour.
When a unit is in cool mode and running and one of a bunch of window/door open/close sensors opens, sends an SMS to my wife and I to close the window
When I turn on a Work From Home virtual device the downstairs thermostat is put into a mode where it only uses the temp sensor in the office. I am home often by my self and use a small space heater to just heat the room so the rest of the house is allowed to cool off.
Each thermostat is checked if the main unit temp doesn’t change at all for 3 hours. If so shoots an SMS to me to make sure its still connected and registering with ST.
This sounds exceptionally painful to try to set up with IFTTT. My ecobee integration is one of the several, and my primary reason, I’ve setup home assistant in the past two weeks. If you have an always on PC (I’m running in a hyper-v virtual machine on windows), Pi, or similar, it is free and the ecobee integration is a great way to start because it is a built in, easy to setup integration. Sounds like you’d manage the highly flexible automations well since you’ve been in deep with webcore.
It has an API (so should remain) integration to ST as well, so I left my existing install intact for anything not relying on groovy. It is a one way integration, but adjusting edge virtual switches in HA can be used as devices and triggers in ST. The ST integration isn’t exceptionally easy and requires a port open (setup with https at least), which I hate, but it is well documented on how to do it and works very well.
Of note, I use tplink access points and there is a custom integration that works well for wifi presence without anything on the phones. Depending on your network equipment, you may be able to simplify your bulk presence.
Fully agreed. I highly doubt I will find an out of the box solution that can cover what I am doing today, but I have only been watching the alternative choices from an arms length so am not educated enough to actually make a decision and start moving or spinning up new platforms like HA or Hubitat. My plan for now is to quickly (since ST just threw a time bomb into my house) patch something together that is the minimum my self and my family will accept. Once I can get over that hump I think I need to seriously consider moving some/all of my stuff off ST (using a Pi for something has always intrigued me). I’d like to be able to hold out till Matter comes into play to see if any new players join the space. I am trying not to be too reactionary with ST and throw the baby out with the bath water as ST has done my a lot of good for quite a while, but its hard to resist that feeling.
It sounds like everything you are using (Yves DTH and webCoRE) already works exactly the same on Hubitat, with the added benefit that all your rules would run local to your hub (but still needing to communicate with the Ecobee’s API).
Yes, it sounds like it, but I just don’t think I have the bandwidth to make that transition by 9/30 . . . or I think 10/15 now. . . but plan to look into it. I am not hot on the idea of using ST and Hubitat and further sprinkling my solutions around (already bad enough, smart app folder on my phone already bulging) and would prefer to try and pick a solution that would allow me to move as much as I can to one solution so want to do my due diligence before I dive in too much.
I know I can’t really trust what I see in the IDE when tied to place holder, but I am really confused by what I am seeing. I tried to list it out below so people know what I am talking about, but apologies as it’s pretty confusing to write up much less read. My example is for 1 real world device.
What I am trying to do is sort out what I have linked currently as I wanted to try and get the stock integration connected along side the Yves solution for the thermostats to see what I could make work via IFTTT and SharpTools without having to remove the Yves device and nuke my existing automation just yet.
I know I have both as I have the Ecobee sensors linked through the stock integration, but I think I removed or hid the thermostats to avoid dupes. I went to try and relink the stock integration in ST to get the thermostats back but I only see an option to unlink which I assume will delete the devices and destroy the Webcore automation. Is there a way to relink and get both sets of thermostats showing again?
I see 2 thermostats in the IDE with similar names for for one real physical device. I know device names vs labels are confusing but I wasn’t sure which showed where so included both.
In the Ecobee app I have Upstairs Ecobee
In the ST app I see Upstairs Ecobee. When I go to edit it says connected via a linked service so I assume this is the stock integration.
IDE Device=My Ecobee Device, Label=Upstairs, Type=My Ecobee Device. I think this is the Yves version based on naming and attributes available.
IDE Device= ecobee Thermostat - Heat and Cool, Label=Upstairs Ecobee, Type=placeholder. I think this is the stock integration. Being a placeholder really no details available.
Webcore I have Upstairs and My ecobee Upstairs Ecobee. I have only included Upstairs. So I think I have included the Yves and my automation in Webcore still works using the advanced controls like comfort and hold till.
I guess now that I wrote that all out I will see what IFTTT and SharpTools expose since if they can see them that’s all that really matters as the ST app clearly isn’t going to cut it for much of this. Once (or if lol) I get this figured out I would zap the Yves implementation.
I would note that Yves’ Ecobee device handlers are written in Groovy and likely use custom commands and custom attributes. The new SmartThings REST APIs will only expose custom commands and custom attributes that are part of a custom capability definition… otherwise they only expose the standard commands and attributes based on the capabilities that the device uses.
While there are pretty straightforward ways to use custom capabilities in the new Edge drivers, it wasn’t something that was done in the Groovy environment.
The bottom line is these custom commands that aren’t part of a capability definition won’t show up in the new APIs. But these Groovy devices with custom commands will also die when SmartThings shuts down groovy, so your DTH dying ends up being the bigger issue in my opinion.
I’m kind of weak on the new terminology still (heck, weak on the old too) but I’m a little lost on the actual specifics you are calling out (REST API, custom attribute vs capability) as well as if you could actually use an Edge driver combined with a cloud integration. . . but I get the point that the Yves DTH is going away so any attributes/commands it had that are not part of the stock integration also go poof too. My plan was to try and get the stock SmartThings <->Ecobee integration going for the thermostats and then try use that in IFTTT or SharpTools to see what I could do. When I tried an IFTTT applet connected to Ecobee directly it could only set a single temp so right off the bat that makes it hard to handle when the thermostat was set to Auto (both heat and cool), but if via SmartThings I can control both heat and cool at the same time, I could skip the comfort setting and just set them direct.
Basically, when groovy ends you will be left with the cloud 2 cloud ecobee option. This does not expose any custom settings. Only Off, Heat, Cool, Auto are exposed to ST.
Using IFTTT and to get around the limit of set profile until next schedule, I instead used Applet 1
When I leave home, set Away comfort setting for X hours (I used 12hrs but you can pick up to 24hrs) Applet 2
when I arrive home (or whatever your trigger is) set comfort profile to Home. This overrides the previous away Applet and changes the comfort profile.
Yes, that’s what I was thinking. . . but as a last resort. Since I have 2 thermostats and a blink module all tied to home/away, that’s 6 applets. I’m not against paying, but for 30 bucks a year you only get 20 applets which I can see would fill up fast. It does note multiple actions if you unlock pro, but not clear exactly exactly what that means, but hopefully would mean 1 on and 1 off with 3 actions each. Still seems pretty restrictive and rudimentary rule builder for the cost. I could get into the multiple IFTTT accounts as someone suggested, but . . .man SmartThings why are you making me do this!!
I was able to re-link the thermostats by trying to add a device and just choosing Ecobee again. I think in the end that is what was already showing in the SmartThings app and I have lost the ability to see the Yves version in app, but not a big deal since I never control it via SmartThings. The good news is via either service I think it would be pretty straight forward to set an indefinite heat and cool set point when I leave . . . but its the Resume function that is tough. SmartThings doesn’t have resume so therefore SharpTools doesn’t either and IFTTT does have Resume but faces the Applet restriction. As a compromise workaround I might use SharpTools to set the away set points and the IFTTT to resume when return. Not great, but SharpTools seems far more robust in the long run for usage elsewhere so would not be a waste.
Just had an idea to use the Google Home app with a home/away routine, but sadly it can’t control Ecobee thermostats at all. You can add the devices and last time I tried could issue a Resume command verbally, but the thermostats are exposed to the Home/Away routines. I still haven’t given up and trying to see if I can find a way to get the thermostat to resume on its own.
Nice idea. It looks like those aren’t available for Google Home but they are for Alexa (via the Ecobee Plus skill, not the regular Ecobee skill). I think I’m going to use that approach, at least until EcoBee decides to expose more capability in their C2C integration; I’ll need virtual switches for away and sleep, with home being assumed if those are both off, but at least I can add it to my existing scenes and routines rather than creating new automations or SharpTools rules.
Can users without Echo devices still set up integrations and routines via the Alexa app and use it as a hubless automation engine?
It looks like you don’t need an echo device to setup a routine to control an Ecobee. I just setup a test routine to change temperature on an Ecobee with a custom command and I could select my phone as the “From” in the routine. Just be aware that your phone will verbally respond to the request in the routine.
Voice Monkey could also be used to trigger the Alexa routine directly for those who don’t want to create Virtual Switches in SmartThings.
It’s been relatively popular with the SharpTools.io community for triggering Alexa routines or making TTS announcements on Alexa from SharpTools Rules.
Is Ecobee Plus a subscription or just a different skill to turn on? I actually haven’t used a lot of Alexa automation because we mostly have Google devices and . . .up until this impending mass loss of functionality. . . I preferred SmartThings and Webcore.
Anyone know who to voice my request to enhance the ST<->Ecobee integration to? I know not happening any time soon . . . if ever. . .but just figured I would add my name to the request pile while it’s fresh in my mind.
Still boggles my mind that comfort setting and resume are so fundamental to the way Ecobee operates yet they weren’t included. You can override a temp forever but there is no way to get it back following the built in smarts.
At this Point with a very few exceptions, smartthings has published its API, and it is now up to the device manufacturer to provide and maintain an integration.
We should also note that ecobee has announced they will support matter, but no details on that, or whether it would require buying a new model. But that might be their plan for future integration. There just aren’t that many device manufacturers anymore who are willing to invest resources into creating an integration for only one platform.
What’s the terminology of what I should tell them in terms of what I want them to support? Eg what is the stock integration vs what the custom DTHs are using?
