since openHAB 3.1 the new JavaScript Scripting automation add-on is available for using ECMA - 262 Edition 9.
With the new add-on installed, I have problems with importing openHAB host classes for actions like executeCommandLine. In openHAB 3.0, I was able to load the openHAB classes with:
// import Exec class
var Exec = Java.type('org.openhab.core.model.script.actions.Exec')
// import NotificationAction class
var NotificationAction = Java.type('org.openhab.io.openhabcloud.NotificationAction')
// execute a command line
Exec.executeCommandLine('echo hello')
It always worked well, but now I am observing these errors:
org.graalvm.polyglot.PolyglotException: TypeError: Access to host class org.openhab.core.model.script.actions.Exec is not allowed or does not exist.
org.graalvm.polyglot.PolyglotException: TypeError: Access to host class org.openhab.io.openhabcloud.NotificationAction is not allowed or does not exist.
How can I access these classes now?
As I need these Java classes, I am still using the old script enging based on ECMA - 262 Edition 5.1, but I would like to use ECMA - 262 Edition 9 for the new ECMA features.
Thanks in advance.
EDIT 1
The problem is not with my configuration as I was observing the problem above on a fresh openHAB install witth nealy no configuration. My problem is that I am not even able to import any openHAB Java class by Java.type('classname').
Importing a normal Java class like let BigDecimal = Java.type('java.math.BigDecimal') works.
openHAB classes only work with aliased names:
// import itemRegistry with the classname from the openHAB javadoc
let itemRegistry = Java.type('org.openhab.core.items.ItemRegistry') // throws an error as above
// import itemRegistry with an alias (I have this solution from the openHAB community)
let itemRegistry = require('@runtime').itemRegistry // does work
My problem is now, that I do not know how to import the other openHAB classes as I do not know how they are aliased. So how can I found out which aliases to use for what class?
Can’t tell for sure but I’d guess you didn’t properly configure the whitelist as is needed for executeCommand().
People, please, again: don’t post any of your issues in this thread unless you have identified them to be specific to 3.1 and a generic problem to potentially affect everybody, i.e. not caused by your config or rules. Open your own thread, please.
Just upgraded from latest 3.0.x to 3.1 on my production system. Big mistake.
OpenHab is down, UI not reachable after reboot, OpenHab logs empty, nothing OpenHab specific ins syslog that I can see. OpenHab service is shown as active.
The only thing that looks suspicious is a bunch of FireMotD related parsing errors in syslog. Any suggestions?
Tx!
Update: Updated FireMotD via openhabian-config, FireMotD errors gone, OpenHab still down with empty logs (length = 0), absolutely nothing in system logs that I can find…
Update 2: eventually got resolved with a bit of fiddling, thanks to a hint from Wolfgang_S, for details see this thread:
Hi all! in my case I had to rollback to 3.1.0 M5 again since after updating (done the upgrade and then after it failed I did a complete install from start) OH didn’t show any of my things.
I’m using a things file. The file was the exact same used in M5, in fact after the rollback I used the same file.
The only “customizations” I’m using is that I use the Sony TV binding, but I don’t think that it is the issue since if it doesn’t work it just doesn’t work but OH will work anyway (happened before). I also use a script for Tuya lamps.
Saddly I cannot upload the log because I had to rollback and didn’t back it up but this error was shown (it was larger, this is just the beginning that I rescued from my google search history)
I managed to fix my problem by uninstalling some dependencies stated in the Sony TV binding thread. It was this binding after all.
OH 3.1.0 is working now.
Check my post there if you are having issues like mine:
I seem to have this same issue with my Denon X2300W receiver. Wasn’t sure whether the upgrade to OH 3.1 was to blame or the recent firmware update I did on the Denon.
I found another issue. I needed to add/download the additional add-ons which are not in the official addon repo again into the addon folder. Otherwise they won’t recognized. In the milestone builds this was not an issue.
I cannot find the threads here in the forum right now, but afaik using startup text (DSL) rules should be avoided due to different issues that can come up. examples are timing or things like I am experiencing where builtin libraries are not loaded when the rule is executed (I had to introduce a sleep so that logInfo is available).
Another example: system started did work for me on OH 3.0.2…
Florian, did you find a solution ? I get the same issue with OH 3.1
I searched all fora for openhab to find a solution, but nothing seems to work. The remark that we have to whitelist isnt explained either, the key question is which classes do exist and if needed to whitelist, how to do that.
Script execution of rule with UID ‘e475b81b79’ failed: org.graalvm.polyglot.PolyglotException: TypeError: Access to host class org.openhab.core. is not allowed or does not exist
I am trying to find a way to get javascript to execute the sendHttpPutRequest again…
It’s not so much “should be avoided” as “limitations should be understood”. And yes, there can be timing issues in relation to other system services also starting up.
There’s no problem with self contained tasks like setting up some variables, or starting a timer for later actions.
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.