Extending Blockly with new openHAB commands

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?


Definitely not a new “send color command” IMO!
There are plenty of RGB-to-HSB conversion functions available, just choose one that’s concise, bear in mind they might have other ranges for the H,S,B components than openHAB’s 0-359,0-100,0-100.

Also perhaps one to build a HSB color from its components:

(only have to join them with ‘,’)

Here’s a RGB to HSB function that works in Nashorn:

function hex_to_hsb(hex) {
  var rgb = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex);
  if (!rgb) return '';
  var r = parseInt(rgb[1], 16) / 255, g = parseInt(rgb[2], 16) / 255, b = parseInt(rgb[3], 16) / 255;
  var v = Math.max(r, g, b), n = v - Math.min(r, g, b);
  var h = n === 0 ? 0 : n && v === r ? (g - b) / n : v === g ? 2 + (b - r) / n : 4 + (r - g) / n;
  return [60 * (h < 0 ? h + 6 : h), v && (n / v) * 100, v * 100].join(',');

Taken from framework7/utils.js at ce7a2dc21b29a05d6c782bd53a4155f542867d9c · framework7io/framework7 · GitHub (colorHexToRgb) and RGBToHSB - 30 seconds of code.

Thanks Yannick, very much appreciated. I will then do a block for that soon as part of the new series of smaller blocks to be added to 3.2M1 3.3M1.

3.3.M1 :wink:

1 Like

Works like a charm :partying_face:

(note: I make sure that only colour-blocks can be assigned to it)

1 Like

I was always wondering what the print statement was for?


It neither prints to the console nor to the log.

Can you tell me? @ysc do you know?

I always assumed it prints to the logs. I suspect it’s just something that comes with stock Blockly and it’s non-functional right now.

There is no such thing as print in OH I’m aware of.

Weird because it is actually an implementation we have provide long time ago. Maybe Yannick knows

Blockly Reference Documentation status

  • Introduction => done (good enough so far I think)
  • Getting Started => done
  • Items and Things => done (except the current discussion)
  • Timers and Delays => done
  • Voice and Multimedia => done
  • Ephemeris => done
  • Notifications => done
  • Persistence => done
  • Value Storage => done
  • Run & Process => done
  • Logging and Output => done (except the print-question)
  • Blockly Standard categories (extended by openHAB)
    • Colors => done
    • Lists => done

Around 900 lines of documentation finally…


Unlike most, during the holidays I actually have less time to spend on oh and related stuff. But I’ll take a close look and comment after the new year. Ping me if I forget.

Thanks, speaking of holidays … regarding ephemeris.cfg

In the context of [WIP] Ephemeris Documentation is it correct to say that one should copy the default file from /var/lib/openhab/config/org/openhab to /etc/openhab/services and then manipulate it from there? (honestly I didn’t completely read the whole thread)

I also wonder where to put the Jollyday XML file as our generated code calls never provide any filename and if we don’t there is no way to use that functionality?

That seems reasonable. I’ve not really looked at this since OH 3 came out.

Without the file path that a user can provide either there needs to be a predefined path or custom holidays cannot be used.

@ysc @rlkoshak

I have collected a number of small improvements for the next release that I held back until “this” bug is merged (thanks, Yannick).

Before I provide the pull request I would like to have a general yes and no on the ideas improvements

  • Add a block that converts blockly’s rgb block with hexadecimal color representation to openhab HSB
  • Add a block that allows retrieving dictionary key / values
  • Add triggeredEvent to “contextual info” block
  • Add block to check if a stored value exists
  • Add block that allows to inline script

They are already documented in the Blockly Reference (which doesn’t mean I could take that out again there), so it is easier to see what they look like and how they would behave.

If I get your ok, I will provide the PR.


1 Like

Actually yes there is - it will print to stdout and you can likely only see it when you run openHAB directly in the foreground (not as a daemon with systemd or similar). You can also see them appearing even if you’re not “tailing” your log with log:tail - and it doesn’t pollute the logs while you’re debugging.