Every year around Christmas Simon asked me when we would start adding features to the Blockly node, but I never had time to support him. One of the problems was that I failed to show the Blockly workspace in full-screen mode, without nasty side-effects. Fortunately Jeff managed to solve this via RED.tray, which was the trigger for me to get started again with Blockly... So thanks a lot Jeff !!!!
This release has LOTS of new features, as you can read in our release notes:
So hopefully Simon has now enough toys, so he can forget all the christmas evenings that I left him alone with his old Blockly node
Would be nice if some folks could test our new version, which can be installed like this (from within your .node-red folder):
npm install email@example.com
As usual all "constructive" feedback is very welcome.!!
Don't forget to have a look at the existing Github issues before reporting a new issue here.
BTW The french and russian translations are not complete yet, and might even cause failures (due to missing field placeholders...).
Yes I have been asking myself the same question when I started those nodes. Because the less blocks the users have to add, the better. And it would have saved me a lot of hours banging my head against the wall ...
But then we would decide that a lot of constructs aren't possible anymore. Suppose I want to delay every message 2 seconds. When a next message would arrive within 2 seconds, then the previous message would not be send. Which is not what we want...
Or you can stop a periodic interval sending only if certain conditions are met. E.g. you want to keep resend an input message (with payload ON) every second, until an input message (with payload OFF) arrives.
So it really depends on the case whether you want to stop the current timer or not. Therefore I think it is still better to have separate "stop" nodes...
I understand that the stop nodes makes sense and also for the timeout node to be need for manual stop. But for the interval node the stop could be done automatically every time the interval is created to avoid duplicate intervals be running at the same time or to add a checkbox "stop already running interval/timeout", then the user could decide.
Ah ok, seems I have misinterpreted the comment from @Hypnos...
Thought you guys wanted to remove the "stop interval" block, and move the stopping code to the "start interval" block. But you want to keep the "stop_interval" block (to use in conditons like in Simon's example), but as extra you want the "start_interval" block also to stop the previous timer automatically.
Indeed that makes sense. I also cannot think of any examples. It is even a better solution. Otherwise users will be confused by multiple timers running in parallel. I will implement this change!
I still don't think we should also implement automatic stopping on the "set_timeout" block, because of my example above.
Version 2.0.0-beta.2 is available on NPM. All 'known' bugs have been fixed and all discussed features have been implemented. See the release notes for an overview.
For anybody that wants to help us by testing the node, you can install it like this (from within your .node-red folder):
npm install firstname.lastname@example.org
At this point we have implemented all features that we had planned for this major release. We will now wait for feedback from other users (and for our french and russian translations).
This version also contains the buffer related requests from @cymplecy. This is the result of years of legal battle between our lawyers. But finally we came to an agreement (read: I gave up ...), so from now on we can hopefully walk through the same doorway together again