Another update about the progress:
No devices shows up in the deconz portal:
If I try to connect a device, there are only these options:
But I still managed to add the sensors via the “open network” method. But in the portal I can only see the light sensor-part of the Human Body Sensor in the Daylight Control-page.
Haven’t been able to find the other sensors/switches in the portal.
Check out snillevillas guides for adding devices to deconz. Might help. I might have time to support on Sunday or Monday. Fully booked most of this weekend. Try to click around a bit more, you’re making progress at least
This topic is for everything deconz, it is not mine. I myself hijacked it for the component.
Sounds like you’re making progress. It’s great that you cooperate with manup.
We’re having the same thoughts about gui integration. I’ve cloned the front end and started building it. But it will take Some time since I don’t have a lot or experience with gui html and front-end development.
FYI just opened an issue on your pydeconz GitHub page - an exception came up in HA today while I was testing.
That’s great! Might need additional checks before Json parsing. Please if you can add extra print outs and try that some more. I haven’t had any issues lately
@marthocoo You are most welcome to “hijack” this thread 
Just good to gather related stuff. Adjusted the topic accordingly.
@Robban Thanks for all help so far! Much appreciated 
I will check out snillevilla in the meantime.
Found new app to use instead of locally installed UI for deCONZ RestAPI:
Phoscon App from Dresden Elektronik: http://www.dresden-elektronik.de/pwa
Discovers the deCONZ RestAPI automagically, but requires the most recent beta version (2.04.94-qt5).
It connects to the RestAPI and displays the paired devices. Xiaomi Motion Sensor didn’t show up in RestAPI UI, but in the Phoscon App it did, so it was a little bit easier to se what was going on.
(I’m running deCONZ headless on my Raspberry, btw)
Xiaomi Aqara Human Body Sensor
Xiaomi Mijia Smart Wireless Switch
Also, I have ordered smoke-, humidity-, air pressure and window/door-sensors. Will update with test results as soon as I get them.
Its great that you’ve ordered more stuff, as you try more devices, please add comments in documentation PR about devices verified to work.
@Robban I am noticing an issue with the creation of battery sensors. Generally, after adding a device I need to restart HA two or three times before a battery sensor entity for a remote or motion sensor shows up. Also, for one device (an ikea motion sensor) there is no battery sensor entity being created, though deCONZ does report the battery level and there is a battery level attribute of the sensor in HA.
Only remotes get battery sensors since they don’t have their own entity. Every other sensor gets a battery attribute instead
This makes perfect sense. Thanks!
It is however the case that sometimes two or three restarts are needed to get the batteries to show up.
That’s really weird. Restart of hass or deconz? Because if the information is there the entity should get created
Restart of HASS. The battery attribute is visible in the deCONZ Phoscon web app, but the entity doesn’t get created on the first Hass restart after adding the device to deCONZ.
Check the debug output of the component to see if the battery information is posted when booting. It is either a component or deconz issue.
What device are making trouble?
I’m pretty sure the only device I really noticed the issue with was the Hue Dimmer. I’ve had debug logging on for a while now but I have to actually parse through it to see what the behaviour is. Tomorrow I plan to remove the remote from deconz and readd it and see what happens on HASS startup.
Another issue, I’m not sure if you’ve noticed it or if I’ve configured something in either HA or deconz incorrectly: For testing purposes I’ve limited my test system to a Hue Dimmer and two Hue white ambiance lights connected to deconz and configured in a deconz group. When I start HASS, the lights are picked up along with the group - perfect. And the remote sends events which are picked up in HASS - perfect.
But, if I restart Deconz, though the lights are available immediately when Pydeconz reconnects to the websocket, no deconz_event is picked up in HASS on button presses of the remote. If I check the deconz web app, the remote is greyed out as if it’s not yet detected. Shortly after, the icon in deconz is no longer greyed out, which I think means it’s now available, but there are still no deconz events in HASS on button presses. This happened last night when I updated deconz to 2.04.96, I couldn’t figure out why the remote stopped working and so went to bed to leave t for the morning. When I got up, the remote worked again to send deconz_events in Hass.
So I’m not really sure yet if the problem is on deconz side (is it sending button events on the websocket API?) or on the pydeconz side (not reconnecting properly after a disconnect?).
EDIT: Update
After a system restart (so both deconz and HASS restarted), here’s what’s in the logs:
2017-12-10 22:38:34 DEBUG (MainThread) [pydeconz.deconzdevice] Master Bedroom Dimmer created as {'_swversion': '5.45.1.16265', '_on': True, '_ep': 2, '_modelid': 'RWL020', '_sensor_icon': None, '_reachable': False, '_type': 'ZHASwitch', '_name': 'Master Bedroom Dimmer', '_buttonevent': 2002, '_battery': 100, '_manufacturername': 'Philips', '_sensor_unit': None, '_etag': '6402e68da38024e56a1564c84ecb96bc', '_async_callback': [], '_uniqueid': '00:17:88:01:10:3f:62:35-02-fc00', '_sensor_class': None}
And then shortly thereafter:
2017-12-10 22:41:44 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81v{"config":{"battery":100,"group":"11721","on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event"}'
2017-12-10 22:41:44 DEBUG (MainThread) [pydeconz.deconzdevice] Update {}
2017-12-10 22:41:44 DEBUG (MainThread) [pydeconz.deconzdevice] Update {'group': '11721', 'battery': 100, 'on': True, 'reachable': True}
So its looks like the dimmer is at first unreachable, then a few minutes later is reachable. But pressing buttons yields no deconz_event in HASS. Any advice on how I can debug further?
I think this needs more deconz knowledge, maybe check with manup?
A possible visual solution is to not care for the reachable parameter for remotes.
I can’t really tell you what’s happened to my setup overnight, but all of a sudden this morning things are working exactly as they should. After a deCONZ restart (but no restart of HASS) a button press on a remote causes the remote to send a reachable true message over web sockets which pydeconz receives and the button press runs the automation in HASS. Walking past a Tradfri motion sensor marked as “unavailable” after the deCONZ restart causes a web sockets event which pydeconz receives, making the motion sensor available and showing motion in the HASS frontend. I’ve restarted deCONZ and the entire RPi3 multiple times and its worked every time as it should.
So disregard my problem reporting for now, I think this is down to some quirks with the way ZigBee networks work and is most likely on the deCONZ side anyway, since pydeconz seems to have no issue reconnecting to deCONZ after it’s restarted and clearly receives web socket events when deCONZ is sending them.
Also, on a different note, I have enabled the Flux component for two of my colour temperature lights and it’s working flawlessly. It generates a lot of web sockets traffic during the day since it updates the colour temp of the lights so frequently, and tailing the DEBUG log shows that pydeconz is having no problems with sending and receiving the updates. Very nice!
It is really great that you’re taking the time to try it out prior to merge! Im on my feet ready to work on the code if you find anything!
Haha most of my problems seem to be solving themselves, which is good if not somewhat mystifying. Don’t have any time to test today but tomorrow I’ll be migrating more bulbs over to the test environment and also trying to pin down the possible “battery sensor not created right away” issue.