Based on this thread and some of the comments I recently saw on the iOS App Store reviews it seems these are limitations endemic to ecobee.
I do have a “good morning” automation in HA which warms up the house at a set time, but I use it mainly because it also takes in to account work days in my area (using the workday component), otherwise I’d just use the ecobee schedule. I don’t want the house to warm up if I’m sleeping in on a holiday.
One thing that HA does help me with regarding ecobee is its stubbornness when setting a hold temp. It will not honor the next scheduled change if you set a hold, so I use the resume schedule option from HA to break it out of possible holds several times a day. After everyone usually leaves for the day, early evening, in case someone adjusted it during the day, and just before the usual sleep schedule, again, in case I manually changed it.
So, no “fix” per se, but I do get utility out of HA’s automations.
I’m away from my system but happy to share code snippets later if anyone is interested.
A couple automations. One requires the Workday component to be configured, and refers to my specific ecobee mode. Also, my automations may not be configured in a traditional syntax ("-alias:…") so adjust as needed for your configuration.
Warm up the house in the morning, if its a work day (skip holidays as configured by Workday component), which is something ecobee’s schedule doesn’t account for. Note, this doesn’t seem to change the actual comfort setting, as it doesn’t change the sensors involved, but it does seem to honor the temperature range of the comfort setting. It works for me in my case. ymmv
- alias: "ecobee Good Morning mode"
trigger:
platform: time
at: '05:45:00'
condition:
condition: state
entity_id: 'binary_sensor.workday_sensor'
state: 'on'
action:
service: climate.set_hold_mode
data:
entity_id: climate.thermostat
hold_mode: smart4
“Resume” knocks ecobee off a hold mode which can be helpful at various times during the day in case someone set a hold temperature:
- alias: "Resume ecobee Program"
trigger:
- platform: time
at: '08:10'
- platform: time
at: '17:00'
- platform: time
at: '20:50'
action:
service: climate.ecobee_resume_program
Thanks for this, it’s taken me a while, but I’ve managed to get to where I think I want to be. I have a script for each of my hold modes, and I call them via automation. My schedule is pretty routine, so my main purpose for setting modes, is if I maybe leave for work 20 minutes, early, I can set away before the ecobee schedule kicks in, or the same with coming home early, I can set it back to home. Lastly I use it as part of my good night routine to kick off sleep mode if I go to bed early.
The only thing (very minor) that was bugging me, is that if the ecobee was already in home mode, and I came home it would put it in “home hold”, my ecobee is set to hold until next schedule, so it’s not a big deal. Temps are the same, etc. But… It just annoyed me to walk by and see the Hold on the screeen.
Then today it dawned on me, just needed a condition in my script.
I have not tested the condition part, but I’m pretty confident that it should work.
My theromostats have the same schedules, so I only checked one for the condition. But if they had different scheduled I guess you’d just want to have a script for each one.
Made a slight change to the conditions for home and away. Realized that climate_mode and hold_mode were different, so it would not set back to home regardless of hold_mode with my previous settings, if my schedule was currently for home. This should fix that.
Has anyone been able to figure out if it is possible to switch the mode on the ecobee to Sleep? From what I can tell here and by implementing this on my own, the set_hold_mode only holds the thermostat at the specified sleep temperature, but does not actually switch the mode on the thermostat to sleep. As another user mentioned, the ecobee can be set to use different remote sensors for different modes. Using the set_hold_mode function, the thermostat does not look at the sensor settings.
Well I guess I was wrong. The thermostat took a while to adjust and the screen did not reflect the correct temperature, but it is definitely cooling based on the specified sensors.