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.
If you just have a date and no time then a LocalDate should probably be used. I don’t know what is backing the “date” block but my original comments and concerns had to do with ZonedDateTimes (and LocalDateTimes if we are being thorough).
Yes, making that more generic would work, but we would still need to support now.
thank you very much for your effort to extend Blockly for OH.
I was planning to use Blockly for my rules and scripts exclusively. Due to the lack of some functionality I started to write my own Blockly libraries in OH.
I would like to compare to dates, The date-block generates a ZonedDateTime with the fields for time set to 0. Every time i want to check a specific time against another ZonedDateTime I have to alter the time fields returned from the date block with a custom block. This is functional but results in a huge block.
2022-01-11 15:43:37.760 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'ec4c7f85d1' failed: javax.script.ScriptException: groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getActions() is applicable for argument types: (String, String) values: [mqtt, mqtt:broker:mqttbroker]
Possible solutions: getFactory()
How do I get this with my script?
And more generally. I found I have access to a variable called triggeringItem which I can use in the Groovy script, but I only stumbled across it working because I’ve used in other scripting. Is there a definative list of all the things in scope which I have access to while executing my Groovy script from within a UI rule?
That shows almost everything that exists in your rule be default. For your first question you’ll notice actions which is access to the ThingActions class. That’s what getActions() really exists on. Rules DSL hides a lot of that sort of thing from you.
There is no equivalent to triggeringItem but there is event.itemName. You can get the state from items[event.itemName] (or what ever the syntax for working with a Map in Groovy is). You can get the actual Item using ir.getItem(event.itemName).
It might be the case that you also get the same implicit variable as Rules DSL rules get. If so see Rules | openHAB.
I thought that too, but there is not getActions on it.
2022-01-11 16:44:42.180 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'ec4c7f85d1' failed: javax.script.ScriptException: groovy.lang.MissingMethodException: No signature of method: org.openhab.core.automation.module.script.internal.defaultscope.ScriptThingActions.getAction() is applicable for argument types: (String, String) values: [mqtt, mqtt:broker:mqttbroker]
Not sure what I’m meant to do the ScriptThingActions? to get to something I can call publish on.
That list of things is scope was useful. I think it’s just missing triggeringItem from the list. It’s only defined when called from a ‘member of’ rule. But I think it should be in the list, as useful.
Then all I can say is that Groovy works differently somehow and you’ll have to figure it out on your own. I can’t help with that. In Nashorn JS and Jython which are both JSR223, what I wrote is how to get at the Thing Actions.
I’m not sure what ScriptThingActions are either. I can’t find that in the OH JavaDocs. It might be a private data member class or something.
Glad you got it. I should have looked up an example before just going from memory.
Typically in JSR223 the standard way is to use event since it’s more complete and explicit and doesn’t depend on “magic” the way that Rules DSL rules do. In other environments like JS Scripting or jRuby the Rules DSL implicit variables do not exist at all.
Note, that list of things that is in scope is the default preset. It’s what gets exposed in the rule by default no matter what. triggeringItem, triggeringItemName, newState, etc. are implicit variables that depend on how the rule was triggered. They are not part of the default preset. They are like the method arguments passed to the rule when it’s triggered. These do not belong as part of that table.
Sometimes I use that option to make the script more “readable”, but I was referring more to the possibility of adding an option in the block itself to select the number of “and” needed in that block.
Something like we have in the “list” block, where you can select the number of items/lines needed