Ok thanks. I’ll give it a try on the weekend
So, I implemented a nice version and I am going to submit a pull request later (especially since I haven’t looked into any extra work I should do like improving the unit tests). Most of my work is an extension of Duoxillian’s, but since I’m in the process of learning how to use git I just copied his code for now instead of actually working off of what he did. But for now you can grab the code from my ecobee_hold branch if you are interested.
Ecobee comes with 3 climates by default (home, away, sleep), but you can add a lot of them (I don’t know what the limit is). Whatever name you give them doesn’t matter, but you can create a hold with them by setting the hold mode to “smart1”, “smart2”, etc…
I am also working on vacation support within HA, but that will rely on getting a pull request in to python-ecobee-api first.
Very nice! ok, I will definitely try before the weekend now. So I just clone your branch into the current location of the ecobee component?
yeah, just be aware that any updates to HA will override anything you put in those folders, so feel free to experiment, but the earliest this can make it in is 0.38 at this point
or you could follow this
https://home-assistant.io/developers/component_loading/
but I don’t think it’ll work due to the changes in helpers/state.py
Was this updated in 0.38 or is it coming in a future release? Thanks
As a new Ecobee customer, I found it difficult to follow some of these threads. While this one is a bit old, I felt adding some closure could help other new users - so, as of 0.46 (tested version); Yes.
Hold modes are implemented without custom components simply by calling:
- service: climate.set_hold_mode
data:
entity_id: climate.ecobee
hold_mode: 'sleep'
1 Like
Just found this entry because my ecobee was not accepting the names of any of my custom “comfort settings” (like “Good Morning”) when I tried service calls from the front end. Turns out if I use “smart4” it works! (On the ecobee web site, my “Good Morning” comfort setting has a 4 icon next to it.) Can this information to use "smart_X_"be added to the documentation, or is my own custom name “Good Morning” supposed to work?
The “climate.set_hold_mode” works great for pulling in the correct temperature. However, it does not actually change the mode of the thermostat. Different modes can use different sets of remote sensors. This functionality is lost with the current home assistant implementation.
That would be a limitation on the ecobee side.
I’m actually not sure if you can remotely change the sensors that are being used.
If we could just change the mode it seems that everything would work seamlessly. Is there a reason for the implementation of a “set_hold_mode” instead of a “set_mode”? Is that an ecobee limitation or a home assistant limitation?
My understanding is that you would have to make a complete scheduler, which is significantly more complicated and not something anyone wants to undertake (or it would be done 
)
The Ecobee has a list of climates, and whenever you enter a period in the schedule it references the climate list and takes all of the current settings (and then applies any holds/events on top of it). There is no way in the API to set the current climate without changing the schedule. There is no way to change the list of active sensors without either changing the climate or the schedule.
Not sure I understand whats not working for you with set_hold_mode. I use it to pick my Good Morning Comfort Setting, which is configured on my ecobee to use only certain sensors. Isn’t that what you’re looking for?
Use home assistants “set_hold_mode” function with your “Good Morning” setting. Then go check your ecobee thermostat (via the ecobee app or it’s physical interface) and I believe you will see that it is using different sensors than you expect. (assumes the Good Morning setting uses a different number of room sensors than are being used when this experiment starts)
yea i agree. this has been working for awhile for me…
bedtime:
alias: "bedtime"
sequence:
- service: homeassistant.turn_on
entity_id:
- light.bedroom
- service: homeassistant.turn_off
entity_id: automation.doorbell_motion
- service: homeassistant.turn_off
entity_id: automation.plex_spy_notification
- service: homeassistant.turn_off
entity_id: automation.arrive_home
- service: climate.set_hold_mode
entity_id: climate.ecobee
data:
hold_mode: 'sleep'
- service: script.say_sonos
data_template:
volume: '0.50'
where: 'living_room, media_player.basement, media_player.bedroom'
what:
- delay:
seconds: '60'
- service: script.watch_tv_bed
- delay:
seconds: '300'
- service: scene.shut_down_houseOk. Now that I look closer you are right. I’m not getting exactly what I thought I was. I don’t know about the sensors being used, but the thermostat clearly is just holding a temp.
Did you ever verify if this is working as expected. I’d like to set my mode to sleep when I go to bed, away, when everyone leaves, and home when anyone gets home.
I also want the hold mode to be set to until next schedule.
I have a pretty standard schedule, so the ecobee schedule itself is pretty good, but if I leave early, why not put it into way, and if I come home early, why not just put it to home vs waiting for the motion sensor to set it as home, etc.
Bedtime is probably the one I care most about, I don’t want to wait until ecobee thinks I’m in bed, I want to tell it I’m in bed with my goodnight routine.
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.
No rush, but I’d love to see some code snippets.
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
1 Like
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.
ecobee_resume_mode:
alias: "Resume Ecobee mode"
sequence:
- service: climate.ecobee_resume_program
entity_id:
- climate.downstairs
- climate.upstairs
ecobee_home_mode:
alias: "Ecobee Home Mode"
sequence:
- condition: template
value_template: "{{ states.climate.downstairs.attributes.climate_mode =! 'Home' }}"
- service: climate.set_hold_mode
entity_id:
- climate.downstairs
- climate.upstairs
data:
hold_mode: 'home'
ecobee_away_mode:
alias: "Ecobee Away Mode"
sequence:
- condition: template
value_template: "{{ states.climate.downstairs.attributes.climate_mode =! 'Away' }}"
- service: climate.set_hold_mode
entity_id:
- climate.downstairs
- climate.upstairs
data:
hold_mode: 'away'
ecobee_sleep_mode:
alias: "Ecobee Sleep mode"
sequence:
- condition: template
value_template: "{{ states.climate.downstairs.attributes.climate_mode =! 'Sleep' }}"
- service: climate.set_hold_mode
entity_id:
- climate.downstairs
- climate.upstairs
data:
hold_mode: 'sleep'
ecobee_worker_mode:
alias: "Ecobee Worker Mode"
sequence:
- condition: template
value_template: "{{ states.climate.downstairs.attributes.climate_mode =! 'Worker' }}"
- service: climate.set_hold_mode
entity_id:
- climate.downstairs
- climate.upstairs
data:
hold_mode: 'worker'
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.