openHAB 4.0 Release discussion

[Mherwege (Mark Herwege)]

@Lolodomo

@opus

The new input item is coming greatly ( sending text to home-speakes from elsewhere). A small inconsistency remains. While using it on a sitemap file: After a change of the input field it is set if another control gets select when using it in a browser, when using it from.within the android app the input field needs to left via an Enter on the the keyboard.

Not clear at all, even if I understand that it s a conflict problem between Basic UI and the Android app ?
@Mherwege : maybe you understand better than me ?

I think I do.
Indeed, in the Android app, touching outside of the field without using the keyboard entry does not update the value. This has been a concious decision. It would allow you to not update when you make a mistake in the field by touching outside of the field. It would also not update if you mistakenly touched outside of the field when you were not fully done with your input (creating multiple updates that may not be wanted). I had behaviour implemented in the Android app where just losing focus of the field would update the value, but it got rejected as not standard Android type of behaviour and I tend to agree. The suggested alternative was to add a button to confirm the update in the Android app, but I felt there is already the enter key to do just that. It was deemed more Android standard behaviour, but I didn’t want to take up the screen space.
Using BasicUI on an Android mobile phone with Chrome, I don’t get an enter key. I don’t know if similar behaviour as with the Android app would be possible.

[glen_m]

I’m having trouble accessing the provided link, so not sure if you doing this via UI …but here’s a real blind long shot. I had a similar issue with another binding which kept on reverting it’s config… Drove me crazy for while… Until I found and old binding config file sitting in the directory, which changed the setting everytime OpenHAB started…Changed extension to .old, problem went away, UI config remains unchanged now …
Again, a bit of a blind long shot, but sounds similar?

[opus (Jürgen Baginski)]

@Mherwege

This has been a concious decision.

Thanks for the reply on the effort to build the update.
I understand the reasoning.The topic for me is solved!

[rlkoshak (Rich Koshak)]

@mjcumming

Did the event triggers change from 3 to 4?

Yes. From the announcements:

• core.GenericEventTrigger and core.GenericEventCondition parameters have have changed. See Next-Gen Rules | openHAB.
• Rules are now triggered by ItemStateUpdatedEvent instead of ItemStateEvent. If you use JSR223 scripting without helper libraries and expect a certain Java type, code changes might be needed.

There were a number of PRs that impacted rule triggers including but not limited to.

• Add event information in rules for time, manual and RunRuleAction trigger by J-N-K · Pull Request #2965 · openhab/openhab-core · GitHub
• rework GenericEventTrigger and GenericEventCondition by ccutrer · Pull Request #3299 · openhab/openhab-core · GitHub
• Add group name to GroupStateTriggerHandler by J-N-K · Pull Request #3536 · openhab/openhab-core · GitHub
• Fix wrong event subscription in GroupStateTrigger and ItemStateTrigger by J-N-K · Pull Request #3533 · openhab/openhab-core · GitHub

@mjcumming

all other Jython programs are working but this line is not catching the events.

That one is probably impacted by rework GenericEventTrigger and GenericEventCondition by ccutrer · Pull Request #3299 · openhab/openhab-core · GitHub

[ccutrer (Cody Cutrer)]

I’ll check this when I get a chance. I have CO2 sensors myself, and haven’t noticed problems exposing them to HomeKit.

[ccutrer (Cody Cutrer)]

Ah, I see what’s going on. You have a single Number:Dimensionless item linked to both CarbonDioxideSensor.CarbonDioxideDetectedState (the required characteristic for a CarbonDioxideSensor that simply says “I detected CO2” or “I didn’t detect CO2”) and CarbonDioxideSensor.CarbonDioxideLevel (the optional characteristic that can give an actual reading).

In openHAB 3.4, CarbonDioxideDetectedState could not be linked with a NumberItem, but apparently it silently ignored it. openHAB 4.0 introduced the ability to link Number items to many more characteristics that are semantically boolean or enumerations (see the introduction paragraph at https://www.openhab.org/addons/integrations/homekit/#supported-accessory-types). It’s also logging when it can’t convert the item’s state to the enum value as you can see. Because clearly a QuantityType is not the proper thing to link to a detected/not detected characteristic.

If you don’t care about HomeKit showing detected/not detected state, and just want the actual value, I would create a dummy switch item whose value is always OFF, and link that to CarbonDioxideDetectedState. Or write a rule to update that item based on your desired threshold value. You might also consider opening a feature request issue to allow linking a QuantityType type to CarbonDioxideDetectedState, with a lowThreshold configuration to do this automatically, similar to how the BatteryLowStatus works.

[mjcumming (Michael Cumming)]

Thank you!

[plugg3n (Brynjar Honningsø)]

So i upgraded to 4.0 today, on an ubuntu system.
My binding are not doing well.
It can be some and all things to the handler which says not yet ready, trying to pause and enable it I just get handler error.
This is LG, Denon, Nad, free@home, netatmo, and probably more.

So, tried to reinstall the handler, no success.
If i create a new thing, identical to the one failing, it comes up ok=green, until i restart openhab, then the same error.
Take an example of netatmo binding, the bridge is green and ok, but the items go grey (not ready, and get handler error).
Another example at the free@home binding, got like 10 things there, and about half is green and half is grey…

Gonna try debug and se if i can see something more as the normal log doesnt give me anything.
Suggestions?

[hmerk (Hans-Jörg Merk)]

What hardware, what Java version?

[plugg3n (Brynjar Honningsø)]

Its a big tower with a lot of disks, quite old hardware, but i3 540 intel, 4gb ram
@server:~$ java --version
openjdk 17.0.7 2023-04-18

[Hoerli]

I have only tried to start openHAB again.

I did not do a pre-check of the scripts at this time.
Wanted to have the Java problem solved first.

I absolutely did not see the new “get [name] of item” block.
Have now rebuilt the scripts with it. The calculations seem to run again now.

[rlkoshak (Rich Koshak)]

I don’t think that’s a new block. We’ve always been able to use that block to get the name, label, etc of the Item even on OH 3. But support for getting the state as a number or quantity from that block is definitely new in OH 4.

[Rbartlett (Rodney Bartlett)]

Minor annoyance. Thing Event Status changed selection Bubble does not go away after clicking on choice. You have to click somewhere else to close it.

So far everything is working great.

[Rbartlett (Rodney Bartlett)]

I have now migrated all 4 of my servers to new 4.0 installs. They are working great. Had to learn the scripting changes in 4.0 but they were much easier to do now. I use a lot of timers and clear timer. My main server was a lot of work since it has a lot of things, items and rules. But all is working great now. Thank you again for all the work you do to make this a great product.

[lukics (Slaviša Lukić)]

Initially, I had a lot of trouble when I first tried to upgrade my OH3.4.4 version to OH4.01, though the root cause for these problems was not related to this release.
After fixing these other issues the version OH4.01 is running and things seem to be overall ok.

The only thing I see right now is that my OH4.0.1 container is constantly consuming more and more memory. During the troubleshooting of this my other issues I have installed Cadvisor monitoring so I do not have any older data relating to my running OH3.4.4 version.

Right now I see this situation:

I still have enough memory, I use RPI with 8GB, although I can do math with 100MB/24h when the memory will all be used up.

[supersjel (Michel)]

For me most trouble was getting the java 17, but I found this page on the raspberry forum how to upgrade buster to bullseye (although officially not recommended). After that the upgrade to openHAB 4.01 was a piece of cake. Just had to install the old javascript engine for the old rules, change some rule code and fix (a lot of) units i the things. But that was all named in de OH 4 F.A.Q.

@lukics I was a bit afraid of the memory too, but after a day it all settled. Maybe (because of the reboot) it’s the raspberry file cache and JVM heap filling. After a day I observe the normale garbage collection saw tooth pattern and memory usage is stable again. Maybe it will happen for you too (hardware = rasperry PI and I configured the JVM heap at 1Gb). Timeline is a week, First 2 days messy because of upgrade, reboots and fixes on broken rules. After the last peak my fixes are complete and it runs normal again. It loses memory for about a day. And then the sawtooth starts and memory free stabalizes.

[Lolodomo]

I can see mine growing up slowly.
Will see after few days.

Regarding the number of threads used by the java process:

The load of the java process:

[Lolodomo]

It looks like the memory usage first grows up but finally it stabilizes.

So I see no obvious general memory leak in OH4, that is a good news.

[derjoern (Joern Seemann)]

I’m starting to plan my upgrade to 4.0 but the section on breaking changes is missing from the documentation. Where can I find this information?

[wborn (Wouter Born)]

Check the 4.0.0 release notes for more details including breaking changes:

Release openHAB 4.0.0 · openhab/openhab-distro