openHAB 4.0 SNAPSHOT discussion

[jsscripting] Fix regressions from #14135 & Log stack on `IllegalArgumentException` by florian-h05 · Pull Request #14142 · openhab/openhab-addons · GitHub has been merged, the regression is fixed.
I just need to update the docs.

I don‘t know how jRuby does this, but I am not sure whether this would be possible with JS Scripting.

1 Like

Bundler has a feature that allows installing gems inline in a script. So we just run a script generated in Java that’s essentially:


require "bundler/inline"

bundle do
  gem <gem and requirements from addon config>
end

Though in the past we’ve done things more directly reaching into RubyGems internal and calling install gem or something. But this all works because RubyGems and Bundler are part of Ruby/JRuby itself. AFAIK npm isn’t part of node (and/or the GraalVM JSScripting uses?).

Yes, npm is no part of NodeJS (at least there are two different apt packages). In fact GraalVM itself does provide a npm command when you install the NodeJS runtime, but openHAB is neither on GraalVM nor do we use Graal‘s NodeJS runtime, we use the Context API/GraalJSScriptEngine. I don‘t see a chance to perform a npm install from JS Scripting.

3 Likes

I figured it was a long shot. But no harm in asking.

3 Likes

Is there actually something like a OH4 timeline, when a first public release can be expected? Thanks!

SNAPSHOT versions are build nightly and already available.
Milestone versions will/should be available monthly, so M1 is expected beginning of February 2023.
Following our release concept, stable version is planed for end of June 2023.

Hello gents,

Items in JS rules can’t get Items:

I’m running OH4 SNAPSHOT #3276
I have Item name: MotionTimer

I have JS rule:

And when I’m Running this rule I get an ERROR in log and rule not working.

I think some issues with that

var TimerMinutes = items[“MotionTimer”]

I’m also try what Rich Koshak doing with Included JS library

Now I’m stucked with Rules…may be you can suggest something?

With best regards,

Alexey

JS Scripting ECMAScript 2021, right? I ask because this code looks a whole lot like Nashorn ECMAScript 5.1 and the two are not the same. For one thing, JS Scripting doesn’t have an items dict like that.

While you can make Nashorn rules work in JS Scripting, especially for something this short and simple you would do well to rewrite it to use the Js Scripting add-on’s helper library.

Also, you shouldn’t use the this.timer = blah blah blah trick anymore in either language. Use the privateCache.

The rule should look something like this (I’m just typing this in, debugging is an exercise to the student).

console.loggerName = 'org.openhab.rule.'+ ruleUID;
var TimerMinutes = items.getItem('MotionTimer').state; // note the state is always a String in this usage

console.info('TimerMinutes: ' + TimerMinutes);
var timer = cache.privateCache.get('timer');
if(timer !== null) {
  timer.cancel();
}

var turnOff = () => {
  var i = items.getItem('CoridorRoomLightCeiling1_Power1');
  i.sendCommand('OFF');
  console.info('MotionSensor turned ' + i.state); // this almost certainly never worked, 
                                                  // it takes time for an Item's state to reflect the result of command,
                                                  // it likely has always shown the old state.
                                                  // I left it as is to have a one-to-one translation of the original, errors and all
  cache.privateCache.put('timer', null);
};

cache.privateCache.put('timer', actions.ScriptExecution.createTimer(time.toZDT('PT'+timerMinutes+'M') , turnOff);

That is staying as close to the original as possible. However, JS Scripting has a native JavaScript Timer capability which could be used here too with setTimeout.

All the syntax and types involved when using Js Scripting with the helper library are documented here.

There is one thing to note though. In OH 4 the mime types for Nashorn and GraalVM JavaScript have swapped. Previously application/javascript was for the older Nashorn and application/javascript;ecmascript=2021 (or something like that) was for JS Scripting (i.e. GraalVM JavaScript ECMAScript 2021). Now JS Scripting gets the standard type and Nashorn gets the one with ;ecmascript=5.1 or something like that.

If your problem is you have some Nashorn rules and you want to continue to use Nashorn, you’ll need to:

  1. Install the Nashorn JS addon
  2. Open the “code” tab for your rules and change any place you see application/javascript to what ever is required for Nashorn (right now I can’t create a Script with Nashorn even though I’ve it installed for some reason so I can’t tell you exactly what it should be).

Or you can just install the Nashorn add-on and uninstall the JS Scripting addon. That might work.

I think there is a plan to make this switch happen automatically in the future but that’s not done yet.

4 Likes

Thanks a lot Rich,

You are make my day again! You solved my problem with your good explanation. Unfortunately, I don’t have too much experience in JS programming, but now I understand the difference.

Both suggested options helped for me. In the new rules I will use JS, and in the old ones I will change the type for Nashorn:

type: application / javascript; version = ECMAScript-5.1

With regards,

Alexey

Is there a workaround for using SCRIPT instead of JS for MQTT transformationPattern (UI setup), or is it defined similarly as Profile?

In the transformation pattern you can use it in the same way as you use JS. There is no profile yet, but there are two competing PR: Intoduce a profile for the generic SCRIPT transformation by J-N-K · Pull Request #3292 · openhab/openhab-core · GitHub which is similar to the other transformations and https://github.com/openhab/openhab-core/pull/3135 which has a different approach. There is also Allow inline scripts in SCRIPT transformation by J-N-K · Pull Request #3249 · openhab/openhab-core · GitHub which adds inline scripting to the SCRIPT transformation.

2 Likes

Good to know it should work, and I have managed to use SCRIPT directly for Modbus readtransform/writetransform. For MQTT I have tried changing from

transformationPattern: JS:energySave.js

to

transformationPattern: SCRIPT(graaljs:energySave.script)

having the .script file in the transform folder. It runs without error, but linked item does not update. Will have to look further into it.

Is there anyway to install the javascript transformation? I do not see it in the binding section. did they change something where this is no longer a thing?

I am getting alot of errors for it

2023-01-23 17:03:05.657 [WARN ] [t.generic.ChannelStateTransformation] - Transformation service JS for pattern RemoveLetters.js not found!

Since the SCRIPT transformation is already part of 3.4, I would suggest to open a separate thread for that. I would suggest to post the script you use, so someone can debug or give a hint what is wrong.

1 Like

Javascript transformation has been removed because it depends on Nashorn Javascript which is no longer available in Java 17. It has been replaced by the SCRIPT transformation, although the profile is still missing and WIP.

Okay, I was just checking it out and seeing how it was going to play with my current system.
Since the SCRIPT transformation is already part of 4.3, if I tried to slowly convert everything from JS transformation to SCRIPT transformation. Are the profiles in 3.4 working? If so, once I get that working in 3.4 it should theoretically work when the profile is working in OH4, correct?

There is no profile for SCRIPT in any version of OH yet.

@J-N-K

I saw this at startup on build 3292. I have 4 jars in the addons directory. 3 of the 4 bindings have been modified for addon.xml; 1 has not been converted. Not knowing one way or the other if this could be related to having an unconverted binding, I thought it best to mention.

2023-01-24 08:25:01.094 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.0.0 (build Build #3292)
2023-01-24 08:25:01.156 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.util.ConcurrentModificationException: null
        at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1712) ~[?:?]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
        at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[?:?]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
        at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
        at org.openhab.core.internal.addon.JarFileAddonService.refreshSource(JarFileAddonService.java:143) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        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:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]
2023-01-24 08:25:01.219 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'US/Eastern'.```

I’ve seen this the last few times I’ve upgraded the snapshot. It’s pretty consistent so it’s worth reporting I think.

After an upgrade, when OH comes back online, my logs get filled up with:

2023-01-24 09:32:37.968 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.

Restarting makes these messages go away. It’s a minor annoyance but probably needs to be addressed before we release.

It’s complaining about the Shelly Binding but the warning comes from core so it’s not clear where the problem lies.

On a different note, after just upgrading an hour ago I’m seeing the following from Zigbee which I want to investigate a bit.

2023-01-24 09:37:30.609 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 000D6F000A79BADF: Exception creating channels                                                  │
20│java.lang.IllegalArgumentException: UID segment 'zigbee:device:zg_coordinator:000d6f000a79badf:000D6F000A79BADF_1_voltage' contains invalid characters. The last segment│
20│ of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'.
        at org.openhab.core.thing.ChannelUID.validateSegment(ChannelUID.java:136) ~[bundleFile:?]
        at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[bundleFile:?]
        at org.openhab.core.thing.UID.<init>(UID.java:66) ~[bundleFile:?]
        at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:59) ~[bundleFile:?]
        at org.openhab.core.thing.internal.ThingImpl.getChannel(ThingImpl.java:125) ~[?:?]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:377) [bundleFile:?]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:244) [bundleFile:?]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [bundleFile:?]
        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:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]

It looks like something changed in the last week regarding what’s allowed for Thing IDs?

Edit: An initial investigation appears that the discovered Things use the MAC address as the UID which contains numbers and letters which should match the pattern. :confused: The regex101 tester matches no problem.

I don’t recall seeing such a PR in core but I don’t thoroughly read them all so maybe missed it.

The regex reported doesn’t make much sense to me either. Why [\w-]*|[\w-]*? They are both the same expression.

And why is it Zigbee the only one reporting the error? All most all of my other Things have a mix of numbers and letters and some start with numbers too and those are working no problem. Maybe something changed on the binding (I don’t read those issues and PRs, there’s too many)?

1 Like

I think it’s trying to account for channel UIDs with groups (the regex to the right of the |) and without groups (to the left of the |).

Edit:
Because it’s complaining about the channel UID, not the Thing UID. Does it not like the underscores?