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.
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.
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.
