[ANNOUNCE] node-red-contrib-blockly : 2.0.0 betas (currently at beta 2)

Hi folks,

After 3 years of inactivity, @cymplecy and myself are proud to present version 2.0.0-beta.1 of the node-red-contrib-blockly node :partying_face: :clinking_glasses: :champagne:

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 :wink:

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...).

Have fun !!!!!!
Simon and Bart


??? What is that?

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...


It's a namespace in RED that is used by the node edit UI. It manages the stack of overlays etc.

1 Like

Ah, one to add to the list of things to investigate! Thanks.

1 Like

Oh Great One - you don't seem to have added in my contribution :slight_smile:

Aaaahhh I had forgotten that you had added your code changes in the issue, instead of a pull request...
Don't take it personally :lying_face:
Will fix it tonight. Short lunch break is over ...

And which idiot said - just post code changes - don't do pull requests.........


1 Like

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 ...


I'm wondering if the JS of the interval block should automatically include the stop interval JS code.

Then, users wouldn't have to add the specific stop interval block unless they needed it later on as part of the logic of their code.

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...

1 Like

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.

@BartButenaers Can you show an example of when default stopping would not be appropriate?

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:

  1. When somebody presses a button down, an input message with msg.payload="down" will arrive.
  2. That input msg will start a new interval timer, which sends an output msg every 200 msec.
  3. 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.
  4. 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...

Hopefully that makes sense?

I think this is that scenario

in which case - no harm in generating the stop interval JS code when down is received

I can't come up with a case when it would be wrong to do so

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 ...

After 2 years of pleading and arguing - the byte block finally returns a byte :slight_smile:

I'll never have to program in JavaScript ever again :slight_smile:

:clinking_glasses: :clinking_glasses: :clinking_glasses:


Now you can organize an entire conference about the Blockly byte block next year ...

1 Like

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 :rofl: