openHAB 3.3 Release discussion

I just upgraded to 3.3 from 3.2 on my RPi 3B. Everything seems to work fine.

Thx devs!

Thanks for 3.3 of OH. I’m very happy about it. I’ve seen an issue with things or items which name starts with an number for example:


it could not be added and my existing links are missing.

From the docs:

Names must not begin with numbers.

Stricter checking was introduced in the latest versions of openHAB.


I upgraded from 3.2 to 3.3 (on Raspi / Docker) some weeks back, and after every (!) reboot of the entire Raspi, openHAB did not load with the following log entries:

Launching the openHAB runtime...
** /openhab/userdata/tmp/ (Permission denied)**
	at java.base/ Method)
	at java.base/
	at java.base/<init>(
	at java.base/<init>(
	at org.apache.karaf.main.InstanceHelper.writePid(
	at org.apache.karaf.main.Main.launch(
	at org.apache.karaf.main.Main.main(
!SESSION 2022-08-02 21:00:53.456 -----------------------------------------------
java.vendor=Eclipse Adoptium
BootLoader constants: OS=linux, ARCH=arm, WS=gtk, NL=en_US

!ENTRY org.eclipse.osgi 4 0 2022-08-02 21:00:53.731
!MESSAGE Error saving on update
** Permission denied**
	at java.base/ Method)
	at java.base/
	at org.eclipse.osgi.storagemanager.StorageManager.createTempFile(
	at org.eclipse.osgi.storagemanager.StorageManager.getOutputStream(
	at org.eclipse.osgi.internal.framework.StorageSaver$
	at java.base/java.util.concurrent.Executors$
	at java.base/java.util.concurrent.FutureTask.runAndReset(
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/

Just restarting only the openHAB container always solved the problem, but as a Newbie it almost derailed me.

From what I can see, this was a cache problem, which I resolved via…

sudo su
cd /var/lib/docker/volumes/
rm -r /var/lib/docker/volumes/openhab_data_openhab_userdata/_data/tmp/*
rm -r /var/lib/docker/volumes/openhab_data_openhab_userdata/_data/cache/*

Assuming this is not a usability problem on my side, maybe a future update can just empty the cache to avoid this.

It’s a permission problem. Did you by chance change the UID under which OH is running inside your container?

During an upgrade, the cache is already cleared automatically, but if the permissions are wrong it wouldn’t be able to do so. Look in userdata/logs/update.log to see if there were any errors after “Clearing the cache…”.

Not that I know of. If I remember correctly, I did a fresh install of 3.2 to get rid of another problem with frequent disconnects (unfortunately not successfully :confused:), restored my userdata via duplicati, and then some weeks later did the update.

Looks ok to me:

Replacing userdata system files with newer versions...
Clearing cache...
Performing post-update tasks for version 3.3.0:
  Deleting File: /openhab/userdata/config/org/openhab/mqttbroker.config
SUCCESS: openHAB updated from 3.2.0 to 3.3.0

All I can say is if it ever happens again, we’ll need to see the permissions on those files. File permissions all based on user and group and a “Permission Denied” error means the user openHAB is running under does not have permission to write (in this case) to that file nor permission to create files in those folders.

Given the complexity added by containers it’s easy to get this messed up. Beyond that, all I can do is repeat that the upgrade script already does clear the cache.


In case this comes up again I’ll report back.

I am having the same problem…and dealing with some life circumstances making it hard to troubleshoot. The things that do not initialize correctly are WLED and Hue Motion Sensors… I guess I’ll try to delete and re-add, but no amount of clean reboots and clearing cache seemed to help… and not sure where to look…

“systemInfo”: {
“configFolder”: “/etc/openhab”,
“userdataFolder”: “/var/lib/openhab”,
“logFolder”: “/var/log/openhab”,
“javaVersion”: “11.0.13”,
“javaVendor”: “Azul Systems, Inc.”,
“javaVendorVersion”: “Zulu11.52+13-CA”,
“osName”: “Linux”,
“osVersion”: “5.10.103-v7l+”,
“osArchitecture”: “arm”,
“availableProcessors”: 4,
“freeMemory”: 70032264,
“totalMemory”: 259522560,
“startLevel”: 70

and the hue sensor reports this:

{ledindication=The data type of the value (class java.math.BigDecimal) does not match with the type declaration (BOOLEAN) in the configuration description.}

A least for this the answer could be found in this thread by searching for “ledindication”. Likely you have a number like “0” that used to work, but now needs to be “false” or “true”. That is what the message says. “BigDecimal” is not “Boolean”. Details above.

1 Like