openHAB 4.0 Release discussion

There is an unfortunate bit here which, if I can figure out how to fix I would in a heartbeat.

This code is JS Scripting with the helper library which is what Blockly converts to in OH 4. The JS Scripting library goes to great lengths to present everything as a pure JavaScript class/object/etc.

Unfortunately, in UI rules, we get the raw Java event Object. That means event.<anything> is going to give you a Java Object. event.oldItemState therefore is a Java State Object, not a String. The Java org.openhab.core.library.types.OnOffType.OFF does not equal the String "OFF".

The easiest thing to do will be convert the event.oldItemState to a String before comparing it to 'OFF'. Of course, you could also import OnOffType and compare to OnOffType.OFF instead but you’d need to use an inline script block to do that.

Note, this is going to do a string compare meaning '8' <= '75' will be false. You probably want to get the numeric state of the Item instead of the .state (the “get [name] of item” block let’s you get the numeric state) and compare to a number 75.

This comparison is fine because the state is a String so you are comparing String to String and it will match.

1 Like

Built small remote server from scratch to replace one of my 3.44 devices. The install worked great and I have it running perfectly as a remote back to my 3.44 server. I have had so much trouble with Logs in the past, that I decided to do this one from scratch instead of update. Since it worked so well, I will probably do the rest that way. Just wish there was a way to export my configs and import into the new device. I have 3 RPi3b+ remotes reporting to my main server. Main server is RPi4 with 100 Things, 256 Items and 63 Rules. Thanks for a great update.

1 Like

Thanks! I added the blocky “create text with” in between, solving the thing with 4.0 now! YAY! This leads to the code received_command = String(event.itemCommand);

And the numeric comparison worked with your other proposal to get the state, leading to the code if (75 <= items.getItem(‘OpenWeatherMap_Wetter_Bewolkung’).numericState)

Yesterday i make a clean Openhabian install with OH4 and restore my configuration from by 3.4.4 system. When I select a trigger “a trigger channel fires” in the rule UI, I cannot select a channel to fire. Also old Rules with a trigger channel fired will not work on the new system. I use the Astro Binding for sunset, sunrise etc…

Maybe you’ll have to update the FireMotD cache. Try

sudo FireMotD -G all

I have a major issue since upgrade, seems to be JAVA related, I’m a but confused about what Java version I should : I have Ubuntu server which Zulu 11 and Oracle v8 java versions

  Selection    Path                                         Priority   Status
  0            /usr/lib/jvm/zulu11/bin/java                  2116601   auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java   1111      manual mode
* 2            /usr/lib/jvm/java-8-oracle/jre/bin/java       1081      manual mode
  3            /usr/lib/jvm/zulu11/bin/java                  2116601   manual mode

java -version
java version “1.8.0_191”

when I upgrade I got warning:

[openHAB] WARNING: We were unable to detect Java 17 on your system. This is needed before openHAB can be started.

now I get errors during startup

2023-07-29 13:23:50.648 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-runtime-base; type=karaf.feature; version="[4.0.0,4.0.0]"; filter:="(&(osgi.identity=openhab-runtime-base)(type=karaf.feature)(version>=4.0.0)(version<=4.0.0))" [caused by: Unable to resolve openhab-runtime-base/4.0.0: missing requirement [openhab-runtime-base/4.0.0] osgi.identity; osgi.identity=openhab-core-base; type=karaf.feature [caused by: Unable to resolve openhab-core-base/4.0.0: missing requirement [openhab-core-base/4.0.0] osgi.identity; osgi.identity=org.openhab.core.config.core; type=osgi.bundle; version="[4.0.0,4.0.0]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.core.config.core/4.0.0: missing requirement [org.openhab.core.config.core/4.0.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.openhab.core.common.registry)(version>=4.0.0)(!(version>=5.0.0)))" [caused by: Unable to resolve org.openhab.core/4.0.0: missing requirement [org.openhab.core/4.0.0]; filter:="(&("]]]]
        at org.apache.felix.resolver.Candidates$MissingRequirementError.toException( ~[org.eclipse.osgi-3.18.0.jar:?]

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

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

All the Java lingo can certainly be confusing.

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

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.

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.


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

A post was split to a new topic: Problem after upgrade

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


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"}

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.

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

It’s my first pull request! :slight_smile:


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

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


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>( ~[bundleFile:?]
	at org.apache.karaf.features.extension.StoredWiringResolver.update( ~[bundleFile:?]
	at org.apache.karaf.features.extension.Activator.bundleChanged( ~[bundleFile:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.applyDelta( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolveAndApply( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolve( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer.resolve( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.start( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$ ~[org.eclipse.osgi-3.18.0.jar:?]

3 posts were split to a new topic: High load on OH4

Did you set the log-levels?


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 :frowning:

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( ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at javax.script.AbstractScriptEngine.eval( ~[java.scripting:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvoca                                   ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationIntercepti                                   ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvoca                                   ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationIntercepti                                   ~[?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0( ~[?:?]
        at java.util.Optional.ifPresent( ~[?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute( ~[?:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.executeActions( ~[?:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.runRule( ~[?:?]
        at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$ ~[?:?]
        at java.util.concurrent.Executors$ ~[?:?]
        at ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$ ~[?:?]
        at ~[?:?]
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.