Homematic Binding: "Channel not found for datapoint" errors for definitely existing channels

Happy new year and thank you very much @gerrieg. I know what to do the next time it occurs now.

Hello Gerhard, I’m running OpenHab 2.2 with homematic binding to a RaspBerryMatic. Some days ago I updated my RaspBerryMatic from a quite old version to the latest version. Since that day I get a lot of error messages “Channel not found for datapoint …” in my openhab.log. How can I solve the problem? Is there a new or updated homematic binding available that I can install to eleminate these error messages? If yes, where can I get it from and how to perform the update process? Or is there another workaround that you can propose to me? Thank you very much in advance for your help.

Unfortunately since my upgrade to version 2.4 I experience this error very often. I have to restart OH multiple times to get my setup in a working state. Does it help to provide debug logs? I’m using a RPi3 and docker on Raspbian Stretch

I am encountering this issue quite frequently on my setup, and while I am sadly not available at this moment to help debug this further, I hope the following details may help someone to get a more stable repro (in my case, the issue manifests itself every 2-3 days).
I am running: OH 2.4.0(stable) + Homegear 0.7.34-2678 on an Odroid C1 with an almost-read-only setup (all the logging and most part of configuration redirected to ramfs). This means I use quite a few logrotate scripts (triggering on log size) which also do:

  • reload Homegear service after its logs rotation,
    /var/log/homegear/*.log /var/log/homegear/*.err {
        missingok
        rotate 1
        compress
        delaycompress
        notifempty
        size 1M
        create 644 homegear homegear
        sharedscripts
        postrotate
        service homegear reload > /dev/null
        endscript
    }
    
  • restart Openhab after its logs rotation
    /opt/openhab2/userdata/logs/*.log {
        missingok
        rotate 1
        compress
        delaycompress
        notifempty
        size 1M
        create 640 openhab openhab
        sharedscripts
        postrotate
        service openhab2 restart > /dev/null
        endscript
    }
    

Quite frequently, I get either of the 2 error conditions:

  1. some Homematic things end up in UNITIALIZED (BRIDGE_UNINTIALIZED) state, while others using the same bridge are ONLINE (the bridge also is).
  2. all the things seem to be ONLINE, though no actual data is received, and the log is flooded by Channel not found for datapoint errors

Condition #2 is more nasty, as it is not detectible from the UI, and only visible in the logs (or when items start lingering in a stale state for a while).
This started happening to me after migration from OH 2.3, but I changed quite a lot of things in my setup, so multiple conditions may have caused it.
Workaround that brings my system back to life is touching the .things file (I even have a rule for it :slight_smile: ).


All in all, to a naked eye this appears to be a timing issue indeed. If getting a stable repro is of issue, I hope trying to loop-reload Homegear while OH is running may help trace it.

Will try to collect more useful info once I find some time for it.

1 Like

I’m seeing the exact same behavior as @mbronk. I can also confirm that touching my homematic.things file seems to help. Sometimes I need to do it twice.

One additional detail that might help in our investigation: For me this only happens for my HomeMatic IP devices. Regular devices seem never to be affected.

Hi,

I am facing the same issue with “Channel not found for datapoint”. While everything was working fine, suddenly the warnings showed up and my thermostats failed to set their temperature.
Setting the log level did not change anything:

2019-09-23 22:37:37.496 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '0' for 'OEQ2636958:4#PARTY_STOP_TIME' from gateway with id 'ccu'

2019-09-23 22:37:37.511 [WARN ] [ematic.handler.HomematicThingHandler] - Channel not found for datapoint ‘OEQ2636958:4#PARTY_STOP_TIME’
2019-09-23 22:37:37.530 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘1’ for ‘OEQ2636958:4#PARTY_STOP_DAY’ from gateway with id ‘ccu’
2019-09-23 22:37:37.563 [WARN ] [ematic.handler.HomematicThingHandler] - Channel not found for datapoint ‘OEQ2636958:4#PARTY_STOP_DAY’
2019-09-23 22:37:37.589 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘1’ for ‘OEQ2636958:4#PARTY_STOP_MONTH’ from gateway with id ‘ccu’
2019-09-23 22:37:37.604 [WARN ] [ematic.handler.HomematicThingHandler] - Channel not found for datapoint ‘OEQ2636958:4#PARTY_STOP_MONTH’
2019-09-23 22:37:37.629 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘0’ for ‘OEQ2636958:4#PARTY_STOP_YEAR’ from gateway with id ‘ccu’
2019-09-23 22:37:37.646 [WARN ] [ematic.handler.HomematicThingHandler] - Channel not found for datapoint ‘OEQ2636958:4#PARTY_STOP_YEAR’
2019-09-23 22:37:38.610 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (String) value ‘3014F711A0001F98A9AABBDA’ for ‘CENTRAL:0#PONG’ from gateway with id ‘ccu’
2019-09-23 22:37:38.625 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (String) value ‘3014F711A0001F98A9AABBDA’ for ‘CENTRAL:0#PONG’ from gateway with id ‘3014F711A0001F98A9AABBDA’
2019-09-23 22:37:51.782 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (String) value ‘ccu’ for ‘CENTRAL:0#PONG’ from gateway with id ‘3014F711A0001F98A9AABBDA’
2019-09-23 22:37:51.803 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (String) value ‘ccu’ for ‘CENTRAL:0#PONG’ from gateway with id ‘ccu’
2019-09-23 22:37:52.601 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘1’ for ‘OEQ2636589:4#CONTROL_MODE’ from gateway with id ‘3014F711A0001F98A9AABBDA’

I also tried what has been suggested here Cleaning up the startup process / renaming rules (windows possible) (the prefered variant).

Is there anything else I can try? Can I provide any additional information?

I am seeing this on Bidcos based devices aswell.

Has there been any progress on this issue?

I am still seeing the Channel not found for datapoint warnings intermittently and my things stop updating (now at OH:2.5.5 + Homegear: 0.7.45-3101).
It does look like a timing/threading issue to me… each time it seems to only affect a few HM-CC-RT-DN devices from the set I have. Which one gets affected, seems completely random (btw. they all look perfectly OK the whole time in Homegear). Restarting Openhab multiple times (or reloading things file) seems to help (at least for some time), but the errors come back after the server is running for a longer while.

Unfortunately, when this happens, there is no way I know of*, to programmatically detect this, so that it can be auto-recovered from using a rule… so is very annoying :confused:
* - other than inspecting LastUpdate of items or having a log parsing rule (ugh!)

BTW. Unsure if it matters, though FYI - I am using a purely things file-based configuration (e.g. the JSON DB gets wiped each time I upgrade OpenHab).


There used to be a simmilar issues reported here: https://github.com/openhab/openhab-addons/issues/3010 and here: https://github.com/openhab/openhab-addons/issues/1825
@gerrieg - Can you please advise if they are related? Would it help if we move this conversation into a proper github issue?

What would be the next steps to get it fixed?

I have also got several HM-CC-RT-DN but have never seen any error messages regaridng this device.
But I am using Raspberrymatic and not Homegear, so maybe this problem has to do with Homegear.

Can you give us some more information about your installation:

  • on what kind of machine openHAB is installed?
  • where is Homegear running? Is it installed on the same machine
  • is always the same channel affected or does it also change randomly?
  • can you post the exact error message?

It would help if you could enable trace and then post all relevant messages from openhab.log that have been looged before the error message.

Hello @MHerbst,
I have no data to support it, but I am open to the hypothesis that the issue might very well be triggered by Homegear (I am sure it has some quirks to it - some I had to manually work around, to get OH/Homegear work with Winmatic window opener :slight_smile: ).

Though, even if Homegear is the trigger… given restarting Openhab without touching Homegear does help - I claim it is Openhab which needs a bugfix :slight_smile: At the very least - it is now unable to recover from an intermittent issue (assuming it was Homegear’s fault).


To your questions:

  • It is an Odroid C1 board running Ubuntu 18.04.4 LTS. This is my custom setup/install with (almost)read-only filesystem (most of the data sits in ramdisk) - particularily: not using Openhabian / using text based configuration for everything.
  • Yes - running on localhost. Here’s my bridge config:
    Bridge homematic:bridge:homegear [ gatewayAddress="127.0.0.1", type="auto", callbackHost="127.0.0.1", rfPort="2001" ] 
    
  • It is always all the channels I have configured for a particular device (typically 1-2 devices out of 4 HM-CC-RT-DN’s behave like this)
  • See below - 2 log 'entries' (**click to expand**)
    2020-06-11 10:34:57.243 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#RSSI_DEVICE'
    2020-06-11 10:34:57.246 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#RSSI'
    2020-06-11 10:34:57.249 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#SIGNAL_STRENGTH'
    2020-06-11 10:34:57.255 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#LOWBAT'
    2020-06-11 10:34:57.263 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#ACTUAL_TEMPERATURE'
    2020-06-11 10:34:57.267 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#BATTERY_STATE'
    2020-06-11 10:34:57.271 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#BOOST_STATE'
    2020-06-11 10:34:57.275 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#CONTROL_MODE'
    2020-06-11 10:34:57.279 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#FAULT_REPORTING'
    2020-06-11 10:34:57.283 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#PARTY_START_TIME'
    2020-06-11 10:34:57.287 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#SET_TEMPERATURE'
    2020-06-11 10:34:57.290 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#VALVE_STATE'
    2020-06-11 10:37:11.801 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#RSSI_DEVICE'
    2020-06-11 10:37:11.810 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#RSSI'
    2020-06-11 10:37:11.814 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#SIGNAL_STRENGTH'
    2020-06-11 10:37:11.820 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:0#LOWBAT'
    2020-06-11 10:37:11.829 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#ACTUAL_TEMPERATURE'
    2020-06-11 10:37:11.835 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#BATTERY_STATE'
    2020-06-11 10:37:11.842 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#BOOST_STATE'
    2020-06-11 10:37:11.848 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#CONTROL_MODE'
    2020-06-11 10:37:11.853 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#FAULT_REPORTING'
    2020-06-11 10:37:11.858 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#PARTY_START_TIME'
    2020-06-11 10:37:11.863 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#SET_TEMPERATURE'
    2020-06-11 10:37:11.869 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint 'KEQ0573507:4#VALVE_STATE'
    
  • Note it is logged as a WARN - and there’s no error in the PaperUI/HabMin - the devices just stop updating. Also, the WARNs flood the logs when this happens (I am stipulating a WARN is produced each time the device sends a channel update)

Unfortunately, the issue is intermittent, with no known trigger I know of. Since my setup is logging to a ramdisk, I cannot leave it enabled on TRACE for any period longer than sub-minutes, as it overflows too quickly and logrotate doesn’t keep up. I’ll need to redo my whole setup to be able to capture more logging (not impossible, but very time consumung).

And my take is, there are 2 issues:

  1. For this issue happening (condition unknown)
  2. For the binding not recovering, once it has happened.

Logs are certainly critical for #1, but perhaps we can work with what we have for for #2 ? I think @lars_francke might have been on to something with the getChannel() returning NULLs.

Since others are also seeing this issue - perhaps someone can provide a decent log trace?

This is really a strang thing. Either openHAB “forgot” the thing definition and the channels or for some reason the device id has changed. I think, I can enhance the warning log message to print some more information.

Not really.

With using thing files the Homematic Binding queries the channels on every restart and creates the thing with the queried channels. Sometimes the binding does not collect all channels and when data for these channels arrives the “Channel not found for datapoint” error is triggered.

If you use JsonDB the thing is only created once, if channels are missing, these are missing forever (until you delete and recreate the thing from the Inbox). Data for missing channels triggers the warning.

The real problem occurs when the devices are queried and the due to some communication hickup some channels are missing. “Channel not found for datapoint” is just the symptom, not the problem.

I have given up on this problem long time ago and moved all critical heating related stuff one layer down to Homegear & Node-Blue.

The best solution would be to create the channel if data arrives, but i do not know if the information is sufficent to create the channel.

This happens more often with devices with massive amounts of channels (radiator thermostat and wall thermostat) but i have also seen this with wall mounted motion detectors or switches.

Ah OK. Now I understand .

I have defined my things with Paper UI and only the items in text format. So I never got this problem.

I would be interesting to see whether there are any messages in the log (maybe you have to enable DEBUG mode to see the messages.

I have made some changes to implementation of the communication between the binding and the CCU (or Homegear). You can download a test version of this version here: https://github.com/MHerbst/openhab-addons-test/blob/master/org.openhab.binding.homematic-2.5.6-SNAPSHOT.jar

The best solution would be to create the channel if data arrives, but I do not know if the information is sufficient to create the channel.

I don’t think it will work. Or at least it won’t be that easy because it would not fits into the current workflow. I have seen that the binding uses a special request to get information about the available datapoints (= channels) of a device.

I own a few HMIP-SWDO-I window contacts and wanted to add them to my sitemap. However, creating items with type Contact doesn’t work. Adding an item with Type String works, though:

    Contact FensterkontaktBueroState "Fenster Büro [MAP(window.map):%s]" (Fensterkontakt,Buero) { channel="homematic:HmIP-SWDO-I:3014F711A061A7DA498FAB79:00109A4996xxxx:1#STATE_CONTACT" }
    String FensterkontaktBueroStateStr "Fenster Büro [MAP(window.map):%s]" (Fensterkontakt,Buero) { channel="homematic:HmIP-SWDO-I:3014F711A061A7DA498FAB79:00109A4996yyyy:1#STATE" }

    Frame label="Büro" {
        Switch item=RollladenBuero
        Default item=FensterkontaktBueroState
        Default item=FensterkontaktBueroStateStr
    }

After some digging, I found out that for HMIP-SWDO* devices, a virtual channel called STATE_CONTACT should be added which can be used for Contact items (https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.homematic/src/main/java/org/openhab/binding/homematic/internal/communicator/virtual/StateContactVirtualDatapointHandler.java and https://github.com/eclipse-archived/smarthome/issues/5786). However, this channel is not shown in PaperUI. If I try to reference it in an Item, it doesn’t work either. The log file shows the error message

    2020-06-12 20:06:21.466 [WARN ] [ternal.handler.HomematicThingHandler] - Channel not found for datapoint '00109A4996C824:1#STATE_CONTACT'

I tried installing the 2.5.6-SNAPSHOT version @MHerbst posted, but that didn’t solve the issue either.

openhab> bundle:list | grep -i homematic
239 x Active x  80 x 2.5.6.202006071526      x openHAB Add-ons :: Bundles :: Homematic Binding

Ultimately, I’d like to display whether all windows are closed and I don’t know whether this would work with item type String. I found quite a few code samples which show how to do this with Contact items.

Please let me know if there is anything I can do to help debug this problem.

What I can see in the code a STATE_CONTACT channel should be created for all Homematic devices with names starting with HMIP-SWDO. Can you please enable TRACE mode, remove one of the window contacts and perform a new discovery. Then please post openhab.log (starting at the discovery).

Also, I would like to have a screenshot from the thing definitions in Paper UI (would like to see the channel definitions).

If the information are not sufficient to find the reason for this problem I can prepare a jar file with some enhanced log information.

Interestingly, after removing a thing and re-discovering/adding it, the channel “State Contact” is shown.

This is a thing, which was not removed:


And this is the thing I just removed and added again:

Here’s the log file you requested: https://we.tl/t-1UzzYZALJC (I wasn’t able to attach it to my post as it exceeds 1MiB and the forum software doesn’t let me upload gzipped files)

Please let me know if you need any additional information, otherwise, I’d go ahead and remove all my door/windows contacts and re-add them.

Is it possible that you created the things before the issue was solved? If a binding changes a type or adds a new channel it is always necessary to remove a thing and create it again.

The log information are looking good.

BTW: you have installed a test version of the binding that also contains some changes regarding rollershutters. But the implementation is not finished yet and will not work correctly for HMIP-BROLL. If you do not delete (and re-create) the rollershutter device there will be no problems.

Yes, I created all things before the issue was solved, i.e. I did the initial discovery with OH 2.5.5 (most likely even an earlier version). I just deleted and re-added “Fensterkontakt Büro” to verify that it is now showing the virtual channel.
Thanks for the heads up regarding HMIP-BROLL! I’ll make sure not to delete those.

I’m also still seing the “Channel not found for datapoint ‘NEQXXXXXXX:0#RSSI_DEVICE’” errors, so you are not the only one. I think this will not get fixed anytime soon though, and since for me it only affects my thermostats I can kinda live with it not working. I am using a configuration file based approach so there shouldn’t be the need to delete and recreate if I’m not mistaken. A simple restart always seems to fix it for some time, until it breaks again…

Hi all, me still getting this error from time to time, too (after days or weeks, cant tell a exact timing).
I use a pivccu3 since ages, and since ages i get the described error from time to time out of nowhere.
It only occurs on my Heating Thermostats (HM-CC-RT-DN) and room thermostats (HM-TC-IT-WM-W-EU)
I have quite some more Homematic bidcos devices, which never shown this error behaviour.

all my things and items are file configured. Reloading the Openhab2 several times fixes it usualy.