openHAB 4.0 Release discussion

Configuration for persistence add-ons, including the persistence strategy was moved in the UI to under the add-on’s page. Navigate to Settings → Other Add-ons → InfluxDB and click the little gear icon at the upper right.

I just found it myself… thanks for the confirmation

installing debian 12 on a vm using openhabian script. So far all good some knx items with uom that had to be changed and some profiles javascript transformation. All my config is via files so i would say painless so far. Still some showstoppers in my case unifi protect :frowning: but will wait and see if the dev will update the marketplace entry. All my rules are still in dsl so no major chage there aswell. I will probably end up going doing the ui route if there is no alternative but for now with all files config its still working.
thank you devs for the hard work.

1 Like

I observe the same behaviour:

  • Clean install of Openhabian with OH 4 (official release)
  • Restore my configuration from OH 3.4.4
  • Enocean add-on gets stuck with message “Trying to get base id…”
  • Add-on does not become Online

The add-on runs without issues on 3.4.4

There is also an open issue on Github: [enocean] USB 300 cannot be set up in OH4 · Issue #15181 · openhab/openhab-addons · GitHub

I’m sharing my experience with the upgrade.
I expected a smooth upgrade, since I had just installed a new installation on a PI3 with openhabian last week, with a OH4 (latest snapshot I guess?).
Only made small configuration with 5 bindings or so.

I started the upgrade and after it finishes, I couldn’t see any errors that on the linux prompt.
But at that point a wasn’t able to execute any commands.
After disconnecting I couldn’t connnect to the SSH, although the system was pingable.
Also de OH self, the frontail and Node-Red were offline.
After a power-cycle I was abble to reach linux again ans also Node-Red en frontail is working now.
Only OH not and is showing errors in frontail about openning a zip-file.

I have no idea what I could have done wrong here, but this worries my for upgrading my production with version 3.4.

Is there a way to restore this, or just write a new SD image and restore the backup?

The logging is showing the following:

2023-07-24 18:19:39.640 [ERROR] [Events.Framework                    ] - FrameworkEvent ERROR
java.util.zip.ZipException: Exception in opening zip file: /var/lib/openhab/cache/org.eclipse.osgi/58/0/bundleFile
	at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:356) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.doOpen(ZipBundleFile.java:51) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.internalOpen(CloseableBundleFile.java:140) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.lockOpen(CloseableBundleFile.java:78) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.getEntry(CloseableBundleFile.java:274) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.BundleInfo$Generation.getEntry(BundleInfo.java:425) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.ManifestLocalization.findResource(ManifestLocalization.java:238) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.ManifestLocalization.lookupResourceBundle(ManifestLocalization.java:165) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.ManifestLocalization.getResourceBundle(ManifestLocalization.java:136) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.ManifestLocalization.getHeaders(ManifestLocalization.java:78) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.storage.BundleInfo$Generation.getHeaders(BundleInfo.java:190) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.privGetHeaders(EquinoxBundle.java:520) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.getHeaders(EquinoxBundle.java:515) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.getHeaders(EquinoxBundle.java:509) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.apache.karaf.features.internal.region.SubsystemResolver.prepare(SubsystemResolver.java:178) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:390) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.util.zip.ZipException: zip file is empty
	at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1598) ~[?:?]
	at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1382) ~[?:?]
	at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1477) ~[?:?]
	at java.util.zip.ZipFile$Source.<init>(ZipFile.java:1315) ~[?:?]
	at java.util.zip.ZipFile$Source.get(ZipFile.java:1277) ~[?:?]
	at java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:709) ~[?:?]
	at java.util.zip.ZipFile.<init>(ZipFile.java:243) ~[?:?]
	at java.util.zip.ZipFile.<init>(ZipFile.java:172) ~[?:?]
	at java.util.zip.ZipFile.<init>(ZipFile.java:186) ~[?:?]
	at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:342) ~[org.eclipse.osgi-3.18.0.jar:?]
	... 21 more

looks like this is relatet to this one (maybe): https://community.openhab.org/t/openhab-not-working-with-zulu11-0-20/147910

Okay, maybe to quick with writing this. But after cleaning the cache it works again! Or at least is starting now.
For some reason I forget this option, but seems alway needed with after an upgrade?!
If so, maybe this should be added in the upgrade scripts?

But now the bindings are failing?

[ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing

Resource mvn:org.openhab.addons.bundles/org.openhab.binding.enphase/4.0.0 does not contain a manifest

It should happen as part of the upgrade automatically. The cache is where the add-ons get installed to so clearing the cache forces OH to go and download all the add-ons again, thereby upgrading the add-ons too.

However, is something goes wrong, and what you described certainly fits that, the download may be interrupted or otherwise result in a corrupted add-on which can cause problems.

I can’t offer any advice for the new error though. This is an official add-on?

Yes, they are all official add-ons. And all of them are failing not just one.
Like hue, cloud, openweathermap and so on.

Just preformed a restore from the backup. This solves the issue in the end.
But doesn’t give me the confidence for the upgrade from 3.4 tot 4.

Maybe I did something wrong, I don’t know, but all seems running again.

Thanks for all your effort and passion you have put into OH 4.0!
I am still on 3.4.4 but plan to upgrade. However, the release notes seem to be missing the section on breaking changes, or the link is not working properly. Is there another source that provides this information?
(sorry in case I am just not seeing the right information …)

I share unfortunately same experience as @JensD after receiving OH4 packages on my openhabian system. OH4 doesn’t or cannot initialize my enoceanpi bridge, that kills the communication to half of my automation items.

Please find log messages here:

Thanks, this link works!

I have two problems, which I could not solve and did not found any relevant information in the actual documentation.

The first problems are the UoM for my Netatmo setup. I did not understand, why I had to add the unit “%” to the channel for humidity, to get them work. It was something, I would expect from the binding himself. And this results in a sub-problem, I could not solve. I have the rain gauge and the new Units are (from Number:Speed) km/h for the rain value. In the Netatmo app, the unit is mm/h. Same for rain in the last hour. openHAB uses “m”, correct is “mm”. I tried to change this with , unit=“mm/h” and ,unit=“mm” and it seems, that openHAB uses this, because I could see the values in the UI, but when it rains an hour ago, I got no values in my setup. The rain from today afternoon, which was measure with openHAB 3.4.4, was visible in the history. All devices were online.

The second is a new problem coming from KNX. I had configured a scene with 1.022 as a switch. In real it is a switch and the scene have a ON and OFF. 1.022 is used in the ETS. I got now a message in openhab.log:

Configured DPT '1.022' is incompatible with accepted types '[class org.openhab.core.library.types.OnOffType]' for channel 'knx:device:bridge:bj_up_1_1_7_eg:k1'

See Release openHAB 4.0.0 · openhab/openhab-distro · GitHub which discusses changes to UoM in depth.

The way UoM is now implemented, the value you set in the unit is the unit the Item carries. If the binding updates the Item using different but compatible units, the value will be converted to the units defined in the unit metadata.

When there is no unit metadata supplied, the system default for that type of unit is used. For Speed the system default is km/h. As part of the upgrade process, if you have managed Items unit metadata was created and populated based on the State Description Pattern and, if that didn’t exist, from the Channel. If you have text file based Items, you must create the unit metadata yourself.

Logs? Events received by OH won’t just be dropped without errors in the logs.

Side comment, I checked the code, and the binding provides rain intensity values in mm/h. So even when linking the channel to a raw Number item (not Number:Speed), the values would be as expected.

Indeed which means the problem you are having has nothing to do with units. There is something wrong with the binding, channel, or link between the channel and the Item.

Is it now possible to configure the semantic tags by file manually? Haven’t read sth. in the blog post and also not finding a documentation page for it

1 Like

No, my proposal is not yet merged.
In the coming days, I will open a new topic, providing the required bundle and the instructoons / documentation for users who can’t wait for this feature.

3 Likes

Some of you report here, that they have after update to 4.0.0-1 some issues with unit’s, e.g. in Netatmo.
I have the same units problem, with my Shelly HT’s. (HT and HT Plus). The temperature value is shown currect with e.g. 25.0 degrees. But the humidity is shown in “0.6 one” and not in 60% as in the 3.4.4 Openhabian version it was in past.

Is this now a principle problem, or only one in the Shelly binding?