[UPDATE] node-red-contrib-ui-time-scheduler

[fellinga]

Ui Time Scheduler

It's been a while since the initial announcement of my ui-time-scheduler node, so I wanted to provide an update on how things have developed and of course introduce it to everyone who doesn't know about it.

Default Mode	Event Mode

Overview

• easily create schedules at the node-red dashboard
• control one or more devices with just one node
• very simple flow structure / does not need a lot of space at the dashboard
• two modes:
  • Default Mode : define a time frame in which your device should be switched on
  • Event Mode : define an exact time to carry out an arbitrary action
• the node is currently available in English and German

Recently added

• Solar events! You can now create schedules based on sunrise/sunset.
• Data is now stored in the nodes context -> no need to worry about persistence of data if you changed the node-red contextStorage to localfilesystem.
• It is now possible to disable/enable individual timers as well as entire devices
• Event Options can now be predefined within the node's options
• You can now block device output unless a value changes

Demo (Default Mode)

Feel free to make suggestions or report problems at the nodes GitHub site or just leave a comment here in this topic. I'd appreciate you feedback.

Thank you!

[davidz]

Thanks for the excellent work.
Is it possible to add a "select all" button in the date selection? This can save lots of clicks if there are multiple timers that need to be set up for all days

[fellinga]

Hi @davidz,

definitely possible, but I am not sure about adding more items to the list. I was also asked to add a weekdays/weekend list item - so adding all of the request would result in a very long list. I've tried to automatically select all after unselecting the last element, but that did not feel quite right.

How do you feel about a long list? Or do you might have any other suggestions to resolve this?

[davidz]

I think it is fine to add one more "select all" option to the bottom of the list, such as below. In our case, we may need to add multiple timers a day to acquire data. It is common for the machines to run 7 days a week. It definitely provides better user experience when there are more than 10 timers to set up

If one wants to only select week day, then he can "select all" and then uncheck "SU" and "SA".

[fellinga]

v1.11.0 is now available with the requested addition.

[davidz]

Thank you very much Fellinga! This is very useful

[fellinga]

No problem! If there is anything else you need, please, let me know .

[jodelkoenig]

Hi fellinga,

great node. Thanks a lot for your contribution.

Whenever I open a tab with a scheduler, only active timers are shown. Is there an option to always show ALL timers instead? I turn timers off and on depending on other parametera. And quite often only see "Nothing planned yet" (or so, I use a german desktop), which in fact is irritating since there are (de-activated) timers.

/Cheers

[fellinga]

@jodelkoenig 1.13.1 now stores the selected filter value together with the rest of the configuration. So it will "remember" the selection. I've also added a icon next to the filter to make it clear which filter is currently selected.

@Christian-Me 1.13.2 should fix the width issue.

[jodelkoenig]

Cool ... thanks fellinga. Also for your feedback concerning Device Name on github. I see the challenge here and am fine with whatever you do related to it. Again: I really appreciate your node, hence time and effort you spent and continue to spend.

/Cheers

Edit: Confirmed working

[davidz]

Is this a bug? There is a ui-switch node connects to the output of the ui-scheduler. We want the ui scheduler automatically control the switch, and we also want to manually control the switch from time to time.
If we select "Block device output unless value changes" from the ui-scheduler, and we turn on the switch manually, then the ui-scheduler automatically turns off the switch with a payload of "false" after around 15 seconds.
The ui-scheduler is not supposed to output anything unless the scheduler reaches the scheduled time, right?

Please see attached test flow picture and test flow codes.

[{"id":"40e18e86.e27f","type":"ui_time_scheduler","z":"a7dc7375.637e7","group":"b3d9c28a.67fad","name":"","startDay":0,"refresh":60,"devices":["Device 1"],"onlySendChange":true,"customPayload":false,"eventMode":false,"eventOptions":[],"sendTopic":false,"lat":"","lon":"","outputs":2,"order":6,"width":0,"height":0,"x":500,"y":1080,"wires":[[],["f92a1b5d.88ea98","c5b32c0c.d3be"]]},{"id":"f92a1b5d.88ea98","type":"debug","z":"a7dc7375.637e7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":670,"y":1140,"wires":[]},{"id":"c5b32c0c.d3be","type":"ui_switch","z":"a7dc7375.637e7","name":"","label":"switch","tooltip":"","group":"b3d9c28a.67fad","order":17,"width":0,"height":0,"passthru":true,"decouple":"false","topic":"topic","topicType":"msg","style":"","onvalue":"true","onvalueType":"bool","onicon":"","oncolor":"","offvalue":"false","offvalueType":"bool","officon":"","offcolor":"","animate":false,"x":740,"y":1080,"wires":[[]]},{"id":"b3d9c28a.67fad","type":"ui_group","name":"Overall vibration","tab":"39de3350.dc591c","order":1,"disp":true,"width":"15","collapse":false},{"id":"39de3350.dc591c","type":"ui_tab","name":"Overall vibration","icon":"dashboard","order":5,"disabled":false,"hidden":false}]

[fellinga]

"Block device output unless value changes" does the following: Whenever you deploy the node the nodes state is undefined. A 60 second refresh rate checks every full minute if the state has changed -> Since the state after a deploy is undefined it will fire the corresponding true/false value. Every future event will only fire if true has changed to false or false has changed to true.

I tried that with your flow and it seems to be working. Could it be that the first true/false value was misleading?

[davidz]

Yes you are right that the first true/false value output causes the issue when the user has not input the timer definition yet. We thought that choosing "Block device output" will block any output from ui-scheduler unless it reaches the user-defined time.

Is there an option for the ui-scheduler not to fire anything in "on" and "off" event mode no matter the timer is defined or not?

If not, then we may have to switch back to the single event mode, in which ui-scheduler only fires when it reaches the user-defined time. This is slightly inconvenient for IOT applications since we only want to turn on/off a sensor for a short period of time. When there are lots of sensors, it takes twice the time to set up the timer

We don't want to take the risk that a user may do manual testing of the sensors before he sets up the timers.

[fellinga]

Sorry for the delay, I am currently on vacation.

@davidz

Is this a bug?

Okay so to answer your initial question, no it is not. The idea of the default mode, or as you even called it "the on and off event mode", was to manage a devices on/off status that is defined at any time, if no timer is set or the current time is not in a timers time range then the device should definitely receive a false.

To find a solution to your problem...

1. the RBE node has a feature that ignores the initial value, that would probably do the trick but it would obviously also ignore the first true. So that would have to go through a switch node or something similar.
   
   

Implementing a similar functionality that ignores the initial value for the UI time schedulers default mode doesn't seem quite right. But I am, as usual, open to suggestions.

@davidz

When there are lots of sensors, it takes twice the time to set up the timer

By the way: I am planning on implementing a timer copy function - should reduce the time to set up timers.

[davidz]

Thanks Fellinga for the explanation.

IMHO, for IOT applications, the initial default state of devices/sensors should be decided by the device/sensor, not relying on the external timer. Some needs to be "on" in default, some needs to be "off" in default.

It took us some time to debug and realize that it is the timer that turn off the sensors when we are manually starting/testing the devices/sensors each time when we implement a change to the flows.
Each time when the Node-RED flows is modified, the timer fires off a "false" message after dozens of seconds.

A copy function is a great feature. This timer is extremely useful and thanks for your help.

[fellinga]

@davidz

IMHO, for IOT applications, the initial default state of devices/sensors should be decided by the device/sensor, not relying on the external timer. Some needs to be "on" in default, some needs to be "off" in default.

Okay, that makes sense to me but still leaves a few possibilities for the actual implementation.
Your specific case should only ignore an initial false, is that correct? Only if no timers are set up at all or even if a timer is set up for this device?

[davidz]

Ideally, at least in our case, even if a timer is set up for this device, the timer should not send out anything to the device unless it reaches the specified "on/off" time.

[fellinga]

Okay, I've got an idea that would leave the "block device output unless value changes" as it is and additionally provides a setting that would meet your requirement. You can expect an update by the end of next week (after my vacation).

[davidz]

Great. Thank you very much!

[fellinga]

1.14.0 is now available.
You can now select a "Single Off" option in Default Mode which makes sure "false" is only sent at the specified end time of a timer. "true" will be sent multiple times in between start and end time, just like it did before.

A good side effect is that you can now combine "Single Off" and "Block" and the Default Mode will be very similar to the Event Mode, hence only send true once* at a defined start time and send false once* at a defined end time. (*at a refresh rate of 60 seconds).