I just found something really useful and wanted to share it with the community.
I have a use case when an input_select changes values I want to compare it to the existing value of a fan. In my implementation I have 7 pairs of inputs and fans that need to follow this pattern. My original flow had 7 state change triggers followed by 7 get state nodes as I needed to specifically match each input_select to the correct fan.
Then I discovered that I can add my own custom attributes to an entity in customize.yaml. For the 7 input_selects, I added a custom attribute called ‘fan’ that contains the entity id of the fan that each input corresponds to.
In my new version of the flow I have a single state trigger with a substring criteria of
input_select.fan and I can get the matching fan node by passing the custom attribute to the entity_id of the get state node using a simple mustache template
Not only does this simplify the existing flow, it also means that were I to add another input_select/fan combo I don’t need to update the flow.
Off now to do the same thing with a bunch of door sensors and lights…
yep, you can store to the object which then travels with a message whatever you want. Either in HA or in NR.
Anyway thanks for the idea. Most obvious/simply solutions are most hard to invent
Out of curiosity if you don’t mind: why do you comparing input state with current state? Maybe you indeed have reasons. But I can see often logic: if light on is requested, then enable it only if it’s turned off.
IMO in most cases such condition is not needed since sending turn on to already enabled device dies nothing.
Also I’m not sure if such a testing of state is parallel-safe. I mean if it cannot fall into race condition.
I am comparing the state of an
input_select entity with the state of a
fan entity. In my UI, I have a custom button that toggles through the input select, and this flow is used to update the fan speed to match the value of the input_select.
Here’s a sample of the
name: Office Fan
And this is the button template I am using (requires custom button-card)
When the button is tapped, it moves the
input_select to the next value. That triggers the flow and sets the fan speed to match (if the fan is not already in that speed range).
I have a corresponding flow that sets the
input_select value to match the fan speed when the fan is changed by some other means, (manual switch, voice command, etc).
input_select can update the
fan and also the
fan can update the
input_select, I check the value prior to changing the target to prevent endless loops.
Yeah… this is the reason.
Maybe you can prevent it by checking the user who triggered the message. I mean either by person through GUI, NR automation or physical device state change. So NR shouldn’t process state change which has been already triggered by NR. Just guessing.