Controlling a flow using entity attribute?

Third party integrations Node-RED
1

Im using HA to control a heatpump for my hottub using the gecko integration. It has an attribute: hvac_action that I what to use to control a flow. But I cant find out how to read it.

image
image414×520 33.5 KB

An old thread in the forum suggested to create a sensor, so I tried:

template:

  • binary_sensor:
    • name: “hottub_heat_on_off”
      state: >
      {{is_state(‘climate.hottub_heater.hvac_action’, ‘heating’)}}
      off

Using the template developer tool it always return false. But I dont know how to get more detailed debug info.
Any suggestions how to debug or what Im doing wrong?

2 
{{ states_attr('climate.hottub_heater', 'hvac_action') }}

Should give you the attribute.

3

Thank you so much!!! I have been pulling my hair for 3 hours. I did not know about state_attr

I made the sensor like this and it works like a charm:

template:

  • binary_sensor:
    • name: “hottub_heat_on_off”
      state: >
      {{ is_state_attr(‘climate.hottub_heater’, ‘hvac_action’, ‘heating’) }}
4

you don’t need to create a sensor in HA. With the events state node if you uncheck the Current state equals previous state the flow will trigger with any change of any of the attributes.

image
image1008×591 38.1 KB

then you can filter your attribute with a switch node

image

[{"id":"1fedceed.0fe881","type":"server-state-changed","z":"b7ef5764.977e88","name":"Heater","server":"9405c3fe.d0a6c","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"climate.hottub_heater","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","outputs":1,"output_only_on_state_change":false,"for":0,"forType":"num","forUnits":"minutes","ignorePrevStateNull":false,"ignorePrevStateUnknown":false,"ignorePrevStateUnavailable":false,"ignoreCurrentStateUnknown":false,"ignoreCurrentStateUnavailable":false,"x":190,"y":1780,"wires":[["8b9fc4f6.060958"]]},{"id":"8b9fc4f6.060958","type":"switch","z":"b7ef5764.977e88","name":"is Heating?","property":"data.new_state.attributes.hvac_action","propertyType":"msg","rules":[{"t":"eq","v":"heating","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":350,"y":1780,"wires":[[]]},{"id":"9405c3fe.d0a6c","type":"server","name":"Home Assistant","addon":true}]

If you are concerned about the flow triggering too often due to other attributes updating, add this to your flow:

image
image806×234 10 KB 

[{"id":"1fedceed.0fe881","type":"server-state-changed","z":"b7ef5764.977e88","name":"Heater","server":"9405c3fe.d0a6c","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"climate.hottub_heater","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","outputs":1,"output_only_on_state_change":false,"for":0,"forType":"num","forUnits":"minutes","ignorePrevStateNull":false,"ignorePrevStateUnknown":false,"ignorePrevStateUnavailable":false,"ignoreCurrentStateUnknown":false,"ignoreCurrentStateUnavailable":false,"x":130,"y":1820,"wires":[["8a9c1b19.d3fab8"]]},{"id":"8b9fc4f6.060958","type":"switch","z":"b7ef5764.977e88","name":"is Heating?","property":"data.new_state.attributes.hvac_action","propertyType":"msg","rules":[{"t":"eq","v":"heating","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":350,"y":1820,"wires":[[]]},{"id":"8a9c1b19.d3fab8","type":"switch","z":"b7ef5764.977e88","name":"","property":"data.new_state.attributes.hvac_action","propertyType":"msg","rules":[{"t":"neq","v":"data.old_state.attributes.hvac_action","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":235,"y":1820,"wires":[["8b9fc4f6.060958"]],"l":false},{"id":"9405c3fe.d0a6c","type":"server","name":"Home Assistant","addon":true}]
4 Likes
5

That is a neat way of doing it. Thanks a lot!

1 Like
6

Is there a difference between using an events:all node and listening to the event bus? Is using the unchecked event: state an easier way to find the listener for a particular entity/device/etc.

I’m still trying to understand the event bus and I think I am over simplifying it by seeing it as similar to mqtt.

7

AFAIK, from what I can find in debug, you can more or less achive the same with both, specially when speaking about state_changed events. I’m just used to the event state node since it’s more compact to set one or various entities in substring, I can make use of the for field too, and there’s the if state field with all the logic comparators.

The unchecked event state node does behave 95% like the events: all node. The remaining 5% is some information missing in one or in the other msg.object.

For the most part it’s enough to use the event state node but the are some scenarios where it’s unavoidable to listen to events, like, for example, when you want to know the entity’s old_state. Or when a timer ends and you want to know whether it’s been finished or cancelled, the only way to distinguish that is by listening to the event bus.

1 Like
8

this helped me a lot. thanks

1 Like
9

is it possible to call all attributes to the switch?

like: data.new_state.attributes.* (everything)
so you can make a switch node with multiple attributes and go from there

now you have to make a new flow for every attribute

10

AFAIK every time any attribute changes, a new message is sent with all the info for every field, regardless of whether every attribute changed or not, so in order to distinguish whether a particular attribute has changed, you should filter them one by one in some way…

What are you trying to achieve? could you elaborate?

11

Never mind, while documenting and taking screenshots i saw that the change node is keeping changes on that specific attribute and not specifying the attribute and then say “contains” so the node is about 1 specific attributes and not in general…

i understand now thanks