Setting Ecobee hvac_mode

I’m trying to set up an automation to change the Ecobee hvac_mode, not the away mode, based on current external temperature. I’ve got OWM running, and it’s pulling environmental metrics with no issue, but I can’t figure out the right method to get the automation to trigger.

This is my current config, and it’s super basic, and probably wrong on multiple levels…ugh…

- alias: Turn Cool On
  trigger:
    platform: numeric_state
    entity_id: sensor.openweathermap_temperature
    above: 32
  action:
    service: climate.set_hvac_mode
    data:
      entity_id: climate.downstairs
      hvac_mode: cool

Any help on this is much appreciated.

Trigger the automation manually (Configuration > Automations > Execute). It will skip the trigger and simply execute the automation’s action. If climate.downstairs is set to cool then we know the action works properly and the problem might be due to the trigger.

A Numeric State Trigger will trigger at the moment the entity’s value increases above (crosses) the threshold. If you are currently testing this automation while the sensor is already above 32, the automation will not trigger.

Hmmm…interesting. So I just went an checked the thermostat, and it’s on cool mode. Checked the log, and it looks like it happened a few minutes after I posted this thread.

Is there some delay in the Ecobee API functionality that I’ve overlooked? I see OWM pulling metrics as expected, and I see the Ecobee state updated as expected, but I’m guessing the actual automation trigger just took a while to fire off?

Check Logbook to see when the automation was triggered (or Configuration > Automations and look at Last Triggered under the autoamtion’s name). It should be the precise moment when you manually triggered the automation.

If the thermostat responded some time later, that difference represents the delay of propagating the command via the cloud service.

BTW, ecobee thermostats support HomeKit. If you use the homekit_controller integration, commands between Home Assistant and the thermostat are local and instantaneous (i.e they don’t use ecobee’s cloud service). However, it’s my understanding (because I don’t actually own an ecobee thermostat) that you can control a bit more of the thermostat’s features via the ecobee integration than the homekit_controller integration. Nevertheless, for fundamental activities like setting temperature, hvac_mode, etc the homekit_controller integration is adequate.


EDIT

If you are ever curious about how a given integration communicates, its documentation will specify it in the “IoT class” field.

For example, this is homekit_controller:
IoT class: Local Push

This is ecobee:
IoT class: Cloud Poll

The terms are defined here: Classifiers

  • Assumed State: We are unable to get the state of the device. Best we can do is to assume the state based on our last command.
  • Cloud Polling: Integration of this device happens via the cloud and requires an active internet connection. Polling the state means that an update might be noticed later.
  • Cloud Push: Integration of this device happens via the cloud and requires an active internet connection. Home Assistant will be notified as soon as a new state is available.
  • Local Polling: Offers direct communication with device. Polling the state means that an update might be noticed later.
  • Local Push: Offers direct communication with device. Home Assistant will be notified as soon as a new state is available.
1 Like

Ecobee API is very slow. It is not a local API so relies on the Web. I have an automation that controls the fan and mode depending on temperature on different floors as well as if windows are open and it is very slow in responding sometimes.

1 Like

I’m, unfortunately, not that familiar with the homekit integration, or that particular ecosystem in general. Does the homekit_controller integration rely on any external equipment, or can it be leveraged to interact with homekit-capable products without the external middle-man? Also thank you for that classifier entry. I didn’t even see that on the integration page, and that’s a great piece of info going forward.

Let’s begin by describing how HomeKit is used without Home Assistant. Apple uses the term “accessory” to describe a device that can talk “HomeKit”.

Imagine you own an Apple device like an iPhone or iPad or HomePod. The latest versions of iOS already have the Home app installed (the app that manages HomeKit accessories). You buy a HomeKit accessory (like an ecobee thermostat) then use the iPhone or iPad to scan the accessory’s HomeKit code (printed on the device itself and/or an accompanying sticker). If you can’t scan it, you can enter its code manually. That “pairs” the accessory to the iPhone. All HomeKit communications between the accessory and the iPhone take place on your local network and require no cloud service or additional hardware. Ideally, the iPhone/iPad/HomePod you used should remain at home so it can serve as your “HomeKit Controller”, especially if you have created rules such as turning accessories on/off at certain times.

What Home Assistant’s homekit_controller integration does is replace the iPhone. You register each new accessory to Home Assistant and not to any iPhone or iPad you may have. Home Assistant serves as the “HomeKit Controller” in your house. To pair the accessory to Home Assistant, you have to manually enter its HomeKit code (i.e. you can’t scan the code).

If you have a HomeKit accessory that is already paired to an iPhone or iPad, you first have to un-pair it before you can pair it with Home Assistant. The un-pairing procedure varies from one manufacturer’s device to another. For example, I have several ecobee Switch+ devices and you press a button for 5 seconds and an interactive voice menu offers several choices including one for “Reset HomeKit”.

All of my ecobee Switch+ devices are paired to my Home Assistant instance via the homekit_controller integration. As a result, each switch’s motion, light, and temperature are reported as sensors and the device itself is controllable as a switch. All sensor data and switch commands communicate instantly via my local WiFi network.

4 Likes

I set my automation trigger to Time Pattern every 15 minutes

minutes: /15
platform: time_pattern

then I set and conditions such as a time range, outside temperature range, and zone (so that it only activates if I’m home) and then I set the action with the following:

data:
  hvac_mode: heat_cool
  target_temp_high: XX
  target_temp_low: YY
entity_id: climate.thermostat
service: climate.set_temperature

Replace XX and YY with the desire temperatures.

2 Likes

How does a Time Pattern Trigger address the OP’s issue of slow cloud communications?

Ok that makes a lot more sense. And if I’m following the logic and functionality, I should be able to parse the functions that need more immediate actions(hvac mode changes, thermostat temperature changes) via the homekit_controller integration, and use things that aren’t time-sensitive through the climate.* integration? ie: it’s not an either/or solution?