[homematic] HM-CC-TC Thermostat HANDLER_CONFIGURATION_PENDING due to invalid default parameters

[BifbofII]

The default configuration of things for the HM-CC-TC device seems to contain invalid parameter values.

Expected Behavior

Configuration files (thing files) that are correctly working in OH2.5 should load correctly in OH3.x

Current Behavior

Loading thing files with HM-CC-TC things results in them ending up in the UNINITIALIZED (HANDLER_CONFIGURATION_PENDING) instead of ONLINE.
Full message shown in the web UI is available here and hints at invalid default parameters being set when the thing is loaded.
If a HM-CC-TC thing is created via the web UI, the configuration fields mentioned in the error message are highlighted red and need to be manually corrected to a value larger than 10 for the user to be able to create a thing.

Possible Solution

From what I can tell, this issue is very similar to #12183, which was related to another component and fixed in February in #12192. I am not familiar with the code enough to provide more pointers or fix it myself and create a PR.

Steps to Reproduce (for Bugs)

Via the web UI or with a thing file, create a thing for a HM-CC-TC device, you should see that the default values are invalid.
An example thing config:

Bridge homematic:bridge:ccu [ gatewayAddress="192.168.xxx.xxx", callbackHost="192.168.xxx.xxx" ] {
  Thing HM-CC-TC JEQ0012660 "Name" @ "Location"
}

Context

My OpenHAB instance is still running on v2.5 since I didn't have time to spend the time on upgrading.
Now I was starting to play around with this an this seems to not work right now.
Is there any way to fix this that his not creating the things via the web UI and fixing all of the invalid parameters by hand?

Your Environment

• OpenHAB 3.3.0
• Homematic 3.3.0
• OpenHAB Docker on Debian

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/update-to-openhab-3-1-0-breaks-homematic-binding/124095/28

[MHerbst]

I think this problem is caused by a change in OH core that checks configuration settings for valid values.

The Homematic binding sends a request to the CCU to receive possible values and also a default value. It seems that for some devices the returned data is maybe not correct. I have tried to find out the allowed values for this devices but they are not documented in the official documentation from EQ3.

Maybe you can help me with a trace logging: please set the log level for the Homematic binding to TRACE and then restart OH. After the restart and loading the thing definitions openhab.log should contain information about the retrieved information. I would need this information.

[BifbofII]

Thanks for looking into this. This should be the log you asked for. openhab.log. I'll gladly provide more log traces if necessary.

[MHerbst]

Thanks for the log file. It is the suspected cause. The returned configuration information for the TIMEOUT data points contain these values:

HmDatapoint[name=TIMEOUT_THURSDAY_4,value=null,defaultValue=0,type=INTEGER,minValue=10,maxValue=1440,options=null,readOnly=false,readable=true,unit=minutes,description=TIMEOUT_THURSDAY_4,info=null,paramsetType=MASTER,virtual=false,trigger=false]

The binding expects a minimum value of "10", but the default value is "0" and this is outside the allowed range. I will have to look into the code. I think the validity check can be modified that default values are accepted if they are outside the allowed range.

[MHerbst]

@BifbofII I think, I have solved the problem but I don't have device that I can use to verify the solution. I have uploaded a test version of the add-on here: https://github.com/MHerbst/openhab-addons-test (should also work with 3.3).

Please give it a try. If it works correct now, I will create a PR

[BifbofII]

I just tested your updated version and it works. Thank you so much for your help.
If you create a PR now, will this become available with OH 3.4 or is the release of addons independent from OH itself?

[MHerbst]

If you create a PR now, will this become available with OH 3.4 or is the release of addons independent from OH itself?

I have created a PR but the solution will be officially available only with 3.4.