openHAB 4.0 Release discussion

[kjknauss (KJ)]

Says it right in the warning. Java 17 is required.

[mtrax (Paul (mtrax))]

thanks I am a but confused over the different java version Java 17 = OpenJDK 17 right is that the same as Zulu ? anyway installed Java17 and now starting… thanks

[wborn (Wouter Born)]

All the Java lingo can certainly be confusing.

@mtrax

Java 17

This is the specification of the language/APIs etc. It defines how to write your code and how Java Virtual Machines (JVMs) should behave.

@mtrax

OpenJDK 17

This is an implementation of the Java 17 specification. It is the most popular one. The OpenJDK code was open sourced by Oracle. Oracle obtained it after buying Sun Microsystems. It wasn’t always open source so some companies created their own implementation. This is how JVMs like OpenJ9 came into existence.

@mtrax

Zulu

Because OpenJDK is open source nowadays anyone can compile it and offer their own support model on top of that. The Zulu JVM (by Azul) is based on OpenJDK code. Oracle only offers limited
public support to non-paying customers. So if you want to use a JVM with good support you either have to pay Oracle or use a JVM from another vendor like the Zulu JVM.

---

If there is a Java 17 (openjdk) package available in the repositories of your Linux distribution try that one first (install it with apt/dnf/yum etc).

If it’s not available because you use an older Linux distribution (and don’t have time to upgrade it) use the Zulu JVM because it is most compatible with the oldest OSes.

If none of these work, you can also try other OpenJDK builds by other vendors such as Eclipse Temurin (formerly known as AdoptOpenJDK) or Amazon Corretto.

[betahydri (Jan Tiedemann)]

Same here you’re not alone see my rescent post.

[florian-h05 (Florian H.)]

@iLion

When I use the iOS openHAB-App (version 2.4.46), all properties are in English. The menu is called in German “Eigenschaften” and then I changes to English:

I am using the iOS app in version 2.4.58 (that’s via TestFlight), and for me everything works fine.

[Z0l (Zoltan Orosz)]

Hello,

Using OH 4 via docker, the upgrade went well but there was one single issue with the DSCAlarm binding. This was in the logs:

Configuration model ‘dscalarm.items’ has errors, therefore ignoring it: [39,61]: mismatched input ‘“shieldGreen”’ expecting RULE_ID

There is a single line in the example config that yields an error with OH4 and I checked the page of the binding and it still has the same syntax; the problem is with the <“shieldGreen”> statement in the below. This had no issues since OH2 or so. Removing that makes everything work again (and I admit I have no idea what it does).

String PANEL_TROUBLE_MESSAGE "Panel Trouble Message: [%s]" <"shieldGreen"> (DSCAlarmPanel) {channel="dscalarm:panel:MyBridgeName:panel:panel_trouble_message"}

[Lolodomo]

Yes, this was one of the breaking changes mentioned in the release notes.
Please propose a fix of the binding documentation, then I will merge it.

[Z0l (Zoltan Orosz)]

Here you go: Update README.md by Z0l · Pull Request #15334 · openhab/openhab-addons · GitHub

It’s my first pull request!

[Lolodomo]

Your first contribution is now merged (I just updated its title)

I just ran a search in all other binding README files without finding other similar examples. We are fine now I believe.

[milo (M)]

Hello I see always this message at startup

2023-07-30 12:20:37.750 [ERROR] [Events.Framework                    ] - FrameworkEvent ERROR
java.lang.NullPointerException: Cannot invoke "org.osgi.framework.wiring.BundleWiring.getRequiredWires(String)" because the return value of "org.osgi.framework.Bundle.adapt(java.lang.Class)" is null
	at org.apache.karaf.features.extension.BundleWires.<init>(BundleWires.java:52) ~[bundleFile:?]
	at org.apache.karaf.features.extension.StoredWiringResolver.update(StoredWiringResolver.java:130) ~[bundleFile:?]
	at org.apache.karaf.features.extension.Activator.bundleChanged(Activator.java:51) ~[bundleFile:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:949) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:229) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:138) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:130) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:217) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:857) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:560) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:503) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:492) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.start(Module.java:446) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1689) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) ~[org.eclipse.osgi-3.18.0.jar:?]

[J-N-K (Jan N. Klug)]

Did you set the log-levels?

[Hoerli]

Hi!

Have “accidentally” updated my openHAB from 3 to 4.
In the process, everything went completely broken first.
(RPi 4B - manual installation).

I had to update Java to Java 17, which turned out to be a dumb job at first.
The SDK script didn’t work cleanly, because the openHAB user didn’t get the Java variable, but only the user the script was executed with.
This cost me close to 2h of work and testing

After openHAB finally started, it broke a lot of Blockly scripts.
1st problem: All “get state from item” broke and had to be recreated. The blocks were previously “light green” and now “green” like a text block.
Error-Log for one example:

2023-07-30 13:26:00.293 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined
        at <js>.:program(<eval>:4) ~[?:?]
        at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvoca                                            bleAndAutocloseable.java:53) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationIntercepti                                            ngScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvoca                                            bleAndAutocloseable.java:53) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationIntercepti                                            ngScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:71) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) ~[?:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1188) ~[?:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:997) ~[?:?]
        at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]
        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-07-30 13:26:00.299 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'UsbLadestationAkkuLaden' failed: org.graalvm.poly                                            glot.PolyglotException: ReferenceError: "itemRegistry" is not defined

2nd problem: Additions don’t work anymore. 11 + 22 is not 33 but 1122. This can be fixed with “1x11 + 1x22”.
I have also checked that all items to be added are declared as number and not as text.

After I adjusted then 4h all scripts, no more errors seem to exist in the log.

[Wolfgang_S]

@F_Hatz

Could it be, that OH4 needs a lot more queing ressources than OH3.4?

what are your settings in EXTRA_JAVA_OPTS ?
In an other thread one complaint about slow running OH process.
After changing EXTRA_JAVA_OPTS it was running better.

[F_Hatz]

These are my settings (same as for OH3.4)
EXTRA_JAVA_OPTS=“-Xmx4G -Dlog4j2.formatMsgNoLookups=true -Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0 -Djdk.util.zip.disableZip64ExtraFieldValidation=true”

[BigGeorgeTx (George M Hyde)]

This is the thread to which @Wolfgang_S referred, which solved the problem for me running openHABian on a Pi 4 B with 2GB RAM:

Very High Memory Usage and frequent restarts with OH4

Since I upgraded from 3.4.4 to 4.0, I have noticed that everything is very s l o w. Memory usage is high, though processor usage appears low: [image] And openHAB restarts on its own frequently. I get an email from iCloud every time the binding reconnects after a restart, and I have received 76 since I upgraded the evening of July 23. (I have no reason to think the iCloud binding is causing the problem, I only mention it because the email from iCloud is an easy way to track it). There is no…

[iLion (Lars Gusewski)]

Hi, now it works also for me. In the upgrade documentation was a comment, that the renew-key for Netatmo is not longer necessary and could removed. I had done this and reauthorize the binding to connect. After this step, every Netatmo device was online, but there was no change. I simply restarted openHAB later and then it works. So to clarify: No UoM problem like I thought.

The only thing in the definition I made different was the use of “%unit” instead a “mm”.

[iLion (Lars Gusewski)]

When I use Safari on my phone to connect to my openHAB, I got a German translation, when I use the app, it stays also with 4.0.1 in English. I cleared cache again. No change.

[iLion (Lars Gusewski)]

So new problems with battery level and UoM. I have devices from AVM (DECT 301), Shelly (H&T), Netatmo Modules (Indoor and Outdoor) and Philips Hue (Motion Indoor and Outdoor) which all have a battery level channel. All of them should, when you look into the openHAB binding documentation (4.0.1), use an item type of Number and the UoM should be percent.

In my openHAB 4.0.1 only Netatmo delivers without any editing a percent value, which is shown with “%” in the UI.

Number eg_schlafzimmer_netatmo_innenmodul_messwert_batterie "Batteriestand" <battery> (gBatterie_Netatmo_Schlafzimmer) ["Measurement", "Energy"] {channel="netatmo:indoor:abcdefgh:basisstation:schlafzimmer:battery#value"}

For AVM and Philips Hue, I had to add a “,unit=”%" to the relevant channels, then the UI shows also “%”. Without, I got only a Number value like “73”.

Number eg_badezimmer_dect301_messwert_batterie "Batteriestand" <battery> (gBatterie_Thermostat_Badezimmer) ["Measurement", "Energy"] {channel="avmfritz:FRITZ_DECT_301:192_168_3_2:avm_fb_thermostat_badezimmer:battery_level", unit="%"}
Number eg_badezimmer_hue_messwert_batterie "Batteriestand" <battery> (gBatterie_Bewegungsmelder_Badezimmer) ["Measurement", "Energy"] {channel="hue:device:************:bewegungsmelder_02:battery-level", unit="%"}

Only Shelly H&T will not work like expected. I also added the “,unit=”%" to the channel and got then a value like “100.0” without “%”. Then I changed the item to

Number eg_badezimmer_sensor_messwert_batterie "Batteriestand [%.0f %unit%]" <battery> (gBatterie_Shelly_HT_Badezimmer) ["Measurement", "Energy"] {channel="shelly:shellyht:******:battery#batteryLevel", unit="%"}

And now it shows again only a battery level of “100” without any percent.

So my first question is, if anybody knows if the bindings for AVM, Hue and Shelly don’t have finally implemented the UoM completely?

And why is the behavior of the Shelly H&T so…?