EDIT: PLEASE DO NOT PANIC! THERE IS A SUPER EASY FIX - JUST READ THE THREAD AND ADD ANY CONSTRUCTIVE FEEDBACK
This morning I saw that Node Red update to version 12.x removed the STOPTIMER node as it is not used much and has not been updated in over 5 years. This made me wonder whether there is a better, or more conventional way, of doing what I do using the STOPTIMER node.
A typical example of how I use it is to turn off something after a period of time. The delay can be reset by, for example, new motion events. If the device needing to be turned off gets turned off in some other way, the timer is cancelled so that the turn off command is not fired over the already busy Z* mesh network.
Are there better ways of doing the above without using the STOPTIMER node?
Is there a better node to use with the same functionality? I found a few that appear to be forks of this one, but they too seem to have low usage so I worry I will find myself with lots of flows using an unsupported node. In other words I am trying to reduce my exposure to the risk of needing to update a large number of nodes all of a sudden.
Edit: I am aware the STOPTIMER node can be re-installed, and I did, but now that I saw the last update was over 5 years ago, and that it is no longer installed by default with Node Red, I would prefer to adopt a more recent/supported alternative.
EDIT AFTER LOTS OF POSTS IN THIS THREAD:
As discussed in the thread below, the trigger node is a far superior node than StopTimer. I updated all my flows to use the trigger node and everything works fine. To mimic the StopTimer node minimizing any other changes you will need to set it up like this (thanks to @Mikefila@quizzical@mchinery):
This is one of my simple flows where I replaced one node for the other with no other changes. One could change the change node (see below in yellow) sending msg.payload: STOP to sending msg.reset: true to reset the trigger eliminating the need to add STOP inside the trigger node.
I am in the same boat, the update wrecked a lot of my flows because I use stoptimer pretty extensively. Interesting that Trigger works as a decent alternative, but curious to hear what others are doing to replace stoptimer and looptimer.
Same boat here too, it wrecked a bunch of my flows so I rolled back for now and disabled auto-update.
Stoptimer is pretty basic, is there a reason it needed to be updated in the last 5 years? Kind of seems to fall under the “if it ain’t broke, don’t fix it” mantra. It did what it did and it did it very well.
In addition to losing stoptimer node, after update, I have noticed that Node Red is not communicating with HA Server as it will list any entities, devices, areas, etc. Has anyone else noticed this?
It wrecked a bunch of my flows too. I had 45+ instances of stop-timer. I had started using stop-timer-varidelay a while back but didn’t update the original ones.
All I had to do was re-install stop-timer into the pallet, then restarted the NR addon. All my flows were “connected” again and working like a charm.
This does seem like an odd one to remove due to “not much use”, but at least it was a pretty simple fix.
I can’t really think of anything stop timer can do that trigger can’t. And trigger is part of the core set of NR nodes maintained by the NR team. So I guess switch to that? Unless there’s something you find you can’t do with it.
Screwed here, too. I use stoptimer in some flows that monitors a medical device. It’s a simple node that just works. Why should “no updates in five years” condemn it? There’s been no updates to the comment node either- is it next?
I missed the “Breaking Changes” because I had Auto Updates turned on and I didn’t know anything was wrong until the add-on updated itself.
I got my flows back up by re-installing the StopTimer node as per Frenck’s note on the update anyhow I plan on migrating to the Trigger node for the very reason @CentralCommand stated. It guarantees longer longevity and less trouble.
I had this issue as well. It is late, so I just restored my node-red addon to 11.1.2. I’ll get around to replacing all of my stoptimer nodes with trigger nodes this weekend, then try the update again. Fingers crossed I don’t run into the lack of communication issue again.
I’m using the stoptimer 70 times.
On the use of the trigger node as a replacement. Is my understanding that this is the correct configuration of the trigger node to serve as a one-toone replacement of the stoptimer (I was a bit confused for example between the option for the latest msg object vs the original msg object)?
I suggest you watch your tone a bit, It seems like I read this thread better than you did.
Yes the changelog and this thread both explain I can reinstall the nodes and that’s what I did.
However there are also arguments being set out that it’s better to replace it with the trigger node.
After a message hits the trigger node it blocks any messages from going through until whatever duration you put in “wait for” has passed (or until it’s been that long since it’s last received a message if you do “extend delay if new message arrives”).
When the time has passed it sends a message. If you choose “original message” then it sends the first message it received which started the delay. If you choose “latest message” then it sends the last one it received before the delay ended.
If you’re just trying to emulate exactly how stop timer worked then choose “latest message”.
