HomeMatic Offline Communincation Error and Offline Bridge Error

Add-ons Bindings
1

Hey guys,

I know that the second error is of course because of the first one. I have a CCU2 and CCU3 so both are offline. And both are working as a bridge for different HomeMatic devices. So the Offline Bridge Error is clear. Insinde PaperUI I can read on both Things for the CCU`s that the connection is lost.

OpenHAB is in the version 2.5.12-1 and the OpenHAB Addons also. I have updated the firmware of both CCU`s. So maybe the solution is quite easy and I should downgrade it. But I was wondering because yesterday the CCU3 worked for a few minutes and then again was offline. The current firmware version of the CCU3 is 3.57.5 and the CCU2 uses 2.57.5.

CCU2 configuration:
Firewall:
Homematic XML-RPC API: Full Access
Remote Homematic-Script API: Restricted
IP addresses who should have access are 192.168.0.1; 192.168.0.0/16 because this would make it accessable in a upper network.

CCU2 thing configuration:
Gateway Address: 192.168.0.12
Gateway Type: CCU
Callback Network Address: 192.168.0.5
Install Mode Duration: 60
Timeout: 15
Discovery Time to Live: -1
Socket MaxAlive: 900
RF Port: 2001
Wired Port: 2000
HMIP Port: 2010
CUxD Port: 8701
Group Port: 9292

CCU3 configuration:
Firewall:
Firewall policy: Ports open
Homematic XML-RPC API: Full Access
Remote Homematic-Script API: Restricted
Mediola access: No access
IP addresses who should have access are 192.168.0.1; 192.168.0.0/16 because this would make it accessable in a upper network.

CCU3 thing configuration:
Gateway Address: 192.168.0.50
Gateway Type: CCU
Callback Network Address: 192.168.0.5
Install Mode Duration: 60
Timeout: 15
Discovery Time to Live: -1
Socket MaxAlive: 900
RF Port: 2001
Wired Port: 2000
HMIP Port: 2010
CUxD Port: 8701
Group Port: 9292

I mean, the update does not change the configuration. Therefore, it is perhaps more the compatibility between the binding/addon and the firmware.

For the CCU2 I get as example:

09:26:27.128 [INFO ] [nternal.communicator.client.RpcClient] - Interface 'WIRED' on gateway 'MEQ0461285' not available, disabling support
09:26:27.175 [INFO ] [nternal.communicator.client.RpcClient] - Interface 'CUXD' on gateway 'MEQ0461285' not available, disabling support
09:26:27.254 [INFO ] [communicator.AbstractHomematicGateway] - HmGatewayInfo[id=CCU,type=CCU2,firmware=2.8.6,address=MEQ0461285,rf=true,wired=false,hmip=true,cuxd=false,group=true]

Does the last line mean that it is waiting for firmware 2.8.6 to be installed or does it mean that I could only install this firmware, so that mine is too new? Or in other words, do I need to configure something else so that it recognises a new firmware version? I do not see where to configure the firmware version number.

Perhaps someone can help me further. Many thanks in advance!

2

The last line is only an information about the configuration of the detected CCU.

Did you open all necessary ports in the CCU firewall configuration? If there are no more messages, this probably means that the binding can not get the necessary information.

3

Yes, all ports are open. I think you can see my conifugarion. What is missing is the port 9125 for XML-RPC and 9126 for BIN-RPC Callback, but it is default. Also missing is the Bind Address. Anything else is configured like described above.

If I look here, I have configured it as described there. The only reason I can think of now is that the firmware of the CCUs is too new for binding.

4

I thought of something else. I installed a database and then made some security setting on ports on my Ubuntu server. The CCU3 is still not running. The CCU2 runs, according to the following port releases:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
9000                       ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
1883                       ALLOW       Anywhere
22                         ALLOW       Anywhere
9000 (v6)                  ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)
1883 (v6)                  ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)

sudo ufw allow 2000
Rule added
Rule added (v6)
sudo ufw allow 2001
Rule added
Rule added (v6)
sudo ufw allow 2010
Rule added
Rule added (v6)
sudo ufw allow 8701
Rule added
Rule added (v6)
sudo ufw allow 9292
Rule added
Rule added (v6)
sudo ufw allow 8181
Rule added
Rule added (v6)
sudo ufw allow 9125
Rule added
Rule added (v6)
sudo ufw allow 9126
Rule added
Rule added (v6)
sudo ufw allow 43439
Rule added
Rule added (v6)
sudo ufw allow 9090
Rule added
Rule added (v6)
sudo ufw allow 8080
Rule added
Rule added (v6)
sudo ufw allow 9443
Rule added
Rule added (v6)
sudo ufw allow 8443
Rule added
Rule added (v6)
sudo ufw allow 5555
Rule added
Rule added (v6)
sudo ufw allow 8701
Skipping adding existing rule
Skipping adding existing rule (v6)
sudo ufw allow 8101
Rule added
Rule added (v6)

Of course, it is now a question of what would still have to be released for the CCU3…

5

Okay, it’s a different error. When I restart openHAB, the CCU3 now works, but the CCU2 does not. Both should work. Is this because of the ports? Because they both use the same ports?

Status: OFFLINE - COMMUNICATION_ERROR Jetty start failed
6

I diasbled the firewall with sudo ufw disable and rebooted the system but at first it prefers the CCU 2 and later the CCU 3. So only one could be used.

7

If I am not mistaken, the Callback Network Address, the Bind Address, XML-RPC Callback Port and BIN-RPC Callback Port must not be specified in either thing, because it will do this automatically.

So, now I have tried and tested a lot. You often see these two problems that I mentioned. Maybe this will help other members in the future.

8

Sometimes the bind address is a problem if the machine where openHAB is running has got more than one IP address (or openHAB is running in a Docker container). In these cases sometimes a wrong IP address is used.

For OH 3.1 this behaviour will change and the binding will listen on all available IP addresses.

9

That will probably have been the reason then. Thank you very much. What about 127.0.0.1? Wouldn’t that point to the IP of the Docker container? Would this be more stable?

10

127.0.0.1 is the localhost. If you use this address only processes running on the same machine would be accessible. If you use it within a docker container then only other processes running withon container are accessible.

1 Like