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()).
but Blockly doesnât let me loop through âget context attributeâ
or doesnât allow to âsend commandâ to an Item passed via the context dictionary.
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.
No, itâs a bigger issue than that. Itâs not a bad thing to have in the Blockly reference but itâs true for all the UI rules languages or even text based JSON rules (few people know that you can write âUIâ style rules using JSON in .json files in the automation folder). I definitely plan to add it to the parts of the Getting Started Tutorial that cover rules that remain to be beefed up and rewritten.
Do you prefer â<=â or âis before / equalsâ ?
I noticed there is no way currently to create a zdt with a text, the only one we have is the one below. Would it make sense to add a datetime-block?
I remember you (Rich) once mentioned that adding such a block would be a lot of work. Which other comparison operations or operations in general did you have in mind if you look at ZonedDateTime ?
In general, I noticed that we have date blocks in ephemeris and persistence with more coming. Additionally they are distributed over in ephemeris.js, persistence.js and dateoffset.js (I have added the code to the latter and the block to ephemerisâŠ). Wouldnât it make sense to have a seperate area and move all zdt blocks there?
isBefore is what will most closely match how it works in all the other rule languages. I find it to be more self documenting as well. But I donât have a firm opinion on that. Either way should work.
Maybe. There are times where one has a DT string they need to parse. However, the number of ways a DT can be represented is huge and I would probably limit it to just supporting ISO8601 strings. If the users need more flexibility than that they will have to use raw code. Otherwise you need to get in the business of providing formatting strings and stuff like that, which would be awesome in the long run but Iâm not yet sure worth the effort right now.
I donât know that we need to support all of ZDT, but at a minimum we would need to support the add/minus methods. isBefore and isAfter weâve already discussed and you basically have working. Iâm of two minds as to whether we should expose epoch or not. I like to encourage people to use Duration instead but thatâs a whole other set of blocks with a bunch of operations too.
But of course as soon as itâs there people will want to control how itâs displayed or logged so we might need to support formatting too.
I think so since itâs a cross cutting feature and requirement. They are needed for all those Actions as well as to be used in their own right.
The only thing I donât like when I prototyped this when I try to translate â<=â as it would become âis before or equalâ which doesnât sound so nice.
One other thing I just noticed:
How could me make the block more clear that is a date comparison block - I used the blueish logic block color - I could instead use the zdt color. Adding the label âdateâ wouldnât look nice, I think.
The effort is minimal. If it makes sense I would add that and I would just support one format. I think it is good enough for most of the cases.
Ok, that resonates with me. Though I would love to here @ysc opinion on that as well. It wonât break anything but it will appear differently (I also need to find a way how to document that in the blockly reference then)
Iâll have a look into that after having finished the check.
from Yannick.
