Question regarding using multiple messages in the same flow

I have just started using Node-Red and finding questions along by trying things out, but this one thing keeps bugging me, which I am sure there are more convenient ways to solve.

I have an automation, where I check the power draw on my washing machine and switch, depending on the power draw, to set an input_select for my washing machine to the correct status in Home Assistant (Off, Idle, Running). If it goes from status Running, a notification will be sent out.
The automation works great, but currently I have duplicated nodes, especially the node when checking the current status of my input_select.

I am thinking it must be possible to poll the current state right after the state change of the power draw and then combine both the state_changed and the current_state nodes with a Join node, but my problem is how do I then get this joined message after the Power Draw node?

Any input will be appreciated.

I think you can use this as a reference.

What about:


You set the value of the input_select whatever the value.

Then, in a second flow, with the trigger, you check whether the state is “not running” and if before it was “running”, in this case, notify.

You can get the current state straight after the state change. However, by default they both write to msg.payload and msg.data. This can be changed in the current state node so you could have it put the data in, for example, current_payload and current_data. The switch nodes that look at the current state would then need to be changed to pick up the info in these different locations.

Having said that, the trigger state gives you both the new and old state. Therefore you don’t actually need to get the current state, you can just check if the old state was “Running”. This is what @greengolfer has explained.

@michaelblight
Perfect!
This answers both my original question, which will undoubtedly come in useful in future flows, but also a neat alternative to my flow with the trigger-state node.

Thank you @greengolfer as well for the very explanatory image. I had not thought about splitting the flow up in two parts.

Although, one issue with splitting the flow into two parts and then using the trigger-state node, is that I will always have to call the service within HA to change status, even if the status is already equal to the “new state”.
Maybe I am overthinking this, but when working with software development, I always try to reduce any calls to other services.

Sure, otherwise I will be checking the current state, but that feels a lot better than actually calling a service to set the value, when it already equals the current value of the entity.

Nice one, I will definitely give that a read.