You are ware of this but I want future readers to see this explicitly said. You are not working with a Java ZonedDateTime like in Rules DSL.
Unfortunately I can’t help with this specific issue as that looks right to me.You could fall back to using a ZonedDateTime as a work around for now. All of Java is available to you when you need it.
Yes, quite right to point this out explicitly, as it could result in confusion. Thanks!
Yes, agreed, and it’s easy enough to do that. But…
I just don’t get how such a basic Javascript API can return something different than expected in the openHAB environment. As it was the very first thing I tried, it made me wonder if there is anything else that doesn’t behave as expected.
I would expect it to work too but have no experience with that.
The only major difference I’m aware of between GraalVM ECMAScript and “standard” is that in GraalVM we don’t have an event loop which is causing us some other problems (e.g. no Thread.sleep equivalent is possible since promise and await depends on that event loop).
Yeah, I saw that too. I decided to use setTimeout in place of Thread:sleep in a couple situations, but it’s not ideal since the code runs asynchronously.
setTimeout(() => {
// Do stuff after 2 second delay
}, 2000);
@mhilbush / @rlkoshak
I have found no downside in using setTimeout like this or do i miss here something?:
console.log("this is the start message")
setTimeout(() => {
console.log("this is the 1sec message")
setTimeout(() => {
console.log("this is the 2sec message")
}, 1000);
}, 1000);
Well, it’s not a true sleep, as it doesn’t block the execution of the main rule thread. So, it’s easy to get yourself into trouble by putting code after the setTimeout block, which would execute before the code in the setTimeout block. In other words, unless you’re very careful, it’s possible to create some unexpected behavior in your rules…