I’m using a Tradfri Gateway for about a year now and especially in the first months it caused me more than enough headaches. Sometimes because of the gateway running unreliable, sometimes because of the HA tradfri integration running far from flawlessly. TBH most of the other components connected to my HA instance have been more fun using than these tradfri devices.
This is the main reason I wanted to get rid of the tradfri gateway. The other is, that I want to use non-tradfri zigbee components as well and don’t wanted to install multiple zigbee gateways.
Thus, since a couple of days I’m testing a Raspbee premium zigbee gateway with a previously never used trafdri bulb and it’s remote and this is, what I experienced:
As I always try to go minimal, the first approach was to use the headless Raspbian image on an old RPi 1. Ok, I know this was asking for trouble, but hey… According to the manufacturer, the RPi 1 is a supported device for the Raspbee module and the Raspbian images.
Anyways, the performance of the system and especially the Phoscon App was terrible, I experienced some weird behavior with the app and the os always went haywire after a couple of minutes because of some system service running amok. As far as I found out, this was some wifi stuff going south because… well, probably because there was no wifi hardware connected or integrated into this RPi at all. I finally got rid of it by disabling it via systemctl, but because of the poor overall performance I quickly started over with a RPi 2.
Again, I first tried the headless image on the RPi 2. Turned out, the weird behavior of the Phoscon app was the same as before: When using the name of the RPi in the URL, the app only recognized a gateway at 127.0.0,1 and going with it, a login was never possible. The gateway was only recognized properly when using the IP of the RPi in the URL. I may be wrong, but to me this looks like some crappy name resolution code in the Phoscon app.
While we are at it: The login. Was never possible with Chrome on a Win10 client, despite the correct password being used. Neither clearing the cache, nor incognito mode helped. I finally had to use Microsoft Edge or Firefox to properly login into the instance.
And the problems had just begun. Registering my tradfri bulb and a remote needed some serious effort. Until now, I don’t know exactly, how to reliably register a device. I literally put the devices onto the Raspbee module. I reset and power cycled the devices multiple times in different orders. Sometimes the device was recognized in a couple of seconds, sometimes after two or three minutes and sometimes it seemed, if the device wasn’t recognized at all, but then it magically appeared in the list of registered devices after a logout and re-login.
I’m kind of scared when thinking about registering my tradfri panels to this Raspbee module… They are permanently installed on the roof of my bathroom and far from the wall switch, which whom they are turned on and off. 
And while the Phoscon App looks sleek, I struggled to find the right places in the UI to configure my zigbee devices correctly. The first mistake: I assigned the remote directly to the lamp. The result: Dimming kind of worked, but changing color temperature didn’t work at all. Some googling revealed: This is a known limitation. I’m supposed to put the lamp (even if it’s only one) into a group, assign the remote to the group and use the switch editor to manually assign functions to every button on the remote. Uhm… ok.
The switch editor gave me more headaches. Added actions for the remote buttons were sometimes saved, sometimes not. Sometimes I had to define the same action for the same button twice until it appeared at least once in the list of key assignments. Sometimes, when adding some key to the list, this key didn’t appear after saving, but instead one of the previously defined but lost again key assignments suddenly appeared. WTH?
After a lot of messing around with the key assignments I was finally able to test dimming and changing color temperature… and honestly wasn’t delighted. Both dimming and color changing was kind of unresponsive and far from smooth. With the remote assigned directly to the lamp, at least continuous dimming was possible. I.e. holding the remote button until the desired brightness or color is reached. But with the buttons configured in the switch editor, I always had to press the remote buttons multiple times and the brightness changed only gradually. I still don’t know, if this is expected behavior of the app or if I still did something wrong with the configuration…
Anyways: In the end I ditched all groups and key assignments in the Phoscon app. I only registered the raw devices to be able to forward them to Home Assistant and wrote some automations for continuous and smooth (!) dimming in HA. This finally gave me a similar “user experience” with the tradfri remote as with my other remotes and bulbs still connected to the tradfri gateway.
The latest issue I’m struggeling with is a bug with the color_temp attribute not being exposed correctly to HA for w/ww bulbs (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1861), which will hopefully being fixed with the next deConz version. Currently, because of this bug, I’m not able to write a proper HA automation for continuous color temperature cycling using the tradfri remote. :-/
Oh, and sometimes in between all this I also started over with a third SD card image. This time the (non headless) desktop image, after I realized, that there’s no other way to use the deConz GUI with my Raspbee module than to run it on the same device, the Raspbee module is physically connected to. Ok, I admit, this is clearly a case of RTFM.
At least, when switching the SD image again, I didn’t have to re-register the bulb and the remote, as the backup and restore function of the Phoscon app worked flawlessly …or did it?
No, actually not! The backup and restore didn’t work flawlessly at all. I couldn’t find it in the first place, because after klicking the “Gateway” link in the settings menu the page turned completely empty. After some more googling I found out, that this is also a known issue and the workaround is to remove the “2” from “settings-gateway2.html” in the URL. Yeah… why not.
Ok, to cut a long story short: Is it just me doing everything wrong that can be done wrong with this module? Or is this the long term user experience I have to expect, even if I’m doing everything right?
Does it get better sometimes? Does it at least work reliably after everything is configured properly?
ATM I’m really not sure, if I want to further encumber me with this module or if I put it back into the shoe box where it came from until I desperatly want to use any non-tradfri zigbee device in my house. What do you think?
Edit: I almost forgot this weird problem of my Raspbee zigbee network becoming unavailable after a reboot of the Pi, suddenly appearing after three days without any issues. Turned out, the
deconz-gui service suddenly refused to autostart. And that this is obviously caused by an uncaught race condition in the order the services are started at boot time. Again, this seems to be a known issue as well. Since April…