Since I took away my Hue bridge and only have been using my Conbee Stick I’ve been experiecing lights that wont go off anymore, stay on or get greyed out in phoscon.
Now it seems to work again. Hopefully you can come with a solution.
paste earlier today:
https://paste.ofcode.org/qYGKDLiZHXXDHg4ZjH7Wvz
last codepaste (no real errors):
Moved to general support as it is not a phoscon bug 
I am able to reproduce!
The logs show multiple times the 0xD2 error code, this is an interesting one:
17:02:24:587 0x0000000000000000 error APSDE-DATA.confirm: 0xD2 on task
0xD2 means the Zigbee broadcast table is full. This happens when too many broadcasts/group casts are send in fast succession. The logs show such a case at:
17:02:24:500 add task 421 type 14 to group 0x0002 cluster 0x0006 req.id 227
17:02:24:511 add task 423 type 14 to group 0x0014 cluster 0x0006 req.id 229
17:02:24:512 add task 425 type 14 to group 0x0015 cluster 0x0006 req.id 232
17:02:24:514 add task 427 type 14 to group 0x0018 cluster 0x0006 req.id 234
17:02:24:516 add task 429 type 14 to group 0x0004 cluster 0x0006 req.id 236
17:02:24:524 add task 431 type 14 to group 0x0005 cluster 0x0006 req.id 238
17:02:24:526 add task 433 type 14 to group 0x0007 cluster 0x0006 req.id 240
17:02:24:527 add task 435 type 14 to group 0x0008 cluster 0x0006 req.id 242
These are group casts for the On/Off cluster.
Note: On the Zigbee level every group cast is repeated x3 times — by each router — so it propagates through the network. Routers use a internal broadcast table to track the already repeated group casts, which is usually as small as 8.
What happens here is that the network gets filled up with requests.
To fix this usually a delay between group casts should be used to prevent filling up the network with requests. To be safe 500 milliseconds to 1 second is fine.
There is a command line parameter to artificially add delays between requests:
--group-delay=<milliseconds>
However I’d recommend to first figure out what triggers all those requests. Could be an automation or rules I guess?
I think maybe that was because I turned restarted because I was trying to get the log. The last log of 19:18 was a reproduction of the other actual error.
Some lights are getting stressed out and wont respond unless I turn of the whole ‘‘downstairs’’ group in phoscon.
Hmm from the last log I don’t see suspicious errors, commands seem to be send fine. Can you control one of the trouble lights directly in deCONZ Cluster Info Panel (On/Off cluster), so that they react?
Nope, not responding with exec commands. Only works when I turn off/on group ‘‘beneden’’ in phoscon:
see log: ontrol: 0x18, mfcode: 0x0000 20:04:16:432 payload: 000025d6090000000020:04: - Pastebin.com
What was the MAC address of the light you tried to control?
0x001788010985AEA0?
In the logs it looks, fine commands are send with success status 
yeah true, saw ‘‘succes’’ happening on log when clicking, but light is not responding. Literraly just wanting to go off when I shut down whole group. Yesterday happened with different lights. Today certain spots also didn’t wanted to go along.
Just a test but can you try the command “Off with effect”, I have seen this for Ikea lights before which didn’t want to turn off as well but reacted to this command.
At first didn’t seem to work. After a while light was off. But couldn’t turn it back on. Tried everything. Again only worked when shutting down / turning down whole group (has to be ‘‘beneden’’ and not the group ‘‘woonkamer’’ where the Hue Bloom is also part of).
Interesting, can you please do another test and try if turn it on with the “On with recall global scene” command instead normal “On” command.
Light seems to lose connection totally
.Turning off / on Whle deconz Group turns the light on again. But light stays noted as ‘‘not reachable’’ even though it turns off and on with the rest.
Switching through scenes reproduces the error. Light does not respond to any of the exes (no FAILED though).
Other info: When I came home yesterday (2 spots were on and 1 random light was still on) Dont have any crazy automations (fresh install). Naming the group the same as the light causes home assistant to double those light. Firtst i thought that was causing the error, but after fix, still the same.
Problem now mainly seems to manifest around the bloom…
4/11
Problem still consists; again later in the evening yesterday, multiple lights didn’t want to respond. Do I need bring my Hue Bridge back or do you have any other solution ?
Repost here from Discord Thread:
Hi, I’m not sure if my problem belongs here to the api, deconz itself or phoson. Hope it fits here and sorry if it has been posted here before. I’m a bit in a hurry because it is a dark night and I’m sitting here without working light switches 
Just since this night (problems always start in the dark :-/) no scenes or groups (all created in phoscon) are switchable in my network. I tried it via deconz, phoscon app and home assistant. I can switch the individual lights, but no scenes or groups. Phoscon and home assistant react to the scenes and show the desired state, but the actual lights do nothing. This is quite annoying because my busch-jäger wall switches depend on scenes and now everything is dark.
Setup: RPI4, Raspbee II, lots of routers in the mesh (hue bulbs and busch-jäger wall switches), deconz 2.23.1 and after the problem occured now 2.24.3. Everything worked fine for months. Restarted deconz and pi itself, too, without solving the problem.
Powercycling every single device helped and suddenly everything worked after a stressfull night.
Weeks later (today) the problem occured again and powercycling did not help. In addition my network slowly looses one device after the other. I recorded a log but the only find in there were several “0x0000000000000000 error APSDE-DATA.confirm: 0xD2 on task”
RaspbeeII Firmware 26780700
Deconz 2.23.1, Deconz 2.24.3 and now Deconz 2.26.3 (it happend on all three versions)
greetings,
zAm1987
Thanks for the report, in another chat I had a similar case also with the 0xD2 error (meaning the Broadcast Table of the coordinator is full).
A quick and dirty workaround is a power-cycle of the RaspBee/ConBee, e.g. via GCFFlasher while deCONZ is not running:
GCFFlasher_internal -d /dev/serial0 -r
(or power down the pi and detach USB power cable for a few seconds, does the same).
I plan to handle this in deCONZ automatically when the error is detected N times. But will likely take couple releases (hopefully v2.27.1 or v2.27.2).
Hi manup,
thanks for the response.
Power cycling the raspberry pi (and as such hopefully the raspbee II) did not helped in my case. I plugged off the usb-cable and switched the micro-sd, so the whole system was powerless for about a minute.
I will try the command for gcfflasher this evening, though.
Update:
I found an earlier timeslot and tried the command and a longer shutdown. Then powered on the devices in the first room and watched deconz. The first light now reacts again to group and scene xommands, however the first Busch-Jäger LightLink switch does not connect. After that I tried the devices in the next room and none of these (Hue Lights and Busch-Jäger LightLink switches) is able to establish a connection. Only my Illuminize window covers somehow are able to connect across the whole flat.
To me it seems that those Busch-Jäger’s are the culprit, as powering them on seem to stop the network Routing (but no 0xD2 errors right now). However, they worked for a long time with deconz. Are there any recent changes in the deconz versions from deconz onwards 2.23 concerning those switches?
In another thread with similar Problems another user also has Busch-Jäger in his Network:
https://forum.phoscon.de/t/scenes-and-groups-not-working-anymore/