I am currently testing a flow that has multiple 'eztimer' nodes in it. These work great for scheduling something to run once a day, but as soon as they have triggered for the day, they won't trigger again until the next day.
For testing, this is a little too long to wait, so looking for a way to reset a node's internal state, even if it is a little brutal.
I have tried sending it a msg.reset but the node doesn't handle them. Restarting node-red doesn't reset them (nor should it). Changing the time in the node properties only changes the next day's scheduled time. The only workaround I have at the moment is to delete the nodes and re-wire them into the flow and set their properties again. Yes, I could inject msgs to simulate a trigger, but given this is for feeding animals, I want to be sure that the flow and the nodes work end-to-end before I put it into 'production'.
Is there a way to reset a node, or even all nodes to help with testing (I could then use a function to continuously inject new schedules into nodes to have them trigger within minutes).
Perhaps I need to temporarily hack the node to respond to a message and 'restart the schedules'.
Are you saying that if you set the trigger time to a point in the future that it does not re-trigger when that time is reached? If so then I would class that as a bug in the node. A node-red restart should certainly cause it to trigger at the new time, even if it doesn't without the restart.
The node has the ability to force it to send its message by sending it a trigger, which can be useful in testing.
Finally of course, if you change the system time and restart node-red it should do it the configured system time.
Yes, if the node has already triggered for today and I update it to trigger at a later point that day, it won't; it will wait that new time tomorrow. e.g. if it fired at the scheduled time of 12:00, and I then updated it to fire at 13:00 (either via the node editor or via a message) it would wait until 13:00 tomorrow.
Now that you say it, it does appear to be a bug or least unexpected behaviour - I'll raise question on guthub. For example BigTimer does trigger again the same day. But I can't use it since it doesn't allow me to programmatically configure the on/off times from the dashboard UI with enough granularity.
I would like to avoid sending it message to force it since I want to be sure that it actually does work reliably on the timer. Call me paranoid, but it is for unattended feeding when we are away from home for a day, so I wanted to be sure!
I had forgotten about the possibilities of time travel to solve it though!
Disconnect it from the internet if you do that as otherwise it will likely return you to the present without waiting for you to pull the big lever and make the appropriate Dr Who noises.
