[SOLVED] Item updated through HTTP binding channel automagically returns to UNDEF state after ~13s

OpenHAB 3.3.0
Debian Linux

An Item that gets its state from a HTTP channel returns to the UNDEF state shortly after it has received a value from the HTTP channel.

HTTP binding with the following Things definition:

Thing http:url:nefitpressure "Nefit Easy pressure" [
        Type number : CVPressure "CV water pressure"

and Items definition:

Number CV_Pressure "Water pressure [%.1f bar]" {channel="http:url:nefitpressure:CVPressure"}

Somehow, about 10-13 seconds after the Item state is updated with the correct value, it returns to the UNDEF state. I turned on debugging for the HTTP binding, but nothing shows up in the logs, except:

2022-12-14 20:49:12.446 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CV_Pressure' changed from UNDEF to 1.9
2022-12-14 20:49:25.057 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CV_Pressure' changed from 1.9 to UNDEF

Nothing else shows up in either of the two logs.
Also, nowhere else in my configuration is the CV_Pressure Item referenced as I have not yet added it to any Widget or rule/script.

Any suggestions how to debug this?

Debugging 1on1: try to set the specific binding you want to check to DEBUG or TRACE level. So you open the console (running on native Linux it’s openhab-cli console in SSH - on docker it’s docker exec -it openhab /openhab/runtime/bin/client (see Docker). Password is habopen in standard. Then you can set the http-Binding to TRACE-leve with log:set TRACE org.openhab.binding.http. After that you should see all the stuff, that’s going on with http-binding in openhab.log. oh and reverting it back to “INFO” is same: log:set INFO org.openhab.binding.http

It should tell you, if the baseURL always responds with the correct JSON. My 2cents are, that the thermostat responds with a 500er error from time to time.

Hi @binderth,

Thanks for the tips. I did turn on debugging for the HTTP binding, but nothing extra is logged. I’ll switch to TRACE to see if it helps.
I’m not so sure it has to do with the response of the device since it is set to poll every 30 seconds and the ‘switch’ back to UNDEF happens 13 seconds after a value is retrieved. We’ll see…

Sorry for the delay. When changed from DEBUG to TRACE it finally started showing some relevant logging.