Possible to build a Node-RED timer flow that survives reboots/updates?

The use case is this: I’d like to put an NFC tag on my furnace that I tag when i replace the air filter, such that it sets a 90 day timer and reminds me to change out the filter after 90 days elapses.

I know how to build a simple Node-RED flow that will trigger from an NFC tag and count down a few hours or even days. What I can’t quite figure out though is how to have it work reliably across a long time frame such that it survives reboots/updates without resetting.

Is this possible in Node-RED or do I need to get into YAML configs?

Use a datetime helper in HA then check it from NR. They can be created from the HA UI under Confiugration > Helpers

You could try this. I’ve had no problem storing numbers in node red long term. I’ve found context storage to survive reboots and even several version up dates. You need to first enable context storage in settings.js

This is a modified counter that has been very stable. I am also not a coder so maybe run this along side the ha helper.

You can set the date by entering yyyy-mm-dd. It will convert it to a timestamp and store it. Set the inject to a time for it to check everyday. If the timestamp for today is >= the stored value it will send on otherwise off.

[{"id":"6aac76c5.ad1b88","type":"inject","z":"d6a46901.ebee1","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"2022-04-16","payloadType":"str","x":310,"y":780,"wires":[["9fa0724c.c50e68"]]},{"id":"9fa0724c.c50e68","type":"function","z":"d6a46901.ebee1","name":"Convert to timestamp","func":"p = msg.payload;\nmsg.payload= Date.parse(p);\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":560,"y":780,"wires":[["1376ad87.877e72"]]},{"id":"1376ad87.877e72","type":"change","z":"d6a46901.ebee1","name":"set timestamp","rules":[{"t":"set","p":"topic","pt":"msg","to":"set","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":800,"y":820,"wires":[["d70f06ec.63d5d8"]]},{"id":"d70f06ec.63d5d8","type":"function","z":"d6a46901.ebee1","name":"date checker","func":"var date_time = context.get(\"future_date\"); //change \"future_date\" for each instance\n\nif(msg.topic == \"set\") {\n    date_time = msg.payload;\n} else if (msg.payload >= date_time) {\n    date_time_now = \"on\";\n} else {\n    date_time_now = \"off\";\n}\ncontext.set(\"future_date\", date_time); //change \"future_date\" for each instance\nnode.status({ text: date_time_now });\n\nmsg.date_time_now = date_time_now; \nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":955,"y":860,"wires":[["5a6122b9.1598fc"]],"icon":"node-red-dashboard/ui_dropdown.png","l":false},{"id":"cdfb7286.5abc48","type":"inject","z":"d6a46901.ebee1","name":"Set daily check time","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":330,"y":860,"wires":[["d70f06ec.63d5d8"]]},{"id":"5a6122b9.1598fc","type":"debug","z":"d6a46901.ebee1","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"date_time_now","targetType":"msg","statusVal":"","statusType":"auto","x":1140,"y":860,"wires":[]}]

https://nodered.org/docs/user-guide/context#saving-context-data-to-the-file-system

1 Like

You can also try the stoptimer-varidelay node.
You can set your 90 days (you’ll have to do some math as it only accepts units in milliseconds, seconds, minutes or hours). It has a feature to remember the time left over NR resets/reboot/etc. Works well for me (then again, I’m biased as it is ‘my’ node) and I’ve had positive feedback from others.

Personally I’ve never used it any delay that long … but there are others who have used it for 30 days successfully.

I can atest he’s not biased :). Varidelay works wonders ^^

I’m looking at your node now, and I’m curious if there’s a downside to using the ‘resume on deploy/restart’ option. Why is it not on by default?

There is no real downside that I’m aware of. Honestly, I try to keep the default behavior the same as the original Stoptimer.

great, thanks for the reply