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.
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?
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.
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.
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.
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.
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.
@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.