Thanks @J-N-K that sort of worked for me. I had it configured in my tradfri.things file but have had to remove it and let OH discover it as a thing and then specify the code otherwise it would not work. Tried clearing the cache and re-entering the code but that did not seem to work.
Mine is totally screwed after the latest Ikea Firmware update.
I will have to reset the Gateway to fix it I guess, but in that operation I will reduce my number on devices from 28 to 4, just to keep track of what is ‘happening’.
The rest of the devices I will transfer to Conbee/deconz.
1 - Group actions operates all lights in perfect, instant synchronisation. (though http/REST API)
2 - Paired devices and setup can be backed up (and restored).
3 - Zigbee-net pairing remotes/groups with lights are done in the WEB app. No need to pair next to light.
4 - Ikea remote button events are catch-able for use in rules.
5 - No gateway connection issues.
6 - OH2 HUE binding interfaces easy to devices (but no native /groups control)
7 - OH2 deconz binding interfaces to sensors through Websocket. (No polling required)
1 - On 5 button remote, the < & > buttons does nothing, so the ‘manual backup’ cannot control color.
2 - Firmware updates are not transparent(, but possible)
I have also tried out the HUE bridge with Ikea lights and it works OK, but no pairing of remotes (other than direct remote-light for manual backup), and no possibility to back up paired devices.
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.
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.