Using Customizations to create generic flows

Third party integrations Node-RED
1

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.

Old Flow
Old Flow1164×473 40.9 KB

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.
E.g.

input_select.fan_office:
  fan: fan.office_fan

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 {{data.new_state.attributes.fan}}

New Flow
New Flow988×123 9.09 KB

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…

2

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 :slight_smile:

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.

3

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 input_select configuration

fan_office:
  name: Office Fan
  options:
    - low
    - medium
    - high
    - "off"

And this is the button template I am using (requires custom button-card)

  fan_toggle:
    template: standard
    icon: mdi:fan
    tap_action:
      action: call-service
      service: input_select.select_next
      service_data:
        entity_id: entity

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).

As the 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.

4

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.