Channel types or config descriptions for thing missing in the respective registry

Hans_Lree · February 24, 2025, 5:12pm

Continuing my evaluation of openHAB 4.3.2, I’m now constantly getting warnings during startup

Channel types or config descriptions for thing 'homematic:HM-TC-IT-WM-W-EU:ccu:MEQxxxxxxx' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.

for all six HM-TC-IT-WM-W-EU textual Thing definitions.

Looks very much like a new incarnation of the previously logged issue

github.com/openhab/openhab-addons

[homematic] Thing definition for HM-TC-IT-WM-W-EU with channels for SET_TEMPERATURE delay causes log error

opened 03:46PM - 07 Nov 19 UTC

closed 07:28AM - 27 Jul 21 UTC

DigiH

bug

For my HM-TC-IT-WM-W-EU wall thermostats I have manually defined the things as f…ollows ``` Thing HM-TC-IT-WM-W-EU MEQ00XXXXX "Wall Thermostat Bathroom" { Channels: Type HM-TC-IT-WM-W-EU_2_set_temperature : 2#SET_TEMPERATURE [ delay = 4, receiveDelay = 0 ] } ``` to have the SET_TEMPERATURE with a 4 second delay. During the startup of OH I always get the error `[ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HM-TC-IT-WM-W-EU_2_set_temperature could not be resolved.` for every wall thermostat with this channels definition. Looking in Paper UI at the Set Temperature Channel, the 4 second delay seems to be recognised correctly. <img width="695" alt="Screen Shot 2019-11-07 at 16 33 15" src="https://user-images.githubusercontent.com/17110652/68402897-5ca34d80-017c-11ea-9587-3867751ebe65.png"> And looking at the actual debug log `2019-11-07 16:27:13.089 [DEBUG] [ternal.handler.HomematicThingHandler] - Received command '21.0 ?C' for channel 'homematic:HM-TC-IT-WM-W-EU:ccu:MEQ00XXXXX:2#SET_TEMPERATURE' 2019-11-07 16:27:13.091 [DEBUG] [converter.type.AbstractTypeConverter] - Converting type QuantityType with value '21.0 ?C' using QuantityTypeConverter to datapoint 'MEQ00XXXXX:2#SET_TEMPERATURE' (dpType='FLOAT', dpUnit='?C') 2019-11-07 16:27:13.094 [DEBUG] [ematic.internal.misc.DelayedExecuter] - Delaying event for 4.0 seconds: 'MEQ00XXXXX:2#SET_TEMPERATURE' 2019-11-07 16:27:17.098 [DEBUG] [ematic.internal.misc.DelayedExecuter] - Executing delayed event for 'MEQ00XXXXX:2#SET_TEMPERATURE' 2019-11-07 16:27:17.105 [DEBUG] [ommunicator.AbstractHomematicGateway] - Sending datapoint 'MEQ00XXXXX:2#SET_TEMPERATURE' with value '21.0' to gateway with id 'ccu' using rxMode 'DEFAULT' 2019-11-07 16:27:17.694 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value '21.0' for 'MEQ00XXXXX:2#SET_TEMPERATURE' from gateway with id 'ccu'` it does state "Delaying event for 4.0 seconds:", and 4 seconds later correctly "Executing delayed event". So is my manual Thing Channel delay definition correct and the log error is a bug, or is there an error in my manual definition and the correct adaption is a lucky fluke? Any help in getting rid of these log errors is greatly appreciated. openHAB 2.5.0 M4

but with the added

In case it does not happen immediately after an upgrade, it should be fixed in the binding.

might there be a chance this is being eventually addressed if it is still an issue with the Homematic binding not correctly interpreting textual defined delays, or have the textual delay configurations changed since then?