Checkfirst for call service node before changing state

I am currently moving all my scripts drom Domoticz to NodeRED (in combination with Home Assistant).

I have a lot of events that set a state using the call service node. It is not clear to me how HA behaves in case nodered is triggering a state which is already active. For instance the home status entity (home, away, vacation, sleep, etc) is swiched based on some rules. Sometimes the status is already “sleep”, but nodered also sets it to sleep. Does this mean that the sleep state is activated again (meaning it also triggers the state nodes that i use in other nodered flows for automation)? Or is the call service node first checking cirrent state befor updating (this was a setting in domoticz, called checkFirst() )?

Of course i could add a Current state node upfront the Call service with a check of current state. But it saves me a lot of unnecessarily nodes if this is not required

I’ve tried to find this in the websocket documentation and the forum but didn’t find anything about this. Is it perhaps a bias in my thinking as a former Domoticz (dzvents) user?

No it doesn’t
Automations only trigger if the state changes, and in this case it doesn’t change

Great thanks, good to know for the logic behind the automations!

The strange thing is is that the Call Service node fires a message on the output, also if the state is not updated in Home Assistant (because it was already in that state). Is there a way how I can prevent this message from being send?

Below is the example where I experience this. The Home status can be changed by several different events. Which means that it is sometimes changed to ‘Home’ while it was already at ‘Home’. For the Call Service node itself it is not a problem. As decribed above it is only changing something in Home Assistant in case it was not yet that status. But it is creating an output message, also if the status was not updated. Which is not what I want, because I only would like to know it in case the status is updated:

Any ideas on how to fix this? I can of course always add Current state nodes before sending the message, but this will create a lot of additional nodes (I have this behaviour in a lot of flows) and possibly traffic to the HA WS

When you have a message passing through then it will pass through.
Set up a new trigger state node instead and connect this to “Push berichtje” and disconnect it from Home status.
This means if the home status changes in the trigger state node then it will “Push berichtje”.

1 Like

Thanks, that is a good solution. The only disadvantage is that i cannot specify in the message what triggered the home state

You can use a flow variable.

1 Like