I deleted a previous message. Your work around is great actually. I ran the standard set_preset_mode to home. Then I added a 5 second delay and ran your resume code. That took the hold off, and left it in home.
Thank you for the workaround.
Funny, I received your original post in an email and was thinking “I am doing exactly what he is describing.” So yeah, I also want ecobee to set sleep mode etc. on its own. I’m just forcing it into away mode when I leave the house, and then forcing it back into its native schedule when I return. Glad it’s working for you now!
Your reply sounds great, but unfortunately doesn’t work for me. I am trying to figure out how to set the away mode, AND be able to revert to the schedule while I’m away. Because the away mode is an indefinite hold, my house won’t be preheated, or even begin heating, until I arrive home, and/or that away hold is turned off. I could programmatically turn off, IF I knew what the current ecobee programmed state was, but, that functionality/information seems to have been removed. It worked perfectly for me before 0.96 and 0.97. I am very disappointing in the recent changes. The best idea I can come up with, is to create a custom climate mode simulating an away mode. Anyone else have any ideas?
I’m making it work, but I do agree that it worked perfectly before. I think not having the prewarm function is really going to suck in this new england winter.
I’m somewhat new to HA, so I don’t know if there is someone to message, or do we not get any say.
I submitted a GitHub issue report with the author. We’ll see what kind of a response I get. A work-around, might be to create an additional climate mode, set up the same as your regular away mode, and then call that climate mode in your script, instead of the default away mode. I haven’t tested that theory yet.
This is what I found with my ecobee, hopefully this will give you what you need:
{"preset_mode":"away"}
results in persistent away hold, which survives changes in the ecobee program schedule; whereas
{"preset_mode":"Away"}
puts the thermostat into away hold, but only until the next schedule change. This discovery was purely by luck - my ecobee reports three states in Developer Tools > States:
preset_modes: Home,Away,Sleep
and I just used copy/paste in my coding to test the various states, which resulted in non-persistent behaviour for all three (which was not what I was expecting! 
).
2 Likes
What version of Hass.io are you running. I tested mind, and the capital “A” did nothing (no hold was set at all), only the lowercase “a” sets the persistent away mode. Mine is v. 0.97.
@c.dawg
I’m running HomeAssistant 0.97.1 in a docker container (image pulled from homeassistant/home-assistant:latest) on Ubuntu 18.04 LTS. To double check my results I just created a test schedule on my ecobee as follows:
Then I ran the following automation at 12.45pm:
Result on my ecobee at 12.45pm is as follows:
Result on my ecobee immediately after the schedule change at 1pm is as follows:
Temporary hold wiped out.
Next I changed my automation to use lowercase “away”:
…and I ran the automation at 1.15pm. Result on my ecobee immediately after the automation ran is as follows:
This remains unchanged on the ecobee at 1.40pm, showing that the away hold survived the 1.30pm schedule change successfully:
Here are the states for my ecobee as reported in HA:
FWIW I always run the ecobee in Auto mode, as it controls both heating and cooling (AC).
Ugh … there must be something different between your setup, and my Hass.io, because using the capital “A” doesn’t set any kind of a hold on my Ecobee at all. I am very disappointed with the recent changes. I used to have full interaction with my Ecobee, and now it seems very restricted.
I’m guessing it’s an operating system or python variance, rather than Home Assistant itself. But it might be different incarnations of ecobee, I guess. Here’s my system info, as of today, perhaps it helps you determine what’s different between mine and yours:
According to the notes, it looks like they may have reverted the behavior in .98. I"m going to wait for a couple of days to see if there is a point release immediately, and then install. Will update on here after I do.
I’ve updated, and it does not seem to have changed the hold state.
Something else I’ve found is that if I set the ecobee to off, and turn it back on,it will default to Heat instead of the last state that it was in.
I’m going to figure out how to put in a ticket.
I noticed that one of my automations was not working, and finally today tracked it back to a new case sensitivity issue with my ecobee. In the below condition, the “A” in Away was previously lowercase. It worked fine until a recent HA update. Not it only works with a capital A.
condition:
condition: or
conditions:
- condition: template
value_template: "{{ state_attr('climate.downstairs_ecobee','preset_mode') == 'Away' }}"
- condition: template
value_template: "{{ state_attr('climate.upstairs_ecobee','preset_mode') == 'Away' }}"
My workaround for preset_mode: Away being permanent was to create a custom preset mode called “Economy” that acts as a temporary away mode. Of note, you can now enter custom comfort settings by name, rather than “smart1, smart2, etc.”
Sorry to drag out an old thread, but this seems about as good a place as any to mention this:
I’m also seeing the same behavior with holds on Away. If I use a capital A in Away, it holds until the next scheduled change, but a lower case a in away holds indefinitely.
In my case, I’m trying to setup an ExtendedAway mode, and DO want it to persist past the schedules, but can’t make it. It feels like a better way to deal with this would be to have a flag we can set when we call climate.set_preset_mode. Other smart home platforms I’ve used let you decide when you call the mode.
I trolled through climate.py a bit trying to see if I could figure it out, but gave up.
Anybody else have any ideas?
1 Like
Fast follow-up here with my solution. Far from how Ecobee was intended to be used, but I’ve been able to set any mode I want, and make it persist, by setting bespoke vacations.
Mostly I was using these extended aways for multi-day away periods, like a weekend away, or an overnight business trip, so this isn’t really that far from what I wanted. I use the ecobee.create_vacation method without a start or end time, and it automatically sets for 14 days. My programming already predicted my return(proximity), so at the right time I simply remove that vacation with delete_vacation.
Seem to all work fine.
