Hey, I faced a comparable situation two days ago. Around noon, my whole network went dead (which is a bit larger). I checked the network settings in deconz GUI and what was presented to me somehow felt fishy. Due to whatever reason, I had a different PAN-ID, network key and zigbee channel. Luckily, I was able to sniff the traffic which allowed me to see my device communication (after having changed the channel back from 15 to 25, still had the network key included in wireshark). However, I had no success via deconz GUI to restore the initial settings, it simply didn't work. Then I recalled something I've read in one of the release notes which might be able to solve it, and it did the trick indeed.

Created a wiki page for it so it doesn't keep on dwelling in the depths: Network lost issues. Maybe you want to give it a shot anyway.

@manup you may want to pin the wiki article or a comparable issue. That feature was a great help to me and it might aid in resolving other people's network issues. Were quite some over the past couple of months...

@SwoopX Thanks for the info, but that doesn't apply in my case. As you can see in my screenshot above I only have a single network config. And as I started the complete setup with the version no. mentioned above, I think I don't suffer from any past issues from old firmware/software issues.

I read through most of the older issues here, on HA issues and forums and I think my situation is not affected by most of the problems as they are upgrade related in some way.

As I said, this is a brand new install with everything fresh from the beginning.

I also have almost the same setup running at my place (only difference is a Raspberry 4 instead of 3b+) with more than 100 devices (Ikea, Hue, Innr, Xiaomi, etc) running perfectly fine. That is why I decided to create a new issue and didn't "reuse" one of the existing ones.

And as I started the complete setup with the version no. mentioned above, I think I don't suffer from any past issues from old firmware/software issues.

Well, it must not necessarily be due to some legacy config stuff. I had running my config for several months and it happened out of a sudden. The last update I made was 3 months ago or so.

Point I wanted to make here is that configuration looked ok but it did not work. Applying configuration from the "secret" Phoscon page resolved it. Why not give it a try, it cannot go any more wrong :neutral_face:

@SwoopX I should have mentioned that before, but I already tried loading that one config I have available there without any success.

I see, too bad. Somehow, it feels familiar. Have you checked #2245 already?

@SwoopX yes, I did search and have a look at most of the related issues including this one.

I did a reboot right now and disabled autostart of the deCONZ container and then started it manually when everything was up in HA. I noticed the following on startup:

starting version 232
[21:42:04] INFO: Waiting for device...
[21:42:05] INFO: Starting VNC server...
[21:42:09] 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
[21:42:11] INFO: Starting Nginx...
[21:42:11] INFO: Running Hass.io discovery task...
[21:42:11] INFO: Running the deCONZ OTA updater...
[21:42:11] INFO: Running the IKEA OTA updater...
[21:42:11] INFO: deCONZ is set up and running!
2020/01/02 21:42:11 [notice] 390#390: using the "epoll" event method
2020/01/02 21:42:11 [notice] 390#390: nginx/1.10.3
2020/01/02 21:42:11 [notice] 390#390: OS: Linux 4.19.88-v7
2020/01/02 21:42:11 [notice] 390#390: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2020/01/02 21:42:11 [notice] 390#390: start worker processes
2020/01/02 21:42:11 [notice] 390#390: start worker process 419
21:42:11:410 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/
21:42:11:434 CTRL. 3.16.221:42:11:636 dev /dev/ttyAMA0
21:42:11:636 COM: /dev/ttyACM1 / serialno: DE2132210
21:42:11:636 COM: --dev: /dev/ttyACM1 (ConBee II)
21:42:11:636 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt
21:42:12:057 parent process bash
21:42:12:057 gw run mode: docker/hassio
21:42:12:057 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version
21:42:12:058 sd-card cid: 035344535033324780ffffffff0127d1
21:42:12:098 DB sqlite version 3.16.2
21:42:12:101 DB PRAGMA page_count: 35
21:42:12:101 DB PRAGMA page_size: 4096
21:42:12:101 DB PRAGMA freelist_count: 2
21:42:12:101 DB file size 143360 bytes, free pages 2
21:42:12:102 DB PRAGMA user_version: 6
21:42:12:102 DB cleanup
21:42:12:105 DB create temporary views
21:42:12:166 don't close database yet, keep open for 900 seconds
21:42:12:167 started websocket server at port 8081
21:42:12:182 found node plugin: libde_rest_plugin.so - REST API Plugin
21:42:12:189 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
21:42:15:573 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
21:42:15:607 dev /dev/ttyAMA0
21:42:15:607 COM: /dev/ttyACM1 / serialno: DE2132210
21:42:15:607 COM: --dev: /dev/ttyACM1 (ConBee II)
PROTO: CRC error
PROTO: CRC error
21:42:15:679 dev /dev/ttyAMA0
21:42:15:679 COM: /dev/ttyACM1 / serialno: DE2132210
21:42:15:679 COM: --dev: /dev/ttyACM1 (ConBee II)
21:42:15:715 DEV config changed event
21:42:15:787 Device firmware version 0x264A0700
21:42:15:794 unlocked max nodes: 200
21:42:15:875 Device protocol version: 0x010B
21:42:15:895 new node - ext: 0x00212effff050392, nwk: 0x0000
21:42:16:006 don't close database yet, keep open for 900 seconds
21:42:16:006 LightNode 5: Wohnzimmer Tischlampe added
21:42:16:023 don't close database yet, keep open for 900 seconds
21:42:16:024 LightNode 6: Wohnzimmer Schrank added
21:42:16:047 don't close database yet, keep open for 900 seconds
21:42:16:048 LightNode 7: Schlafzimmer Decke added
21:42:16:064 SensorNode 2 set node 0xccccccfffea6f966
21:42:16:082 SensorNode 3 set node 0xccccccfffe3eeefc
21:42:16:100 SensorNode 4 set node 0xec1bbdfffe23ab3c
21:42:16:119 SensorNode 5 set node 0xccccccfffea7a8db
21:42:16:135 SensorNode 6 set node 0xccccccfffe3d9446
21:42:16:152 SensorNode 7 set node 0xccccccfffee589dc
21:42:16:169 SensorNode 8 set node 0xccccccfffee2e978
21:42:16:185 SensorNode 9 set node 0x14b457fffed4253d
21:42:16:202 SensorNode 10 set node 0xccccccfffe54452d
21:42:16:278 ZDP node descriptor request to 0x00212EFFFF050392
21:42:16:278 APS-DATA.request id: 4, addrmode: 0x02, addr: 0x0000, profile: 0x0000, cluster: 0x0002, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x04
21:42:16:278 ZDP send request id: 0x03 to 0x00212effff050392
21:42:16:329 Current channel 25
21:42:16:350 CTRL ANT_CTRL 0x03
21:42:16:382 Device protocol version: 0x010B
21:42:16:440 Current channel 25
21:42:16:460 CTRL ANT_CTRL 0x03
21:42:16:490 Device protocol version: 0x010B
21:42:16:549 Current channel 25
21:42:16:569 CTRL ANT_CTRL 0x03
21:42:16:600 Device protocol version: 0x010B
21:42:16:659 Current channel 25
21:42:16:679 CTRL ANT_CTRL 0x03
21:42:16:753 APS-DATA.confirm id: 4, status: 0x00 SUCCESS
21:42:16:753 APS-DATA.confirm request id: 4 -> confirmed, timeout 38155024
21:42:16:758 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8002, lqi: 241, rssi: 19
21:42:16:758 APS-DATA.indication request id: 4 -> finished
21:42:16:758 APS-DATA.request id: 4 erase from queue
21:42:16:758 ZDP status = 0x00 -> SUCCESS
21:42:16:758 ZDP Node_Descriptor_rsp 0x00212EFFFF050392 - 0x0000
21:42:16:837 Mgmt_Lqi_req zdpSeq: 1 to 0xEC1BBDFFFE33B91E start index 0
21:42:16:837 APS-DATA.request id: 10, addrmode: 0x03, addr: 0xec1bbdfffe33b91e, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
21:42:17:367 dev /dev/ttyAMA0
21:42:17:371 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII

I was wondering about the following lines in my log:
PROTO: CRC error
after initializing the Conbee II and searching for similar log lines I found #1996 which seems to be the exact problem I am experiencing.

Hi
since tonight I'm facing exactly the same situation. All my devices do not react. Absolut nightmare!

My whole house is not to use anymore. And I thought I'm on the right site with deconz!

Tried to restore the netword thing but didn't help.

Any inputs what I could do?

Thanks for any help!
Beat

Hi
Ok after last nights total crash, I did restore my latest backup this morning. For sure still nothing working. Then I did reset every single light (have 32 of different brands) with Touchlink and run the add light process. The lights came back one after another. But unfortunately all the scenes were deleted.

If I'm not the only one having this issue then I think this is a massive problem of deconz!

I have no idea what caused that problem as the system was running with this firmware since July and my last change is 10 days ago. It started on Monday night when some lights started randomly blinking. I just managed to turn all lights off and then about 5 lights didn't show connection. So I tried to reconnect but failed and on Tuesday night after some more trying to fix it at once all my light were disconnected and gone.

@robertlandes : How did you fix your problem?

Kind regards
Beat

I have exactly the same problem, it's rather annoying to have to completely reset the network every time I happen to reboot my docker host device (in my case a Synology). @manup: Any ideas? Anything we can do to facilitate the troubleshooting?

I just had the same problem again. Some lights didn't react, some started randomly flashing. Had to disconnect each light from power and restart Deconz.

Now everything is working again.

@manup: Any ideas what could cause this. It is getting critical for me now with 2 events like that within 2 weeks!

Kind regards
Beat

@robertlandes I am having the same issue.

After reboot there is no connection possible. And its easy to reproduce:
Reset the gateway -> add lights in phoscon, create a group -> reboot --> no connection to lights or groups.

I am developing with deconz for quite a while now and it always worked fine after reboot.
Right now I am only adding 2 lights from my desk but nothing works after reboot.

The only thing I changed compared to the last months is that I was using a Conbee 2 now. But it does not work with my old Conbee 1 either now.

deconz Version: 2.05.64
Conbee 1 Firmware: 26330500

Edit: I upgraded to the latest version 2.05.72 same issue
I am running deconz headless on a RPi. the deconz service runs fine

@nodefeet Exactly the same issue here. On reboot, all connections are gone. The settings are correct (channel, network ID, security key...), but the devices are no longer connected. It looks like the coordinator is not correctly saving details of its neighbours or something similar.

The only exception from the devices I have at hand are a Philips Hue Motion Sensor, which will manage to re-join each time.

I can even recreate it on my deCONZ GUI App on my windows machine.

Step 0: Reset the Gateway
Step 1: Add lights
Step 2: reboot

Result: no connection even after several hours

To be clear I am using these lights for almost a year without any connectivity issues.

@nodefeet In my case, even after many days the connections don't come back up (except that Philips Hue Motion Sensor). Definitely something missing in what is saved and restored after a reboot.

@jcaron23 same for me. The connection is lost permanently.

At least in my case it has to do something with Conbee's non-volatile memory.
I was able to get another Conbee 2 and it works now after reboot or shutdown, although I have no idea how I supposedly should have damaged the EEPROM of my old Conbee 1 and the new Conbee 2.

But here is what I don't understand:
If network settings are lost in the Conbee after reboot. Shouldn't it be possible for me to at least reload the configuration from the hidden network site (ALT+Click on Advanced in Gateway page) for one of my "damaged" Conbees?

After reboot the networks settings (Channel, PANID, Network Key) are the same as before. So as expected loading these settings does not reenable the connection. Backups do not help as well.

Applying the configuration took a while in my case. I havent touched anything for like 5 minutes. Maybe you were too impatient?

@SwoopX unfortunately there is no connection possible even after hours.

I was about to write how I discovered that this issue happens when you start the raspberry with deconz without an Ethernet network connection. And indeed I was able to "destroy" multiple Conbees this way. I could even reproduce it on a fresh raspbian install with deconz. But thanks to the support of dresden-elektronik the following seems to work for me!

Solution

All I did were the first three steps from the technical support page from deconz:
[Point 6 under Troubleshooting for ConBee II with Linux ](https://phoscon.de/en/support#conbee2

1. Close deCONZ if it’s running
   -> I did: sudo systemctl stop deconz
2. Unplug the ConBee II and wait 10 seconds
3. Connect the ConBee II again and wait 10 seconds
   -> I did: sudo systemctl start deconz afterwards

I am currently not able to reproduce the connection error after reboot and my "destroyed" Conbees seem to work again. Everything works fine :grinning:.

Great. Hm, Im my case, it is a Raspbee. Might be that I unplugged my Pi Zero running it for a while as part of the (at least my) solution... Anyhow, those steps should be remembered!

I'm seeing this issue and the above fix by @nodefeet did not work.

I have rebooted everything multiple times in different orders and at best I can get a single connection to a switch. :(

Next step is reset it all and start from scratch. I had such high hopes after the initial setup being so seamless. Hopefully this can be figured out soon.

same problem here. At every restart all my network goes down.

Just to make sure:

Did you try repowering the lights?

Sometimes my lights need to be restarted as well after deconz restarts before there is any communication possible again.

I am having the exact same issue after a restart of the host system and had to reconfigure all devices today.

Is there a way to download, install and use older versions of the firmware? From what I understand this is a recent issue, so finding in which firmware version the problem was introduced should help to track it down.

Hi everybody, I hope with the next release 2.05.73 the reboot issue gets addressed for some cases. But there seems to be some issue deeper.

Can you please try in deCONZ GUI:

• Leave
• Join

To restart the Zigbee network, to see if that brings the network back.

Can you please try in deCONZ GUI:

* Leave

* Join

To clarify, should I have a broken network to start with?

The steps are meant for the case when deCONZ shows "In Network" state but for some reason "all" devices are not reachable.

For me I just loose the 3 last device registered. Others devices (11) are present ! Any idea ?

In fact it seems that it happens on Xiaomi sensors that were previously paired with the GW Xiaomi, then removed from it.
I have just paired an Aqara sensor (opening) and I find it after restarting Deconz.

The other possibility is that in the meantime I have updated to version 2.05.74

We are currently trying out the conbee 2 stick for our home and already ran into this issue wasting several hours. Any chance this will be fixed soon? Otherwise we'll have to return the stick as it is simply broken.

Hello, have the same problem. Everything works fine until i reboot my Raspberry Pi. deConz is setup as service and start on boot.
When i reboot my system, lost everything and have to pair again.
In https://phoscon.de/en/changelog/ is in Elvis - Fix deCONZ not trying to reconnect to the ConBee, ConBee II or RaspBee in certain states after loosing the connection.
But have 2.5.74 and have this issue with reboot :(

@manup : I can confirm that your suggestion worked for me. some of my Xiaomi devices needed to be triggered (e.g. open/close door) to reconnect. but afterwards all of them are back and provide data to iobroker.

I was brave enough and rebooted my hardware. Fortunately everything worked fine after the reboot too.

thx for the hint

Configuration :
Ubuntu 18.04.4 on Zotac ZBOX
Conbee II FW 26530700
Xiaomi : multi sensor & contact sensor
Ikea : Exender 1, Remote Control, Wireless Dimmer
ICZB-KPD18s
IO broker

We've had the same problem for several months. After restarting the Deconz server, all lights fail to control. A power cycle of the lights fixes it. Note that even though Deconz can't control the lights, a Philips remote can, so there seems to be nowthing wrong with the light or the zigbee network.

Same here, I purchased a Conbee II stick to start learning about home automation and I'm already unlucky. When I restart my PC usually all sensors are lost (sometimes 1 gets detected). When I pair again all is well.
Conbee II Firmware 0x264a0700
DeCONZ 2.05.75
Windows 10
Xiaomi Aqara WSDCGQ01LM temp/humidity/pressure sensors version 20161129

Do they re-connect if you power-cycle the lights? In my case, they always seem to do that. But this kida negates the purpose of having them zigbee controllable in the first place. And it renders the entire solution very unreliable for any application except possibly the die-hard hobbyist and enthusiast.

@TheWizz I understand it was just about sensors.

@StefkeJ Is it? Sensors do usually not "come back" instantly, but when they have something to report. It can last up to 1h (e.g. for Xiaomi).

@TheWizz , @SwoopX I just have 4 of those sensors, no lights or anything else. 3 hours computer uptime: 1 sensor detected.

from @TheWizz

Do they re-connect if you power-cycle the lights? In my case, they always seem to do that. But this kida negates the purpose of having them zigbee controllable in the first place. And it renders the entire solution very unreliable for any application except possibly the die-hard hobbyist and enthusiast.

Unfortunately, I have to completely agree with you on this

Hi, any news on this? Is there a workaround? This is a very critical issue

The lack of response to this issue (and others just like it) here is concerning. This is about basic functionality of the product, and not some peripheral aspect. Furthermore, numerous users seem to have this very problem, so its not a one-off. Since the component that's losing the connection (i.e., the CONBEE USB stick) is a product we all bought and paid for (and not part of the open source code), I'd say there's an obligation on Dresden Electronics to pay some attention here.

So where are you!?

-JM

https://phoscon.de/en/support

I'm in agreement with you

The lack of response to this issue (and others just like it) here is concerning. This is about basic functionality of the product, and not some peripheral aspect. Furthermore, numerous users seem to have this very problem, so its not a one-off. Since the component that's losing the connection (i.e., the CONBEE USB stick) is a product we all bought and paid for (and not part of the open source code), I'd say there's an obligation on Dresden Electronics to pay some attention here.

So where are you!?

-JM

I totally agree with you.

We have to contact support as @ebaauw suggested, at least to know if they are working on this serious issue.

From my point of view it requires an internal escalation to fix it asap.

I did not face this problem since 2 month now => fingers crossed! But I did also not touch deconz in anyway...to scared!

So I'm going to write to Dresden Electronics Support with a link to this post. Who else is doing the same?

This needs fixing otherwise it will remain a major problem and deconz will not be a reliable product for productive home automation projects.

I wrote a support email but haven't heard back.

It would be interesting to hear what happens if you turn off your DECONZ (and unplug the USB stick while off, to make sure it loses power), then back on again, to see if you're seeing the same as I do. I.e., it then fails to control any lights until you power cycle the lights, and then they come right back. Scary, I know, but I guess it would help Dresden to know how to repro the problem (although one would figure they should have seen it too by now…).

-JM

@TheWizz it's been reported that it may work what you proposed in terms of stooping deconz and unplugging the stick. It's further up this threat.

Just to clarify; I'm not "proposing stopping and unplugging the stick" to _fix_ the problem, but to _reproduce_ it.

-JM

Unfortunately this workaround didn't work for me, after reboot I lost all connected nodes.

In my case it can simply be reproduced by turning off the host

after reboot I lost all connected nodes

Yes, that confirms my finding. The CONBEE network doesn't survive a DECONZ server restart which also powers off the CONBEE. Again notice what I said above that stopping the server and unplugging the stick _reproduces_ the problem. It doesn't fix it. So this isn't a "workaround", it's a way to reproduce the problem, that I hope will help Dresden fix it, since it renders their solution pretty much useless for us.

-JM

Yes, right, do you know if is it possible to downgrade the firmware to a previous working version?

Just install a previous version with GCFFlasher_internal.

This could be a temporarily solution for all the users that are facing this issue, do you know which version could be fine?

Hi all, I now read through the whole thread and I‘m ‚happy‘ 👎 to see, that I‘m not alone with this issue. I saw such behaviour multiple times, as the deCONZ/ConBee network seems to have forgotten multiple devices in the morning. Normally after switching the few ones, which have ‚survived‘ the night, triggered the rest to come back. That took then normally max. 5-10 minutes.
But today it went really worse. Nearly no device ‚survived‘ and the network is now back after more then 4 hours, which is definitely not acceptable.
After recognising that in the morning I did two reboots of the whole system which didn‘t help at all.
In general I implemented a routine, longer time ago, which triggers some of the routers (Hue Plugs) at 2:00 in the night. But that seems also not being preventing such connection losses.

Frustrating is in addition, that I freshly did a firmware update (2.05.75, 264A0700) on the stick, which solved my issues with some motion/light sensors. ... no again downgrading, hmhm :-(

Hi guys, FYI I just sent a mail to [email protected] as suggested by @ebaauw .
Have a nice day.

@StefkeJ thanks. I just also planned to do so this evening, but first would like to check the points from the Dresden/Phoscon support page, linked above by @ebaauw.
I hope that we will get an answer, pressing thumbs 👍

I checked now all points and everything seems to be fine. Thus I also just sent out a mail to Dresden.
As this status seems only occure in my network during night or very early in the morning, when nothing is really switched, in addition I implemented a routine which now triggers some Hue Plugs each hour.
If this helps (as a workaround) I will post it here.

In my case, with a ConBee II, the issue seems to have been resolved with release 2.5.75. I have rebooted the box several times and all devices have come back up on restart without doing anything.

jcaron23, when you say "reboot", have you actually powered down "the box", by unplugging its power cord for a minute or so, alternatively unplugged the CONBEE stick while the server was off? Many computers these days keep some USB devices powered over a reboot (and sometimes even while "shut down"). I have a feeling that the loss of connection is caused more by the CONBEE losing power than the server software itself being restarted.

-JM

@TheWizz On the previous version even a simple reboot would break everything in my case.

I have done several reboots, and at least one actual power off with power unplugged (disconnecting USB-C power and adding PoE). Not sure if it lasted a full minute, but probably close to it.

Note that this is with a ConBee II, not the original ConBee. I believe the release notes of the last few versions mentioned firmware changes for one but not the other, not sure what the status on that is. Currently running firmware 264A0700.

It's my understanding that CONBEE and CONBEE 2 differes only mechanically, an that they're both identical from a functional point of view.

https://phoscon.de/en/support#conbee-v1-v2-differences

Mike

@TheWizz I think that's a very high-level view, and they mean that they are functionally identical in terms of features, not actually technically identical. They don't use the same firmware. For instance the release notes for 2.05.75 state:

New firmware 0x26340500 for ConBee I and RaspBee to fix IKEA routing issue. The ConBee II firmware for the fix will be available soon.

According to https://deconz.dresden-elektronik.de/deconz-firmware/ the ConBee II firmware 264A0700 has not changed since may 2019 (while the latest RaspBee / ConBee I firmware is 26350500 from early march), so the issue probably wasn't addressed in the firmware but in the deCONZ code.

Release notes for 2.05.74 state:

After deCONZ starts it will now wait 15 seconds before the device gets automatically connected in order to prevent reboot issues. This is a workaround which will later on be fixed in firmware of ConBee II.

(which again points to differences between the ConBee and ConBee II)

So maybe the problem with reboot is/was not the same on the ConBee and ConBee II. With the ConBee II it seems to have been fixed.

OK. Thanks for your thoughts and speculations.

In either case, a proper response from Dresden (either here or to any of the support emails sent to them on the subject) would be prudent. Such a response should include clear step-by-step instructions on how to fix this problem. Until I see such a response (that actually fixes the problem) we will not use nor recommend their solution to our customers.

I sent them a support email a while back, but have yet to receive a reply. Has anyone else sent a support email as suggested by ebaauw above? Have you received any reply?

-JM

I have sent an email to support with a link to this thread 3 days ago but no answer yet...

As mentioned above, I also sent a mail out yesterday. Due to Easter time I do not think to get a response before mid/end of next week.
In general my workaround keeps my network alive last night and I also didn’t have this smaller, around 08:00 o’clock, issues in the morning. I will observe this further on. Maybe it’s a valide workaround until we see a fix from Dresden.

same problem here, never got a response so far. This is really frustrating.

Same problem here. On the ConBee II on 2.05.74, it states "the version is up to date". My Osram smartplugs are very dumb now...

"the version is up to date" is for the firmware, not deconz version, you need to update your version yourself if you need (as I think it don't solve the problem)

Guys, who of you is running the Conbee II on a rp4?

Yes, for one of my development/test environments. Don't plan on using it for production anytime soon. I don't yet fully trust Raspbian buster - too many updates in too short succession. Also the ConBee II 0700 firmware still seems to lag a bit behind the 0500 firmware.

@ebaauw That question was more to the others trying to find the least common denominator. I cannot really dig too deep into that since I only run Raspbees and my production environment is a Pi Zero, so no USB3, no docker or whatsoever involved

As I recall from discord, we had either permissions issues (user not added to dialout group) or Conbee II on a rp4 without extension cable to dance around the issue of signal interference with USB3...

almost exact same issue as OP here.
I am running hass.io on virtualbox on win10.
first it worked but then the next day after reboot all devices are not reachable. (VNC viewer shows only 1 connection to aqara motion sensor.)
also i began to have disconnect/reconnect loops of the conbee. they went away after manually flashing the FW again according to their guide.
what do i have to do for this whole thing to start working again?
(update: i use a USB extension cable)
(update2: i reset and re-added everything. works again for now)
(update3: everything unavailable again after reboot, hass.io boot, HA server restart and decon plugin restart. see log #2 at the end. pls help

here is the log from home assistant deconz plugin.
[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 [11:25:18] INFO: Waiting for device... [11:25:18] INFO: Starting VNC server... [11:25:21] INFO: Starting the deCONZ gateway... libpng warning: iCCP: known incorrect sRGB profile 11:25:21:343 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/ 11:25:21:351 CTRL. 3.22.011:25:21:368 COM: /dev/ttyACM0 / serialno: DE2154373 11:25:21:368 COM: --dev: /dev/ttyACM0 (ConBee II) 11:25:21:368 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt 11:25:21:390 parent process bash 11:25:21:390 gw run mode: docker/hassio 11:25:21:390 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version 11:25:21:391 DB sqlite version 3.22.0 11:25:21:391 DB PRAGMA page_count: 30 11:25:21:391 DB PRAGMA page_size: 4096 11:25:21:391 DB PRAGMA freelist_count: 0 11:25:21:391 DB file size 122880 bytes, free pages 0 11:25:21:391 DB PRAGMA user_version: 6 11:25:21:391 DB cleanup 11:25:21:391 DB create temporary views 11:25:21:393 don't close database yet, keep open for 900 seconds 11:25:21:393 started websocket server at port 8081 11:25:21:394 found node plugin: libde_rest_plugin.so - REST API Plugin 11:25:21:395 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin [11:25:21] INFO: Starting Nginx... [11:25:21] INFO: Running Home Assistant discovery task... 2020/04/14 11:25:21 [notice] 618#618: using the "epoll" event method 2020/04/14 11:25:21 [notice] 618#618: nginx/1.14.0 (Ubuntu) 2020/04/14 11:25:21 [notice] 618#618: OS: Linux 4.19.107 2020/04/14 11:25:21 [notice] 618#618: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2020/04/14 11:25:21 [notice] 618#618: start worker processes [11:25:21] INFO: Running the deCONZ OTA updater... 2020/04/14 11:25:21 [notice] 618#618: start worker process 628 [11:25:21] INFO: Running the IKEA OTA updater... [11:25:21] INFO: Running the LEDVANCE/OSRAM OTA updater... [11:25:21] INFO: deCONZ is set up and running! 11:25:22:531 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin 11:25:22:540 COM: /dev/ttyACM0 / serialno: DE2154373 11:25:22:540 COM: --dev: /dev/ttyACM0 (ConBee II) 11:25:26:962 Announced to internet http://dresden-light.appspot.com/discover 11:25:31:314 New websocket 172.30.32.1:55828 (state: 3) [11:25:31] INFO: Successfully send discovery information to Home Assistant. 11:25:32:158 COM: /dev/ttyACM0 / serialno: DE2154373 11:25:32:158 COM: --dev: /dev/ttyACM0 (ConBee II) 11:25:32:198 Device firmware version 0x264A0700 11:25:32:203 unlocked max nodes: 200 11:25:32:311 Device protocol version: 0x010B 11:25:32:318 new node - ext: 0x00212effff0554df, nwk: 0x0000 11:25:32:325 SensorNode 6 set node 0xec1bbdfffe434cbc 11:25:32:328 SensorNode 2 set node 0x00158d0003a28923 11:25:32:329 SensorNode 3 set node 0x00158d0003a28923 11:25:32:332 don't close database yet, keep open for 900 seconds 11:25:32:332 LightNode 2: tradfri added 11:25:32:335 SensorNode 4 set node 0x00158d0003f2957e 11:25:32:335 SensorNode 5 set node 0x00158d0003f2957e 11:25:32:405 Current channel 11 11:25:32:430 CTRL ANT_CTRL 0x03 11:25:32:465 Device protocol version: 0x010B 11:25:32:535 Current channel 11 11:25:32:559 CTRL ANT_CTRL 0x03 11:25:33:879 don't close database yet, keep open for 900 seconds 11:25:33:879 LightNode 1: Configuration tool 1 added 11:25:36:160 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF 11:25:36:160 GW firmware version: 0x264a0700 11:25:36:160 GW firmware version is up to date: 0x264a0700 11:26:04:405 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 11:26:16:095 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 11:26:21:179 Current channel 11 11:26:21:187 Device TTL 2363 s flags: 0x7 11:26:27:811 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 11:26:39:507 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 11:26:51:306 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 11:26:51:306 max transmit errors for node 0xEC1BBDFFFEABD57A, last seen by neighbors 78 s 11:26:52:490 0x3DDB seems to be a zombie recv errors 6 11:26:52:490 LightNode removed 0xec1bbdfffeabd57a 11:26:52:490 Node zombie state changed 0xec1bbdfffeabd57a 11:27:21:179 Current channel 11 11:27:21:191 Device TTL 2303 s flags: 0x7 11:27:32:156 saved node state in 0 ms 11:27:32:162 sync() in 5 ms 11:28:21:174 Current channel 11 11:28:21:184 Device TTL 2243 s flags: 0x7

log #2
[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 [21:08:52] INFO: Waiting for device... [21:08:52] INFO: Starting VNC server... [21:08:55] INFO: Starting the deCONZ gateway... libpng warning: iCCP: known incorrect sRGB profile 21:08:55:937 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/ 21:08:55:940 CTRL. 3.22.021:08:55:954 COM: /dev/ttyACM0 / serialno: DE2154373 21:08:55:954 COM: --dev: /dev/ttyACM0 (ConBee II) 21:08:55:955 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt 21:08:55:977 parent process bash 21:08:55:977 gw run mode: docker/hassio 21:08:55:977 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version 21:08:55:977 DB sqlite version 3.22.0 21:08:55:977 DB PRAGMA page_count: 32 21:08:55:977 DB PRAGMA page_size: 4096 21:08:55:978 DB PRAGMA freelist_count: 0 21:08:55:978 DB file size 131072 bytes, free pages 0 21:08:55:978 DB PRAGMA user_version: 6 21:08:55:978 DB cleanup 21:08:55:978 DB create temporary views 21:08:55:980 don't close database yet, keep open for 900 seconds 21:08:55:980 started websocket server at port 8081 21:08:55:981 found node plugin: libde_rest_plugin.so - REST API Plugin 21:08:55:981 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin [21:08:56] INFO: Starting Nginx... [21:08:56] INFO: Running Home Assistant discovery task... 2020/04/14 21:08:56 [notice] 618#618: using the "epoll" event method 2020/04/14 21:08:56 [notice] 618#618: nginx/1.14.0 (Ubuntu) 2020/04/14 21:08:56 [notice] 618#618: OS: Linux 4.19.107 2020/04/14 21:08:56 [notice] 618#618: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2020/04/14 21:08:56 [notice] 618#618: start worker processes 2020/04/14 21:08:56 [notice] 618#618: start worker process 624 [21:08:56] INFO: Running the deCONZ OTA updater... [21:08:56] INFO: Running the IKEA OTA updater... [21:08:56] INFO: Running the LEDVANCE/OSRAM OTA updater... [21:08:56] INFO: deCONZ is set up and running! 21:08:57:153 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin 21:08:57:164 COM: /dev/ttyACM0 / serialno: DE2154373 21:08:57:167 COM: --dev: /dev/ttyACM0 (ConBee II) 21:09:02:096 Announced to internet http://dresden-light.appspot.com/discover 21:09:05:387 New websocket 172.30.32.1:40916 (state: 3) [21:09:06] INFO: Successfully send discovery information to Home Assistant. 21:09:07:442 COM: /dev/ttyACM0 / serialno: DE2154373 21:09:07:443 COM: --dev: /dev/ttyACM0 (ConBee II) 21:09:07:492 Device firmware version 0x264A0700 21:09:07:500 unlocked max nodes: 200 21:09:07:608 Device protocol version: 0x010B 21:09:07:614 new node - ext: 0x00212effff0554df, nwk: 0x0000 21:09:07:620 SensorNode 2 set node 0x00158d0003a28923 21:09:07:621 SensorNode 3 set node 0x00158d0003a28923 21:09:07:624 don't close database yet, keep open for 900 seconds 21:09:07:624 LightNode 2: Dimmable light 2 added 21:09:07:626 SensorNode 4 set node 0x00158d0003f2957e 21:09:07:626 SensorNode 5 set node 0x00158d0003f2957e 21:09:07:697 Current channel 11 21:09:07:720 CTRL ANT_CTRL 0x03 21:09:07:757 Device protocol version: 0x010B 21:09:07:831 Current channel 11 21:09:07:855 CTRL ANT_CTRL 0x03 21:09:08:981 don't close database yet, keep open for 900 seconds 21:09:08:982 LightNode 1: Configuration tool 1 added 21:09:11:437 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF 21:09:11:439 GW firmware version: 0x264a0700 21:09:11:439 GW firmware version is up to date: 0x264a0700 21:09:39:173 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 21:09:50:877 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 21:09:56:462 Current channel 11 21:09:56:470 Device TTL 2290 s flags: 0x7 21:10:02:589 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 21:10:14:287 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 21:10:26:105 0xEC1BBDFFFEABD57A error APSDE-DATA.confirm: 0xD0 on task 21:10:26:106 max transmit errors for node 0xEC1BBDFFFEABD57A, last seen by neighbors 78 s 21:10:26:795 0x0DF3 seems to be a zombie recv errors 6 21:10:26:796 LightNode removed 0xec1bbdfffeabd57a 21:10:26:796 Node zombie state changed 0xec1bbdfffeabd57a 21:10:26:807 rule event at 21:10:25.932: /groups/1/state/any_on: 0 -> 1 21:10:56:458 Current channel 11 21:10:56:466 Device TTL 2230 s flags: 0x7 21:11:56:455 Current channel 11 21:11:56:463 Device TTL 2170 s flags: 0x7 21:12:56:456 Current channel 11 21:12:56:467 Device TTL 2110 s flags: 0x7 21:13:11:441 GW firmware version: 0x264a0700 21:13:11:442 GW firmware version is up to date: 0x264a0700 21:13:56:445 Current channel 11 21:13:56:452 Device TTL 2050 s flags: 0x7

Guys, who of you is running the Conbee II on a rp4?

First of all, answering that question could be helpful.

We're generally mainly using Intel NUC. But for this "can't reconnect after server restart until lights are power cycled" error, the type of computer used to run DECONZ shouldn't really matter.

-JM

We're generally mainly using Intel NUC. But for this "can't reconnect after server restart until lights are power cycled" error, the type of computer used to run DECONZ shouldn't really matter.

-JM

tl;dr: try to import an old (the older the better) backup you hopfully made via deconz gui

same here. using nuc with esxi, debian vm and the docker container so there are some layers to traverse ;)

For me nothing worked besides reseting all devices but that wasnt an option for me anymore. What finally did work (dont ask me why, I dont know) was a more or less random backup I made 3 month ago. Backup imported, container restarted, changed network config via alt+left click and after ~10minutes all devices were discovered again. I've also changed the channel but I think that didnt had any influence. This seemed to work altough there was a firmware and deconz version discrepancy if I compare it to the most recent container I've used so far.

In the end, the whole process does not make much sense to me in terms of logical traceability and logic but: it works, somehow.

I use a ConBee II on a normal INTEL mini PC running Ubuntu 18.04, Phoscon-GW Version 2.05.75 / 8.3.2020 (Beta) and Firmware 264A0700.

That system just survived a reboot without problems. Before updating to this version, I also had the problem with missing sensors and the need to reconnect them.

My case seems to be a bit other, as 1. I'm using the stick with a Raspi 3B and 2. the problem didn't occure again since I mentioned it here. My 'keep alive routine during the night' prevents my setup now since then from forgetting any device or getting frozen in the morning. Really thought that it was the same as it occured shortly after the firmware update to 264A0700.

My case seems to be a bit other, as 1. I'm using the stick with a Raspi 3B and 2. the problem didn't occure again since I mentioned it here. My 'keep alive routine during the night' prevents my setup now since then from forgetting any device or getting frozen in the morning. Really thought that it was the same as it occured shortly after the firmware update to 264A0700.

for me there was never an issue "in the morning" but after restart of the debian vm running the docker container. Seems like there are multiple issues leading to similar behavior

Guys, who of you is running the Conbee II on a rp4?

I do. And with the previous version (2.05.73 IIRC) it always lost everybody after a reboot, with 2.05.75 I don't see the problem. I had a short power outage yesterday and everything came back nicely (didn't check how fast though, but previously even hours and days of waiting did not resolve the problem for most devices).

I just did an extra-reboot, but no problems occurred. So I‘m looking forward positively and observe further on ...

I'm using the raspberry pi 4 with conbee II and the issue is always reproducible every time i reboot the raspi

@raelix have you tried the Phoscon-GW Version 2.05.75 / 8.3.2020 (Beta) mentioned above to see if that fixes the problem? If not, what version are you on?

-JM

Thanks guys for the input. I guess it would indeed be beneficial that everybody gives a brief summary of the setup like that

Hardware running the ConbeeII: e.g. NUC, rpi, etc
Connected to USB3: Yes/no
Using docker: Yes/no
deconz version: e.g. 2.05.75
Firmware version: e.g. 264A0700

For folks running the stick directly attached to USB3, a USB extension might be advisable, as USB3 might cause interference with 2.4GHz transmissions https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html

@TheWizz @Smanar Updating Phoscon-GW to the beta version 2.05.75 / 8.3.2020 did indeed solve the issue. I have rebooted several times since.

Hardware running the Conbee II: Pi2
Connected to USB3: No
Using docker: No
deconz version: 2.05.75
Firmware version: 264A0700

Hi @TheWizz I have the latest available version:

Hardware running the Conbee II: Raspberry Pi 4
Connected to USB3: Yes
Using docker: Yes with HA
deconz version: 2.05.75 3/8/2020
Firmware version: 264A0700

OK, I've updated a NUC running Ubuntu 18.04 LTS to deconz 2.05.75. Running on a CONBEE with firmware 26330500 (claimed to be the "latest" by Phoscon).

My problem remains. For todays test, I had two of a larger number of recently purchased HUE bulbs in the room. When I start the computer and deconz, the window appears with all the devices shown. The blue dot in the garteway box flashes. Green wires appear shortly going to the two HUE lights physically in the room. No blue dots in those two boxes, instead the occasional red flash. But the wires from the gateway to those two lights remain green, indicating that they are seen, but they can not be controlled.

I can regain control of either of those two lights by power cycling the light (as before). Then it soon begins to flash blue dot. it can now be controlled. Red wires appear from this (now controllable) HUE light to the other ones (which aren't physically in the room), indicating it attempts to "mesh" with those but obviously failing.

I can get the other HUE light to work as well by likewise power cycling it.

So my question remains, what shall I do to make the system connect and control the lights reliably after a controller computer restart, without having to power cycle the lights manually?

-JM

those two lights remain green, indicating that they are seen

No, indicating that they are in the routing table of the device on the other end of the line. The GUI shows routes, like a city map, not actual traffic.

Red wires appear from this (now controllable) HUE light to the other ones (which aren't physically in the room), indicating it attempts to "mesh" with those but obviously failing.

Again, no: indicating a route of poor quality.

So my question remains, what shall I do to make the system connect and control the lights reliably after a controller computer restart, without having to power cycle the lights manually?

Check for radio interference. Particularly from USB3 devices. Make sure the ConBee is in a USB2 port and use a USB extension cable. Unplug any USB3 devices from the NUC. Make sure there's some distance between the ConBee and any Wifi router or adapter, and the Bluetooth adapter.

Hardware running the ConbeeII: Raspberry Pi 4
Connected to USB3: Yes
Using docker: no
deconz version: 2.05.75
Firmware version: 264A0700

All working well since the upgrade to 2.05.75. It used to lose all devices on reboot on 2.05.73.

Check for radio interference. Particularly from USB3 devices.

There's no USB3 on this NUC. Same problem regardless of environment (anything from a quiet office to a busy tradeshow floor). NEVER works when server just started. ALWAYS can be made to work by power-cycling the HUE lights. Those ones then connect promtly, showing flashing blue dots and can be controlled. So it doesn't seem to be any radio interference in the environment, Furthermore, initially (before power cycling) those HUE lights respond to the HUE remote, so zigbee in the HUE end seems fine.

Make sure the ConBee is in a USB2 port and use a USB extension cable.

Done. Made no difference.

Unplug any USB3 devices from the NUC.

There's no USB3 on this NUC.

Make sure there's some distance between the ConBee and any Wifi router or adapter, and the Bluetooth adapter.

The behavior we see is 100% repeatable, regardless of the radio environment (busy or very quiet).

-JM

To complete the list:
RasPi 3B running on Stretch
No Docker
USB2
Same Phoscon version and firmware as @jcaron23
And as written, I had the problem only one time after the firmware update. DeConz needed >4 hours to recover the entire former network. Afterwards no more real problems.

Edit
So I did some more testing and found the following:

• If I turn off auto start of Deconz and reboot the VM and then manually start Deconz afterwards, there is no problem: entities are available.

So with this knowledge, how do I investigate this further? Is it a HA issue?

Original Post
I have a similar problem:

Since a couple of weeks my Zigbee entities would become unavailable, I was able to fix the problem by just restarting Home assistant (NOT the VM). First I thought it was just a one time issue, but then the next week, the same day, my entities were unavailable. Then I realized, that I have fixed VM backup schedule running that's shutdowns my HA VM overnight, takes a backup and restarts the VM.

So then I found the issue, started googling and found other people having the same issue:

• Zigbee entities not available after a reboot. (in my case, the VM)

The strange thing is however that everything 'seems' to be operating normally, with that I mean:

• I can't find any errors in the deconz log
• Gateway Status is connected
• With the VNC viewer the network seems fine?
• Just by restarting HA (NOT) the VM the problem is fixed, but that's not a solution for the long term.

Let me state that i'm not an expert, so if others could point me in the right direction where to look for errors that DO state there is a problem, please let me know. The only thing I have now is, entities shown as unavailable with a system that seems fine on first sight...

Info:
Hardware running the ConbeeII: Custom NAS (UnRaid) running Hassio in a VM
Connected to USB3: No, USB 2.0 with extension cable
deconz version: e.g. 2.05.75
Firmware version: e.g. 264A0700

Screenshots:

This restart function 'fixes' my problem:

Log
[17:25:06] INFO: Waiting for device... [17:25:06] INFO: Starting VNC server... [17:25:09] INFO: Starting the deCONZ gateway... libpng warning: iCCP: known incorrect sRGB profile 17:25:09:671 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/ 17:25:09:696 CTRL. 3.22.017:25:09:719 COM: /dev/ttyACM1 / serialno: DE2140315 17:25:09:719 COM: --dev: /dev/ttyACM1 (ConBee II) 17:25:09:719 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt 17:25:09:754 parent process bash 17:25:09:754 gw run mode: docker/hassio 17:25:09:754 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version 17:25:09:756 DB sqlite version 3.22.0 17:25:09:756 DB PRAGMA page_count: 30 17:25:09:757 DB PRAGMA page_size: 4096 17:25:09:757 DB PRAGMA freelist_count: 0 17:25:09:757 DB file size 122880 bytes, free pages 0 17:25:09:757 DB PRAGMA user_version: 6 17:25:09:757 DB cleanup 17:25:09:757 DB create temporary views 17:25:09:760 don't close database yet, keep open for 900 seconds 17:25:09:760 started websocket server at port 8081 17:25:09:762 found node plugin: libde_rest_plugin.so - REST API Plugin 17:25:09:763 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin [17:25:10] INFO: Starting Nginx... [17:25:10] INFO: Running Home Assistant discovery task... 2020/04/17 17:25:10 [notice] 644#644: using the "epoll" event method 2020/04/17 17:25:10 [notice] 644#644: nginx/1.14.0 (Ubuntu) 2020/04/17 17:25:10 [notice] 644#644: OS: Linux 4.19.115 2020/04/17 17:25:10 [notice] 644#644: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2020/04/17 17:25:10 [notice] 644#644: start worker processes 2020/04/17 17:25:10 [notice] 644#644: start worker process 651 [17:25:10] INFO: Running the deCONZ OTA updater... [17:25:10] INFO: Running the IKEA OTA updater... [17:25:10] INFO: Running the LEDVANCE/OSRAM OTA updater... [17:25:10] INFO: deCONZ is set up and running! 17:25:10:852 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin 17:25:10:863 COM: /dev/ttyACM1 / serialno: DE2140315 17:25:10:863 COM: --dev: /dev/ttyACM1 (ConBee II) 17:25:15:258 New websocket 172.30.32.1:53410 (state: 3) 17:25:15:637 Announced to internet http://dresden-light.appspot.com/discover [17:25:20] INFO: Successfully send discovery information to Home Assistant. 17:25:20:893 COM: /dev/ttyACM1 / serialno: DE2140315 17:25:20:893 COM: --dev: /dev/ttyACM1 (ConBee II) 17:25:20:928 Device firmware version 0x264A0700 17:25:20:933 unlocked max nodes: 200 17:25:21:039 Device protocol version: 0x010B 17:25:21:054 new node - ext: 0x00212effff05222d, nwk: 0x0000 17:25:21:151 don't close database yet, keep open for 900 seconds 17:25:21:151 LightNode 1: Woonkamer lamp TV-Meubel added 17:25:21:192 don't close database yet, keep open for 900 seconds 17:25:21:192 LightNode 2: Keuken lamp added 17:25:21:225 don't close database yet, keep open for 900 seconds 17:25:21:226 LightNode 3: pomp added 17:25:21:265 don't close database yet, keep open for 900 seconds 17:25:21:265 LightNode 4: Woonkamer lamp bijzettafel added 17:25:21:293 SensorNode 2 set node 0x0017880106e8930c 17:25:21:320 don't close database yet, keep open for 900 seconds 17:25:21:320 LightNode 6: Hal Lamp Piano added 17:25:21:418 Current channel 15 17:25:21:439 CTRL ANT_CTRL 0x03 17:25:21:474 Device protocol version: 0x010B 17:25:21:547 Current channel 15 17:25:21:571 CTRL ANT_CTRL 0x03 17:25:21:645 no button map for: RWL021 ep: 0x02 cl: 0x0001 cmd: 0x0A pl[0]: 021 17:25:21:645 ZCL attribute report 0x0017880106E8930C for cluster: 0x0001, ep: 0x02, frame control: 0x08, mfcode: 0x0000 17:25:24:022 don't close database yet, keep open for 900 seconds 17:25:24:022 LightNode 5: Configuration tool 5 added 17:25:24:894 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF 17:25:24:894 GW firmware version: 0x264a0700 17:25:24:894 GW firmware version is up to date: 0x264a0700

......
Created a wiki page for it so it doesn't keep on dwelling in the depths: Network lost issues. Maybe you want to give it a shot anyway.
...
So, I am having issues that started with moving to a new computer (Windows 10). The issue is that my sensors either cannot be reached or if they are reachable, they do not report status. I wanted to go back to an earlier version. I found the secret page that is accessed holding the alt-key for the settings. I see all the previous versions and I click load on an old version, but it is always the most recent version that gets loaded. What do I do to get an old version loaded? Thanks. Elliott

......
Created a wiki page for it so it doesn't keep on dwelling in the depths: Network lost issues. Maybe you want to give it a shot anyway.
...
So, I am having issues that started with moving to a new computer (Windows 10). The issue is that my sensors either cannot be reached or if they are reachable, they do not report status. I wanted to go back to an earlier version. I found the secret page that is accessed holding the alt-key for the settings. I see all the previous versions and I click load on an old version, but it is always the most recent version that gets loaded. What do I do to get an old version loaded? Thanks. Elliott

How can I tell if the older configuration is successfully loaded? I tried to load a 2.05.74 and 2.05.73 version, It states it can take up to 1 minute, then it restarts and Deconz is working. But when I go back to the ALT + advanced button section it still highlights the most recent version 2.05.75 (grey bar) Is this normal or should the grey bar highlight the profile you loaded?

Thx for helping!

Edit
So I did some more testing and found the following:

• If I turn off auto start of Deconz and reboot the VM and then manually start Deconz afterwards, there is no problem: entities are available.

So with this knowledge, how do I investigate this further? Is it a HA issue?

For the meantime I created an automation that starts the Deconz addon with a one minute delay, after HA startup.

I'm having exactly the same issues, and its becomming tiresome when I rarely have to reboot.

But at least knowing to disable auto start will temporarily fix half of the problem. Thanks @HammerNL89

Would be good to understand what is happening here, happy to reproduce and provide logs if someone needs these. Its very easy to reproduce though!

......
Edit
So I did some more testing and found the following:

• If I turn off auto start of Deconz and reboot the VM and then manually start Deconz afterwards, there is no problem: entities are available.

So with this knowledge, how do I investigate this further? Is it a HA issue?

For the meantime I created an automation that starts the Deconz addon with a one minute delay, after HA startup.

Thanks for sharing but how did you do that?
I can't find Deconz in my automations.

@tinus20vt should be like so
https://community.home-assistant.io/t/can-add-ons-be-started-by-an-automation/58806

@HammerNL89 wrote:

• If I turn off auto start of Deconz and reboot the VM and then manually start Deconz afterwards, there is no problem: entities are available.

So with this knowledge, how do I investigate this further? Is it a HA issue?

For the meantime I created an automation that starts the Deconz addon with a one minute delay, after HA startup.

This seems to be related to the change in 2.5.74 where they added a 15-second delay before reconnecting. Maybe the actual delay depends on your hardware and how deCONZ is started etc. On the RPi image, deCONZ is already started quite late I believe, and of course different hardware will take more or less time to boot.

It seems there is some form of race condition on start and if deCONZ connected to the stick to early everything gets messed up. The release notes for 2.5.74 stated:

After deCONZ starts it will now wait 15 seconds before the device gets automatically connected in order to prevent reboot issues. This is a workaround which will later on be fixed in firmware of ConBee II.

So they probably know what the actual issue is. In the meantime, the workaround may need to be modified by extending the wait a bit more (or checking for some specific condition instead?).

After I had to manually release a bunch of locked out lights of an unhappy client I tried to have a look again at this issue:

related issues: #1185, #2015, #2023, #2035, #2333

Start Setup
Hardware: RPi3B+, Conbee
Connected to USB3: No
Using docker: No
deconz version: 2.05.72 headless
Firmware version: 26330500

Current Situation

• After every rebooting the RPi I need to power cycle the lights
• After restarting deconz service I do not need to repower the lights
  (as a side note it does take around 20 sec until the lights are visible/controllable in deconz )

Steps I did to upgrade
Conbee Firmware
$ sudo systemctl stop deconz
$ wget http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF
$ sudo GCFFlasher_internal -d 0 -f deCONZ_Rpi_0x26350500.bin.GCF
Result: lights still need repowering

Conbee II
Just for testing I tried a Conbee II with the latest Firmware: 264A0700
Result: lights still need repowering

Deconz Software Firmware
Then I updated Deconz to 2.05.75
$ sudo systemctl stop deconz
$ wget http://deconz.dresden-elektronik.de/raspbian/beta/deconz-latest-beta.deb
$ sudo dpkg -i deconz-latest-beta.deb
$ sudo systemctl start deconz

Result
Worst case: ligths are completely locked out after reboot.
I tried it several times. As soon as you reboot there is no connection possible.
lights are greyed out. power cycling does not help.

I did the same procedure from my previous post:

All I did were the first three steps from the technical support page from deconz:
[Point 6 under Troubleshooting for ConBee II with Linux ](https://phoscon.de/en/support#conbee2

Close deCONZ if it’s running
-> I did: sudo systemctl stop deconz
Unplug the ConBee II and wait 10 seconds
Connect the ConBee II again and wait 10 seconds
-> I did: sudo systemctl start deconz afterwards

After restart the light is gone. After searching for new lights deconz finds it, but it is not controllable.

After reseting the gateway again and manually releasing the light. I added the light again:
And now it seems to work. I currently do not need to repower the lights after reboot/shutdown!
Let's see how long it works

Probably unrelated
Since it seems to be a problem during boot up. I noticed that in the service file /lib/systemd/system/deconz.service: StartLimitIntervalSec was changed from 60 to 0 (see beta vs staple phoscon rasbian images).

[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service

[Service]
User=1000
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80
Restart=on-failure
StartLimitIntervalSec=0 # was 60
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

At first I thought this might be the reason why deconz connects to fast to Conbee.
But with StartLimitIntervalSec=0 systemd will just attempt to restart your service forever after failure.

And it also does not seem to have any affect at all, because StartLimitIntervalSec has to be in the Unit section

As you can see:
$ systemd-analyze verify deconz.service:

[/lib/systemd/system/deconz.service:11] Unknown lvalue 'StartLimitIntervalSec' in section 'Service'
fake-hwclock.service: Cannot add dependency job, ignoring: Unit fake-hwclock.service is masked.

(I have a rtc on my RPi and disabled the fake-hw-clock )

@nodefeet Thanks for the detailed insights and also the nice catch on the service error. Saw that as well but wasn't in the mood yet to do some investigation in this regard.

Although it might not change much, you may try to disable the deconz service completely, so deconz is not automatically started on boot. As I see it is run headless, wait a minute after the system has booted and then launch deconz manually with the command from ExecStart /usr/bin/deCONZ -platform minimal --http-port=80
Might be worth to get an indication if any timing issues could be related.

@nodefeet thanks for your effort! This somehow reminds me to the issue I recently had where I wasn't able to join the device anymore even by trying to re-pair them
@SwoopX you remember/agree?

@nin9s Yeah, I recall

I've been having these issues on and off for quite some time. The only things that have worked for me are:

a) power cycling the rpi
b) using the Advanced configuration (alt-click as described here), and rolling back the configuration settings a few versions even though the settings look identical

2 days I have lost to this problem when I came across this thread. I’m very close to send my deconz back and go for a refund. Countless hours I have wasted on reprogramming all my automations in HomeKit after everything went to shit after a simple reboot... are there fixes planned ?

I have mainly aqara stuff (wired light switches and wireless buttons, motion sensors etc), I wanted to get rid of the aqara hub since it uses an external server, boy what a mistake I made! It was rock solid with that Chinese hub and here I am, already lost 2 days, trying to figure out why nothing is responding and losing all my automations after rebooting the rpi!

I think I ran into this issue too. Super annoying. Any updates on how to fix it? I tried all(?) things suggested here but nothing was working. I believe the trigger was unplugging the pi to put it in a new case. Previous reboots have been fine.

I am trying to find a persistent way to at least reproduce the issue :

Here are two questions to anyone to with the latest version:
Deconz: 2.5.75
Conbee: 26330500
Or Conbee II: 264A0700

1. Can you provide steps to consistently create the bug that the lights need to be be power cycled after reboot the the RPi?
   _-> I needed to this every time. With the latest version I had no issues so far._

2. Can you provide steps to consistently reproduce the critical bug that the lights are completely unresponsive (and stay unresponsive whatever you do, no power cycling helps) after rebooting the RPi?
   _-> I was not able to do this in previous version. This bug happened rarely, so I cannot say if the current verison fixes it.
   -> Once I had the issue. The lights are locked out after every reboot. I could fix the “messed up” Conbee with the steps from my previous posts:_

   1. Close deCONZ if it’s running
      -> I did: sudo systemctl stop deconz
   2. Unplug the ConBee II and wait 10 seconds
   3. Connect the ConBee II again and wait 10 seconds
      -> I did: sudo systemctl start deconz afterwards

-> _But as I said before I still had to manually release every light and rejoin them. Loading a backup via the hidden config page never worked for me._

Questions to everyone else:
If you have an older version or still have these issues with the latest version.
Did it help to use @SwoopX comment about delaying the startup of deconz?

One simple way that should do the trick is to add the following line in the Service section of /lib/systemd/system/deconz.service:
ExecStartPre=/bin/sleep 60

All I can say is that delaying the startup of the homebridge connection to deconz did help me not losing the devices (so far), I have set it up yesterday but I’m still testing some stuff. Yesterday it was hanging on 1 unresponsive light, meaning that homebridge never fully booted. I believe it has something to do with a different problem where my aqara no neutral wire switches are generating 4 lights. Of which only 1 is the actual switch. It might be hanging on one of those other 3 it creates. Not sure. I’m still trying to do some other tests. I did not lose any devices in HomeKit anymore, that’s the most important bit for now

Can you provide steps to consistently reproduce the critical bug that the lights are completely unresponsive (and stay unresponsive whatever you do, no power cycling helps) after rebooting the RPi?

For me this seems to happen everytime I disconnect the conbee for some time from power.

I cheered too soon. I ran my pi for a week without starting to program my automations, just to see how stable its was. I was getting confident again and spend half a day programming my switches, automations etc. Today I needed to reboot the pi, and yes everything is broken again.. I'm really about to throw this deconz out and go back to aqara hub.. No idea what I'm doing wrong here.. the ph lightlist command seemed to have fixed the rebooting issue but today in the logs I saw that the deconz gave an error before the lightlist command kicked in, as a result: missing switches and all my automations are gone.

@ebaauw Any idea why this happened?

Also a bunch of other errors started to show up.. Also only since the reboot. I really need to fix this. I'm currently doing construction works in my house so the power goes out fairly often. This just can't kill my entire automation in my home every time.. It's getting pretty annoying :-(

The ECONNREFUSED means that Homebridge Hue cannot connect to deCONZ, probably before Homebridge was started before deCONZ (or before deCONZ started it's web server). As you can see in the log, Homebridge Hue waits until the gateway is available, so this isn't causing missing switches or lost HomeKit assignments.

The TypeErrors are probably caused by Homebridge Hue exposing ZHAPower /sensors resources without an associated /lights resource. I thought I fixed that, see #664, but this is apparently a slight variation. Could you please capture and attach a debug log file and attach the debug dump file? See the README.

Anyways, looks like Homebridge Hue continued before all lights were exposed. Did you maybe run ph lightlist too soon after starting deCONZ (so it doesn't contain all /lights resources)? The debug dump file should tell me. Or did you add more switches after running ph lightlist?

I need to figure out how to get you the debug file, did not do it before. The strange thing is, that even after restarting homebridge, some lights do not come back either. Either they are gone, or show up with a little house icon with the text "niet geschikt", which if I translate it means "unsuitable". The one missing is even stranger, it's a double rocker switch (wired), and only 1 of the 2 are missing from homekit? It's the same switch.. And still only 1 out of 2 is still visible.. Strange things are happening and I'm not sure where it's coming from.

Good Morning,
I mailed Dresden Elektronik three weeks ago, but got no reply.
Is there anyone who contacted the company and did get a reply? What did they write?
Have a great day,
Stef

Strange things are happening and I'm not sure where it's coming from.

@KLucky13 Those are all symptoms of Homebridge Hue starting while deCONZ hasn't yet exposed all /lights resources. This happens because not all /lights resources are listed in the lightlist. Either you ran ph lightlist too early after starting deCONZ, or you added new switches after running ph lightlist. Let deCONZ run for half an hour or so, and then re-run ph lightlist.

@StefkeJ perhaps they are closed ATM cause of covidis
Long time we haven't see @manup too.

Some more pieces added to the puzzle here. Our problem has been a loss of connection to all HUE lights after a server shutdown with power disconnected to the CONBEE dongle. After startng the server, all HUE lights fail to connect. However, given enough time, they seem to connect. Here, "enough time" is somewhere between 20 minutes and 10 hours. This unpredictability makes the system unusable in our application.

However, today we found a work around that seems to "fix" the problem, and that may also explain why some users don't seem to have it at all. Previously, we've had _only_ HUE lights in the system. We've sometimes used just two lights, and at other times up to twelve. We've used them in all kinds of environments, always with the problem descibed above. But today we found that if we add _another_ (non-HUE) zigbee device to the system, that seems to "fix" the problem. All the HUE lights then connect soon after server start. It doesn't seem to matter what kind of "other zigbee device" we connect. We've used an IKEA Trådfri light or an Osram power plug. Both had the effect of making the entire system come up soon after start. But if we remove this "foreign" device, leaving only HUE lights and the CONBEE in the system, the problem comes right back.

Hopefully, this will allow others to reproduce the problem, and perhaps provide a clue to Dresden Electronics (assuming they read this forum, which appears far from a sure thing given the lack of response here or to emails).

-JM

My setup has hue and Trådfri devices but never recovered as far as I can tell. I waited overnight before I rebuild everything.

I am also suffering this issue every time I reboot the deconz container running in a Intel NUC. It seems it is not a problem with power after physically restarting the device but restarting deconz software.

After a restart, my 3 Xiaomi temperature&humidity sensors keep connected but not my 2 Xiaomi motions sensors and my Xiaomi door/window sensor.

When I manually trigger these sensors (moving in front of them or opening the door) I see logs in deconz with the received data but the UI is not updating (showing the last refreshing time) nor does HomeAssistant gets notified. Logs are like these ones:

deconz            | 09:25:38:394 APS-DATA.indication from unknown node XXXXXXXXX
deconz            | 09:25:38:394 no button map for: lumi.sensor_motion ep: 0x01 cl: 0x0406 cmd: 0x0A pl[0]: 000
deconz            | 09:25:38:394 ZCL attribute report XXXXXXXXX for cluster: 0x0406, ep: 0x01, frame control: 0x18, mfcode: 0x0000 

Sometimes some of that sensors come back without doing anything but sometimes the only solution is pressing the buttons they include in order to connect them again (no need to delete & re-add them using the UI, just pressing that button that Xiaomi sensors include).

Here is my setup:

Hardware running the Conbee II: Intel NUC8I3BEH
Connected to USB3: Yes, with a 3m USB extension cable (my NUC only has USB3 ports)
Using docker: Yes (a single docker-compose.yml with everything related to automation like HomeAssistant, MQTT...)
Deconz version: 2.05.75 3/8/2020
Firmware version: 264A0700

And here is the deconz setup in docker-compose.yml:

  deconz:
    image: marthoc/deconz:amd64-2.05.75
    container_name: deconz
    restart: unless-stopped
    network_mode: host
    privileged: true
    volumes:
      - ./deconz:/root/.local/share/dresden-elektronik/deCONZ
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/ttyACM0
    environment:
      TZ: Europe/Madrid
      DECONZ_WEB_PORT: 7777
      DECONZ_WS_PORT: 7778
      DECONZ_VNC_MODE: 0
      DECONZ_VNC_PORT: 5900
      DECONZ_VNC_PASSWORD: XXXXXXX
      DEBUG_INFO: 1
      DEBUG_APS: 0
      DEBUG_ZCL: 0
      DEBUG_ZDP: 0
      DEBUG_OTAU: 0

Yesterday I had a look at my test setup again:
And as almost expected the lights were uncontrollable and locked out. So 2.5.75 did not fix the issue for me.

Again once this issue is there it happens after every reboot.
Again the steps: stop deconz -> unplug ConBee -> wait 10 seconds -> connect ConBee wait -> 10 seconds -> start deconz "repair" the ConBee. @tharwan Did you try this procedure?

Again after starting from scratch I tried to reproduce this issue, but was not able to do so. I stopped and restarted deconz, soft and hard resetted the Pi3+, un- and replugged Conbee several times. But of course now it's always working.

For now I added the startup delay mentioned from @SwoopX. I will report when the issue occurs the next time

@nodefeet Any idea how to perform the "unplug" step with a raspbee head?

@cosmo84 Well, you can't programmatically turn off the 5 V power to raspbee.

But the following sequence should do the same:
$ sudo systemctl stop deconz
$ sudo systemctl disable deconz
$ sudo shutdown -h now
unplug your RPi (Phoscon Gateway)-> wait for 10 s -> repower the Pi -> wait for startup and at least 10 s more
$ sudo systemctl start deconz

Like I said, these steps do not recover my lights but after manually releasing the lights one more time and doing everything from scratch it works as it should. At least until it doesn't 😞.

If it worked for you you can reenable the autostart of deconz
sudo systemctl enable deconz

@cosmo84 Well, you can't programmatically turn off the 5 V power to raspbee.

But the following sequence should do the same:
$ sudo systemctl stop deconz
$ sudo systemctl disable deconz
$ sudo shutdown -h now
unplug your RPi (Phoscon Gateway)-> wait for 10 s -> repower the Pi -> wait for startup and at least 10 s more
$ sudo systemctl start deconz

Like I said, these steps do not recover my lights but after manually releasing the lights one more time and doing everything from scratch it works as it should. At least until it doesn't 😞.

If it worked for you you can reenable the autostart of deconz
sudo systemctl enable deconz

thx, seems this fixed my issue of connections not starting up.

To be honest, this is a disaster.

Although it’s way too early to determine if the delayed startup trick actually works for me, here is how I implemented it in the hopes it might prevent others from this issue:

First make sure you did the unplug procedure from above.

Then I created a timer for the deconz.service:
sudo nano /lib/systemd/system/deconz.timer

with the content:

[Unit]
Description="Delayed startup for deconz"

[Timer]
OnBootSec=30
AccuracySec=1

[Install]
WantedBy=timers.target

(I do not know what delay time is actually needed, but I thought that 30 sec should be more than enough)

The nice thing about this timer is that it only delays the startup of deconz after reboot and not every time you restart the deconz.service and it's part of the systemd environment.

Enable the autostart of the timer:
sudo systemctl enable deconz.timer
And disable the autostart of deconz.service since it will be started by the timer from now on:
sudo systemctl disable deconz.service

Also @manup shared some insights in another issue that I think are related to ours:

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-626328136

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-626573109

Some quotes:

There is a new Firmware Update for the Conbee 2 out (since 10. May). And an upcoming firmware update of deconz (2.05.76)

Further it has improved startup to prevent the device going silent. (We're still testing out various cases to fix the boot issue for good).

There is a new bootloader 3.x in development which is already part of RaspBee II, it has a way more robust design and protocol to fix the issues of 2.x version.

As far as I remember from a phone call with Mr. Preuß from January they suspect a bootloader issue as well. But I honestly do not know much about these things so they might not be related at all.

I just have a bunch of phoscon gateway waiting to be installed and I hope there is a fix coming up. 😕

I'm running version 2.05.77 and firmware 26580700 (Conbee II) and devices still remain unavailable after a reboot of the VM.

I've just signed up to say I'm having the same problems, running the Hass virtual appliance on esxi, newest firmware etc and loosing a lot of devices after a reboot :(

I just bought a new Conbee II and hit the same issue. I struggled for 2 days thinking I missed something obvious. I tried the deconz container on the pi, deconz on windows. I also tried the integration with a venv HA setup and a Hassio VM setup. Those devices are not coming back after a reboot. I am very disappointed that an critical issue like this can happen with a product well regarded in the community.

I tried version 2.05.77 also 2.05.75 on windows. I tried with the initial firmware version 264A0700(?). I then upgraded it to 26580700.

Bought Conbee II and a few Xiamoi sensors and got it all up and runing on Saturday (4 days ago). My Synology were i run Home Assistant Core and Deconz in Docker on decided to reboot this night and now i have the same issue as all of you.

First i did not get any updates, when i restarted the container it could not find the sensors. When i pressed the refresh button they were found but were showing old values and they are not getting any updates.

I am not sure how i can get my devices up and running again? Someone mentioned repair but i don't know how.

I don't mind doing so manual work to get this up and running on each reboot until the issue has been resolved, i would just like to not have to restart everything and connect all the devices from the start.

Got bored and reseted my devices, noticed they are working, except a few of them do not give battery level but will give that some time.

One question i have. If i create a backup, and i get the same issue again will a restore of the backup solve it?

One question i have. If i create a backup, and i get the same issue again will a restore of the backup solve it?

At least not in my case. I even restored the whole vm to the last bit and it didn't work 🤷‍♂️

However it's working currently and interestingly also surviving multiple reboots - don't ask me why and what changed

When you "reboot", please try instead to make a full shutdown, unplig the Conbee for a few seconds, plug it back in and restart. Let us know if all devices still work as expected. I have a feeling that it is the Conbee stick loosing power that's causing the problem, and many computers keep USB power on over a reboot (and some even while shut down).

-JM

Got bored and reseted my devices, noticed they are working, except a few of them do not give battery level but will give that some time.

One question i have. If i create a backup, and i get the same issue again will a restore of the backup solve it?

Mine didn't come back after a restore of either the home assistant snapshot or the entire vm

Have the same issue, it's a new Raspbee II, current firmware. After a reboot it forgets all devices and I have to re-learn all of them.
The device is running on a Raspberry Pi B+ with Raspbian and all updates are installed.

I have a new issue that just came out of nowhere. 2 of my wired aqara licht switches all of a sudden show "low battery" and have a "build in" motion sensor and light sensor???

https://ibb.co/QHzk9dc
https://ibb.co/zXWcWb2

In total I have about 10 wired switches, beginning of this week, one of them did it and now today another one followed?

Can you provide a screenshot of those 2 devices from deconz GUI so we can have a look at the exposed clusters?

Can you provide a screenshot of those 2 devices from deconz GUI so we can have a look at the exposed clusters?

I have no easy way to hook up a screen to my raspberry so I will do this the next time I need to take it off the wall (its mounted to the wall in the basement). For now I will leave it since it still works, I just get a long list of "empty batteries" and clutter of extra stuff I don't need

@KLucky13 If you are running a Linux/Unix, use ssh -X to login, and then just start the application. It will open on your desktop.

Not sure about Windows though ...

@KLucky13 If you are running a Linux/Unix, use ssh -X to login, and then just start the application. It will open on your desktop.

Not sure about Windows though ...

I have a windows and a Mac; no linux, apart from the raspberry itself

Has anyone who contacted the company directly ever received a reply?
Or successfully asked for a refund?

I contacted the company on April 8, and again April 29, to get some help.
I never received a reply ...
So I am considering to send the stick back and ask for a refund...

gr
Stef

I'm still thinking about it, but also need to explore alternatives.
All in all it's a nice device, and if they can fix this grave bug it works fine.

This lengthy discussion is a bit concerning. Apparently, there are numerous paying customers experiencing loss of basic functionality after a restart/power loss. There is ZERO official response. Neither here, nor to any support emails as far as what's reported above. Perhaps DEs line of business is really something else, and this is just a little side project for them, where they really couldn't care less?

-JM

If i'd known about this before I purchased I would definitely chosen a competing product. So whilst it doesnt solve our problem, i've left and edited my reviews accordingly so others buying now will know. I would recommend everyone else leaves reviews on amazon and where ever describing their expereinces and lack of offical response and support.

I contacted them several times and never got a response!

Still no news on this? wtf

I also would appreciate some input from dresden elektronik about this issue.

@manup: I am not sure if you are aware of the significance of this.
This issue renders complete home installations useless with hours of work wasted to release and reconnect everything.

I do not understand why this issue does not have a higher priority to you.

Holy cow. My whole home automation is built on sand?!
I‘m using a RaspBee @ RaspPi 3B+ and had just one problem with the virtual light sensor of the Phoscon Gateway showing only the „Moon“ all the time.
No answer from DE yet, but I just get discouraged to receive one.

Moreover I found this issue where I will loose my complete setup due to a power cycle?!

@gregorschulz in the JSON of your virtual sensor, you have "true" at the "config/configured" field ?

@Smanar
This virtual daylight sensor is a built-in sensor in the RaspBee Phoscon-Gateway. It shows the „Moon“-symbol in the own GUI.
Which json do you mean?

@nodefeet @gregorschulz

I'll be closing this issue for now. Please open own issues on your personal situation. As this issue is open since Jan, new issues cannot be related and should be given their own topics.

If this issue is not fixed then why close the ticket (very recent side tracking not-withstanding)?

@cooperaj In my personal experience in reading over 400 issues the past week, i've noticed that there is allot of reasons why devices are gone. The personal experience in moderating learned that having threads like these never lead to a proper solution.

From the user perspective, a issue that is fully related to their environment helps solving this issue faster than having 1 thread with 20 people with 15 different configurations.

From the developers perspective, having all these cases seperated helps to see paterns. This thread have become a mess in which you can't figure out what happend where with what parameters.

I want your issue solved, hence i want you to open a own issue.

I did file a separate issue for this quite a while back as https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2015 However, that one was merely closed as "stale" with no answer or resolution, so I'm not sure filing individual issues works either. But if you prefer that method, please have my individual issue re-opened and look into it now.

-JM

I did file a separate issue for this quite a while back as #2015 However, that one was merely closed as "stale" with no answer or resolution, so I'm not sure filing individual issues works either. But if you prefer that method, please have my individual issue re-opened and look into it now.

-JM

@TheWizz
I would like to ask you to be careful on how to approach things here. Demanding stuff like this is not done in any situation. I am in no way employed by DE and just doing this on voluntary basis.

Ok, I also don't see how it is helping when the same problem is discussed in several different issues, but I opened #2915 for my case.

Given the lack of feedback from the vendor I'm seriously considering throwing work away and just return the device.

@andreasscherbaum I think i made myself clear on this topic by staying positive and polite, but apparently there still people that do not understand that negativity only makes things worse. You are asking for change but yet you are not contributing to do make the change.

If people keep doing this, i will be locking this issue.

@Mimiix How is opening the other issue as requested not helping?

It is, but the negativity isn't helping ;)

@Mimiix Others complained about the lack of feedback from the vendor as well, and you made it clear that you are not working for them. I dunno, how else can someone express frustration about this lack of feedback? I spent time writing a couple Ansible Playbooks for this, I submitted a PR or two, and sent in a bug report. That's fine, and I got feedback there. But when it comes to serious issues like this, am I forbidden to say anything about it?

@andreasscherbaum Allot of things have been said. And trust me, i'm forwarding all of this to @manup and talk about it with him. Stuff needs to be better and stuff needs to be done. Hence i am still talking to you, because i know how you feel. I'm also the guy in trying to fix this thing by doing my part and trying to make it a better place. Last week i've closed over 250 of the 480 issues. That aint fun either, but i'm doing my part.

Do i think DE needs to step up? Yes
Do i think DE Dropped the ball? Yes
Do i think stuff needs to be fixed? Yes
Does complaining about this all day long over and over again solve issues? Absolutely not.

This stuff needs time and i'm on it. Trust me on this, yesterday also included allot of stuff for the community as that is my only concern at this point. I am not a developer, i just like to see this place grow.

Hi all, just called DE (Tel.: +49351318500) and talked to the support. The issue is know and a fix/workaround is in place.

Mail from DE:
Mit der deCONZ 2.05.77 und der Firmware 26580700 sollten die Bugs behoben sein. Evtl. muss einmal unten genannter Workaround durchgeführt werden. Wenn die Geräte nicht von selbst nach einer Wartezeit wieder kommen müssen sie evtl. einmal neu angelernt werden. Danach aber nicht wieder und ein Neustart sollte kein Problem darstellen.

Update Firmware:
wget http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF
sudo GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f deCONZ_ConBeeII_0x26580700.bin.GCF

Update deCONZ:
wget -N http://deconz.dresden-elektronik.de/raspbian/deconz-latest.deb
sudo dpkg -i deconz-latest.deb

Details auch hier:
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

Workaround:

1) im deCONZ „Leave“-Network
2) im deCONZ Netzwork Settings öffnen
3) mehrmals den „Save“-Button betätigen (Parameter werden neu gesetzt)
4) Network-Setting mit „Done“ – verlassen
5) „Join“- Network

The magic around the firmware update might be, and I wouldn't have known about it either, to leave and rejoin here.

Would it be possible for someone to translate the above into proper English? I know I can do a Google Translate, but since this is mainly an engish-speaking place, it would be prudent to have any workaround described clearly so everyone can benefit.

-JM

Can it be assumed that a new version of Deconz will be made available that contains the updated firmware, and can apply this without going through the GCFFlasher_internal dance? Any ETA on such a proper solution?

-JM

@TheWizz Please update as mentioned in your issue. After that, let's see what happens. You can't start to apply this without your updates first. It's essentially the same as is recommended to you: update.

The only difference is the leave and join network part. I will translate that later.

In regard to your request to use without GCFFlasher, open a feature request in the Phoscon git. Afaik you can update from phoscon, but need to manually download still: https://dresden-elektronik.github.io/deconz-rest-doc/configuration/#import

@TungstenE2 please open your own issue in your regards if you have issues after that. I will make sure what you posted gets translated.

From now, i'll lock this issue as people keep going on. The addition from @TungstenE2 is great, i'll make sure to make a page in Wiki later today or tommorow.

To make things go faster, i've added the page:
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Possible-fix-for-devices-not-connecting

Thanks again for your effort @TungstenE2 !