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()).
yes
No, I tried and this why I added it.
It is actually pretty simple: It lets you enter multiline text which is directly injected where the block. No isolation, everything is accessible…
Thanks for your input und the 
from Yannick.
Hi,
I appreciate the availablity of OH commands and context in Blockly very much!
Is there a way in OH Blockly to pass (a list of) Items from a Rule to a Script ?
I tried following in a Rule :
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.
This is exactly what I just provided yesterday for the next release - see a few posts above
" * Add a block that allows retrieving dictionary key / values"
see get-value-of-key-from-dictionary
It will be available for 3.3 M1
Hello Stefan,
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?
Thank you for your effort!
Johannes
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.
Sorry to bother you with that….I have overread it and the solution is more then clear to me….
Thank you!
No worries - just spread the word 
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.
1 Like
good point. Do you like to add.this to the blockly reference?
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.
Ok, but it is such good info that I have added it to the Blockly’ reference myself as it is really a very valuable information.
I have started zdt comparison and I think the best way is to provide a comparison block that can be added to an if-block like so
This already works. Some questions:
-
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?
1 Like
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.
Thanks for the input.
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.
“Is before or the same as” would work, I think? “Equals” is a bit mathsy, which may be confusing when it comes to dates!
Given the nature of timestamps, unless the two operands are literally the same variable, they will never be equal. The Java ZonedDateTime has a resolution down to the nanosecond. It’s almost impossible to generate two separate timestamps that are the same at that resolution. That’s why ZonedDateTime doesn’t really even mess with equals.
So I would say, don’t bother with <= nor >=. == will only return true if the two timestamps are really the same variable. To actually compare two different timestamps for equality, you need to do it in a fuzzy way. Decide on a resolution, for example, equal within a second or equal within 100 milliseconds.
I think it should be the blueish logic color. It’s a logic block so I think that’s most appropriate.
In Stefan’s example he’s comparing dates though - this would be equal timestamps for the same date, wouldn’t it?
1 Like