Done 4 power cycles today and Ikea Gateway did not reconnect on any of those.
Reconnected on first bundle restart from Karaf each time though.
Done 4 power cycles today and Ikea Gateway did not reconnect on any of those.
Hi, my experience, with OpenHabian on RPi (v 2.4.0) and Tradfri-gateway (v1.4.15) is this:
- If I reboot RPi no problem, Tradfri is reconnected after several seconds (sometimes a couple of minutes).
- If I cycle power OFF/ON of Tradfri, it never reconnect with OpenHab. To reconnects it, i must go on Paper-UI/Configuration/Things, and edit the configuration of the Tradfri-gateway. If I re-enter the Security Code the reconnection is very quick, if I change the IP address to a fake address and then reset it to the correct address, the connection come up after 30-40 seconds.
I hope this can help to solve the problem.
Thanks and good work.
I have the same issue. When I open the tradfri App and restrart oh it’s get back running. I Thing we really need a solution for that, thats stays permanent. Light is very important in the dark days
Found this errors running oh 2.4 with tradfri newest firmware.
2019-02-16 13:08:48.656 [WARN ] [iscovery.TradfriDiscoveryParticipant] - Discovered
Tradfri gateway doesn’t have an IP address: [ServiceInfoImpl@1378908897 name: ‘gw-dcefcabcf933._coap._udp.local.’ address: ‘(null):0’ status: ‘DNS: JmDNS-IP-2 [/192.168.0.4] state: probing 1 task: null’, has NO data, empty]
2019-02-16 13:08:48.659 [WARN ] [iscovery.TradfriDiscoveryParticipant] - Discovered Tradfri gateway doesn’t have an IP address: [ServiceInfoImpl@594301319 name: ‘gw-dcefcabcf933._coap._udp.local.’ address: ‘(null):0’ status: ‘DNS: JmDNS-IP-1 [/2a02:908:4c1:f560:42:c0ff:fea8:4%eth0] state: probing 1 task: null’, has NO data, empty]
2019-02-16 13:08:48.659 [WARN ] [iscovery.TradfriDiscoveryParticipant] - Discovered Tradfri gateway doesn’t have an IP address: [ServiceInfoImpl@1825249167 name: ‘gw-dcefcabcf933._coap._udp.local.’ address: ‘(null):0’ status: ‘DNS: JmDNS-IP-3 [/2a02:908:4c1:f560:0:0:0:4%eth0] state: probing 1 task: null’, has NO data, empty]
2019-02-16 16:31:20.422 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@265e9c3c rejected from java.util.concurrent.ScheduledThreadPoolExecutor@504e03c4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 11607]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622) ~[?:?]
at java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:668) ~[?:?]
at org.eclipse.californium.core.network.CoapEndpoint.runInProtocolStage(CoapEndpoint.java:718) ~[?:?]
at org.eclipse.californium.core.network.CoapEndpoint.sendRequest(CoapEndpoint.java:392) ~[?:?]
at org.eclipse.californium.core.CoapClient.send(CoapClient.java:922) ~[?:?]
at org.eclipse.californium.core.CoapClient.observe(CoapClient.java:889) ~[?:?]
at org.eclipse.californium.core.CoapClient.observe(CoapClient.java:723) ~[?:?]
at org.eclipse.smarthome.binding.tradfri.internal.TradfriCoapClient.startObserve(TradfriCoapClient.java:75) ~[?:?]
at org.eclipse.smarthome.binding.tradfri.handler.TradfriThingHandler.lambda$1(TradfriThingHandler.java:115) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
I have tried out the Conbee/deconz for a while, but it is not stable. Lights becomes unreachable in the Zigbee network.
Will try using a HUE gateway next. The HUE binding is lacking a bit due to no maintainer, but its REST API is identical to deconz so that will be a breeze.
The fact that the Ikea gateway does not always re-connect is specially annoying for my old mother 140km away. I have managed to come to the rescue (remote) each time though since I have the gateway on a Z-Wave power plug, but sometimes it takes several attempts power-cycling the gateway and restarting the binding in karaf to get the lights online again.
Guys, I lost the overview. I am on OH 2.5 M1, which is quite outdated regarding this topic, I think. Meanwhile there are bug reports, discussions and solution approaches in at least three threads:
where the last two ones are part of the ESH repository which meanwhile has been merged (right?).
Is someone on snapshot builds and can confirm something was improved? Thank you.
Just installed SNAPSHOT #1562
Issue is still there.
I’m moving my devices over to a HUE Gateway now.
Not a solution, but a workaround
IKEA published a brand new firmware, v1.8.25, especially with improved HomeKit connection, see e.g.
Has someone received the update? Does it resolve the issue?
Hi guys, I had the same problem, but it appears to be solved by entering the security code in “pre-shared security key” (“show more”). Hope that helps!
You can also disable / enable the tradfri gateway ‘thing’. It’s the clock picture on the right of the thing.
I had to wait for a few minutes. But all is online again
I have recently done a hard reset (with a pin) of my Ikea Gateway following the 1.8.25 firmware disaster.
I have added just 1 E27 CT bulb and 1 5-button remote.
OH2 still fails to re-connect after a restart.
The state of this issue makes for a very unstable experience and it has been like this for many months now.
I see the same on a second site I run.
My solution is ditching the Ikea Gateway all together opting for this solution instead.
T@OMR I find it interesting the mixed results people have. Makes me curious what the differences are in the setups.
Don’t get me wrong I had some myopenhab problems once that no one seemed to duplicate. I am sure in my case it was a typo somewhere. Starting over on my openHAB install fixed it.
For the tradfri I am wondering is it a network issue, tradfri issue or an openHAB issue. I don’t know how to explain as my install to be rock solid and yours to be unstable.
My problem regarding the issue of this thread, started last fall.
Everything has always been stable once Online, until the next powerUp or restart. (with rare bulb/panel hangs)
Problem started simultaneously on two separate sites, both running OH2 on x64 Linux Ubuntu server PCs. It’s hard to say if it was caused by an Ikea firmware upgrade or if it came with my bi-weekly upgrade of OH2 to the latest Snapshot.
All I know is that I suddenly found that I had to log in to Karaf and restart the tradfri bundle, often several times and sometimes even power-cycling the Gateway in order to get it Online again.
I have also experienced 2 times after such a power-cycle that all my device pairings was lost.
This lead me to replace the Gateway some time ago.
With the arrival of the 1.8.25 firmware version, it became super unstable, losing COAP connection after an hour or two, and sometimes even not connecting to the Ikea Android App. (but it always answered to ping requests)
So after struggling over a week with this, I had to reset the Gateway with a pin. Back to ‘normal’ after that. On my second site, the 1.8.25 firmware upgrade caused no problems. I was just unlucky I guess.
Firmware upgrades are never totally risk free.
Well, water under the bridge. I’m super happy with my new setup, enjoying fast, synchronous actions on large groups of lights, with a backup of everything
(Keeping the Gateay Online with 1 CT Bulb, just to check if they push any new bulb firmware. There is an issue with lights in larger groups (>12) becoming unreachable over time, both on deconz and the Philips HUE Gateway. Both camps think it’s a bulb issue.)
Do you mean you have no problems anymore?
I faced this issue the other day. I changed the IP of gateway to a wrong one and then back to a new one and it worked again.
But it is not a reliable way of living…
After I moved the majority of my Ikea devices (save 2) to deconz, all is super stable.
I now have: (all lights and wall-plugs are Ikea, switches a mix of Ikea 5-button, HUE and Mi Cubes)
12 switches (remotes), 2 sensors and 33 lights/wall-plugs on conbee/deconz,
28 lights and a sensor on a Philips HUE Bridge
Ok, after reading all the comments, following many different links with hints and tips, still my Gateway will not re-connect to Openhab. Does anybody have a solution for this problem other than buying a usb zigbee stick?
Many thanks! Solved my communication error.
my Tradri gateway still goes offline after a couple of days. Nothing really improved over the last months. There were three GitHub reports:
- https://github.com/openhab/openhab-addons/pull/4764: Closed, but did not help
- https://github.com/eclipse/smarthome/issues/6065: Open. An update of Californium was announced, but it did not help
- https://github.com/eclipse/smarthome/issues/6748: Open.
Can you report an improvement?
Did the latter two issues get lost during the merge of the Eclipse framework?
Every now and then I’m finding tradfri hub disconnected from openhab and need to re-enter the pre-shared key. I’m slowly migrating over to zigbee2mqtt.io (with ota fw upgrade for TF devices - no more reason to stick to TF hub) - that’s my solution
Okay. Heals the problem. But it’s rather a workaround than a solution.
Looks like many people quit from the binding as the problem seems to be impossible to be clearly identified.