Homematic IP Things go OFFLINE on CCU2 reboot

env: oh 2.2.0-010 on Synology

When the CCU2 reboots, all homematic IP things (door/window contacts in my case) go OFFLINE and remain in this state. The other homematic Things work as expected once the CCU2 is back.

openhab.log (CCU2 reboots nightly at 2:00)

2018-02-06 02:00:10.444 [WARN ] [ommunicator.AbstractHomematicGateway] - Connection lost on gateway 'ccu2'
2018-02-06 02:01:26.445 [ERROR] [ommunicator.AbstractHomematicGateway] - java.net.ConnectException: Connection refused
	at org.openhab.binding.homematic.internal.communicator.client.XmlRpcClient.sendMessage(XmlRpcClient.java:104) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.client.XmlRpcClient.sendMessage(XmlRpcClient.java:108) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.client.XmlRpcClient.sendMessage(XmlRpcClient.java:73) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.client.RpcClient.listDevices(RpcClient.java:158) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.getDeviceDescriptions(AbstractHomematicGateway.java:420) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.newDevices(AbstractHomematicGateway.java:640) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleNewDevice(RpcResponseHandler.java:104) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleMethodCall(RpcResponseHandler.java:53) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.server.BinRpcResponseHandler.run(BinRpcResponseHandler.java:46) [253:org.openhab.binding.homematic:2.2.0]
	at org.openhab.binding.homematic.internal.communicator.client.XmlRpcClient.sendMessage(XmlRpcClient.java:90) ~[?:?]

... (above ERROR repeats a couple of times)...

2018-02-06 02:01:41.090 [INFO ] [ommunicator.AbstractHomematicGateway] - Connection resumed on gateway 'ccu2'
2018-02-06 02:01:41.679 [WARN ] [ematic.handler.HomematicThingHandler] - java.net.ConnectException: Connection refused
2018-02-06 02:01:41.700 [WARN ] [ematic.handler.HomematicThingHandler] - java.net.ConnectException: Connection refused
2018-02-06 02:01:42.092 [WARN ] [ematic.handler.HomematicThingHandler] - java.net.ConnectException: Connection refused
...

Karaf

openhab> smarthome:things list | grep matic
homematic:bridge:ccu2 (Type=Bridge, Status=ONLINE, Label=Homematic Bridge, Bridge=null)
homematic:HMIP-SWDO:ccu2:0000D7099A4019 (Type=Thing, Status=OFFLINE (COMMUNICATION_ERROR): java.net.ConnectException: Connection refused, Label=EG_Kinder_FensterRechts, Bridge=homematic:bridge:ccu2)
homematic:HM-CC-RT-DN:ccu2:OEQ1256161 (Type=Thing, Status=ONLINE, Label=OG_Bad_Heizung, Bridge=homematic:bridge:ccu2)
...

What can I do to improve this situation?

Hi Olivier,

I’m new to openhab and Homematic and faced the same problem, also at startup.
The ccu2 seems to need way more time to be ready than openhab.
As a workaround I manually restart openhab after the ccu2 is ready.

Does anyone know if/how you can hook into the openhab startup process and wait for the ccu2 to be available?

Tobias

I don’t know for sure. But maybe you can check the state of your ccu from your openhab host by some script (e.g. via ping and curl) and than include such a script in your startup process with a systemd service. That service needs to be a predecessor for your openhab service.

I just had an idea but did not test it. As i don’t have an CCU.
you could add a constrain for that the openhab service has to wait.
So add some thing to Requires=, Wants= , After=, Require for the systemd service which starts openhab.

So add a additional systemd service to ping you ccu, replace <YourCuuIp>.
/usr/lib/systemd/system/wait-for-ccu.service

[Unit]
Description=Ping a CCU until it becomes reachable

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'while ! ping -c1 <YourCuuIp>; do sleep 1; done'
TimeoutStartSec=60s

And add this to the openhab service as requirement. But then it won’t start as long as CCU is not reachable.

/usr/lib/systemd/system/openhab2.service

[Unit]
Description=openHAB 2 - empowering the smart home
Documentation=http://docs.openhab.org
Documentation=https://community.openhab.org
Requires=wait-for-ccu.service
Wants=network-online.target
After=network-online.target

Thank you for your ideas, finally it worked. :slight_smile:

So what I did:

disable the openhab systemd service to disable auto-run at startup (openhab2.service) -> this allows you to start OH manually without the dependency on the CCU
sudo systemctl disable openhab2.service

create a new systemd service that waits for the CCU service to be loaded
/usr/lib/systemd/system/wait-for-ccu.service

[Unit]
Description=Wait for the CCU until it becomes available
Requires=pivccu.service
Wants=network-online.target
After=network-online.target pivccu.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'while ! sudo pivccu-info | grep -q State:.*RUNNING; do sleep 1; done'
TimeoutStartSec=60s

create a copy of the existing systemd service for OH and modify the [Unit] section: add a dependency for the wait-for-ccu.service
/usr/lib/systemd/system/openhab2-ccu.service

[Unit]
Description=openHAB 2 (with CCU dependency) - empowering the smart home
Documentation=http://docs.openhab.org
Documentation=https://community.openhab.org
Requires=wait-for-ccu.service
Wants=network-online.target
After=network-online.target wait-for-ccu.service

Enable the newly created systemd service openhab2-ccu.service to be started automatically sudo systemctl enable openhab2-ccu.service

Great! I just tried it, and it worked for me too. …at least the CCU is now up after restart.

…Unfortunately the HM-IP devices not. The “GATEWAY-EXTRAS” and “HM-RCV-50 BidCoS-RF” are still “OFFLINE - CONFIGURATION_ERROR”.
Someone having the same problem?

Ok found an answer. I had to change the “gateway-type” in the homematic bridge settings to “noccu”. Now its working, even without the “wait-for-ccu” loop.