Extending Blockly with new openHAB commands

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?

image

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:

image
(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(',');
}
print(hex_to_hsb('#ff0000'));

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?

image

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…

3 Likes

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.

Thanks
Stefan

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.

Learn something new every day. :slight_smile:

The is the event Object, right?

Does if stored value "Foo" = "undefined" not work? Is this just to make it more human friendly or is there a different technical limitation being dealt with here?

Is the code isolated in any way? Does it have access to everything defined in the script, variables and such? Can I get stuff out of this code? How does it work positionally in the code? I like this idea as a relief valve for those cases where Blockly doesn’t quite yet support what a user needs to do but agree it should be used as a last resort.

For flexibility it might be easier to deal with if they are submitted as separate PRs but I leave that up to Yannick.

I really like adding the event to contextual info. That is more inline with where I think JS Scripting is going to go too.

I don’t have a strong opinion on any of these. They all seem reasonable additions.

For context I used it a lot when I migrated to JS before Blockly, because if it happens to work for you, it’s way more convenient since you can just print('something');, no need to jump through hoops of instantiating a logger etc. So it was the first custom block I made and I kept it. But if it ends up being confusing as many won’t actually know what it does I’m open to removing it, since writing to the logs is equally convenient in Blockly.

I would hold on to it and when we move to JS Scripting change it to console. That will still log to openhab.log but also doesn’t require setting up the logger and I guess is more JavaScripty. We could even modify it so it logs to the same logger JS Scripting is using for console so when the change over happens that part at least will be transparent to the end users.