Conbee II/Deconz stops working when firmware update is needed

Happened again yesterday :frowning:

Yup, happened to me again today only 4 days in. You were right it’s not the firmware, must be Deconz. It’s just odd the forum is not flooded with similar posts considering how popular the Conbee is.

I think I’ll try reverting to the “headless” SD card image. I used to run it on my dedicated pie and it was rock solid then. The downside being it has no graphical view, just the Phoscon web app, but at least it kept running.

As you say, very odd that there aren’t more reports. Please let me know if your fix works! I emailed dresdner about a previous issue and they did not respond.

Ok, so it happened again! Now convinced you are right - it’s deconz, not the stick. This time nothing worked: restarting HA, rebooting the pi, unplugging the stick, hitting the update firmware button in deconz. Eventually, I unplugged the stick, then hit the update firmware button, at which point it began updating! When I plugged the stock back in, it worked. (Of course still on the same firmware)

It is indeed a struggle. Since my last post I’ve been testing a few deconz versions trying to find a stable one and these are my findings so far.

Just to recap: I’m running HA in Proxmox on a NUC-like mini PC. Maybe for that reason I was never able to make the official HA add-on connect to my Conbee II and instead ended up running deconz on a dedicated RPI 3B+.

It took me a while to discover that the deconz download page actually points to two different image folders.There’s a Beta and Stable folder. You would think the images in the Stable folder were the stable ones, but I found that’s not the case for me at least.

The latest stable “Desktop” version is 2.05.67 (Phoscon_Gateway_2019-09-07.xz) and as we know that one will stop working at random intervals asking for a firmware update even though my stick is on the latest 264A0700. Thinking the issue may be caused by a bug in the Desktop UI I decided to go with a “Headless” version instead - starting with the “stable” versions.

2.05.61 (Phoscon_Gateway_Headless_2019-04-10.xz) (stable): Ran this for a full day before discovering none of my Xiaomi sensors weren’t updating anymore. Other sensors worked ok, so I reckon this version simply doesn’t support Xiaomi.

2.05.63 (Phoscon_Gateway_Headless_2019-04-15.xz) (stable): Ran this for 14 hours and it too stopped working, so apparently has the same bug.

2.05.69 (Phoscon_Gateway_Headless_2019-09-07.xz) (stable): This only ran for 4 hours. Same issue. Now switching to the “Beta” versions.

2.05.72 (Phoscon_Gateway_Headless_2019-12-16.xz) (beta): This version has a different bug. It will run flawlessly for exactly 24 hours, then the pie freezes. It’s very odd. I set up a Ping sensor in HA and sure enough after exactly 24 hours on the minute pinging the pie’s IP fails.

2.05.64 (Phoscon_Gateway_Headless_2019-04-23.xz) (beta): This is the image I’m currently running, so far no issues. It’s only been 5 days but I have high hopes because I previously ran this image for about 9 months with no issues although on an older firmware. When I first got my Conbee II I believe this was the default Headless image linked in the download page. The only reason I started messing with deconz was curiocity towards the Desktop version and its fancy visual connection map I’d seen people talk about. But I’ll rather do without the map and have a stable deconz. Fingers crossed :slight_smile:

Same here, conbee2 stick in hassos via vmware exi usb passthrough. It works but after a whil devices are not connected anymore. vnc login works, see devices, but no connection to them. Sucks.

If I restart the addon it won’t detect usb stick untill I physically eject and insert it in the host:
[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 237
[07:51:05] INFO: Waiting for device…

[07:54:05] FATAL: No device /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2194613-if00 found!
[cmd] /run.sh exited 1
[cont-finish.d] executing container finish scripts…
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.

I run latest…?

I don’t think this is the same issue. I had similar problems for a while, but pretty sure they were down to interference between zigbee and wifi. Try moving your zigbee and wifi channels around and see if that helps.

1 Like

A bit of an older thread but I experience the same issues. As far as I’m aware, I’m on the latest firmware version.

I’m running Hassio on an rpi4 with the Conbee II stick using deCONZ. After a reboot, everything is working fine and all temperature sensors (xiaomi aqara) are sending updates. After an unspecified period of time (hours, or days) I notice all sensors seem to be stuck.

Version 2.05.79 22/05/2020
Firmware Not connected

Only solution is to restart the pi.
After reboot, the Firmware field now depicts 26580700.

By the way, accessing the VNC interface instead of the web gui also shows a “not connected” error message. I did notice these lines in the log files.

14:22:37:500 COM: --dev: /dev/ttyACM0 (ConBee II)
14:22:37:551 device disconnected reason: 4, index: 0
14:22:38:458 wait reconnect 15 seconds
14:22:38:499 dev /dev/ttyAMA0
14:22:38:499 COM: --dev: /dev/ttyACM0 (ConBee II)
14:22:39:457 wait reconnect 14 seconds
14:22:40:457 wait reconnect 13 seconds
14:22:41:458 wait reconnect 12 seconds
14:22:42:458 wait reconnect 11 seconds
14:22:43:458 wait reconnect 10 seconds
14:22:43:571 Websocket disconnected 127.0.0.1:36016 (state: 0) 
14:22:44:458 wait reconnect 9 seconds
14:22:45:458 wait reconnect 8 seconds
14:22:46:458 wait reconnect 7 seconds
14:22:47:458 wait reconnect 6 seconds
14:22:48:458 wait reconnect 5 seconds
14:22:49:457 wait reconnect 4 seconds
14:22:50:458 wait reconnect 3 seconds
14:22:51:458 wait reconnect 2 seconds
14:22:52:458 wait reconnect 1 seconds
14:22:52:500 dev /dev/ttyAMA0
14:22:52:500 COM: --dev: /dev/ttyACM0 (ConBee II)
14:22:52:525 device disconnected reason: 4, index: 0
14:22:53:458 wait reconnect 15 seconds
14:22:53:500 dev /dev/ttyAMA0
14:22:53:500 COM: --dev: /dev/ttyACM0 (ConBee II)
14:22:54:458 wait reconnect 14 seconds
14:22:55:457 wait reconnect 13 seconds
14:22:56:458 wait reconnect 12 seconds

After reboot, the log looks a lot more promising, which makes sense since the sensors are updating again.

14:30:35:757 found node plugin: libde_rest_plugin.so - REST API Plugin
14:30:35:763 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
14:30:43:303 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
14:30:43:359 dev /dev/ttyAMA0
14:30:43:359 COM: /dev/ttyACM0 / serialno: DE2193857
14:30:43:359 COM: --dev: /dev/ttyACM0 (ConBee II)
14:30:43:574 dev /dev/ttyAMA0
14:30:44:365 Announced to internet http://dresden-light.appspot.com/discover
14:30:44:366 discovery server date: Thu, 17 Sep 2020 12:30:44 GMT
14:30:44:366 	 local time seems to be ok
14:30:44:366 discovery found version 2.04.35 for update channel stable
14:30:53:704 dev /dev/ttyAMA0
14:30:53:704 COM: /dev/ttyACM0 / serialno: DE2193857
14:30:53:704 COM: --dev: /dev/ttyACM0 (ConBee II)
PROTO: CRC error
PROTO: CRC error
14:30:53:763 dev /dev/ttyAMA0
14:30:53:804 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26580700.bin.GCF
14:30:53:804 GW firmware version: 0x00000002
14:30:53:829 Device firmware version 0x26580700
14:30:53:832 unlocked max nodes: 200
14:30:53:904 Device protocol version: 0x010B
14:30:53:921 new node - ext: 0x00212effff05a2aa, nwk: 0x0000
14:30:54:007 SensorNode 19 set node 0x00158d0004657766
14:30:54:008 SensorNode 17 set node 0x00158d0004657766
14:30:54:008 SensorNode 18 set node 0x00158d0004657766
14:30:54:011 SensorNode 4 set node 0x00158d000465b7bf
14:30:54:012 SensorNode 3 set node 0x00158d000465b7bf
14:30:54:012 SensorNode 2 set node 0x00158d000465b7bf
14:30:54:015 SensorNode 7 set node 0x00158d000464b332
14:30:54:016 SensorNode 6 set node 0x00158d000464b332
14:30:54:016 SensorNode 5 set node 0x00158d000464b332
14:30:54:019 SensorNode 9 set node 0x00158d000464d885
14:30:54:019 SensorNode 10 set node 0x00158d000464d885
14:30:54:020 SensorNode 8 set node 0x00158d000464d885
14:30:54:022 SensorNode 15 set node 0x00158d0004210776
14:30:54:023 SensorNode 16 set node 0x00158d0004210776
14:30:54:024 SensorNode 14 set node 0x00158d0004210776
14:30:54:026 SensorNode 22 set node 0x00158d0004648bb8
14:30:54:027 SensorNode 20 set node 0x00158d0004648bb8
14:30:54:028 SensorNode 21 set node 0x00158d0004648bb8
14:30:54:151 Current channel 11
14:30:54:167 CTRL ANT_CTRL 0x03
14:30:54:205 Device protocol version: 0x010B
14:30:54:256 Current channel 11
14:30:54:275 CTRL ANT_CTRL 0x03

Slowly but surely, sensors within HA are updating as well.

I am still getting these issues periodically - perhaps every couple of weeks. Restarting home assistant usually works, sometimes rebooting the pi is needed. I’m on the latest versions of everything.

It’s really frustrating - for the rest of my family it really impacts their experience. My hue hub is rock solid. It hasn’t had a single issue in two years. Home assistant is pretty stable, but the conbee stick is really flaky, and the support team don’t even respond to emails.

If there was a good alternative to the conbee II I would definitely try it. I’m getting to the point of writing a script to reboot if I don’t get any info from the sensors for a few hours.

1 Like

Same issue here. Going to have to go back to Smartthings for my zigbee devices because I cant get this working after the firmware update.

I just recovered after two days of outages related to the “firmware not connected” thing. I too am on an rpi4 and am booting off of an SSD on one of the usb3 ports. It hadn’t been a problem until I updated the firmware through phoscon the other day. After that, deconz could no longer connect to the stick. I deleted everything and reinstalled. Still nothing.

I even reinstalled ZHA, but it couldn’t connect either. Assuming it was related to the usb3 thing, I set up an instance of deconz on another pi but still nothing.

While reading through the docs I see it mentioned that the firmware update will fall silently if initiated through phoscon. I downloaded a copy of deconz for windows and ended up manually updating the firmware through the command line. Plugged it back into my pi and there it was. All devices came back after a restore from backup.

The only thing I miss from smartthings was the stable zigbee.

1 Like

Andy, I did everything you said and still cannot get it to work right. I am going to get a longer usb dongle today to see if that helps, but i really think its the firmware update. Everything worked perfect until I did that. Now I may have to resort to moving all my zigbee stuff back to the smartthings hub.

I’m using a 2 meter long cable. Did you follow the firmware instructions exactly? You used the command line interface and got a success message? Given all the trouble I’ve had with zigbee and zwave, and given how stable esphome has been, I’m now wishing I would have just used all esp devices from the start.

I am also having issues around firmware updates. Is there any way to manually disable the firmware update part of the plugin, so that I can have a stable environment? Lights stopping to work randomly and then doing reboots until it starts randomly working kinda sucks…

Here the same! Also stopping all devices (unavailable) once in a while. until I update and then back…

Just a quick update for everyone. Issues were getting more frequent: it got so bad that as soon as a device didn’t respond, I’d go straight to deconz, and sure enough, the network map wouldn’t be displayed. A restart of HA would usually fix it - for a couple of days. I thought the issues must just be ZigBee issues in my house, but before giving up on all my sensors
But I bit the bullet and moved off Conbee entirely. I bought an zigbee2mqtt stick. This worked flawlessly, and I’ve moved everything onto it, including all my hue and IKEA bulbs. The add-on is far better than the horrible phoscon / deconz vnc combo, much easier to see the network, much better service visibility, much easier to pair devices. Wish I’d done this months ago.

1 Like

I too am having issues with my conbee stick, been working flawlessly until now. I keep installing a firmware update, but it doesn’t seem to update. Could you tell us which stick you bought?

The electrolama zigazigah. (https://electrolama.com/projects/zig-a-zig-ah/)

It’s slightly more effort to set up - you have to flash the stick (but no hardware required to do so), and you have to add the repo for the zigbee2mqtt addin to hassio. However, no regrets, wish I had done it months ago. The UI is much better than the phoscon/deconz mess - visibility of the devices and network, easier to pair, etc.

I now realize that some of the issue with deconz was that I didn’t have enough zigbee devices on the conbee II for a reliable mesh (because when I’d tried to move lights off the hue hub to deconz it was horribly unreliable and latent). But now I’ve got everything on zigbee2mqtt - philips bulbs, ikea bulbs, xiaomi sensors, and it just works - reliable and minimal latency.

1 Like

Thanks, I’ll check it out.

Old thread, but I am seeing these exact issues with my new RaspBee II mounted in a new Pi4. Extremely annoying! Entire setup is messed up after a reboot and sometimes not all sensors will come online at all. Very frustrating