Banging my head against the wall here.
Javascript v11
The Item:
DateTime CalendarEventEnd_CCMain (gCalendarTstat,gHVACZONE_CCMain){channel=“icalendar:eventfilter:feed_community:result_0#end”}
The javascript rule ECMAv11 in the UI rule editor:
var triggeringItem = items.getItem(triggeringName); // WORKS
var v1 = time.ZonedDateTime.now().plusSeconds(10); // WORKS
var nowplus = new DateTimeType(v1); // ERROR
triggeringItem.sendCommand(nowplus); //ERROR
I can’t figure out how to instantiate an instance of the old DateTime so that I can sendCommand it to the DateTime item.
See the use of the runtime object in “Advanced Scripting” at the bottom of the helper library help docs for the easiest way to import OH specific types.
But: you don’t need to create a DateTime type for this. The sendCommand method expects a string input. In the case of a DateTime item, it expects a string input in the local time format, not ZonedDateTime. Fortunately, there are two simple methods to make this transformation: toLocalDateTime and toString. So your command should look something like this:
Just to add on a little to @JustinG’s response, openhab-js, the helper library for ECAMScript 11, goes to great lengths to make is so you don’t have to touch Java Classes and Objects except in rare and extreme circumstances.
There is code built into the add-on that automatically converts to/from JS-Joda ZonedDateTime to java.time.ZonedDateTime for you.
Another gotcha is both sendCommand and postUpdate expect a String in all cases. So as demonstrated, the toString() is going to need to be called no matter what type of Item it is.
The problem here is that JS-Joda is going to give you an ISO8601 formatted date time string but Java’s ZonedDateTime has it’s own slightly different format which kind of breaks when it comes to parsing an ISO8601 string that includes the timezone. That’s why converting to a LocalDateTime first works, it strips off the time zone.
There has been some efforts to address this in the library but it ran into some intractable technical issues which haven’t been overcome yet.
One final bit. I recently got most of my timeUtils added to openhab-js so you could replace
var v1 = time.ZonedDateTime.now().plusSeconds(10);
with one of
var v1 = time.toZDT('PT10s'); // ISO8601 formatted duration string
var v1 = time.toZDT(10000); // number of milliseconds into the future
var v1 = time.toZDT().plusSeconds(10); // calling topZDT() without an argument returns `now`
time.toZDT() will also convert from Java ZonedDateTime, DateTimeType, a DateTime Item (which then gets the state and converts that), simple time based strings (e.g. “13:01” will give you a ZonedDateTime at 1:01 PM today), etc.
If you need a ZonedDateTime and it kind of makes sense as some sort of representation of time or duration, time.toZDT() can probably convert it into one for you. The only think it doesn’t handle is parsing ISO8601 date time strings with a timezone for the same reason the OP code failed. But I just got an idea that might make it kind of work.
Thanks for the help. I don’t know why I’m having such a difficult time, but now I need to convert that DateTime to something that I can calculate milliseconds from now to send as a timer expire parameter.
And remember the first place you should look any time you want to see how to do something is the addon’s docs. Everything you can do is documented there. Revisit the docs on every update to OH look for additions and new features.
