Tradfri 1.8.25 - offline - communication_error

This is something I never did so far. I’ll have to look it up in the documentation.

is it possible to automate restarting of the binding if that might temporarily solve the problem?
My openhab is pretty much useless for months since the latest trådfri update :frowning:

I could imagine a solution by running a rule when the Tradfri gateway state is not ONLINE, and by trying to reset the security code in a REST API JSON message.

Sadly I’m not used to work with the REST API so I can’t provide the proper message to send through the rule.

I’m not used to work with the REST API but I could imagine a solution by running a rule when the Tradfri gateway state is not ONLINE, and by trying to reset the security code in a REST API JSON document.

EDIT - there’s a simple solution.

First identify the number of the TRADFRI bundle:

$ /usr/share/openhab2/runtime/bin/client list | grep -i 'tr.*dfri'
228 │ Active │  80 │ 2.5.0.201907090424    │ openHAB Add-ons :: Bundles :: TRÅDFRI Binding

Take note of the first number (228 in my case).

Now add the following Item:

Switch Reset_Tradfri_Gateway "Restart TRADFRI binding"

Then create the following rule and replace NNNN with that number (228 in my case).

rule "reset"
 
when
    Item Reset_Tradfri_Gateway received command ON
then
    // Replace NNNN with the 1st number returned from running the following command at the Karaf console:
    // list | grep -i 'tr.*dfri'
    executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart NNNN", 6000)
    Thread::sleep(2000) 
    postUpdate(Reset_Tradfri_Gateway, OFF)
end

You could also try using the following `executeCommandLine() line:

    executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart 'openHAB Add-ons :: Bundles :: TRÅDFRI Binding'")

maybe even a cron could do it, for me everything works if I restart entire server, I do not need to enter anything to get all to work

That’s possible, see: Tutorial: Restart Binding from rule

I’m pretty sure only a binding restart is required. I think that is what happens when you save the new/same security code.
There are examples on how to shh into karaf to do this.
Another option is to go the Conbee/deconz route. I did and have never looked back. Search this forum for my full writeup on that.

I saw you mentioned that before, thanks.
I am perhaps just being a stubborn developer that wants thing to work properly, they way they are intended to.
I am constantly getting this ringing question in my head, if Conbee works fine without need for restart, why should not tradfri binding work fine as well?

I am afraid that if I switch now to conbee, at one point in future something new/important will come on this binding that might require me to switch back, and then I might as well switch entire HA platform.
I just do not like such workarounds for long term, stable solutions (one of the reasons I chose openhab in the first place)

I agree with you 100%. I also kept my Ikea Gateway with a minimum setup (one bulb only) to keep track of binding state and new firmware. Even with this setup, it only comes online 50% of restarts, and this was on a snapshot from last week. Sometimes the binding needs several resets to come online again.
I’m wondering if it could be platform related. Both my problem sites are x86/Ubuntu systems. Does it work better on a less powerful RPi? If there are differences it could be timing related, and that again is a sign of sub-optimal SW design.
Does the binding have a maintainer these days, or is it left in limbo?

Here’s an implementation of a rule and it works. I’m using a longer timer at system startup and a shorter timer when invoking the binding restart by hand. The Item changed names and in my case I’m also using Telegram to notify me:

/*  Restart the IKEA TRADFRI binding at system start or upon request.
    Make sure to define the following Switch item:

    Switch DBG_Restart_Tradfri_Binding "Restart the IKEA TRADFRI binding"

    The bundle will be restarted by using "runtime/bin/client bundle:restart" as follows:
    A. By identifying the bundle ID (may change over time)
    Replace NNNN with the 1st number returned from running the following command at the Karaf console:
    list | grep -i 'tr.*dfri'
    executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart NNNN", 6000)

    B. By using the bundle name (may change over time as well)
    OR: Run this without first checking the bundle ID:
    executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart 'openHAB Add-ons :: Bundles :: TRÅDFRI Binding'")
*/

// Use a timer to delay the restart command
var Timer cmdDelayTimer = null

// True if properly initialised
var boolean initialised = false


rule "System startup - restart TRADFRI binding"
when
    System started
then
	if (cmdDelayTimer !== null) {
        cmdDelayTimer?.cancel()
    }
    initialised = false
    sendTelegram("homebrainz", "<b>System started:</b> Will restart the IKEA TRADFRI binding in 90 seconds")
    cmdDelayTimer = createTimer(now().plusSeconds(90), [ |
        executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart 'openHAB Add-ons :: Bundles :: TRÅDFRI Binding'")
        sendTelegram("homebrainz", "<b>System started:</b> Restarted the IKEA TRADFRI binding")
        createTimer(now().plusSeconds(5), [ |
            postUpdate(DBG_Restart_Tradfri_Binding, OFF)
            initialised = true
            cmdDelayTimer = null
        ])
    ])
end


rule "Restart TRADFRI binding on request"
when
    Item DBG_Restart_Tradfri_Binding received command ON
then
    if (initialised === true) {
        if (cmdDelayTimer !== null) {
            sendTelegram("homebrainz", "<b>Restart binding on request:</b> A request to restart the IKEA TRADFRI binding iis already on its way. Nothing to do.")
        } else {
            // Restart the binding and set the timer
            sendTelegram("homebrainz", "<b>Restart binding on request:</b> Will restart the IKEA TRADFRI binding in 5 seconds")
            cmdDelayTimer = createTimer(now().plusSeconds(5), [ |
                executeCommandLine("/usr/share/openhab2/runtime/bin/client bundle:restart 'openHAB Add-ons :: Bundles :: TRÅDFRI Binding'")
                sendTelegram("homebrainz", "<b>Restart binding on request:</b> Restarted the IKEA TRADFRI binding")
                createTimer(now().plusSeconds(5), [ |
                    postUpdate(DBG_Restart_Tradfri_Binding, OFF)
                    cmdDelayTimer = null
                ])
            ])
        }
    } else {
        sendTelegram("homebrainz", "<b>Restart binding on request:</b> Not yet intialised. Please retry later.")
    }
end

EDIT 2: improved the rule by keeping track of state initialisation and by using a delay timer. At startup, a delay of 90 seconds is used, while the delay upon manual request for restarting is only 5 seconds.

Thanks @shutterfreak I will look into it.
I guess some workaround needs to be done for it to work with docker, but is a good start I think

Hi guys,
I’m on 2.5 M1 (Are there any newer milestones?) and on firmware version 1.8.26 and I cannot bring it back online no matter what I do. I tried restarting the bundle, the Gateway, OpenHAB and the whole RPi running OpenHAB to no avail.

Also tried re-entering the password. The only thing I haven’t tried is resetting the Gateway to factory default. It’s working fine with the Tradfri app.

MAke sure you remove it from paper ui. Remove all tradfri config files.
Then clear cache

Then try again. I had an issue at one point and realized in my frustration i had duplicated something. I had to restart. I manually removed from the json dB cause the paper ui did not appear to actually be removing it.

I was in your place. Had to factory reset the Gateway. (more)

I’m sorry to say that snapshot #1655, which I think for most purposes is equal to the new M2 release, still often requires a bundle restart of the Trådfri binding in order to get Gateway and things online.

@OMR remind me what hardware are you on?
Also are you tied wired or wirelessly to your network from openHAB?

Curious why we have such a mixed bag of results.

OH is running on this HW.
OS is Ubuntu Server 16.04.6 LTS (x86_64), java 1.8.0.201-b09
My network is all wired, Ikea Gateway connected (with non-original 0.5m patch cable) to a Giga-Eth port in the back of my Asus RT-AC87U router (in the cellar).
This router is connected through a 20-30m patch cable to an Asus RT-AC66U running in AP mode. The VivoPC is connected straight to this AP with a 0.5m patch cable. This is the optimal place for my Z-Wave & Zigbee USB sticks. Also separates the Ikea GW and the Conbee for minimal interference.

Whenever the Ikea GW does not connect in OH, ICMP ping works fine.
Sometimes after a VivoPC/OH restart, the Ikea Gateway does connect, but most often not.
Usually when it doesn’t, one restart of the bundle in Karaf is enough, but sometimes I need to do it 5-6 times.

Me too.

Thanks for answer and description.

I am in process of switching to deconz, not because I have issues with tradfri beyond one light that intermittently connects. I want to enhance the features of remotes, both my Phillips and ikea remotes.

My gateway has 1.8.26
I have upgraded from 2.4.0. to 2.5.0.M2.
In 2.4.0 I had a couple of addon files in order get it working:
image
I left this configuration after during and after the upgrade.
The result was that for each OH restart I needed to go to paper-UI and re-enter the security code.
I removed now the addon files and enabled the 2.5.0.M2 TF binding.
Having now exactly the same behavior. Even worse.
Sometimes when entering the security key, the GW goes online and then immediately offline.
I will step back to addon files from 2.4.0.

Just FYI:

I asked lots of questions to Ikea support, one of them was this:

  • OpenHAB needs to re-initialize the binding with the security code every day to stay connected

Answer from Ikea:
This could be mDNS issue which we are working on. Stability fixes are coming in the next Gateway update that is released next week. Additional fixes will come later this fall.

3 Likes