The short answer here is that the new GraalVM JavaScript addon has almost nothing in common with the built in Nashorn JavaScript support. So pretty much everything is going to work differently. Unfortunately there are not a whole lot of examples of docs written for this add-on yet so your best bet will be to look at the README and actual code at GitHub - jpg0/ohj: Openhab Javascript Library for examples on how to use it.
As you figure it out I’m certain contributions to the docs would be most welcome.
Most of those issues were fixed in OH 3. OH 3 introduced startup levels which makes it possible to delay the execution of startup rules until the rest of OH is ready. However the way that system started rule triggers changed. In OH 2 when you reload a .rules file it will trigger the system started rules. That is not longer the case. Instead system started rules only run when the system started. If OH is already up and running and you load a .rules file, the system started rules will not trigger again because the system has already started.
There was an issue to add a new rule loaded trigger but I don’t know the status of that.
I have an issue that appeared after upgrading to OH 3.1 (from 3.0) as well… Mainly my Z-Wave USB stick stopped working. And judging by the debug logs it seems to be a serial port issue:
2021-07-10 15:45:52.495 [DEBUG] [ort.serial.internal.RxTxPortProvider] - No SerialPortIdentifier found for: /dev/ttyACM0
It was working just fine with 3.0 for months and survived several minor upgrades, but not the 3.1 one. If anyone has any ideas, I have a thread open here:
I upgraded from OH3.0 to OH3.1. I didn’t see any error messages during the upgrade. Everything is working except the icons used on pages within cards are no longer displayed. These icons are stored in the folder /etc/openhab/html/icons (SMB share: \\openhab\openHAB-conf\html\icons ). It might be a problem with access rights or the OH build-in webserver. Any hints how to solve or analyse the problem?
I rebooted several times and checked the log.
The following warnings show up about 30s after the start:
2021-07-14 18:25:17.330 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Vienna’.
2021-07-14 18:25:17.367 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘47.51782094289231,10.717695237253793’.
2021-07-14 18:25:17.370 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘de_AT’.
2021-07-14 18:25:17.371 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to ‘SI’.
2021-07-14 18:25:25.142 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘SmartHome.items’
2021-07-14 18:25:26.340 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘rrd4j.persist’
2021-07-14 18:25:31.272 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2021-07-14 18:25:31.517 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘SmartHome.rules’
2021-07-14 18:25:41.900 [INFO ] [org.openhab.ui.internal.UIService ] - Started UI on port 8080
2021-07-14 18:25:45.389 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@19e4d10[provider=null,keyStore=null,trustStore=null] 2021-07-14 18:25:45.391 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@19e4d10[provider=null,keyStore=null,trustStore=null]
I don’t know if these warnings are indicators of a authentication problem. Any idea how to solve that?
This behavior started after the upgrade from 3.0 to 3.1 without any other change. Same problem on Windows PC Web-Browser and Android App on two tablets. I run openhabian on PI4.
Your help is very much appreciated.
3.1.0 Release version spawned a terminal error list so I reverted back to 3.1.0-M4 because I didn’t trust it. 3.1.0-M4 has always had an error free terminal window,
I did a logout/startup of the new OH a few times but it still generated this error list in the terminal.
Screen shots of terminal window attached. Does anyone understand this gibbberish??
I did my upgrade in the usual way by creating a backup and then restoring that backup into the newly downloaded version.
Thanks in advance.
Hi Wolfgang, so OH3.1.0 release now flags these inconsistencies? Can I just ignore the problem? I think there were errors showing up run the OH user log too. How would I find and fix the problematic item? All my items have seemed fine and nothing has showed as null up till this upgrade claims that something is amiss.
If MapDB were throwing an error over Item state NULL, that would be a bug. That should be silently ignored when persisting, and as it is ignored there should not be any persisted NULLs either. You’ll likely have hundreds of Items in NULL state at system startup.
Equally random guess, there’s a bit of rubbish in your MapDB database (potentially from OH1 days depending on your migration route) that new persistence code is choking on.
I wonder what happens when an Item changed type since last recorded. Maybe a restore-on-startup used to fail silently and now complains.
How costly would it be to delete your DB and let it start a fresh one? MapDB is usually only used for restore-on-startup
I upgraded 3.0.? to 3.1 using apt on a Ubuntu system. I rebooted and OH did not come up. In the logs I see the following errors:
2021-07-13 02:18:24.477 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-core [66]
2021-07-13 02:18:24.523 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-frontend-jaxrs [67]
2021-07-13 02:18:24.530 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-rs-client [68]
2021-07-13 02:18:24.545 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-rs-sse [69]
2021-07-13 02:18:24.549 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-security [70]
2021-07-13 02:18:24.552 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-transports-http [71]
I don’t know if that points to a problem as some seem to be listed as “optional”. But those were the only things in the log. A quick search on the forum on “Could not resolve” returned a post that a reboot helped, and another suggested editing a pom.xml file (although that was for different dependencies). So I rebooted and now I’m not getting anything in the logs.
Before I start digging into this more I’m hoping someone might know of a quick resolution. When OH isn’t working I realize how much I use it! I did take a backup before the upgrade, but (silly me) have never tested a restore. For that do I need to load the 3.0 package with apt then just run the openhab-cli restore command?
Hello Ross,
I’m not sure what you mean about an item changing ‘type’ since last recorded but I doubt that because I would have created the backup file only 5 mins before doing the restore into the new OH version. Also, I never had OH1 and I have rebuilt the system from scratch a few times during ver OH2.x.x so there’s unlikely to be any rubbish in the MapDB.
Surely there can’t be major code differences between 3.1.0-M4 and the final Release 3.1.0… how can a final release be WORSE than the preceding later Milestone versions???
I’m going to have to stay with M4 until a clear definitive diagnosis and cure is recommended by the user community. Thanks for your thoughts anyway.
Sounds like you need to ask for your money back, really. How dare they not give you an immediate definitive diagnosis.
Let us know if you ever want to look into it further.
Dear Bernhard, I have the same problem as you are describing with the icons. Another user also described that issue here:
I’ve recorded a GIF to show the issue. It always happens when I’m navigating to another page. And it happens since I’ve updated to OH3.1.
After a refresh the images appear again.
you’re hilarious Ross… seriously though, sounds like you’ve misinterpreted my reply and have taken umbrage at me expressing a modicum of frustration that a release version might disappoint. I am always polite and very appreciative of help from the community members and do try to contribute to the forum also with solutions.
Courtesy costs nothing…
Thank you @Integer Mike for your quick reply. In my case refresh does not help.
Your reply motivated me to deeper analyze the behavior.
When I open the overview page (default start page without “/page/…” in the URL) the icons are displayed even after I do a refresh (I first thought that they show up because they are stored in the cache).
The problem seems to be related to the OH build-in webserver (URL, timeout, …?)
F7 icons work fine, only icons stored on the OH build-in webserver do not show up (icons stored in the folder /etc/openhab/html/icons … SMB share: \\openhab\openHAB-conf\html\icons ).
I get a similar problem, when I am using the openHAB App (Android) and try to rotate the tablet cross or upwards.
The error occurs only, if u open a widget like in this case “Wohnzimmer” from the overview page.
When the overview page is displayed solo, the rotation works fine.
Tried to record my tablet screen, hope it is bearable.
Exactly that was the thread I remembered but couldn’t find (@NCO for your reference) . AFAIK the startup levels cannot be used in rules but only in the UI though. Therefore the “started” trigger still fires quite early when not all items are loaded. So in my example this leads to logInfo() not being available during startup.
Now that I am thinking of it I probably should use virtual startup-items that get triggered by UI rules which have a proper startup-level trigger to avoid the issues.
I’m getting the same error
‘’’
org.graalvm.polyglot.PolyglotException: Error: Invalid CommonJS root folder: /etc/openhab/automation/lib/javascript/personal
‘’’
unfortunately for me I can’t get past it, have tried everything I can think of.I’m doing scripts from within the rule not file level.
running on 3.1.0
you’re hilarious Ross… seriously though, sounds like you’ve misinterpreted my reply and have taken umbrage at me expressing a modicum of frustration that a release version might disappoint. I am always polite and very appreciative of help from the community members and do try to contribute to the forum also with solutions.
