openHAB 4.0 SNAPSHOT discussion

I have just tried to upgrade my Windows 10 system to 4.0.0-SNAPSHOT. I was not able to access the Web or SSH after the upgrade and get the following openhab.log

openhab.log (8.8 KB)

I installed zulu17.40.19-ca-jdk17.0.6-win_x64 and set JAVA_HOME to C:\Program Files\Zulu\zulu-17


Any suggestions on what may be wrong?

Windows! :smiley:
Nah, just kidding but i guess there is something wrong with your configuration. Create a backup and then go with a clean fresh install of 4.0. Once you have it up and running you can try to restore your backup step by step.

Great job guys :wink:
I’ve decided to give 4.0 a try last night to see what the logs throw at me. Transition went really smooth and everything is looking good and is working fine so far.

What i haven’t figured out yet is how i’m able to whitelist my shell scripts again.

2023-03-02 04:45:12.358 [WARN ] [ng.exec.internal.handler.ExecHandler] - Tried to execute '/etc/openhab/html/muellabfuhr/ %2$s', but it is not contained in whitelist.

contents of misc/exec.whitelist , just in case i need to go and see the eye doctor and finally need a pair of glasses :upside_down_face:

/etc/openhab/html/muellabfuhr/ %2$s

Owner, rights and location (misc/exec.whitelist) are correct and the contents are unchanged.
It has been working fine with 3.4. Guess there has been a change that i kinda missed?

No, that’s probably a bug. I’ll check that.

1 Like

Thx Jan, but no rush. Thanks for everything you did so far. You are an incredible force in this project and it would not be the same without you. :+1:


I wanted to say that for the first time in a long while I’m usually getting a completely clean start. :partying_face: Great work to everyone!

However, I’ve been seeing something odd the past few snapshots which I’m pretty certain is a timing issue. I’m still investigating and need to confirm this but it seems that two out of every three starts of OH, any rules that trigger soon after runlevel 40.

This can be because of an event (e.g. an instance of Thing Status Reporting [; triggering because of the Things coming online, Items which start to receive events before runlevel 80, or an explicit runlevel rule like Delay Start [;

When this occurs, I’ll see

20│2023-03-02 10:35:25.924 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'rules_delayed' failed: <eval>:1:4 Expected ident but found {│
20│var {helpers} = require('openhab_rules_tools');                                                                                                                         │
20│    ^ in <eval> at line number 1 at column number 4                                                                                                                     │

for every rule that runs during this period. It’s always that first line of the rule it complains about. Once runlevel 100 is reached (maybe as early as 80, I’m adding stuff to verify) the rules work just fine.

It’s not the worse thing in the world, though it does break my Delay Startup rule which is supposed to turn off some rules that shouldn’t fire until start is closer to complete.

I’m going to try to narrow down the timing a little better but reporting the initial behavior in case someone can say “Oh I know what’s going on!”

See [exec] Fix whitelist not read by J-N-K · Pull Request #14522 · openhab/openhab-addons · GitHub


Answered my own question. For addon’s that don’t do anything karaf specific, or use new features from above java 11, the following works to create a hybrid build of the jar…

-Dohc.version=3.2.0 -Dmaven.compiler.source=11 -Dkaraf.version=4.3.7


looool so viel zu lass dir zeit… ich war nur kurz im bad. vielen dank <3

Thx again Jan. Problem solved. I just updated. Whitelisted scripts are being executed.
Logs are clean and everything is back to normal. :+1:

Just upgraded to snapshot 3343 and I’m getting flooded with jetty upnp exceptions. Opened an issue here…

EDIT: I was on 3335 before this, concerned that the Jetty upgrade from the Karaf upgrade may be the cause here.

A fix was done yesterday to jupnp and the fix is working.
Unfortunately, the last snapshot (3344) is still packaged with the old jupnp version (2.6.1) while the version 2.7.0 is required.

Sweet! I’ll hold for the next snapshot.

EDIT: 3347 seems to fix the issue.

As most experts on the status+stability of 4.0.0-SNAPSHOT are hanging around in this thread, let me ask the question here: Do you think we are now ready for a first milestone release? Our release build has finally been fixed yesterday (thanks to @pfink!), so that we could do a milestone any time. Let me know, what your feeling is and if you see some critically broken things right now that should be fixed first.

Any chance we can get some of the pending bindings reviewed and merged in prior to?


I’m running a recent snapshot build (#3346) in 2 locations. Both installations have around 30 addons installed. One location has about 150 things and 2000 items; the other has about 120 things and 1300 items. Both are running very smoothly.

The only thing I’d like to see included in the milestone release is the support for channel groups in the thing update instructions. It feels to me like the thing update instructions are a large and new feature that would benefit from testing through a few milestones releases. If we miss the March milestone release, we only have the April and May milestone releases before the full release in June. There also are a few addon PRs that are dependent on this change.

I too have been running the 4.0 Snapshot as my production system and the last week has been pretty smooth. I’m still seeing a few issues around startup (see above with the Shelly binding after a cache clean and that intermittent problems with rules). I’m also seeing a couple of errors from the zwave and ZigBee bindings but they do not seem to impact their ability to function.

Once OH comes up it runs really smoothly. I love watching my events log zooming by with openhab.log mostly silent because nothing’s wrong.

My system is more modest with 15 bindings, 382 Items, 71 Things, and 65 rules (about a third of which come from rule templates posted to the marketplace).

From my side I see no major bugs that absolutely have to be fixed. Though we might want to spend a little bit on a migration guide given the need to upgrade the OS many will face to get the required version of Java.

I too have my pet major feature of like to see added sooner rather than later in the overhaul to UoM. That’s one breaking change that could impact a lot of users so getting it in front of a wider audience sooner can help us develope migration guides and possibly even migration tools.

But that shouldn’t stop the creation of a milestone.

Slightly off topic, please excuse, but:

I’d like to second this. The PR for my binding has been open for more than one year, and I’m definitely not the only one who has a long standing PR like that. Since the 4.0 migration will be a pain for the addon marketplace [1] it would be great if somebody could check the queue of pending PRs before it’s too late in the 4.0 cycle.

[1] Since the jars are not compatible, one needs to open 2 threads to support both versions, which both is harder to keep track of and dilutes discussions between both threads. It would have been great if the marketplace supported multiple jars/kars per thread and choosing the right one by checking the version number or some metadata.

1 Like

I think it’s pretty stable too now and packed with new features compared to 3.4. :slight_smile: So I’d create an M1 ASAP so we don’t loose any more time with testing. It will hopefully also give users a stable milestone to revert back to in case unstability is introduced due to more changes.


After some major difficulties last weekend, the snapshots are stable again.
Some new features are still in progress but I think there is nothing that should prevent generating a first milestone.

1 Like

Have some issues since yesterday with IPCAMERA binding

sending a picture if someone rings on door

rule "Haustuer Foto"
   Item Haustuer_Klingel changed to ON
	{val telegramAction = getActions("telegram","telegram:telegramBot:Telegram_Bot")
	telegramAction.sendTelegramPhoto("", "Haustür")

Haustür:Download failed with status 500
calling the URL from browser result:

HTTP ERROR 500 java.lang.IllegalStateException: !asyncSupported: NotAsync:org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet@536b0858
URI:	/ipcamera/192168493/ipcamera.jpg
MESSAGE:	java.lang.IllegalStateException: !asyncSupported: NotAsync:org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet@536b0858
SERVLET:	org.openhab.binding.ipcamera.internal.servlet.CameraServlet
CAUSED BY:	java.lang.IllegalStateException: !asyncSupported: NotAsync:org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet@536b0858
Powered by Jetty:// 9.4.50.v20221201

not sure if it is related but happens since upgrade yesterday