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

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:


Any news on when this will be available within NodeRed from the Palette? Currently only showing the 3 year old version?

Hi @dougle03,
Normally in a couple of weeks from now. We hope that some people will test our beta, and that our translators have time to translate the texts.
P.S. There will also arrive at least one extra beta version, because I found a bug last night ...

Excellent, I'll look forward to it, thanks.

Note: I'm not a sufficiently competent user to evaluate Beta modules; I'd likely cause more confusion rather than help... lol

1 Like

Any user that can use the final release of our node afterwards and complain that something doesn't work, is also an awesome beta user :wink:

1 Like

One of the visually nicest new features is we can now change the appearance of the Blockly blocks

As a long time Scratcher, I've always disliked the default appearance but now I can switch to the Zelos theme via the config


1 Like