Ui Countdown Timer Switch
It's always nice to automate things but sometimes automation needs some flexibility that can be triggered manually. I've created a UI node that is basically a simple switch but displays the time it was activated and turns itself off after a certain amount of time (it also displays the end time).
What is it for?
My personal use case was to activate an irrigation system outside of scheduled times, but you can obviously use it for basically everything.
Highlights
- easily activate a device for a specific amount of time at the node-red dashboard
- create just one or as many countdowns as you need
- choose between a button/dropdown layout
Your feedback is appreciated
Feel free to make suggestions or report problems at the nodes GitHub site.
Thank you!
9 Likes
Wooo - this is brilliant, I'm going to use it to make a Cooking Timer.
3 Likes
Brilliant. I will use this to trigger water changes outside of the scheduled times in my Fish Nook, once I actually build the water change routine.
( Aquarium Controller - Raspberry PI 4B Node-RED, Atlas-Scientific i2c Devices, NCD i2c Relay Board )
1 Like
Nice widget. 
Couple of things to improve:
The node has input and output but the help page (or Readme in github) says nothing about the message requirements or content of messages the node expects or fires.
The styles of items in editable list:
It would be nice if default size fits without need of scrollbars.
Configurable values - the unit of time is not shown or mentioned.
Configuring too many options ends with elements overlapping
Also may be it would be nice to present buttons in value based order?
But overall very usable widget.
1 Like
Thanks for the feedback @hotNipi
Works pretty well for me, tested in Firefox, Chrome and even in Safari. What's your setup?
Laptop Thinkpad
Windows 10
Browser Chrome, latest (no zoom)
Any other node using the editable list, has no scrollbars when not needed.
The change nod for example
By removing this it is rendered correctly.
I updated the help page today, fixed the editable list and added a unit to it.
The editable list already offers a sorting mechanism. This way the user can decide and there might be a good reason to have it not in a certain order .
The user can increase the groups width and display more buttons if needed, but I am aware that the current solution with many entries is not pretty. This is the reason why I added the optional dropdown menu, so that a user can add many entries and the widget still preserves space.
I am not sure if I want to start a new line if it exceeds the current row...since it would take up more space, but it's probably the only solution... open to suggestions though.
v1.2.0: now also allows activating the timer via incoming messages (msg.countdown).
v1.3.0: allows to add a msg.topic and a label to the widget (both are optional)
1 Like
A couple questions:
Should the timer survive a refresh of the UI? Restart? Deploying a flow?
My observations are:
- reload the UI, timer switch retains state
- redeploy flow: timer UI shows in off state, flow editor shows timer "on"
- restart: haven't tried
It would be helpful if the switch could display the correct timer info after redeploying a flow.
I've been setting a global context when the time turns on and clearing when it goes off. I'm torn between whether that is something that would be useful for the timer to be able to do in addition to sending out the message, or if it is so simple to implement externally that the timer shouldn't be cluttered with it. I'm kind of leaning to the latter.
I just released 1.3.1 - it fixes the ''on" state when a re-deploy has happened. Both, a restart & redeploy, currently reset the nodes state and the switch will be off afterwards. I can move the state to the nodes context (in a future update) and it will keep its state after a redeploy but definitely not after a restart (except contextStorage localfilesystem is enabled).
There should be no need for setting any variables in the global context then, right?
Wow! Fast! Thanks!
That will help make the display consistent. Maintaining it over redeploy will be a useful feature, as will being able to store it in localfilesystem (that's where I'm storing my global -- we have frequent power outages, especially during the season when it is most critical to have this flow up and running).
The global I'm using is for a side-effect. I am controlling a swimming pool and I am using your timer for the cleaning cycle. I need a way for other cycles to know that cleaning is active so they don't override it if they get a trigger to start or stop. I may need to rethink how I'm doing that to account for the switch being reset. It's unfortunate that the switch doesn't send out the time when it is activated.
I don't mind adding more options to the node, it's pretty basic at the moment anyway. What information would you like to have inside the message besides the already available payload ?
I went ahead and published 1.4.0. It now saves everything into the nodes context. It also restores everything after a reboot/redeploy if contextStorage is set to localfilesystem. Additionally you can now choose if the nodes state is included in the output message - it should contain all the information that you need.
I'd appreciate your feedback!
Ha ha. Thanks. Just as I forked the repo and was going to look at creating a PR myself
There are a couple other ideas I have that I'm going to experiment with. I want to make sure they fit into the philosophy of node-red (at least as I understand it), so trying to avoid global state. Unfortunately the very nature of a timer implies some sort of state. The challenge is how to work that into messages on a wire. I've got a few ideas there that I'm going to try out. Plus it gives me the push to learn more about creating nodes.
I created a PR adding a couple features for your consideration:
- Adds a message (msg.topic: "status") to query the status
- Adds 2 additional outputs: one branch is the status is on, another if the status is off
- Ability to specify the name of the property to hold the state
- When querying status, the entire input message is passed through to the output
I wasn't able to figure out how to get it to accept a status inquiry message and set the countdown in a single message (if you can point me to some documentation on creating dashboard nodes I'd really appreciate it), but in those cases there would be a conflict with the payload anyway.
Some notes on the design: I wanted to be able to request the status of the timer and be able to make a decision based on the result. It didn't really make sense to require adding a switch because I couldn't think of a reason why somebody would want to query the status and not make a decision based on the result, hence the reason for providing the multiple outputs. Admittedly, this is largely based on my specific needs, but I have tried to adhere to the philosophy that information should travel along wires and not through context, etc. and it doesn't seem that what I'm trying to do is all that unusual.
Source for flow is in the PR and the intended use would not normally combine all the outputs. In my case I'm using the timer as a lockout, so the "on" branch would dead-end and the "off" branch would enter a flow.
Nice and simple! I only have one problem with my usual feedback loop: Zigbee lamps are triggered by a switch (or your timer) and when the lamp actually changed its status I get a message back to the switch/trigger.. to toggle the icon accordingly.
However this does not work with your node. When it receives a msg.payload= True from my Zigbee lamp the timer is on forever and does not count to zero. Is this a feature or a bug? 
hi @haegar33 thank you for your feedback!
Not sure if I can follow. As you can see in the nodes help section
this behavior is intended. What would you expect to happen after the node receives TRUE at its input?
Yes I would expect that an input of True toggles the icon but does influence the countdown timer. Depends on your scenario and what you intended with an input node? Do you expect another GUI switch attached to your input to control the light manually thus overriding the countdown timer completely ?
Actually this is only an issue for lamps which provide a feedback on their status. This ensures proper representation of a GUI dashboard when starting NodeRed or deploying a flow.
Since the countdown timer does not have an icon at the front end, I assume that you want to control another Dashboard UI element? Could you provide an example flow?
Sorry for the confusion. Your widget has an icon to represent the switch. Its the same icon which is used for the simple ui_switch node. And same as the simple switch it reacts to the input. However it also stops the counter when input is true. The switch then remains alway on.
I hope this is understandable now? I don't know how to describe this in more detail, sorry..
Ah yes I understand now, thank you for the explanation.
So yes, it is still an expected behavior. The switch (icon) can be turned on by:
- the front end
1.1 click at the switch (forever on or off)
1.2 click at one of the buttons (on for 'button value' minutes)
- through incoming messages
2.1 msg.payload of true turns the switch on (forever)
2.2 msg.payload of false turns the switch off (forever)
3.1 msg.countdown of X minutes, turnes the switch on for X minutes
All of the options above have to overwrite the previous selection (it would not be a functional switch otherwise).
Back to your issue: What I currently don't understand is: why would you need to feed the timer if the countdown is already on? Because if the timer is already on, the switch (icon) should be on already?
