"wait until" node seems generally unreliable, especially when waiting for a timestamp

Third party integrations Node-RED
1

Hello all. I have build multiple flows using the “wait until” node. Generally there is this huge problem with this node that is imho a massive bug, but I dont think my specific problem stems from that issue.

All “wait until” nodes that are waiting for a numeric or boolean state (e.g. waiting for a specific temperature to be reached/surpassed or a condition to be true) are working fine.

However nodes waiting for a time are horribly unreliable. The way I have set them up is that I have them listen to the HA “Time” entity. (Since afaik NR does not provide a clock of its own?)

Unfortunately HA does not (afaik) provide this time entitiy as a number but as a string thus I don’t see any way of creating something that equals >= meaning if its “that time or later”. So the “wait until” node can only match the specific moment (when the string matches exactly). This is problematic as well, but would be manageable.

However: The node works if i set it to e.g. two minutes from now and stare at the debug until it triggers. If however I set it to e.g. 4 hours from now and walk away it will just not trigger but just sits there stuck on “waiting” even if its past the set time! It’s driving me insane!

Does anyone know how to

A) Have the node not be stuck on waiting after deploying
B) Create something like “>=” for a timestamp aka. “if now or later”
C) Have the node reliably wait for hours without getting stuck?
D) Have any idea on how to do what I’m doing differently/better alltogether? (Edit: Found a way. See below)

Here I my configuration of such a node

image
image509×593 15 KB

Here is the flow i’m using it in. Its just switching between the home and sleep thermostat presets at a predefined time, unless the thermostat is set to “away”.

image
image1616×226 24 KB

Thank you all in advance!

EDIT: Found a way of doing this specific flow using gates and repeating inject nodes. Seems much more reliable. But the questions A/B/C still stand, since not all examples can be solved this way.

This is how I modified the flow, if anyone needs to do something similar:

image
image1463×277 26.6 KB

2

Wait until node is not meant for timestamps. To create time conditions see the time range node in the palette. For more advanced time conditions install node-red-contrib-chronos.

1 Like
3

I see.

Very confusing that it does work in some instances but not in others - and also that the documentation does not state this to be a problem. Also found this thread promoting exactly this use uof “wait until”. Anyway…

“time-range” is good to route an incoming input depending on time, but there is no way I know of to hold the input back until a certain time and then pass it on. That is what makes “wait until” so useful.

I’ll look into node-red-contrib-chronos, thank you for the suggestion.

4

HA has several clocks, I am sure there is an RTC in there somewhere, as well as NTP lookups. HA optionally exposes ‘time’ using the Time & Date integration, which adds one or more date/time entities. Easy to add these using the UI integration.

The ‘time’ entity gives local time as a string “12:34”, however to be useful this needs to be in military 24 hour format, so OK if you live in Europe.

The ‘datetime iso’ format provides “2024-12-26T12:15:00” which is monotonically increasing and can therefore be used directly in string comparison tests.

These sensors are updated once every minute. HA does this randomly, based on the last reboot starting time, so if you are unlucky it will happen at 59 seconds past the ‘real minute’ which may possibly mean that NR flows will trigger at the minute following. However, the Wait node will still see the HA event (as long as the WebSocket has not gone to sleep) and will still run the comparison test.

Using just the sensor.time, which returns a string, we can still perform comparison tests such as >=

If you select the ‘sensor.time’ entity, and the ‘state’ property, and the ‘>=’ comparator, and then select J: expression (JSONata) in the option list, and then enter a string in quotes

“12:04”

JSONata will return a string value, which will still work. “12:04” is indeed equal to “12:04”. I have just tested this and the node fired correctly (although I only waited 10 minutes…)

The alternative to using strings would be to create a new template sensor of your own, set to numerical minutes in the day.

{{now().hour *60 + now().minute}}

This returns total day-minute time, which is both numeric and monotonically increasing. HA will re-render a template sensor every minute, so this should be good to go right out of the box. Test sensor.dayminute >= 1260.

Of course, you may want to use centi-days or deci-hours rather than dayminutes.

PS.

  1. The Wait node has the (perhaps unhelpful) habit of saying ‘waiting’ even when it is not - after redeploying a flow you must actually send in a trigger to set the node up again (even if it says ‘waiting’).

  2. Testing
    sensor.time is (string) 12:37

works just fine, so I am assuming that your node was saying ‘waiting’ but was not actually waiting.

2 Likes
5

Oh wow. That is quite in-depth. Thanks for explaning all this I’ll try to chew through it and understand / test!

Yes, my nodes were just stuck “waiting”. The fact that they just display this, even if they have e.g. been redeployed and thus reset, really is problematic - there is just now way of knowing what is really goiong on with them!

6

Well there you go learn something new everyday. I was under the impression that it didn’t work reliably. BTW cronos has a delay node that will delay to a particular time in the day and is what I use in this situation.

1 Like
7

Assuming that I am right, it is the ‘showing waiting but not actually waiting’ thing that catches most of us out at some point. The only way I know around this is to routinely send msg.reset into these nodes up front to clear them to show ‘reset’, then you can tell that they are not waiting.

8

Yeah that really is confusing.
Since this flow is controlling a pellet-powered heating with a minimal burn cycle of 2 hours I really don’t want to have to fiddle around with it to see whats going on. Needs to be fool-proof.

But I’ll def. try it on other flows!