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 node-red-contrib-blockly@2.0.0-beta.1
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...).
Good question!!
Jeff introduced it here, but to be honest I didn't have time yet to investigate how it works.
Perhaps create a dedicated Discourse topic about it...
Aaaahhh I had forgotten that you had added your code changes in the issue, instead of a pull request...
Don't take it personally
Will fix it tonight. Short lunch break is over ...
Had forgotten to share a demo animation to show the new timer blocks.
It became a real fight to develop those timer blocks, but I'm very pleased with the result...
The demo shows how to resend the input message every (interval of) 1 second.
P.S. The stopInterval block is required to stop the current timer when a new input message arrives. Otherwise you end up with mutliple timers running in parallel ...
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.
Hi @Hypnos,
In that case you can only stop an interval by creating a new one. But you don't always want to start a new interval timer. Sometimes you just want to stop an existing active timer.
Simple example:
When somebody presses a button down, an input message with msg.payload="down" will arrive.
That input msg will start a new interval timer, which sends an output msg every 200 msec.
As long as the button stays down, no new input msg will arrive. So our timer will keep sending every 200 msec an output msg to a dimmer.
When the button is released, an input message with msg.payload="up" will arrive. Now the interval timer should be stopped, to stop sending output messages to the dimmer.
In step 4 we want to stop the timer. We don't want to start a new timer...
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.
Automatic stopping of timer interval is now implemented on Github, and will be published as 2.0.0-beta.2 on NPM in a couple of days.
This demo demonstrates how the timer (which is resending the first message) will automatically be stopped, when the timer is again started (resending the second message):
So in those simple cases no stop-interval block is required anymore ...
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 node-red-contrib-blockly@2.0.0-beta.2
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
