Hi folks,
Before version 0.0.1 becomes available in the grocery near your home, I would like to add timer support to it. However there are multiple ways to implement this in my contribution, so hopefully you guys can give me some advice to help me with all my questions !!!!!
Blockly offers a "delay" block, that pauses the JS interpreter which runs their generated Javascript code. However we will run the javascript in a sandbox on top of NodeJs (similar to the function node), so we will have to build our own solution based on setInterval and clearInterval.
1 - BASIC TIMER BLOCKS
Some basic timer blocks have been added to this Node-Red contribution, to support multiple ways of creating timers. For example log a text 4 times, with 2 seconds in between:
And a similar one, for example ro repeat periodically until a condition is true:
The advantage of these basic blocks is that they are very EASY to use! However they have a series of disadvantages, which are described below...
2 - STOP OBSOLETE TIMERS
As soon as a message arrives in the node, the generated Javascript code will be executed. This means the timer will be started, and run until a specified condition is fullfilled. However there will be other circumstances to stop the timer, otherwise multiple timers would be started (which would be running simultaneously):
- The timer should stop automatically when the flow is (re)deployed. It seems that this already working fine, I 'assume' because the sandbox is restarted ...
- The timer should be stopped explicit when a new input message arrives. Thought to do this somehow automatically (to make sure the users don't forget to stop it), but sometimes you want to start the timer e.g. when the
msg.start=true and stop it when the msg.stop=true.
To accomplish explicit stopping a 'specific' timer, I assume I need something like this:
But this means that the timer name should be specified, when the timer is created. So the basic block should be extended with the timer name:
But now the block becomes more difficult to understand... Any other suggestions?
3 - TIMER ID'S
As can be seen in the first screenshot, the names of the variables (representing the timer id's) are random generated (e.g. timerId_045lwr09cnj). Reason is that those names should be unique, in case multiple timers are created:
However this isn't sufficient in case e.g. the timer is created inside a loop:
In this example two timers are created, but the timer id variable will hold the id of the last timer. So I assume that when the first timer is stopped, that it will incorrectly stop the last timer ...
Could solve that by generating (at the top of the Javascript code) a function, since each function call has its own timerId variable:
function repeatForCount(count, intervalMillis, callbackFn) {
var i = 0;
var timerId = setInterval(function() {
callbackFn();
if(++i === count) {
clearInterval(timerId);
}
}, intervalMillis);
}
repeatForCount(4, 5000, function() {
// ...
});
Is this readable enough for people that want to learn by looking at the generated Javascript code? Or better proposals?
4 - TIMING CONFUSING
Suppose our user adds two timers, as in in the screenshot in the third paragraph. I 'assume' that this might be misleading, since he might think that the first timer will run for 8 (= 4 x 2) seconds and AFTERWARDS the second timer will run for 8 seconds. Or am I just getting paranoid ...
However the first timer will be started, and IMMEDIATELY afterwards the second timer will be started. This means both timers will run simultaneously, and both timers will be finished after 8 seconds.
Don't know how to visualise this better. I could add an extra input for statements that are executed AFTER the timer has finished, something like this:
Or should the user determine by himself when the timer is being stopped, like in this example:
5 - OTHERS
Any other suggestions, issues, ... about timers?
Thanks again !!!!
Bart
Enjoy the shopping.
