Bridge offline need to stop/start OH to recover [SOLVED]

During the last weeks I frequently face the issue that the bridge is offline. OH does not recover from this on its own but I need to stop/start it.
2020-08-01 08:50:40.072 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:50:40.076 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
2020-08-01 08:51:40.091 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:51:40.092 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
2020-08-01 08:52:40.072 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:52:40.074 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
2020-08-01 08:53:40.073 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:53:40.075 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
2020-08-01 08:54:40.074 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:54:40.075 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
2020-08-01 08:55:40.096 [DEBUG] [internal.handler.InnogyDeviceHandler] - handleCommand called for channel ‘innogysmarthome:VariableActuator:SMARTHOME09:cxxxxxxxxxxxxecba84d1dce7d2cca9b:switch’ of type ‘VariableActuator’ with command ‘ON’
2020-08-01 08:55:40.101 [DEBUG] [internal.handler.InnogyDeviceHandler] - Cannot handle command - bridge is not online. Command ignored.
OH is 2.5.7 and innogy binding is 2.5.7 as well. Innogy is accessible from the app and the browser.

Are there any other experiencing this issue?

Might be related to:

@hilbrand ,
I am unsure if I understand your message correctly. Is (#8182) #8224 already fixed?

It’s not yet fixed. It was thought to be fixed, but the fix didn’t work correctly, so it was reversed. The issue reported is that the websocket connects stops and than no commands can be send.

There has been an update of the SHC2 to version 8.16 - 1.1.20.350. The binding still works fine. I have a watchdog/ flip-flop scenario implenented using a state. So I can detect quickly if communication has stopped.
I’ll report how things develop…

The binding still enters the state that reconnect attempts fails. Is there a way to restart the binding from e.g. a script?

1 Like

Thank you. Script and rule have been created. If the binding is not connected for more than 1 hour I will restart the binding. I’ll report if it works.

Works well. I reduced timeout to 15 min.

Hello Juergen, would you like o share your scripts and rules? Thank you. Jan

Openhab rule I use as watchdog

rule “WatchDogZVWDReset”
when
Time cron “20 * * * * ?”
then
var Number nbuffer

// innogy setzt kZVWD=ON
// Openhab setzt kZVWD=OFF
// die rule checked ob doe variable kZVWD von innogy auf ON gesetzt wurde
// falls nein wird ZVWDBuffer nicht zurückgesetzt


if (ZVWDBuffer.state == NULL){
	postUpdate( ZVWDBuffer, 0)
}	
nbuffer = ZVWDBuffer.state as DecimalType

if (kZVWD.state == NULL){
	postUpdate( kZVWD, "OFF")
}

else{
	if (kZVWD.state.toString == "ON"){
		// reset ZVWDBuffer counter
		postUpdate( ZVWDBuffer, 0)	
		//logInfo("WatchDogZVWDReset ", "ZVWDBuffer counter= 0, postUpdate kZVWD = OFF")
		kZVWD.sendCommand ("OFF")
		postUpdate( kZVWD, "OFF")	
		if (nbuffer > 5 ){
			logInfo("WatchDogZVWD ", "Wieder Updates von der RWE Zentrale")		
		}
	}
	else{
		nbuffer = nbuffer + 1
		postUpdate( ZVWDBuffer, nbuffer)
		if (nbuffer > 2){
			logInfo("WatchDogZVWD ", "ZVWDBuffer counter= " + nbuffer)	
		}
		if (nbuffer == 6){
			logInfo("WatchDogZVWD ", "KEINE Updates von der RWE Zentrale")	
		}
		if( nbuffer > 20 ) {
			executeCommandLine("/mnt/USER/haushalt/scripts/RestartInnogy.sh" ,10000)
			nbuffer = 7
		}
		postUpdate( ZVWDBuffer, nbuffer)
	}
}

end

RestartInnogy.sh
#!/bin/bash
sshpass -p habopen ssh openhab@localhost -p 8101 “bundle:restart org.openhab.binding.innogysmarthome”

1 Like

Thank you, Jürgen!

I am also struggling with the connection between Innogy SHC and OpenHAB, so I installed your rule. It’s using two items I defined as follows:

Number 	ZVWDBuffer	"Innogy Restart Zähler [%d]" 	
Switch	kZVWD		"Innogy Status [%s]"	

Is this correct?
But I am also missing the part how Innogy would set kZVWD=ON.

Best regards, Rupert

These are the variables
Number ZVWDBuffer “Innogy Watchdog Reset Counter [%d]” (gBoilerControl)
Switch kZVWD “ZVWD” (All ) {channel=“innogysmarthome:VariableActuator:XXXXXXXXX:XXXXXXXXXXXXXXX:switch”}

And here is the innogy scenario

I did not expect there is so much interest in this. Feel free to ask questions and I’ll try to help

1 Like

and some more information on the script I forgot to post

  1. you need to install sshpass using apt-get install sshpass
  2. make sure permissions for the script as set that openhab can execute the script. I used the following command to test this
    sudo -u openhab /mnt/USER/haushalt/scripts/RestartInnogy.sh

Please excuse if my installation instructions are clumsy but I am a linux beginner myself and most of what I do is copy paste from what I find on the internet.

You could just check if the bridge is online/offline:

rule "InnogyBridgeThingUpdate"
when
    Thing "innogysmarthome:bridge:SMARTHOME08" changed
then
    val bridgeStatus = getThingStatusInfo("innogysmarthome:bridge:SMARTHOME08").getStatus()
    logWarn("default.rules", "Innogy Bridge is " + bridgeStatus.toString())
    if (bridgeStatus.toString() == "OFFLINE") {
        [...]       
    }
end

Sounds good. That an option I have not thought of.
In the very beginning of the binding I had issues with values not refreshing. At this point in time I build the watchdog to make sure openhab receives updates. The interface is important to me as we control our viessmann boiler from the heating demand calculated using innogy thermostats. Works very well if updates are received.

with Binding 2.5.9 the problem seems to be solved.

Have the following issue since a couple of months. After Telekom refreshes the DSL connection to my Fritzbox (every night @ approx. 03:30am), the innogy bridge is OFFLINE and unable to reconnect again. Have to restart openhab every morning then in order to get ONLINE again. A restart of the binding does not help. Thus, for me the issue described above doesn’t appear to be solved.

@Hilbrand: Has anybody an idea what i could do?

Run openHAB2.5.11, snapshot #259 on Windows10 64bit and JAVA 1.8.0_271

Error message in log-file:
2020-12-12 03:29:34.527 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed abnormally (code: 1001). Reason: java.util.concurrent.TimeoutException: Idle timeout expired: 900010/900000 ms

@dk8pn
I had similar behaviour here. When my Fritzbox lost the DSL connection, the SHC could no longer establish a connection.
In a conversation with Innogy support, it was recommended not to assign a fixed IP to the SHC in the Fritzbox.
It was only 1 week ago, but since then at least the SHC seems to connect again.
The problem with the binding described above remains.

Thanks for the hints. Have been unprecise in my post above and need to correct my message: the innogy SHC reconnects (set DHCP within the Fritzbox), but openHAB is not able to reconnect the bridge. The log file INFO is indeed the ERROR message

@Hilbrand: due to the fact, that the binding restart doesn’t help, i am convinced that it is an openHAB issue.