Tradfri binding looses gateway connection after some days

[Tobster77]

The following former Eclipse issues remain unsolved. Basically, the Tradfi gateway is online after reboot, but goes the binding looses connection after some days. Note, it is still reachable via Alexa/Google Assistant and via IKEA's Home Smart App:

The issue is described here:

• Tradfri binding does not reestablish connection to gateway after connection loss eclipse-archived/smarthome#6065
• [Tradfri] Connection gets lost on reboot of OpenHAB server eclipse-archived/smarthome#6748

The issue was also partially adressed here:
#4764
The issue was closed, but the solution approach (updating Californium to 1.07) did not result in an improvement.

A more detailed discussion is here. https://community.openhab.org/t/tradfri-binding-loses-connection-after-power-failure-gateway-reboot/47833/102. Some users gave up and switched to Hue or Deconz to include their bulbs...

Do you need further information (e.g. according to the form for new posts) or would you accept to import the old Eclipse reports?

Thanks a lot!

[jannegpriv]

Also discussed in this thread, and in this issue. The latter also contains the method of detaching and attaching the Ikea GW network cable which resolves the issue.

Since it is possible to resolve the problem by detaching/attaching the network cable to the IKEA GW, couldn't the binding try to restart the network communication when it detects that is has lost it?

Looking in the code this fix is already implemented:

if (status == ThingStatus.OFFLINE && statusDetail == ThingStatusDetail.COMMUNICATION_ERROR) {
            logger.debug("Gateway communication error. Forcing session resume on next command.");
            TradfriGatewayConfig configuration = getConfigAs(TradfriGatewayConfig.class);
            InetSocketAddress peerAddress = new InetSocketAddress(configuration.host, configuration.port);
            this.dtlsConnector.forceResumeSessionFor(peerAddress);
}

When this happens for me I can see the Gateway communication error. Forcing session resume on next command in the log.

Since it starts to work when detaching/attaching network cable for IKEA GW it is looks like that manouver releases something in the GW that makes the communication work again. Restarting network from binding does not have the same effect.

Looking more in the code, since it is not enough to call the this.dtlsConnector.forceResumeSessionFor(peerAddress) method, couldn't the binding re-intialize itself when this happens?

I mean doing a dispose() and initialize() and then initialize() will set up communication again with the establishConnection() call?

Is this too silly? :-)

if (status == ThingStatus.OFFLINE && statusDetail == ThingStatusDetail.COMMUNICATION_ERROR) {
            logger.debug("Gateway communication error. Forcing a re-initialization!");
            dispose();
            initialize();

            /*
             * TradfriGatewayConfig configuration = getConfigAs(TradfriGatewayConfig.class);
             * InetSocketAddress peerAddress = new InetSocketAddress(configuration.host, configuration.port);
             * this.dtlsConnector.forceResumeSessionFor(peerAddress);
             */
}

[leifbladt]

Good to see, that I'm not the only one, who has problems with the gateway. It started a couple of weeks ago, with (as far as I can see) no firmware update causing the issue. 1-2 times a week, the gateway is OFFLINE at the moment, and I can confirm, that it is still reachable via the IKEA app (on Android). Next time it happens, I will try the "trick" with the network cable.

Since I'm not that deep into the development of bindings, I could at least provide help with testing i.e. a development version of this binding.

Thanks a lot, @Tobster77 and @jannegpriv, for digging into this (annoying) topic.

Cheers
Leif

[jannegpriv]

I've built a binding-jar with my (maybe silly) attempt to re-initialize the binding when this happens, the binding-jar has now been running in my production system for 8 days without the issue being trigged (so typical 😄), but if it solves the issue I'll let you know.

[JornHermans]

Same issue here, it didn't happen for like 3 months, and today al of the sudden it did again all other bindings still working and connected (online).

[jannegpriv]

An update on my suggestion for fix above, I actually found that my binding has reconnected yesterday evening after detecting a communication failure, here's my tradfri.log:

2020-03-31 19:30:37.791 [DEBUG] [internal.handler.TradfriLightHandler] - Setting state to OFF
2020-03-31 19:31:00.696 [DEBUG] [g.tradfri.internal.TradfriCoapClient] - CoAP GET request
uri: coaps://192.168.1.134:5684/15011/15012
2020-03-31 19:31:57.045 [DEBUG] [iscovery.TradfriDiscoveryParticipant] - Discovered Tradfri gateway: [ServiceInfoImpl@13643927 name: 'gw-dcefcaba3a07._CC32E753._sub._coap._udp.local.' address: '/192.168.1
.134:5684 /fe80:0:0:0:deef:caff:feba:3a07:5684 ' status: 'NO DNS state: probing 1 task: null' is persistent, has data
        version: 1.10.29]
2020-03-31 19:31:57.085 [DEBUG] [iscovery.TradfriDiscoveryParticipant] - Discovered Tradfri gateway: [ServiceInfoImpl@5785623 name: 'gw-dcefcaba3a07._CC32E753._sub._coap._udp.local.' address: '/192.168.1.
134:5684 /fe80:0:0:0:deef:caff:feba:3a07:5684 ' status: 'NO DNS state: probing 1 task: null' is persistent, has data
        version: 1.10.30]
2020-03-31 19:32:00.707 [DEBUG] [g.tradfri.internal.TradfriCoapClient] - CoAP GET request
uri: coaps://192.168.1.134:5684/15011/15012
2020-03-31 19:32:07.019 [DEBUG] [.tradfri.internal.TradfriCoapHandler] - CoAP onError
2020-03-31 19:32:31.509 [DEBUG] [.tradfri.internal.TradfriCoapHandler] - CoAP onError
2020-03-31 19:32:31.510 [DEBUG] [ternal.handler.TradfriGatewayHandler] - Gateway communication error. Forcing a re-initialization!
2020-03-31 19:32:31.511 [DEBUG] [ternal.handler.TradfriGatewayHandler] - In dispose()
2020-03-31 19:32:32.020 [DEBUG] [ternal.handler.TradfriGatewayHandler] - In initialize()
2020-03-31 19:32:32.109 [DEBUG] [g.tradfri.internal.TradfriCoapClient] - CoAP GET request
uri: coaps://192.168.1.134:5684/15011/15012
2020-03-31 19:32:32.300 [DEBUG] [.tradfri.internal.TradfriCoapHandler] - CoAP response
options: {"Content-Format":"application/json", "Max-Age":604800}
payload: {"9023":"1.tradfri.pool.ntp.org","9092":0,"9066":5,"9059":1585675952,"9201":2,"9060":"2020-03-31T17:32:32.029392Z","9062":0,"9061":0,"9106":0,"9071":1,"9076":10,"9200":"fe120050-7d40-497e-b4b0-f5200c7ff684","9029":"1.10.30","9105":0,"9081":"7e183552044000f1","9082":true,"9083":"276-82-287","9075":0,"9054":0,"9055":100,"9118":0,"9069":1585675761,"9072":3,"9073":29,"9074":1,"9077":25,"9078":1,"9079":0,"9080":60,"9103":"","9093":0,"9107":0,"9202":1580365713}
2020-03-31 19:32:32.302 [DEBUG] [ternal.handler.TradfriGatewayHandler] - requestGatewayInfo response: {"9023":"1.tradfri.pool.ntp.org","9092":0,"9066":5,"9059":1585675952,"9201":2,"9060":"2020-03-31T17:32:32.029392Z","9062":0,"9061":0,"9106":0,"9071":1,"9076":10,"9200":"fe120050-7d40-497e-b4b0-f5200c7ff684","9029":"1.10.30","9105":0,"9081":"7e183552044000f1","9082":true,"9083":"276-82-287","9075":0,"9054":0,"9055":100,"9118":0,"9069":1585675761,"9072":3,"9073":29,"9074":1,"9077":25,"9078":1,"9079":0,"9080":60,"9103":"","9093":0,"9107":0,"9202":1580365713}
2020-03-31 19:32:32.311 [DEBUG] [.tradfri.internal.TradfriCoapHandler] - CoAP response
options: {"Content-Format":"application/json", "Max-Age":604800}

I've only seen this once, but is is a good sign.

[dikkedimi]

Just to add to this discussion, maybe it helps someone.

I removed my manual configuration(textfiles) and the Thing in paperUI. Then reconfigured using PaperUI while monitoring search results in the REST API. Compared results with my existing config and noticed a difference, the bridge name had a dash (-) in it, the newly generated config didn't.

Modified this and now it works again, wonder for how long...

Anyway, hope it fixes some of your issues.