State trigger with Ecobee hvac mode change?


I’m new to the HA platform, another refugee from the decommissioning of the SmartThings V1 platform.
While I could just put the actions directly in an automation that’s enabling my AC at a particular time, I thought it might be useful to de-couple the actions that happen from state changes so that I wouldn’t have to maintain the same actions across multiple other automations. So the basic one I am trying to get going now would turn a switch on that would cause a fan to come on, when my Ecobee is set to enable the cool mode. I also am trying to get a corresponding one that would shut off that switch when the Ecobee mode is set to off.

Initially, the “on” action, seemed to work, but now it is not. I’m not clear why. Reading forum posts I suspect perhaps the cloud aspect to the Ecobee API might be part of it, so perhaps configuring my thermostat as a HomeKit device would help with that? I’m not quite sure yet where addressing it as HomeKit vs the native API would be better.

And a related problem, the off action I have not been able to get to fire, but I noticed in looking at mode values in the entity, 3 of the 4 values are not quoted, but the last value (off) is in single quotes. I wondered if that means I have to put it into the trigger config differently (match the quoting?). I am only using the GUI to generate the automations so far, because I am new to the platform. I have extensive coding background though, and am ok with YAML, so if adding some logic will work better here, that’s fine, I just haven’t learned the syntax for doing so. This is the definition for the “on” trigger right now:

- id: '1623428046907'
  alias: Auto-On with AC
  description: turns things on if the AC mode is enabled(ecobee set to cool)
  - platform: state
    entity_id: climate.main_floor
    attribute: hvac_modes
    to: cool
  condition: []
  - type: turn_on
    device_id: 39b22686bc4032bd05a41dffe8e68a7e
    entity_id: switch.wood_stove_69f
    domain: switch
  mode: single

Summerizing current issues: On state change trigger seems to not be firing, or firing inconsistantly. Off state seems to not fire at all, or is firing too often(immediately after On) or not at all (the question about the state in the dev tools showing the mode value for off, as being single quoted, but no other options are).

I am running the install ona Raspberry PI, versions are:

Hopefully that made sense! Thank you for any assistance!

Edit: I thought I should elaborate a bit more on the mode values. The dev tools shows the values of the state attributes for hvac_modes this way:

  - heat_cool
  - heat
  - cool
  - 'off'

So I’m not clear in the YAML for a state trigger checking if the state goes to off if it would be:

to: 'off'
to: off
or if it doesn’t matter. Since the one isn’t like the others, I wondered if this was significant(and I’m having trouble getting it to fire either way so far) Thanks!

1 Like

If you want the automation to trigger when the thermostat’s current state changes to cool then the State Trigger should not be monitoring the thermostat’s hvac_modes attribute.

This is what you want:

  - platform: state
    entity_id: climate.main_floor
    to: 'cool'

The value of the hvac_modes attribute is a list containing all of the operating modes the thermostat supports. It doesn’t indicate the thermostat current operating mode (that’s represented by the state value).

Screenshot from my system:

Should you want to know when your HVAC system is actively cooling, that bit of information is found in the hvac_action attribute. If it indicates cooling then your HVAC unit is in the process of cooling (as opposed to when it’s idle).

1 Like

Ah ok, got it, so that’s just the enumeration of the state. So state seems like it acts as the default property for an entity? Maybe I shouldn’t think like this, I’m mentally fitting things into object oriented coding mechanisms, as this very much seems like how this is set up. Services seem like methods and states seem like properties to me. Well, I guess that’s a bit off topic. I see where I went wrong now, thank you!

Generally speaking, an entity’sstate represents its main property and its attributes are additional properties. The state is always a string but attributes can have other types.

Services aren’t like methods. If they were then they would be part of the object.

I still use another home automation software (for about 14 years now) that is completely object-oriented where each entity has properties and methods and is based on a class that can be inherited or extended (and much more). All of it can be done via the UI. There’s nothing comparable in Home Assistant.

You’re welcome! If my reply helped to answer your original question, please consider marking my post (above) with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps others find answers to similar questions.

Services aren’t like methods. If they were then they would be part of the object.

They aren’t presented in the UI together, but they are referenced as part of the same entity, so the concept of an entity sure behaves like an object, to me. Like in my prblem, climate.mainfloor I was using incorrectly because I didn’t realize state was effectively acting as a default property. But if I look at the services associated to climate, climate.turn_off sure seems like it could be very much like a method.

The words ‘states’ and ‘services’ I would say could be considered synonyms of property and method. They just seem like they are presented separately in the UI, but they are still associated to the same entity, so it certainly behaves a lot like an object to me.

It could just be semantics and UI presentation, but I think it helps me get a handle on where to look for some of the things going forward. Well, regardless if it is actuall an instanced class behind the scenes or not, it seems a useful way to think about it to me. I’ll mark the other post as a solution.
Thanks again

Not even close. A service call behaves more like a function than a method because it exists independently of the entity. A service call like homeassistant.turn_on can be used to turn on different kinds of entities. Definitely not like an object method.

You’re forcing a round peg into square hole when you attempt to characterize entities and service calls as objects and methods. Think of an entity as a data structure and service calls as a functions that modifies the values held by the data structure. Unlike an object, the data structure cannot be instructed to do anything (because it lacks methods).

Did you ever find a solution for this? I’m trying the same…

Which bit? The first 2 replies covered what I was reading incorrectly in the states vs attributes.