openHAB 4.0 Release discussion

Setup, Configuration and Use News & Important Changes
100

That is the solution…should I open a GitHub issue?

@mstormi what was now the issue to asking this here in this thread?

101

Yes if you expect a fix.
In this repo:

102

One week with OH4,

many thanks for the plenty of work done!

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.

103

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 ?

104

Hi to the openhab core developers - just wanted to say great job on the 4.0 release. When I moved from OH 2 → 3, I had what felt like hell on earth due to many thousands of lines of rules needing checking and correcting because of subtle differences in behaviours. With OH4 it was only 5 hours which is primarily my fault as I had to rebuild some bindings I had made for myself with I have not had time to prep for release. The move from 2 → 3 was at least 2 weeks with many hours a day. So great great job!!! On the release - it couldn’t have been a smoother transistion! :+1:

1 Like
105

I just stumbled across this:

106

Did the event triggers change from 3 to 4? I am using Jython (yes, I know…), all other Jython programs are working but this line is not catching the events.

            self.triggers = [GenericEventTrigger("openhab/items/", "ItemStateChangedEvent", "openhab/items/*", "").trigger]
107

Found a new issue I can’t change the username for the tr064 binding the default is coming back all time…

See here Bildschirmaufzeichnung vom 2023-08-03, 07-26-51 -

108

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.

1 Like
109

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?

110

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

111

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.

That one is probably impacted by https://github.com/openhab/openhab-core/pull/3299

1 Like
112

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

113

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.

114

Thank you!

115

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?

116

What hardware, what Java version?

118

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

119

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.

120

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.