IKEA Trådfri Gateway

I will check it out.
It says it is also using the HUE binding. Hope it can co-exist with the HUE binding I’m already using with my HUE gateway.

It’s not “using” the Hue binding, it complements it. It allows real-time interaction. The Hue binding only supports polling (because the Hue bridge only supports that).

But I think we are offtopic.

I’m experiencing issues with the tradfri binding for more than a year now.
Things got even worse for me since the update to 1.8.25
My Tradfri.things config is useless since then and it’s things have not been available at all since the software update. Ikea seems to be responsible for the enhanced challenges on top of the known ones.
Getting the auto-discovered things to work is not completly hopeless but is not at all stable, having like 2 communication-error-events a week appears about normal.
When this happens, 21 devices of my s.home are offline so yes, it is a major problem.

And there is no easy fix when it happens. This thread and others have a list of measures which sometimes work.

  • click/unclick the stopwatch icon in paper-ui/config/things/tradfri
  • edit the thing there and do something accidential like change its name, reenter the security code or whatever, just enough to make the data appear new and trigger an internal reset
  • openhab-cli console , find the bundle number with bundle:list|grep DFRI , restart it. : repeat
  • uninstall/reinstall the addon
  • stop openhab2, clear the cache, restart it
  • power-cycle the tradfri gateway
  • reboot the raspi
  • force reinstall openhab2 package
    (the steps have been sorted in the order of severity, after doing one repeat all the steps above it.)

each of those measures has at one time or another triggered a tradfri.things renaissance. And failed on many other occasions.

I dream of a basic “stupid” addon, something with no discovery, something I configure with the IP and security code and it just uses them and does not complain that the thing has no IP and thus is at " address: ‘(null):5684’ " (as it does on every. single. start. of openhab2)

I started research into python tradfri-controlers to circumvent using the binding, Ole’s hint at Conbee/deconz is interesting and at times I wonder if it is time to look beyond openhab2 and search a sh-control system with more stability.

Because the way it is now I have to be home every day to fix things like the tradfri binding or people get desparate cause the lights just dont work.

@rubens mine is working great after update. There is another thread about this firmware version.

It sights the fix. Also make sure using tradfri app that all tradfri devices are up to date this appears to cause issues of not.

1 Like

another thread? Lot’s of other threads to that issue. And lots of bugs on github. I consult Google like twice a week on that.
Glad to hear it all works nicely for you.

Tradfri 1.8.25 - offline - communication_error

thanks for the Link, interesting.
As a side effect of working through that thread I realised that pytradfri https://github.com/ggravlingen/pytradfri can be used to better test the current state of connectability of the gateway. If and when Tradfri is shown to be in communication error and pyrtradfri throws exceptions at start then I know I have to powercycle the gateway before I try anything else.
I had checked the android tradfri app but apparently the app has means to contact the gateway even when other channels fail.

I had to reset my gateway with a pin after the upgrade. Tried everything to no avail.
All devices have to be re-paired.

I’ve got several remotes which are struggling to update. Maybe that it for me. I’ve tried deleting it, restarting, but it never appears in the inbox.

Check here for how to update your remotes.

1 Like

Thanks, I’ll give that a go.

All the remotes have now updated, thank you.

I still cannot make the gateway appear in inbox. I’ve set DEBUG on the binding and just getting alot of COAP errors.

Manually adding the gateway seems to set the pre shared key to my security code, and doesnt get an identity.

231 │ Active │ 80 │ 0.11.0.oh250M1 │ Eclipse SmartHome TRÅDFRI Binding

You might need to reset with a pin I’m afraid. A drag to re-pair everything though…
That is why I moved my devices to deconz.
Details here.

yeah i was hoping to avoid that. i’ll keep trying. There is an open issue on github at the moment, might wait to see what happens there.

Tradfri but not carefree.

the good news first, it is still green, online after 2 days :wink:
However, I see quite a few exceptions in the log, they seem to originate from a recurrent task scheduled for every minute. This task does not fail every minute, all ran fine for 10 hours and then exception on 13:00:19.260,13:01:19.340, 13:02:19.258 ,
… 13:08:19.272. Then all is fine for a while and then it fails again at the 19th second

2019-05-02 13:00:19.260 [ERROR] [alifornium.core.network.CoapEndpoint] - Exception in protocol stage thread: This is not a JSON Array.
java.lang.IllegalStateException: This is not a JSON Array.
        at com.google.gson.JsonElement.getAsJsonArray(JsonElement.java:106) ~[?:?]
        at org.eclipse.smarthome.binding.tradfri.handler.TradfriGatewayHandler.onUpdate(TradfriGatewayHandler.java:304) ~[?:?]
        at org.eclipse.smarthome.binding.tradfri.internal.TradfriCoapHandler.onLoad(TradfriCoapHandler.java:65) ~[?:?]
        at org.eclipse.californium.core.CoapClient$MessageObserverImpl.deliver(CoapClient.java:1016) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.CoapClient$MessageObserverImpl.succeeded(CoapClient.java:995) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.CoapClient$MessageObserverImpl.onResponse(CoapClient.java:974) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.coap.Request.setResponse(Request.java:509) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.EndpointManager$ClientMessageDeliverer.deliverResponse(EndpointManager.java:267) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.CoapStack$StackTopAdapter.receiveResponse(CoapStack.java:193) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.ObserveLayer.receiveResponse(ObserveLayer.java:137) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveResponse(BlockwiseLayer.java:321) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveResponse(ReliabilityLayer.java:269) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:98) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.stack.CoapStack.receiveResponse(CoapStack.java:135) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveMessage(CoapEndpoint.java:656) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.access$700(CoapEndpoint.java:562) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl$1.run(CoapEndpoint.java:574) ~[249:californium-osgi:1.0.6]
        at org.eclipse.californium.core.network.CoapEndpoint$5.run(CoapEndpoint.java:721) [249:californium-osgi:1.0.6]
        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 searched the archives and found it mentioned once before in 2017

Things still seem to work. it just trashes the logs and openhab2 lags when it’s busy throwing exceptions.

So i’ve fired up an old instance of openhab i had nocking around on a pi before i migrated to a centos vm. Using this I got my old ID and preshared key. Used those on the new instance and I’m back online… for now! :slight_smile: Thanks all

Edit: I should add that it seems the root cause that started all this was remotes which refused to update. Pull the battery out for a few mins and try again. If the battery is low, change the battery. Resolved after a few hours of doing this. Then it was just getting my gateway back online, which I used the above method.

1 Like


Seems to be the case still, I tried out my first Trådfri today.

I saw that a PR was merged yesterday I think to support blinds.
When will that version be available to use?
(Without the need of installing the jar manually?)

There will be a new milestone release in the next couple of days. Probably tomorrow if everything works nicely.


Can someone help with a rule.
I have 3 led spot in the bathroom. 2 of them are connected to a remote, one of them to a move sensor.
The disadvantage of tradfri is that you can not ‘connect’ a lamp to 2 devices.

What i want, make a rule that if the 2 led change (brightness), the third one follows to the same value

can someone set up an example for me ?
many thanks in advance