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.
I just tried and print() is available in JS Scripting as well with the same effect. You’re right that console.log() would be a nice evolution even if it will be functionally equivalent to logging at the INFO (I think?) level.
All things considered, offering to remove it was a bad idea as it exists already and this would be a breaking change. Especially in Blockly I’m wary of these breaking changes, that’s partly why I’m (too much maybe) punctilious over how things are named and implemented
According to the docs it’s at the TRACE level by default and it logs to the org.openhab.automation.script logger. I’ve not used it myself yet but it might append the rule UID to the logger when it logs but I can’t guarantee that.
I don’t know though if it supports all the usual console methods (e.g. console.assert()).
Actually I rebuild an existing ECMA rule with blockly and I found out, that it is possible to send a volume (in %) with the say command “Voice.say(msg, “marytts:bits1hsmm”, AudioSink, volume)“. Is it possible to add the volume parameter to the blockly say block or is there something I am missing?
Yes, it could be done but for the time being you can do same like I have explained at the play command - known issue . I rather use the two separate commands due to this problem (which is not blockly related). Add a seperate channel to the thing and control it before.
Just to be clear, a Script is a Rule too. It’s just a special type of rule that only has a single script action and a “Script” tag.
It’s an important thing to realize as it does seem to create confusion and problems when people don’t understand that scripts really are not something all that different.
from Yannick.
