The stoptimer node has two functions. It refreshes the timer whenever it receives a new message, which is useful for motion automations; and it can start a timer when something happens, and stop the timer if something else happens.
They are very useful in motion lighting automations.
In the flow screenshot above, when the kitchen motion sensor is triggered between sunset and sunrise, and if none of the living area lights are on, the kitchen can bulbs 1 and 3 are turned on at 10% for 25 seconds, and then they are turned off. We’ll get to the turn off loop I’m using later in the post.
In this flow, every time the motion sensor is triggered, a new message is sent down the line. If that message reaches the stoptimer before the 25 second timer has ended, it restarts. This will keep the lights on until 25 seconds after the last triggered motion event. Make sure that the stoptimer duration is not shorter than the refresh duration of your motion sensor. My sensors refresh every 15 seconds, so any timer above 16 seconds will keep the lights on as long as motion is detected.
So, what if you want to stop the timer?
I have automations setup to monitor my outside refrigerator, because my knucklehead kids will leave the door cracked and it will defrost. So I thought I’d put something together to help stop that.
Here’s what that looks like:
In this flow, the top two flows monitors the refrigerator and freezer doors, the bottom two monitors the temps.
For the doors, an “event:state” node is monitoring the door state. When the door is opened, it sends from the top output which starts a stoptimer for 3 minutes. If the door remains open past that three minutes, a notification is sent to Telegram, which alerts my wife and I. If during that 3 minutes, the door is closed, it sends from the bottom output which triggers a “change” node that changes the msg.payload to “STOP”, which then is sent to the stoptimer node, and the timer is stopped and a notification is not sent.
For the temperatures, an “event:state” node is monitoring the temps of the freezer/fridge, which is then sent to a switch node. The switch node determines if the temps are equal-to-or-higher than a certain value (20 degrees for the freezer, 50 for the fridge), and if they are, to pass it on to the stoptimer which starts a 10 minute timer. I’m using 10 minutes, because the temps can temporarily rise past those values when the door is opened, and the timer gives it enough time to stabilize. If it wasn’t there, a notification would get sent almost every time the door was opened. So if the temps rise over the set value for more than 10 minutes, it’s safe to assume something is wrong.
Once the temp drops back down below the set value, the message is sent from the bottom output which triggers another change node, that will stop the timer, which again, cancels any notifications that were going to be sent.
When to use a stoptimer, instead of a delay node?
A delay node is very simple, it literally delays any messages for the duration of time that you set. There’s a few more things it can do, but as far as stopping it like a stoptimer, there is no function for this. So, when should you use a delay node instead of a stoptimer? Well, technically, you can use a stoptimer as a standard delay node if you wanted to, but I like to try to use them for their specific purpose, as it makes looking at a flow easier for me.
Lets look at another of my lighting automations.
Above is an automation used with our dining room light. In our house, the dining room light is one of those lights that just gets left on all the time, for no particular reason. I put this flow together to turn it off if there is no motion in the dining room room for 20 minutes. I have an “events:state” node checking for motion, and passing it on to a “current:state” node when motion is detected. The current state node checks to see if the Dining room light is on, and if it is, it passes the message on to the stoptimer node, which triggers the 20 minute timer. Whenever motion is detected, it sends another message, which restarts the timer, keeping the light on. When no motion is detected for 20 minutes, the light turns off. If a delay node was used here, the light would come on for 20 minutes, turn off, and then immediately come back on if motion is constantly being detected. This means the light will flash every 20 minutes, as long as someone is triggering the motion detector. So it makes sense to use a stoptimer here in the flow.
When you look further down the flow, after the stoptimer node, you see a call service node which turns off the dining room light. This then starts a 1 second delay node, which then sends to a current state node that checks the state of the dining room light. If the light is off, everything stops here. If the light is on, it loops back to the call service node to turn the light off. I started using these turn off loops when I noticed on rare occasions lights wouldn’t turn off or on correctly. Since there is no reason to stop the timer, a delay node can be used here. The delay node is stopped whenever the current state node says the light is off, and it doesn’t loop the message back around to the call service node to turn off the light. I stoptimer node could be used here, and it would work correctly and the flow would operate correctly, but it’s not “needed”. It’s sort of a “best practices” thing; its best practice to use the correct node in a specific situation.
Below are the codes for the flows if you want to mess around with them.
The code for the Kitchen motion lighting flow
The code for the outside refrigerator example. – Please note that I removed the Telegram notification node as it has all of the info to send to my bot, so you’ll need to connect this to your own notification nodes.
The code for the dining room motion automation.
Home Automation with Home Assistant and Node-RED 