openHAB 4.0 Release discussion

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?

For humidity or more generally for all Number:dimensionless items, you need to set a unit to your item, that is adding unit=“%”.

Could you please try to use 1.012:x/x/x (replace x/x/x with your group address) as group address for that channel? This explicitly sets the DPT in openHAB.

For reference:

Look for “Another example” where this humidity example is explicitly mentioned.

When adding now the “%” to the metadata under unit, I get this error:

Can you show us your item definition?