openHAB 3.3 Release discussion

Hi Rich,

I migrated to OpenHAB 3.3 yesterday. The migration was flawless except my semantic model was mixed up. It is caused by the enforcement of items starting with numbers - the floors in my house are called 1st en 2nd floor in the semantic model. an intuitive name but not permitted now.

In my openhab log I receive errors pointing to this.

I can not change the names in the semantic model. Can you help me how to solve this (rename the items to first and second floor)?

Related to “Handler” issues with Zwave devices: Check the Zwave database for your device and go to the parameter tab. Most of the problems I see reported are with devices that are flagged with “Limit to Options” set to “true” (red funnel), BUT where not all the options allowable between the minimum and maximum are listed. The solution is to either switch the “limit to Options” flag to “false” or to add to the “options” at the bottom of the page.

For instance parameter 2 on this device can only be “0” even though the max is 255.

Hope this helps.



Do these number starting Items appear in Settings → Items? If so, delete the Items there and then recreate them with new names that do not start with a number (there is no such thing as renaming an Item in OH).

If they do not appear there I’m going to assume that they also do not get returned by the REST API. But on the chance that they do, go to Developer Tools → API Explorer and run a query for one of the numbered Items using the items REST API endpoint. If something is returned then you can use the delete REST API endpoint to delete it. Then recreate the Items normally, this time not starting the name with a number.

If you can’t do that you can just ignore the fact that these Items ever existed and just create new Group Items with allowed names and ignore the fact that the wrong ones are still there.

If you really want to clean this up, stop openHAB. Then go to $OH_USERDATA/jsondb. Search through all the files there for all instances of one of these number starting Items and replace it with a different name that doesn’t start with a number. Then restart openHAB. It’s really easy to mess something up editing the JSONDB file manually so be careful and take backups.


@Kai can you add this note as breaking change openHAB 3.3 Milestone discussion - #60 by ssalonen

As I am relatively new with OH I haven’t done upgrades earlier. So, what is the best strategy to upgrade from 3.2 to 3.3?

I would read the release notes here Release openHAB 3.3.0 · openhab/openhab-distro · GitHub first. If you don’t want to read the whole thing, at least read the Breaking Changes section.

Then take a backup, mine is on a computer that runs debian so I just run “sudo openhab-cli backup” to do this.

Then upgrade. Usually there aren’t any issues, but if you have serious ones you can revert to 3.2 and then restore your backup.


Great, many thanks for your advise.

I tried @openhabgs 's code editing suggestion (thanks!) and found it does persist across restarts. Luckily the “invalid” values are ones I don’t use, so to me it doesn’t matter what they are set to. The only issue I’ve noticed is you get messages in the log complaining about applying an invalid configuration (the old values before you edited the code). But the device still works fine.

2022-06-30 17:11:59.602 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=config_11_1; type=BigDecimal; value=0}, {key=group_5; type=EmptyList; value=[]}, {key=group_4; type=EmptyList; value=[]}, {key=group_1; type=EmptyList; value=[]}, {key=group_3; type=ArrayList; value=[controller]}, {key=group_2; type=ArrayList; value=[controller]}, {key=config_2_1; type=BigDecimal; value=0}, {key=config_7_1; type=BigDecimal; value=-2}, {key=config_8_1; type=BigDecimal; value=3}, {key=config_9_1; type=BigDecimal; value=3}, {key=config_3_1; type=BigDecimal; value=0}, {key=config_4_1; type=BigDecimal; value=-69}, {key=config_5_1; type=BigDecimal; value=-85}, {key=config_6_1; type=BigDecimal; value=-1}, {key=node_id; type=BigDecimal; value=37}]' on thing 'zwave:device:daf3e8da:node37' blocked. This is most likely a bug: {config_7_1=The value -2 does not match allowed parameter options. Allowed options are: [ParameterOption [value="254", label="Default (0xFE)"]], config_4_1=The value -69 does not match allowed parameter options. Allowed options are: [ParameterOption [value="187", label="Default (0xBB)"]], config_5_1=The value -85 does not match allowed parameter options. Allowed options are: [ParameterOption [value="171", label="Default (0xAB)"]], config_6_1=The value -1 does not match allowed parameter options. Allowed options are: [ParameterOption [value="255", label="Default (0xFF)"]]}
1 Like

Thanks for pointing this out. I had gone back to openHAB 3.2, and restored my backup, but now I’ve upgraded to 3.3 again and edited the device code to get me by as @openhabgs suggested. On my 2nd upgrade attempt this mimolite device was the only one that caused me trouble. I removed the z-wave snapshot binding before upgrading this time so I think that may be why it went better.

Anyway, I got access for the database from Chris and edited those parameters so they match the technical guide (which was helpfully attached in the database as well). So this should be fixed (for this one device) in openHAB 3.4.

Thanks for your fast response!

These number starting items are not ‘‘real’’ items but the names of a location in my semantic model. E.g. 1e for first floor.

The error in my log is:
2022-06-30 22:20:20.720 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add “GroupItem” with key “1e”: The specified name of the item ‘1e’ is not valid!

I can not view the item with the API explorer.

Since my sematic model is a mess now, I really want to solve this. Is editing jsondb really the only way forward?

You can just call the DELETE endpoint in the API explorer, even if the item is not listed.


Minor issues during updating, the apt-get upgrade showed issues with conflicting vlc-bin (raspberry pi buster OS). But with some manual purging/cleaning/rebooting they we’re resolved.

3.3 resolved two issues for me. Reconnecting the android app after wifi loss and using colors on some Lidl zigbee RGB lights/ledstrips.

So great job, very happy here :smile: :+1:


I’ve tried to setup a fesh new OH system on a separate RPi, but I did not get it running. I’ve tried it a couple of times, but without success. I’ve used the 32 and 64 bit OH images for RPi from the download section.

As mentioned in the download area, waiting 15 to 45 minutes have no effect.

64 bit:

  • Using balena etcher to flash SD card
  • Start RPi with SD card
  • Auto-reboot after 5 seconds; the RPi comes up with default message from Raspi OS
  • Package config starts
  • Select keyboard layout … OK
  • Rename user Pi (but Pi is not a valid user). Alternatively I’ve tried to rename openhabian and the I got the request to enter a new user. But this step fails with an error message that userlib does not exist

32 bit

  • Same like 64 bit, but at Rename user I’m directly asked to create a new user … OK
  • Then openhabian screen occurs, but without any version information. After using the openhabian-config to install latest version it looks normal
  • But there some problems, e.g. the openhab webserver does not run and the log is full of errors like:

2022-07-03 16:17:49.208 [SEVERE] [org.apache.karaf.main.Main] - Could not launch framework
java.lang.IllegalStateException: Error initializing storage for Equinox container.
at org.eclipse.osgi.internal.framework.EquinoxContainer.(
at org.eclipse.osgi.launch.Equinox.(
at org.eclipse.osgi.launch.EquinoxFactory.newFramework(
at org.eclipse.osgi.launch.EquinoxFactory.newFramework(
at org.apache.karaf.main.Main.launch(
at org.apache.karaf.main.Main.main(
Caused by: /var/lib/openhab/cache/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)
at java.base/ Method)
at java.base/
at java.base/
at java.base/
at org.eclipse.osgi.internal.location.Locker_JavaNio.lock(
at org.eclipse.osgi.storagemanager.StorageManager.lock(
at org.eclipse.osgi.internal.framework.EquinoxContainer.(

Until now, I did not manage it. Maybe I should install it from scratch manually based on Raspi OS lite?

Thx for any hints!!

maybe try a different SD card?

The used SD card is new, I’ve unpacked it yesterday. But yes, I’ll try another one (as soon as I get another one)

Ugraded my Raspi 4 to openHAB 3.3. Worked fine. Thank you for this great work.

I noticed something, however (not sure whether it only affects me). In order to find problems I set the log level for openhab.event, org.openhab and some “special” bindings of mine (somfytahoma, boschindego) to WARN. After that the system rebooted irregularly every 5-10 minutes.

Also, after apt-get upgrade I had problems with permissions of the persistence folder After some testing there seemed to be a zram problem. Reinstalling helped. Fix permissions on openhabian-config returned an error.

Confirming that I am getting exactly the same issue with Node Red. Nodes are not updating even thou logs are showing events are occuring. Reverting back to 3.2.

This issue is already fixed.
See here: openHAB 3.3 Release discussion - #69 by randomname
There is full OH3.3 support.

But not is your using the Openhab2 node. So only choice is to redo all the nodes under Openhab3 - and I tried this once before as you can’t just upgrade.

Export all your nodes.
Open in notepad ++.
Replace the openhab2-xyz nodes with openhab2-xyz2 nodes.

Save and import.
Then open all in nodes and activate the needed options. It takes no time at all.