Extending Blockly with new openHAB commands

Yes that would be great. I can’t accept any more features but bugfixes are still ok.

you mean make another one? To avoid Git snafus for single-file edits you can use the GitHub edit file feature (Sign in to GitHub · GitHub).
Sign-off in the commit message is still required, get it from a previous commit.

Sorry for the confusion. I hadn’t seen you have merged the PR. Thanks. Will hopefully be only minor things to fix this issue above.
I would create a new PR for that fix.
New features will then come with a new PR and as you mentioned lately I will target them with small PRs.

@stefan.hoehn I ended up doing the PR: Fix Blockly timer code by ghys · Pull Request #1236 · openhab/openhab-webui · GitHub as I saw another issue and I wasn’t sure if I will be available to review yours before the RC1 build. Thanks!

Ok, thanks.

I can confirm it works now as expected. This is how I tested it (for the curious, I used two different trigger items and I distinguish those with the new block that retrieves event information, i.e. in this case the event item’s name):

I saw you working on the new blocklib (Block Libraries - initial implementation (#1225))
which refers in its editor to “https://openhab.org/link/blocklib-tutorial”.

I checked the latest openhab-docs if I find something there but couldn’t. Have you written something there already so that I can start learning about it?

The link works now!
It points to:

Thanks for the writeup, it works now.

can you do me a favor and merge this last PR. It is a small extension to allow retrieving rules parameters within a script that was written with blocklies. This concludes the blockly “Run & Process” section.

Here is how it can be used when having provided it via a script call as shown in here

The PR is pretty small and should be straight forward

1 Like

We have now released this major update of openhab blocklies as part of openhab 3.2.0. It now contains almost 50 specialised openHAB blocks. Thanks to all who helped by contributing their ideas, reviews and feedback.


Thank you Stefan for your great work on the blockly blocks.
Are there any plans to integrate binding actions like sending a telegram notification or a push notification through the myopenhab service?
I work with telegram notifications and this is the last point I need to change to the blockly editor.

Thanks a lot for your effort!

Thanks Johannes.

Currently, I haven’t planned this but you may be able to contribute this in a way similar to the new Block library approach like in this example that was done for Twitter

see the Tutorial: How To Write Block Libraries

Check the Blockly section of the Marketplace. A number of these Actions have already been built and published there. And as @stefan.hoehn pointed out, there is a really good tutorial for writing your own.

Actually I had a Telegram library in mind for the initial set but lacked the time. :man_shrugging:

myopenHAB push notifications are in the built-in set under openHAB > Notifications.

It’s I think the only case of a set of built-in blocks that depend on an add-on but it makes sense to make an exception for OH Cloud.

1 Like

Hi Rich

I just noticed that when I retrieve tags or groups from items it does return a


Do you by chance know how to convert that into a Javascript list like so?

var list = [‘tag1’, ‘tag2’];

Unfortunately Collections is probably too generic. Do you know if it’s a List, Map, or Set? I think List and Set are treated the same but a Map is different.

It’s almost certainly a List or Set though given what is being returned. In my Nashorn rules I tended to just keep them as Java and used Java’s Stream API to do the filters, forEach, map and reduce. It also works with for(var I in list) .

There is a way to convert too a JS array and back though. I think it’s Java.from(list) which will convert the Java List or Set to a JS array.

Thanks for the guidance. That helped me fixing the blockly problem I detected.

Hi Rich,

did you ever notice that sending colors in OH Blockly doesn’t really work?

actually generates

events.sendCommand(‘Nano_Squares_Jonas’, ‘#ff0000’)

which isn’t really surprising but of course OH doesn’t understand #ff0000.

I wonder if we should make the send command block smarter by detecting the color-# (note that I am not able to recognize that there is a color block - I can only parse the output) and convert it into “255,0,0”.

The other option would be to provide an OH-Block that converts the normal color block to a OH Color.

What do you think?

I don’t have anything that uses color in my setup so I wouldn’t have ever noticed that.

They both have their pluses and minuses. The former means that users can manually send an RGB string in other ways, not just the color block. However if there is ever a case (and there will be cases) where someone needs to use a # for any other reason that use case will break.

The latter would be a bit more transparent to the user though and it should avoid breaking anything so if that’s possible I’d use that approach.

1 Like

Just to be clear, you would propose to add an openHAB conversion block that converts e.g. #A0B0C0 into “160,176,192” ?

Another option would be add a “send Color Command” to the block like so

How do you like that idea?

Not really a color user I’m not sure I have a preference either way. I just would not want to have it implemented in a way that the code will always treat any string starting with # as a color. That will potentially break other use cases.

That was my idea to provide that particular send command that has this special behavior.

@ysc Any preference you would have in this case?