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.
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.
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:
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'));
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?
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.
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.
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.