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.
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.
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)"]]}
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.
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?
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.
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.(EquinoxContainer.java:110)
at org.eclipse.osgi.launch.Equinox.(Equinox.java:53)
at org.eclipse.osgi.launch.EquinoxFactory.newFramework(EquinoxFactory.java:35)
at org.eclipse.osgi.launch.EquinoxFactory.newFramework(EquinoxFactory.java:30)
at org.apache.karaf.main.Main.launch(Main.java:291)
at org.apache.karaf.main.Main.main(Main.java:183)
Caused by: java.io.FileNotFoundException: /var/lib/openhab/cache/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)
at java.base/java.io.RandomAccessFile.open0(Native Method)
at java.base/java.io.RandomAccessFile.open(RandomAccessFile.java:345)
at java.base/java.io.RandomAccessFile.(RandomAccessFile.java:259)
at java.base/java.io.RandomAccessFile.(RandomAccessFile.java:214)
at org.eclipse.osgi.internal.location.Locker_JavaNio.lock(Locker_JavaNio.java:40)
at org.eclipse.osgi.storagemanager.StorageManager.lock(StorageManager.java:403)
at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:716)
at org.eclipse.osgi.storage.Storage.getChildStorageManager(Storage.java:2194)
at org.eclipse.osgi.storage.Storage.getInfoInputStream(Storage.java:2211)
at org.eclipse.osgi.storage.Storage.(Storage.java:256)
at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:184)
at org.eclipse.osgi.internal.framework.EquinoxContainer.(EquinoxContainer.java:108)
Until now, I did not manage it. Maybe I should install it from scratch manually based on Raspi OS lite?
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.
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.