Wait until node breaks if waiting when deploying

Lemonius · May 14, 2024, 2:10pm

If a wait until node is already waiting for something in Home Assistant, and then I make other changes in NR and deploy, then the wait until node will not respond to the thing it is waiting for any more, and so breaking the automation. It will still say “waiting”.

So any day that I’m tinkering in node red, all my flows that are already waiting for something are breaking, until the wait until node is triggered again.

Is this just how it is?

Example flow waiting for light to turn on:

[{"id":"2a88b28ea65f4c01","type":"debug","z":"deeb7742dd438105","g":"eab7355f46af5f95","name":"debug 190","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1620,"y":2720,"wires":[]},{"id":"99a2f44d1dba9582","type":"ha-wait-until","z":"deeb7742dd438105","g":"eab7355f46af5f95","name":"","server":"d4a53f14.6707f","version":2,"outputs":1,"entityId":"light.z2m_sofaceiling","entityIdFilterType":"exact","property":"state","comparator":"is","value":"on","valueType":"str","timeout":"0","timeoutType":"num","timeoutUnits":"seconds","checkCurrentState":true,"blockInputOverrides":true,"outputProperties":[],"entityLocation":"data","entityLocationType":"none","x":1460,"y":2720,"wires":[["2a88b28ea65f4c01"]]},{"id":"26fdb09e62bf8d5f","type":"inject","z":"deeb7742dd438105","g":"eab7355f46af5f95","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":1310,"y":2720,"wires":[["99a2f44d1dba9582"]]},{"id":"d4a53f14.6707f","type":"server","name":"Home Assistant Hkon","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":"30","areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"hidden","statusMonth":"short","statusDay":"numeric","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]

Biscuit · May 14, 2024, 2:17pm

Unless any particular node specifies that it is persistent over a Node-RED restart / deployment, then yes all running nodes have a habit of forgetting everything on restart / redeploy.

You do have the choice though - if you really are deploying everything (full) then yes it will impact other nodes in all flows. Modified flows is the setting I use…

Lemonius · May 14, 2024, 2:32pm

That is a good tip! I guess I’m just thrown off by the “waiting” tag. I would expect it to lose it as well.

Biscuit · May 14, 2024, 8:13pm

Interesting subject. I was motivated to dig around a bit, and the following NR discussion suggests, as I expected, that each node manages the status message itself, so it is up to the node in question to clear the status - under given circumstances.

https://discourse.nodered.org/t/node-status-clear-in-entire-flow/37477

Interestingly, deploy / restart / redeploy is not guaranteed to do anything to the status. Nodes, I read, can be coded so as to clear the status on ‘start’, which would effectively clear any outstanding status message on ‘re-start’. But they don’t have to!

Digging a bit into the code of the Node RED standard delay node (on GitHub) suggests that some nodes do execute a node.status({}) at the start, or at close. Certainly, most (?) of the standard Node RED nodes do seem in my limited experience to clear any lingering status messages on deploy / redeploy.

I am not able to see how the Home Assistant WebSocket nodes work (limited coding experience on my part) but I am guessing that the wait until node does not initialize the status on startup. Indeed, I suspect that all these node retain any status message, only clearing it when the node does so, or if the node is disabled and redeployed.

I think your options are:

live with it
ask @Kermit very nicely if ‘not clearing the status message on node deploy’ is his intended behaviour for the WebSocket nodes
raise a discussion / issue (or even fork the repository and make the code changes yourself)
use ‘reset’

This node, like many in Node-RED, will accept an input with msg.reset, which if it exists (set to any value) will trigger the node to reset. For delay nodes this clears any queue (and thereby the status message). For the wait until node, this a) clears any running timers / waits and b) puts the message ‘reset’ as the status. Sorry, but I don’t know a way to get a flow trigger based on ‘redeploy’ so you would need a ‘clear status’ inject sending ‘msg.reset’ to your wait-until nodes, and use this every time you re-deploy the flow, but it is a suggestion!

mikep99 · May 14, 2024, 9:02pm

I might be missing something here but could you use an events state node to listen for the light to be turned on?
I agree though, that the wait until node can be misleading after deploying flows…

Lemonius · May 15, 2024, 9:24am

I’m happy with the solution to selectively deploy instead of full deploy. It would be more intuitive if the “waiting” message was removed on deploy, but now I know.

I have been setting up a recurring msg.reset to combat this issue, but I didn’t like the thought of having to do that for everything. I also learned that the node will indeed start waiting again if triggered again after full deploy.

But as I said, selective deploy is the solution to keep unrelated wait until nodes running.

@mikep99 I don’t think event state node will allow me to start a flow when the light is turned off, and then continue the flow when the light is turned on again. I’m not sure. This is of course just an example. I love the wait until node.

And, regarding resetting on deploy, I made this work with the eztimer node, it can output when restarting. Maybe someone finds it helpful.

[{"id":"84c1513aef120472","type":"ha-wait-until","z":"deeb7742dd438105","g":"eab7355f46af5f95","name":"","server":"d4a53f14.6707f","version":2,"outputs":1,"entityId":"light.z2m_sofaceiling","entityIdFilterType":"exact","property":"state","comparator":"is","value":"off","valueType":"str","timeout":"0","timeoutType":"num","timeoutUnits":"seconds","checkCurrentState":true,"blockInputOverrides":true,"outputProperties":[],"entityLocation":"data","entityLocationType":"none","x":1690,"y":2760,"wires":[[]]},{"id":"4b2fef486e9c31e7","type":"eztimer","z":"deeb7742dd438105","g":"eab7355f46af5f95","name":"","debug":false,"autoname":"","tag":"eztimer","topic":"","suspended":false,"sendEventsOnSuspend":false,"latLongSource":"haZone","latLongHaZone":"zone.home","lat":"59.89453414065505","lon":"10.817413330078125","timerType":"1","startupMessage":true,"ontype":"9","ontimesun":"dawn","ontimetod":"17:00","onpropertytype":"msg","onproperty":"reset","onvaluetype":"num","onvalue":1,"onoffset":0,"onrandomoffset":0,"onsuppressrepeats":false,"offtype":"9","offtimesun":"dusk","offtimetod":"dusk","offduration":"00:01:00","offpropertytype":"msg","offproperty":"reset","offvaluetype":"num","offvalue":0,"offoffset":0,"offrandomoffset":0,"offsuppressrepeats":false,"resend":false,"resendInterval":"0s","mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true,"sun":true,"x":1520,"y":2760,"wires":[["84c1513aef120472"]]},{"id":"d4a53f14.6707f","type":"server","name":"Home Assistant Hkon","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":"30","areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"hidden","statusMonth":"short","statusDay":"numeric","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]