2 posts were split to a new topic: Icons do not load
2 posts were split to a new topic: Zwave ERROR HANDLER message after upgrade
After updating from 3.1.1 to 3.2.0, my Honeywell TH6320ZW thermostat is not detected properly any more. Seems like Chris removed it from the ZWave binding and has it added back in 3.3.0-SNAPSHOT according to posts in this thread, though I haven’t tested this myself:
In openhab.log I get a new error
2021-12-28 13:00:29.562 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 0039:0011:0008::1.3
The thermostat does still work with any existing Items. But if you try to create a new Item, you can’t - the Thing is empty.
A post was split to a new topic: Error message
Installation of the latest Z-Wave binding snapshot (openHAB-ZWave [Jenkins]) should solve this problem:
Note, this is what happens if you have the wrong credentials for the /etc/openhab/automation folder.
Just updated to 3.2.0 Release Build. (Ubuntu)
All is well.
After reading the Release notes in Kai’s 3.2.0 is here post, I decided to try out JSScript’ing.
Prior to this, I have used DSL only.
When installing JSScript, I noticed these two entries in the log:
2021-12-29 22:55:48.509 [WARN ] [nternal.fs.watch.JSDependencyTracker] - Failed to create watched directory: /etc/openhab/automation/js/node_modules 2021-12-29 22:55:48.535 [WARN ] [rulesupport.loader.ScriptFileWatcher] - Failed to create watched directory: /etc/openhab/automation/js
Letting it slide, I tried creating my first ever JS rule (a 1s test-ticker), only to get this in the log:
2021-12-29 23:35:01.972 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - Error while creating ScriptEngine org.graalvm.polyglot.PolyglotException: Error: Invalid CommonJS root folder: /etc/openhab/automation/js/node_modules at org.graalvm.polyglot.Context.eval(Context.java:379) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.evalInternal(GraalJSScriptEngine.java:376) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSBindings.initGlobal(GraalJSBindings.java:94) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSBindings.initContext(GraalJSBindings.java:90) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSBindings.requireContext(GraalJSBindings.java:84) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSBindings.put(GraalJSBindings.java:127) ~[?:?] at javax.script.SimpleScriptContext.setAttribute(SimpleScriptContext.java:246) ~[java.scripting:?] at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.addAttributeToScriptContext(ScriptEngineManagerImpl.java:254) ~[bundleFile:?] at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.createScriptEngine(ScriptEngineManagerImpl.java:144) [bundleFile:?] at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.createScriptEngine(AbstractScriptModuleHandler.java:92) [bundleFile:?] at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.getScriptEngine(AbstractScriptModuleHandler.java:88) [bundleFile:?] at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:59) [bundleFile:?] at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1180) [bundleFile:?] at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:988) [bundleFile:?] at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:89) [bundleFile:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:829) [?:?] 2021-12-29 23:35:01.984 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '915601a534': Fail to execute action: 2 2021-12-29 23:35:01.985 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '915601a534': Fail to execute action: 2 2021-12-29 23:35:01.986 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '915601a534': Fail to execute action: 2
This is primarily to notify about this behaviour.
Secondly, for me to remedy this situation, is it enough to just manually create these 2 directories?
Think I found the source of my problem.
A year ago I added this:
And I had created a /etc/openhab/automation folder without user openhab write access.
Have remedied this now, and after deleting the test rule and creating another one, the rule runs, but with this warning:
2021-12-30 00:02:23.252 [WARN ] [.internal.OpenhabGraalJSScriptEngine] - Failed to retrieve script script dependency listener from engine bindings. Script dependency tracking will be disabled. 2021-12-30 00:02:23.890 [INFO ] [org.openhab.automation.script ] - Ticker 1s 2021-12-30 00:02:24.235 [INFO ] [org.openhab.automation.script ] - Ticker 1s
I looked for a way to Remove the JSScript add-on, but couldn’t find it.
Wanted to re-install with openhab access to the automation directory. Unsure how serious the warning is though.
Edit: was able to remove the JSScript add-on after a karaf bundle uninstall and an openHab restart.
After a remove/re-install, I still get this warning: (but rule is working)
2021-12-30 00:02:23.252 [WARN ] [.internal.OpenhabGraalJSScriptEngine] - Failed to retrieve script script dependency listener from engine bindings. Script dependency tracking will be disabled.
2021-12-30 15:13:26.998 [WARN ] [.internal.OpenhabGraalJSScriptEngine] - Failed to retrieve script script dependency listener from engine bindings. Script dependency tracking will be disabled.
I am also trying to get the JSScripting to work and got the same error above.
Would be cool to have a migration guide to the new JS dialect.
What have you do? I thought my fingerprint sensor is broken, but now i realize it’s the update’s fault. Before the update i set
channel="nuki:smartlock:***:***:lockState" to value “7”. But this does not work anymore.
they have changed the action-codes in the nuki-binding.
Please read the actual documentation at Nuki - Bindings | openHAB
You have to change the action-codes.
This is benign and can be ignored for now.
See Migrate from Nashorn to JSScripting for UI Rules and the docs for the JS Scripting add-on.
Thank you. That in itself did not help, unfortunately.
But I have now managed to get things running. The two underlying issues that appear to have caused my problems were
- The System Info binding; there appears to be an issue there, as expressed by a number of users here
- for some reason I still had a copy of openhab-addons-3.1.1.kar lying in my addons folder
After uninstalling the binding and deleting the *.kar file things appear to be running well now.
Is the only workaround in OH3.2 for global variables to create items for each variable or are there better solutions? I usually use them as gate-variables to enter loops and stuff. Any other suggestions are welcome! Cheers
If using .rules files, continue to do it like you always have.
If UI rules, with Rules DSL, you are out of luck and have to use Items.
If UI rules using Blockly, you can store values and get them back from one run to the next four a single Script Action/Condition, but you cannot share the variable between Script Actions/Conditions. The same can be done in Nashorn by saving to
JSScripting has a
cache Object which let’s you share variables between Script Actions/Conditions.
Just FYI, I tried again, updating via M5 and RC1, all worked fine this time.
Many thanks Rich,
I’m using .rules files only, so I should be fine I guess. I encountered problems with old rules I took over from OH2.5, but if you say global variables still work as usual on OH3.2 within rules files the problem is somewhere else.
As my problem has been split from this thread I’d like to come back again and want to raise hand that there are now several users complaining about Memory Leak problems. They can be reproduced - see thread here and here.
If moderators like to split this post again, then please simply delete this post. No need to restart all over again…
Just upgraded an Ubuntu 20.04LTS x86 system using apt. Smooth upgrade, working great! Thanks to all involved.
A few observations:
I noticed that openhab.log now provides more more verbose description of validation issues with configuration files. It helped me fix some sitemap validation issues logged by previous OH versions that I couldn’t figure out before (I still use a few sitemaps). Nice add. I didn’t see this in the release notes but maybe I missed it.
Z-wave BE469ZP Deadbolt - was not immediately recognized and the following entry was in the log:
This was solved by manually locking and unlocking the door several times. This thread helped… Trouble with battery powered Z-Wave things
Interestingly the openhab log that included the z-wave issue described above seems to have been overwritten. I have checked all openhab.log.x files in /var/log/openhab and the log representing running OH 3.2 the first few times while troubleshooting this message appears to be missing. Logs prior to and after the upgrade are all present. Not sure how this could happen.
In any case all is well now and thanks again. I am looking forward to experimenting with the new features. Keep up the good work.
I get the same error when simply move one level down in the sitemap menu. The error message is
Unexpected exception occurred while processing REST request.
After this comes many lines in the log with derived error messages.
The problem arises both in a browser using BasicUI and when using the Apple iOS app for OH.
This worked fine without problems in version 3.1
Not sure if it’s different in a “3.2 clean-install”, but my in “3.2 as updated from 3.1”-install, the link mentioned in /sitemaps/readme.txt is https://www.openhab.org/docs/configuration/sitemaps.html , which leads to a 404.
The correct link should be Sitemaps | openHAB from what I can see (so a “/ui/” got included in there).
Maybe nitty-gritty-feedback, I know, but I just stumbled upon this and this would’ve made things more difficult for me three months ago, when I was trying to understand the sitemap-logic.
A post was split to a new topic: Log xml question