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’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:
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
Interesting! Good info!
After gateway firmware 1.9.27 update it has worked 100% Never seen it offline after that.
(on M3)
1 Like
Mine is still broken 
I have to reboot the gateway to get it back online, however it does come back online in openhab without me doing anything.
I’ve had this issue for months (april?), but no time to do any troubleshooting. Is it possible to only update the binding to solve this? I’d like to run 2.4 until 2.5 is released…
I’ll answer my own question in case someone else has the same issue. My Tradfri gateway came online after updating to the latest binding.
Following the guide here
http://blog.haupt.xyz/index.php/openHABconsole
using this address to get the binding
https://openhab.jfrog.io/openhab/online-repo-snapshot/2.5/org/openhab/binding/org.openhab.binding.tradfri/2.5.0-SNAPSHOT/org.openhab.binding.tradfri-2.5.0-SNAPSHOT.jar
2 Likes
On M4 it started acting up again 
For me the gateway only came online when I disconnected the gateway from the Ikea Home Smart App.
Took me a long time to figure this out, hadn’t read it on any forum yet.
I can’t get this to work anymore. Thing always says “Status: OFFLINE - COMMUNICATION_ERROR Error connecting to gateway.”
I already removed the thing (paperui), clean-cache, restart, reboot, gateway reset to factory defaults, removed/reinstalled binding, nothing helps
I’m on OH2.5, gateway is 1.9.27
Any idea?