Why copy when you can just install it? That’s the whole point of rule templates on the marketplace.
That is definitely wrong or, at a minimum points to a difference between what I’m running and the template, though even this should be a meaningless difference. time.toZDT() should handle both the Item, and the String. But one thing you can try which would be informative is to change that line to
'time' : time.toZDT(i.rawState).toToday()
But that’s not where the error is coming from. All three are successfully converting the Item’s state to a joda-js ZonedDateTime on that line. The error is coming later in the call to time.toZDT inside the timerMgr.check() which should be just a passthrough because it’s already a ZonedDateTime.
I’m still trying to reproduce the error.
Are you certain you’ve not installed the openhab-js library? Maybe my checks on versions is failing and you have an older version.
Edit: I removed my rule, updated the template and recreated my rule, still no error on my side. This is very odd.
One other possible idea. Near the top the script action there is a line
helpers.validateLibraries('4.1.0', '2.0.1');
Change the 2.0.1 to 2.0.2. Maybe the small bug I fixed between those two versions is relevant here.
After update to OHB 4.0 I updated java to Zulu17 and installed JavaScript Scripting from settings-automation. If you can point me what should I check I will do this. I’m pretty sure that problem is on my side.
That was just to confirm that you have the latest openhab_rules_tools.
I can’t figure it out. Unless my validateLibraries utility is broken, you are running with the latest of both openhab-js and openhab_rules_tools so that’s not going to be a difference. And unfortunately, that’s where the error is coming from.
Hi @rlkoshak , Unfortunately it’s not a problem with the specific configuration for @Robert_Koziol , I’m seeing the same error. I have tried all the steps you’ve mentioned earlier (updated openhab-rules-tools and reinstalled the template), but no success.
I do see the same small difference in the rule on line 216, even after reinstalling the template:
'time' : time.toZDT(i).toToday() } });
instead of
'time' : time.toZDT(i.state).toToday() } });
I was wondering if Daylight Savings Time could be a factor, that was last weekend over here.
I’ll try some more tweaks, I’ll update the thread if I make any progress. Until then I’ll keep your old rule as the last Nashorn rule in my system, that has been working perfectly for me.
Sorry to be the bearer of bad news (and weird problems), your work here is much appreciated! Your examples and community answers have helped me a lot.
Shouldn’t be unless you had a date time Item at exactly when the time change occurs (e.g. in the US that’s 2 am). This version of the template only looks at the time so as long as that time exists on that day it will use the proper time for that day. The 3.x version template depends on the To Today rule template to advance the dates to today but not thins one.
Ultimately, unless and until I can reproduce the error I’m not sure what I can recommend. I’m using the version of openhab-js that comes with the add-on. I’m running the OH 4 snapshots 3380 (I think). And I’m running with the latest published version of openhab_rules_tools.
Good news, I managed to get a fully working TSM in js-scripting without any errors!
What I did:
uninstall JavaScript Scripting add-on in Automation UI
manually delete folder /etc/openhab/automation/js
restart OHB and install JavaScript Scripting again (after installation ls /etc/openhab/automation/js shows empty folder)
In Settings → Other services → JavaScript Scripting set Do Not Use Included Library
manually install from /etc/openhab/automation/js:
sudo -u openhab npm i openhab_rules_tools
sudo -u openhab npm i openhab
sudo -u openhab npm i git+https://github.com/openhab/openhab-js.git
After restart OHB, TSM rule run with no errors.
Additionally, I tried to set back the original settings Use Included Library and it brings back the error.
Are you on the milestone release or snapshot releaseof OH 4?
If you are on openHABian you can/should install the libraries using openhabian-config.
And you don’t need to install openhab-js both ways. You can either install the latest release (your first command) which is what I recommend, or get the latest unreleased changed from Github (your second command).
That implies that the version of the library that ships with the version of OH you are running is the root of the error. But running with the latest from GitHub does not have the error.
This gave me enough info to go on and I’m finally able to reproduce the error too. It’s definitely an openhab-js library version problem. Something after openhab-js 4.1.0 fixed the problem and 4.1.0 is what ships with the add-on right now. So installing from npm and setting the flag to not use the included library are required for now until the latest version of openhab-js get’s included in the add-on.
I’ll update the required version numbers in the check a the top of the rule accordingly so the solution to the problem is more apparent.
But I have confirmed that the latest release on npm works so you don’t need to use that git installation line.
i also keep having issues with the current version of OH and Time Based State Machine.
i’ve already set it up the way it is described in this post including all the workarounds, but i always kept getting the error message that it basically couldn’t use the provided time format (for example 2023-08-05T10:00:00.000+0200). but that doesn’t seem to be the issue, since changing the datetime widget to only provide time essentially outputs the same format just with the beginning being 1970-01-01TXX:XX:XX.XXX+0100 and i keep getting the same error message.
It seems like the issue is the system time, wherever it get’s it from…
the weird thing is if i get it running for the day it works, but on the next day it stops working. then i just have to run the rule 2 or 3 times and then it works. I can provide console output tomorrow when i have to run the rule again manually.
any ideas?
(i set the javascript scripting add-on to not use the internal library, fyi)
@edit: hm, oddly enough, today i had to run the rule again manually but it didn’t give me any error messages. i now set the time-trigger to run the rule at 00:15, maybe that fixes it.
it seems like now its working, i ran the rule manually today observing the logs, no errors. maybe it was something with the wrong version being installed by npm or it just not using the right version despite setting it.
but somehow it seems that my trigger is not working. the rule should change the time of day at 07:00 in the morning but that doesn’t happen. only when i run the rule manually it actually changes the time of day. is there anything else which could cause the trigger to not work?
One of the first lines in the new rule template now runs a check to see if the openhab-js and openhab_rules_tools libraries are recent enough. But I know that specific error was related to a bug in openhab-js that got fixed so it’s kind of a mystery.
I might need to up the current minimum to 4.2.0 or 4.3.0.
I’m glad that part is working at least.
Keep in mind how the rule works. When it’s run it goes through the time of day items metadata and figures out which ones are the appropriate Items for today given the ephemeris day type (weekday, weekend, holiday) or default if there isn’t a set of Items that match the day type. Then all it does is schedule a Timer for time of day that hasn’t already passed to update the time of day Item with the value in the metadata.
So if it’s not updating the time of day Item on it’s own, it’s not scheduling the timer which means either it’s finding the wrong dayset or something else is going on. I couldn’t begin to guess without debug logs.
You can change the logging level for the rule in all the usual ways (karaf console, log4j2.xml file) or uncomment out the line at the top of the script action:
Don’t forget to run the rule at least once when you are done to return the logging level to INFO and then comment out the line again, if that’s the route you take. The logger name is org.openhab.automation.rules_tools.TimeStateMachine.
so, i’ve changed the log level to see if there’s anything wrong. The only thing i found was that everything seems to be working as expected, only that my new time items are not using the correct time zone. I did change this when the rule wasn’t working at all, so i did change it back to have the correct format and now the timers seem to be working. i’ll report back tomorrow if the new timers are running correctly from now on.
but thanks a lot for your help!
(See attached screenshot for reference, the DAY and NIGHT Timers were set to +01:00, so that might’ve caused the issue)
In the future, please post text where ever possible. Screen shots are pretty much useless to me. They can’t be searched, are all but impossible to read on a small screen, cannot be copied from, etc.
I’ve been checking various things and found that I still had a cronjob for rebooting the vm running at 4 in the morning. I since then removed that and now it’s working, maybe the system start level trigger is not working correctly? The other issue was probably that my timezone was set wrong in my time items.
If you have even one Thing that never becomes ONLINE during startup, you will never reach system runlevel 100. You can change the runlevel to 70 or before and see if that’s a problem.
Well that explains everything. I have a couple of Things that are behind switchable wall outlets that most of the time are offline.
i’ve tested everything for a couple of days and so far everything is working perfectly, thank you very much!
Hi Rich,
I’m using the OH 4.0.2 release and trying to get the time machine to work. I have created corresponding items and these also have valid values.
When calling the rule I always get this error:
2023-08-24 09:51:59.518 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'd1bd349ac8' failed: org.graalvm.polyglot.PolyglotException: Error: "2023-08-24T09:52:09.398+02:00[SYSTEM]" is an unsupported type for conversion to time.ZonedDateTime
2023-08-24 09:52:56.313 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : ConfigurableComponentHolder configuration updated for pid org.openhab.jsscripting with change count 5
2023-08-24 09:52:56.317 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : Querying state active
2023-08-24 09:52:56.319 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : Querying state active
2023-08-24 09:52:56.322 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : invoking modified: modified: parameters [org.apache.felix.scr.impl.helper.ReadOnlyDictionary]
2023-08-24 09:52:56.324 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : invoked modified: modified
2023-08-24 09:52:56.326 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : No change in target property for dependency $000: currently registered: true
2023-08-24 09:52:56.329 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : No change in target property for dependency $001: currently registered: true
2023-08-24 09:52:56.331 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : No change in target property for dependency osgi.ds.satisfying.condition: currently registered: true
2023-08-24 09:52:56.333 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : Querying state active
2023-08-24 09:52:56.340 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : ImmediateComponentHolder Finished configuring the dependency managers for component for pid org.openhab.jsscripting
2023-08-24 09:52:56.343 [DEBUG] [.internal.GraalJSScriptEngineFactory] - bundle org.openhab.automation.jsscripting:4.0.2 (240)[org.openhab.automation.jsscripting.internal.GraalJSScriptEngineFactory(307)] : ImmediateComponentHolder Will not enable component for pid org.openhab.jsscripting: holder enabled state: true, metadata enabled: true
2023-08-24 09:53:16.099 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: Error: "2023-08-24T09:53:26.061+02:00[SYSTEM]" is an unsupported type for conversion to time.ZonedDateTime
at <js>.toZDT(/etc/openhab/automation/js/node_modules/openhab/time.js:266) ~[?:?]
at <js>.check(/etc/openhab/automation/js/node_modules/openhab_rules_tools/timerMgr.js:46) ~[?:?]
at <js>.:program(<eval>:258) ~[?:?]
at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]
at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:71) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1188) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runNow(RuleEngineImpl.java:1039) ~[?:?]
at org.openhab.core.automation.rest.internal.RuleResource.runNow(RuleResource.java:381) ~[?:?]
at org.openhab.core.automation.rest.internal.RuleResource.runNow(RuleResource.java:398) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.4.5]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:517) ~[bundleFile:4.0.4]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.50.v20221201]
at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:310) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.50.v20221201]
at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.50.v20221201]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.50.v20221201]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
2023-08-24 09:53:16.127 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'd1bd349ac8' failed: org.graalvm.polyglot.PolyglotException: Error: "2023-08-24T09:53:26.061+02:00[SYSTEM]" is an unsupported type for conversion to time.ZonedDateTime
I have another question, how do I have to create items that should be used on Fridays and Sundays? For example Friday_night 23:30 and Sunday_night 22:50 ?
install the latest openhab-js library using npm and configure the add-on to not use the built in library; even though it’s the same library for some reason this fixes the problem
I’ve been hesitant to change this in the original template because it’s a temporary problem that will be fixed soon. I might just have to do it anyway.
