In general most Zigbee devices that are lights just work. That part of the Zigbee standard seems to be handled the same way and everyone wants to be compatible with Philips Hue hub
In general any remote control (switch) not on the supported list, will not work.
I just did the update of the Deconz add-on to 5.3.5. After reading the changelog, it was actually a downgrade though?
However, now HASS is not able to connect to any of the DeconZ entities anymore, while in Phoscon they are all there and work. So something is wrong with the latest update of the add-on and it breaks it connection somehow to HASS (integration still shows up and is not removed).
On Github seems I’m not the only one experiencing this?
I’ve rebooted the HASS server in it’s entirety as well, but the entities in HASS do not connect back and show as unavailable.
Only error I see in the log so far:
Logger: homeassistant.helpers.service
Source: helpers/service.py:423
First occurred: 5:24:57 PM (2 occurrences)
Last logged: 5:32:12 PM
Unable to find referenced entities light.attic_light_5, light.attic_light_6, light.attic_light_7, light.attic_light_8
Unable to find referenced entities cover.window_covering_device_18, cover.window_covering_device_19
In the Supervisor log I do see the following (Docker IP of Deconz):
20-06-04 16:06:47 ERROR (SyncWorker_9) [asyncio] Unclosed connection
client_connection: Connection<ConnectionKey(host='172.30.33.1', port=8099, is_ssl=False, ssl=None, proxy=None, proxy_auth=None, proxy_headers_hash=None)>
How can I best troubleshoot to provide some more useful info?
It’s a quite urgent matter because now all my zigbee lights and devices are not working with HASS in the house 
which are almost all the lights I have…
For situations like that, I highly recommend binding switches directly to light groups so that you can control the lights with wall buttons if HA or deconz stops working.
But it is to late for you now. You have to get your system up and running before anything else.
Gee, I’m glad I read the change log before clicking update. When I read it was a downgrade, I decided not to, as my setup was working fine (if it ain’t broke…). Sorry if this is rubbing salt into people’s wounds who did update but I’ve learnt the hard way not to blindly click update on everything.
I gave up trying to do this with Ikea stuff as it was just too brittle. Switches would randomly stop working with lights or the hub and then going through the process of re-binding them would stuff up any other switches I had not disconnected the batteries for… such a headache.
Doesn’t actually appear to be the deCONZ update (downgrade) as I was lucky enough to have a nightly backup and I restored just the deCONZ add-on to 5.3.4 and my issues still exist. It may be related to the actual deCONZ firmware as I upgraded my stick along with the add-on just recently?
I’ve got some sensors showing, most not and no light control. My issues started this evening after I was testing bluetooth on my NUC and HA hung on start so I had to shut the NUC down manually. After this, deCONZ turned to custard so I only updated (downgraded) the deCONZ add-on to see if that would fix it but alas no change.
I’m going to try physically swapping USB ports now (as that has worked before) and if that does not work, I’ll try downgrading the deCONZ firmware on my Conbee II to see if that works and report back.
EDIT: After a host reboot (with 5.3.4), most of my sensors came back but the lights would still not work. I then downgraded (using a backup) even further to 5.3.2 (which has deCONZ 2.05.75) and after a bit of playing around with the port, my lights are now working again but all of my sensors and switches have gone. Go figure. Looking more like the Conbee firmware the more I dig.
To be honest, I’ve had so many issues with deCONZ ever since I changed over, I’m nearly at the end of my rope.
Update: After restoring the light function using 5.3.2 (as the Xiaomi switches I have act as Zigbee extenders/repeaters), all of my sensors and switches slowly came back once they checked in. Ain’t touchin nothin now!
Wondering if anyone can help me on the below. We had a power cut last night for about an hour. After the power came back on everything restarted but my Deconz has been having an issue.
I have a raspbee premium connected to a Pi 3+ running Hassio.
I have the deconz addon which I thought might have had a problem with the latest update so have done a restore to 5.3.2 but that did not help.
I only have two temp sensors and a door sensor so far but they are all showing unavailable in HA and Not Reachable in the Deconz GUI.
On top of this in the GUI my gateway is showing “not connected”
when I stop the deconz add on it shows deconz up and running although does have two worrying lines around “failed to open swrast”
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
starting version 232
[15:54:38] INFO: Waiting for device...
[15:54:39] INFO: Starting VNC server...
[15:54:44] INFO: Starting the deCONZ gateway...
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
libpng warning: iCCP: known incorrect sRGB profile
[15:54:46] INFO: Starting Nginx...
[15:54:46] INFO: Running Home Assistant discovery task...
[15:54:46] INFO: Running the deCONZ OTA updater...
[15:54:46] INFO: Running the IKEA OTA updater...
[15:54:46] INFO: Running the LEDVANCE/OSRAM OTA updater...
[15:54:46] INFO: deCONZ is set up and running!
2020/06/05 15:54:46 [notice] 597#597: using the "epoll" event method
2020/06/05 15:54:46 [notice] 597#597: nginx/1.10.3
2020/06/05 15:54:46 [notice] 597#597: OS: Linux 5.4.42-v7
2020/06/05 15:54:46 [notice] 597#597: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2020/06/05 15:54:46 [notice] 597#597: start worker processes
2020/06/05 15:54:46 [notice] 597#597: start worker process 629
After a short while it then tries to connect obviously and runs into errors:
[15:55:05] INFO: Successfully send discovery information to Home Assistant.
15:54:46:116 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/
15:54:46:134 CTRL. 3.16.215:54:46:456 dev /dev/ttyAMA0
15:54:46:456 COM: /dev/ttyAMA0 / serialno:
15:54:46:456 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:54:46:457 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt
15:54:46:906 parent process bash
15:54:46:906 gw run mode: docker/hassio
15:54:46:906 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version
15:54:46:907 sd-card cid: 035344534533324780ffffffff012bf9
15:54:46:954 DB sqlite version 3.16.2
15:54:46:959 DB PRAGMA page_count: 30
15:54:46:959 DB PRAGMA page_size: 4096
15:54:46:959 DB PRAGMA freelist_count: 0
15:54:46:959 DB file size 122880 bytes, free pages 0
15:54:46:959 DB PRAGMA user_version: 6
15:54:46:959 DB cleanup
15:54:46:975 DB create temporary views
15:54:47:010 don't close database yet, keep open for 900 seconds
15:54:47:012 started websocket server at port 8081
15:54:47:030 found node plugin: libde_rest_plugin.so - REST API Plugin
15:54:47:039 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
15:55:05:405 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
15:55:05:449 dev /dev/ttyAMA0
15:55:05:449 COM: /dev/ttyAMA0 / serialno:
15:55:05:449 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:05:736 New websocket 172.30.32.1:47220 (state: 3)
15:55:05:785 dev /dev/ttyAMA0
15:55:06:082 Announced to internet https://phoscon.de/discover
15:55:06:083 discovery server date: Fri, 05 Jun 2020 14:55:06 GMT
15:55:06:083 local time seems to be ok
15:55:06:083 discovery found version 2.04.35 for update channel stable
15:55:15:140 dev /dev/ttyAMA0
15:55:15:140 COM: /dev/ttyAMA0 / serialno:
15:55:15:140 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:15:174 device disconnected reason: 4, index: 0
15:55:16:104 wait reconnect 15 seconds
15:55:16:147 dev /dev/ttyAMA0
15:55:16:147 COM: /dev/ttyAMA0 / serialno:
15:55:16:147 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:16:185 dev /dev/ttyAMA0
15:55:17:105 wait reconnect 14 seconds
15:55:18:104 wait reconnect 13 seconds
15:55:19:105 wait reconnect 12 seconds
15:55:20:105 wait reconnect 11 seconds
15:55:21:104 wait reconnect 10 seconds
15:55:22:104 wait reconnect 9 seconds
15:55:23:104 wait reconnect 8 seconds
15:55:24:105 wait reconnect 7 seconds
15:55:24:605 start reconnect to network
15:55:25:104 wait reconnect 6 seconds
15:55:26:105 wait reconnect 5 seconds
15:55:26:142 dev /dev/ttyAMA0
15:55:27:104 wait reconnect 4 seconds
15:55:28:104 wait reconnect 3 seconds
15:55:29:104 wait reconnect 2 seconds
15:55:29:855 failed to reconnect to network try=1
15:55:30:105 wait reconnect 1 seconds
15:55:30:148 dev /dev/ttyAMA0
15:55:30:148 COM: /dev/ttyAMA0 / serialno:
15:55:30:148 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:30:168 device disconnected reason: 4, index: 0
15:55:31:104 wait reconnect 15 seconds
15:55:31:138 dev /dev/ttyAMA0
15:55:31:138 COM: /dev/ttyAMA0 / serialno:
15:55:31:138 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:32:105 wait reconnect 14 seconds
15:55:33:104 wait reconnect 13 seconds
15:55:34:104 wait reconnect 12 seconds
15:55:35:104 failed to reconnect to network try=2
15:55:35:104 wait reconnect 11 seconds
15:55:36:104 wait reconnect 10 seconds
15:55:36:137 dev /dev/ttyAMA0
15:55:37:104 wait reconnect 9 seconds
15:55:38:104 wait reconnect 8 seconds
15:55:39:105 wait reconnect 7 seconds
15:55:40:105 failed to reconnect to network try=3
15:55:40:105 wait reconnect 6 seconds
15:55:41:104 wait reconnect 5 seconds
15:55:42:104 wait reconnect 4 seconds
15:55:43:105 wait reconnect 3 seconds
15:55:44:105 wait reconnect 2 seconds
15:55:45:104 failed to reconnect to network try=4
15:55:45:104 wait reconnect 1 seconds
15:55:45:140 dev /dev/ttyAMA0
15:55:45:140 COM: /dev/ttyAMA0 / serialno:
15:55:45:140 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:55:45:162 device disconnected reason: 4, index: 0
15:55:46:104 wait reconnect 15 seconds
15:55:46:138 dev /dev/ttyAMA0
15:55:46:138 COM: /dev/ttyAMA0 / serialno:
15:55:46:138 COM: --dev: /dev/ttyAMA0 (RaspBee)
it keeps trying until it gets to:
15:56:45:149 dev /dev/ttyAMA0
15:56:45:149 COM: /dev/ttyAMA0 / serialno:
15:56:45:149 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:56:45:172 device disconnected reason: 4, index: 0
I have tried uninstalling it all, I have tried taking the Raspbee premium out of the pi (serial) and turning it on without, then plugging back in. I tried resetting the gateway that just says failure.
Any thoughts? It was working fine until the powercut.
I had the same happening yesterday after hard resetting my pi. I had to change the device in the deconz Add-on settings from
device: /dev/ttyAMA0
To
Device: /dev/ttyS0
After restarting everything worked as before.
Sorry if this has been asked before, I have a question and a suggestion.
Once a new device has been added to the deconz rest api, how do we get it so its visible in the HA Add-on GUI (Phoscon)?
Can we have a new forum for deconz instead of just the one thread which has now become very very large?
Did try changing the USB port
Restart HA
It’s connected via the serial pins
Sorry let me be more specific. They appear in the Integration in HA but not in the Phoscon/GUI add in. When this happens the names I set in HA Integration are not persistent. Everytime Deconz is restarted the names reset. Unless the names are changed in the GUI add in the names are not changed in Deconz
What device is it? Some don’t show in the Phoscon GUI in HA like the Xiaomi smoke detectors. If you add a device using Phoscon, the name you give it will become the name of the entity in HA too but not the entity ID. That will be some random ID you ideally have to change. These changing should stick after a restart.
How to get deCONZ working again after a reboot or supervisor upgrade.
*This is based on my experience with a Conbee II connected to a USB port on an Intel NUC
/dev/ttyACM0 from /dev/ttyACM1 ) and restart add-on. Note that your port may differ.N.B The device by ID serial port (/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_xxxxx) has not worked for me for some time so this is why you have to jump through hoops when your hardware reboots as the ports /dev/ttyACMx are randomly assigned on boot.
Thanks for the advice, I have been using the Deconz add I for 12 months. These are not the issues, if they were no Zigbee devices would be working
You can use the refresh device service as an alternative to restart hass at the end
Thanks for the tip.
Yes I have setup an automation to refresh devices so I go and execute that when I need to
Would you care sharing that? Sounds useful. Thanks!