openHAB 3.2 Release discussion

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 ] [] - 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( ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at javax.script.SimpleScriptContext.setAttribute( ~[java.scripting:?]
        at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.addAttributeToScriptContext( ~[bundleFile:?]
        at org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl.createScriptEngine( [bundleFile:?]
        at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.createScriptEngine( [bundleFile:?]
        at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.getScriptEngine( [bundleFile:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute( [bundleFile:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.executeActions( [bundleFile:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.runRule( [bundleFile:?]
        at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$ [bundleFile:?]
        at java.util.concurrent.Executors$ [?:?]
        at [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
        at java.util.concurrent.ThreadPoolExecutor$ [?:?]
        at [?:?]
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:

omr@shs2:~$ ll /etc/openhab/automation/lib/javascript/community/
total 24
drwxr-xr-x 2 root root 4096 Apr 11  2021 ./
drwxr-xr-x 3 root root 4096 Dec 27  2020 ../
-rw-r--r-- 1 root root 5969 Apr 11  2021 timeUtils.js
-rw-r--r-- 1 root root 4199 Dec 27  2020 timerMgr.js

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.
1 Like

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.

1 Like

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

It depends.

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 this.

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:

ConfigStatusInfo [configStatusMessages=[]]

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.

1 Like

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

1 Like

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 , 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

A post was split to a new topic: Restore problem

It’s only me that don’t see how you can install bindings on OH 3.2?
The GUI have changed in 3.2. Seems like the documentation is now outdated.
Installation of Add-ons | openHAB

the look changed a bit but the entry to start with in the menu is the same.
You need to login with your admin account.

Thanks for your reply.
Seems like I got everything now after I restarted openHAB.

I discovered the same issue. I’m monitoring energy consumption with openhab and rrd4j using COUNTER definitions like yours.
This has been working for a year with openhab 3.1 but was broken after upgrading to 3.2. All values are now zero.

I had to downgrade to openhab 3.1 to keep my use cases working.