Ecobee thermostat preset modes not working

[yeahme49]

The problem

As mentioned here and in other forum posts, with Ecobee thermostats if you use 'away' for the preset mode it puts it on an indefinite hold, but if you use 'Away' it uses the hold preference setting on the thermostat itself.

I have some automations that set the preset mode to 'away' because I want it to stay in away mode until I change it. Starting with HA 2024.1 I now get an error with those automations 'The preset_mode away is not a valid preset_mode: Home, Away, Sleep'.

I'm assuming this is due to this https://github.com/home-assistant/core/pull/105745. Is there a way to override this change to get my automations to work?

What version of Home Assistant Core has the issue?

core-2024.1.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Ecobee

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @marcolivierarsenault, mind taking a look at this issue as it has been labeled with an integration (ecobee) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ecobee can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign ecobee Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

ecobee documentation ecobee source _{^{(message by IssueLinks)}}

[afxefx]

Same issue here, broke most of my ecobee automations cause I use the valid preset 'away' which holds indefinitely as mentioned above. Rolling back until resolved.

[schmuy]

Same issue here.

[natedreger]

Yep, been having this issue for the last few days. Home, Sleep and Away give the same error, other presets are fine.

Rpi 3 Core 2024.1.2 Supervisor 2023.12.0 Operating System 11.4 Frontend 20240104.0

[mikesalz]

Samesies

[geekofweek]

Ah, this one again. It comes up every once in a while where the Away indefinite hold gets "fixed" from not working.

I think there are probably a couple of ways to handle it.

• Remove the case sensitivity from the overall climate mode validation check.
• Hard code lowercase home, away, and sleep presets into the Ecobee list of valid presets. They will always be present on all Ecobee devices.
• Go back to the wayback old way of doing things with an away switch / toggle that would turn on the indefinite away hold.

[geekofweek]

Just as an FYI, rolling back the climate init.py to this version will resolve the behavior for now, it removes the validation check which is what causes the issue. It looks at the list of presets that Ecobee provides and considers away not the same thing as Away.

Container file location:

/usr/src/homeassistant/homeassistant/components/climate/__init__.py

[rjmcfadd]

Is this going to be fixed or should I start looking for a different solution to setting the Ecobee to away mode and keeping it there?

[mikesalz]

I changed my scripts to use uppercase presets and it seems to be working now. I am on 2024.1.5. But it sure would have been nice if the dev had provided any kind of response.

    - service: climate.set_preset_mode
      data:
        entity_id: climate.downstairs_ecobee
        preset_mode: 'Away'
    - service: climate.set_preset_mode
      data:
        entity_id: climate.upstairs_ecobee
        preset_mode: 'Away'

[afxefx]

@mikesalz you are correct that your change will function with the new mode validation in place but the hold that is placed on your ecobee will follow your schedule that you have set up while "away" would remain held indefinitely. I assume this is fine for most people but the problem arises when you want more granular control outside of the ecobee schedule, which was present prior to the mode validation implementation.

For example, my use case is I have an ecobee downstairs and one upstairs. If I go upstairs to my office and my wife isn't home, the downstairs ecobee is set to "away" and only removed when I close my office door and go back downstairs. Same thing happens to upstairs when I go back downstairs since we don't frequent the upstairs very often I basically run it manually with the 'away' preset. If I have company staying upstairs, I enable "guest mode" in HA and let the ecobee schedule take care of things.

[mikesalz]

@afxefx Very interesting. I didn’t totally follow that until I tried some experiments with my own system. I set my downstairs to Away using the ecobee app and upstairs to Away using the HA preset. Sure enough, it was interpreted differently by the app.

Native app away shows as “Away for now”:

But HA away shows as a hold until my next scheduled ecobee change:

[genelody]

Same problem here. Rolled back to 2023.12.4 to get my Ecobee automations working again.

[mikesalz]

@marcolivierarsenault can you please provide your thoughts on this issue?

[afxefx]

He is no longer a maintainer(I saw he replied to another issue ticket and linked to discord) so we'll have to wait until a core dev gets time to look or someone else takes over as maintainer.

[MishaelRosenthal]

Same problem here. Rolled back to 2023.12.4 to get my Ecobee automations working again.

Thanks, that worked for me too. Hopefully there will be a permanent fix soon.

[Boh1]

It's unfortunate that this integration doesn't just leverage the existing 'Set Hold' capability in the Ecobee API to implement an 'indefinite away' . It's been there since API Version 1, and would allow 'away' to function as desired by several of the commenters.

[alexsydell]

It's unfortunate that this integration doesn't just leverage the existing 'Set Hold' capability in the Ecobee API to implement an 'indefinite away' . It's been there since API Version 1, and would allow 'away' to function as desired by several of the commenters.

That's exactly what my change linked above does.

[Boh1]

It's unfortunate that this integration doesn't just leverage the existing 'Set Hold' capability in the Ecobee API to implement an 'indefinite away' . It's been there since API Version 1, and would allow 'away' to function as desired by several of the commenters.

That's exactly what my change linked above does.

Fantastic! (Sorry, didn't scan the PR.)

Thanks for this - you are way ahead me.

[MishaelRosenthal]

Is there any progress with landing the changes?

[afxefx]

Is there any progress with landing the changes?

Not that I've seen but you can replace the entire __init__.py file in the climate component as mentioned above or you can just comment out the line responsible in homeassistant/components/climate/__init__.py which is line 708 at the time of this response:

@final
    async def async_handle_set_preset_mode_service(self, preset_mode: str) -> None:
        """Validate and set new preset mode."""
        #self._valid_mode_or_raise("preset", preset_mode, self.preset_modes)
        await self.async_set_preset_mode(preset_mode)

Tested this yesterday after upgrading from 23.12.4 to 24.1.6 and all of my ecobee automations worked as intended but still had to roll back due to ZHA issues with Aqara motion sensors.

Reference: https://github.com/home-assistant/core/blob/dev/homeassistant/components/climate/init.py#L708

[Mr5Picker]

Looks like as of a recent update, a new preset is available called "away_perm" but it does not appear to be fully implemented as selecting it does not force an indefinite hold. Anyone else notice this?

[schmuy]

Just wondering if there are any updates on this

[burnski666]

also checking in. lowercase away and away_perm still dont hold indefinite

[Boh1]

Just wondering if there are any updates on this

Looking through the PR, it seems that @alexsydell is pushing hard to get this across the finish line. Here's hoping!

[alexsydell]

This is fixed starting in 2024.4. Update your automations to use away_indefinitely where you previously used the lowercase away. The new preset will show up in the UI as well.