Homematic IP device status updates stop being received by openHAB (but controlling these devices still works)

Anybody who can help?

Thanks!

Still no change of the behavior. :frowning:

The following line is interesting:

java.io.IOException: -1 setInstallMode: unknown.method name (sending setInstallMode()

You could check if the CCU firewall settings are they they should be.

On my end (not sure if also specified in the docu) I’ve got the local IP of my Raspi defined in there as well:

1 Like

Yes, it’s in there.
And the ā€žno updateā€œ-behavior started after updating to OH 4.3.3

For whatever reason all things are ā€˜online’.

Anyone else with this issue?
Have a great week!

Updating to 4.3.4 didn’t help - issue is still there. Iā€˜ll try to remove the things and start from zero. :smiling_face_with_tear:

Is the problem still there? If yes: Could you please have a look to the logs of the CCU? I think the problem is that the CCU can not connect to openhab

Hi Christian,

problem still exists, yes. :frowning:

By any chance do you know why the CCU2 isn’t able to connect to openHAB anymore?

Schoenes Wochenende!
HMCCU2-2025-05-02.log (593.3 KB)

I am using quite many homematic devices since Openhab 2.2. I noticed that after a while (in my case a couple of weeks) the homematic IP devices don’t update anymore. The CCU3 is connected via ethernet cable. However, they are on different subnets connected by a router. Whenever I reboot the router the connection is down for about 30-50 seconds. This mostly triggers the described problem. So I am required to restart openhab as well (taking about 8 minutes until everything is working again) after rebooting the router after a firmware update.

@Christian_Kittel: were you able to check the log above?
I’m not using a username/password for my CCU2.

What makes me wonder is that openHAB states ā€˜firmwareVersion 2.59.7’ under ’ Thing Properties’ instead of 2.61.7

Sorry for the delay. I investigate your logs. In fact, the CCU cannot connect to Openhab:

May 1 21:02:30 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [vert.x-eventloop-thread-4] Added InterfaceId: 0223f5e5-225a-464e-aa82-1af93b1ae704
May 1 21:02:31 de.eq3.ccu.virtualdevice.service.internal.rega.BackendWorker INFO [vert.x-worker-thread-16] Execute BackendCommand: de.eq3.ccu.virtualdevice.service.internal.rega.BackendUpdateDevicesCommand
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] Retrying connect to {}->http://172.17.0.1:9125
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] Retrying connect to {}->http://172.17.0.1:9125
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] Retrying connect to {}->http://172.17.0.1:9125
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-16] Retrying connect to {}->http://172.17.0.1:9125
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] Retrying connect to {}->http://172.17.0.1:9125
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] I/O exception (java.net.SocketException) caught when connecting to {}->http://172.17.0.1:9125: Network is unreachable (connect failed)
May 1 21:02:31 org.apache.http.impl.client.DefaultHttpClient INFO [vert.x-worker-thread-3] Retrying connect to {}->http://172.17.0.1:9125

I think it is a networking problem. Are you able to open a shell on the ccu to ping to openhab?

1 Like

Not sure how this works but I’ll ask google how to do it. :sweat_smile:
Why is it connecting to http://172.17.0.1:9125/?
openHAB is running on a docker on 192.168.1.100 in the very same network.

That’s a good question. Please check the Homematic binding. There should be a parameter Callback network address. What’s the value of this parameter?

1 Like

It’s empty. The ā€˜Gateway-Adress’ of the CCU2 Thing is set to the CCU2 address: 192.168.1.20
Btw: I have no idea how to ā€˜open a shell on the CCU to ping openHAB’. Can you help me out?

Edit: what I don’t get: why are all Homematic things (incl. CCU2) online in openHAB?

I’m not talking about the gateway adress. I’m talking about the callback adress. It must be the address of the Openhab Server.

About your question: All thinks are online because while the binding is starting, all item of the CCU are queried. That’s way all thinks goes online. In addition while the binding is starting, the binding sends the callback adress to the ccu. The CCU uses this adress to reports all changes in any device to openhab.

1 Like

I think I tried the same setup yesterday but it didn’t change anything. I’ll do a restart and see what happens. :slight_smile:

Yes. Please have a try.

1 Like

@mr.airworthy And does it work?

1 Like

Good morning. Just checked the status this morning. Everything is running again.

@Christian_Kittel thank you so much!!! You’re the man!

For whatever reason both openHAB and CCU2 needed a restart to finally communicate again.

Only one more question: why did this even happen? All I did was the OH 4.3.x update. And why is the ā€œautomatic detectionā€ of the callback address not working anymore?

Again: thank you so much!

I have no idea about the reason why this happened.

I had problems with the callback network address when i change my setup to Kubernetes three years ago so i set the callback address manually and it worked. Maybe it’s not a problem with Openhab but with the container.

Would be cool if we could open a shell into the container. But I don’t know enough about your setup.

Is it possible to run this?

docker exec -it <container name> /bin/bash

1 Like