Closed bluemoehre closed 8 months ago
Update: I added an OTAU image for a bunch of my HUE bulbs. deCONZ tried to update them all at once. That caused the network to be almost inresponsible. Huge delays (1-5s) in commands and after hours the OTAU page still showed the update timers stuck at minutes. Not a single device was updated successfully.
Logs look similar to above. But I gonna put more which looks interesting to me
Logs:
deconz | 01:41:18:953 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:41:18:953 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 91 s
deconz | 01:41:33:524 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:41:33:524 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 106 s
deconz | 01:41:48:224 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:41:48:225 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 120 s
deconz | 01:41:58:473 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:41:58:473 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 7 s
deconz | 01:42:12:552 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:42:12:552 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 21 s
deconz | 01:42:29:403 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:42:29:403 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 38 s
deconz | 01:42:46:065 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:42:46:066 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 55 s
deconz | 01:42:56:156 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:42:56:156 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 65 s
deconz | 01:43:07:985 0x54EF44100075D06C error APSDE-DATA.confirm: 0xA7 on task
deconz | 01:43:07:986 max transmit errors for node 0x54EF44100075D06C, last seen by neighbors 77 s
deconz | 02:52:04:605 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:606 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:704 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:704 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:792 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:793 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:796 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:797 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:797 delay sending request 244 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:797 delay sending request 245 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:798 delay sending request 247 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:805 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:805 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:805 delay sending request 244 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:806 delay sending request 245 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:806 delay sending request 247 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:904 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:905 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:04:905 delay sending request 244 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:906 delay sending request 245 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:04:906 delay sending request 247 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:004 delay sending request 234 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:004 delay sending request 236 dt 0 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:005 delay sending request 244 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:005 delay sending request 245 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:005 delay sending request 247 dt 0 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:104 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:105 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:105 delay sending request 244 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:105 delay sending request 245 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:106 delay sending request 247 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:205 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:205 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:205 delay sending request 244 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:206 delay sending request 245 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:206 delay sending request 247 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:240 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:240 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:241 delay sending request 244 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:241 delay sending request 245 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:241 delay sending request 247 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:245 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:245 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:245 delay sending request 244 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:246 delay sending request 245 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:246 delay sending request 247 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:246 delay sending request 250 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:246 delay sending request 251 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:247 delay sending request 253 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:304 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:304 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:305 delay sending request 244 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:305 delay sending request 245 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:305 delay sending request 247 dt 1 ms to 0x001788010971B077, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:305 delay sending request 250 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:306 delay sending request 251 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:306 delay sending request 253 dt 0 ms to 0x00178801097A346D, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:321 0x001788010971B077 force poll (2)
deconz | 02:52:05:321 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:321 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 02:52:05:339 0x00178801097A346D force poll (2)
deconz | 02:52:05:340 delay sending request 234 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 02:52:05:340 delay sending request 236 dt 1 ms to 0x001788010B50B526, ep: 0x0B cluster: 0x0008 onAir: 1
deconz | 03:04:23:415 0x4C5BB3FFFEC27A4A force poll (2)
deconz | 03:04:23:472 0x4C5BB3FFFEC27A4A force poll (2)
deconz | 03:04:37:931 0x001788010B50B526 force poll (2)
deconz | 03:04:38:053 0x00178801065018ED force poll (2)
deconz | 03:04:38:063 0x001788010B50B526 force poll (2)
deconz | 03:04:38:875 0x00178801065018ED force poll (2)
deconz | 03:04:38:902 0x001788010B50B526 force poll (2)
deconz | 03:04:38:931 0x00178801097A346D force poll (2)
deconz | 03:04:38:974 0x00178801065018ED force poll (2)
deconz | 03:04:38:992 0x00178801097A346D force poll (2)
deconz | 03:04:39:073 0x001788010971B077 force poll (2)
deconz | 03:04:39:114 0x001788010971B077 force poll (2)
deconz | 03:04:39:164 0x001788010971B077 force poll (2)
deconz | 03:04:40:083 0x00178801097A346D force poll (2)
deconz | 03:36:07:072 0x00178801096FF44D error APSDE-DATA.confirm: 0xA7 on task
deconz | 03:36:07:104 5 running tasks, wait
deconz | 03:36:07:204 5 running tasks, wait
deconz | 03:36:07:305 5 running tasks, wait
deconz | 03:36:07:404 5 running tasks, wait
deconz | 03:36:07:505 5 running tasks, wait
deconz | 03:36:07:605 5 running tasks, wait
deconz | 03:36:07:704 5 running tasks, wait
deconz | 03:36:07:805 5 running tasks, wait
deconz | 03:36:07:904 5 running tasks, wait
deconz | 03:36:08:004 5 running tasks, wait
deconz | 03:36:08:105 5 running tasks, wait
deconz | 03:36:08:205 5 running tasks, wait
deconz | 03:36:08:304 5 running tasks, wait
deconz | 03:36:08:405 5 running tasks, wait
deconz | 03:36:08:504 5 running tasks, wait
deconz | 03:36:08:604 5 running tasks, wait
deconz | 03:36:08:704 5 running tasks, wait
deconz | 03:36:08:805 5 running tasks, wait
deconz | 03:36:08:904 5 running tasks, wait
deconz | 03:36:09:004 5 running tasks, wait
deconz | 03:36:09:104 5 running tasks, wait
deconz | 03:36:09:204 5 running tasks, wait
deconz | 03:36:09:305 5 running tasks, wait
deconz | 03:36:09:405 5 running tasks, wait
deconz | 03:36:09:504 5 running tasks, wait
deconz | 03:36:09:604 5 running tasks, wait
deconz | 03:36:09:704 5 running tasks, wait
deconz | 03:36:09:805 5 running tasks, wait
deconz | 03:36:09:905 5 running tasks, wait
deconz | 03:36:10:005 5 running tasks, wait
deconz | 03:36:10:105 5 running tasks, wait
deconz | 03:36:10:204 5 running tasks, wait
deconz | 03:36:10:305 5 running tasks, wait
deconz | 03:36:10:405 5 running tasks, wait
deconz | 03:36:10:505 5 running tasks, wait
deconz | 03:36:10:604 5 running tasks, wait
deconz | 03:36:10:662 0x001788010B50B3E0 error APSDE-DATA.confirm: 0xA7 on task
deconz | 03:36:10:663 delay sending request 15 dt 4 ms to 0x00178801096FF44D, ep: 0x0B cluster: 0x0300 onAir: 1
deconz | 03:36:10:706 5 running tasks, wait
deconz | 03:36:10:805 5 running tasks, wait
deconz | 03:36:10:905 5 running tasks, wait
deconz | 03:36:11:005 5 running tasks, wait
deconz | 03:36:11:104 5 running tasks, wait
Asked devs to checkin. However, this looks like an issue that was fixed before.
In the meanwhile, can you unplug the conbee/raspbee and re-plug and see what happens?
I did that more than once, but this issue is recurring =/
In the end I aborted the updates and did it manually on some bulbs, which worked fine.
Hey @Mimiix ,
I just want to let you know the problem is growing dramatically with the number of devices. I added like 8 more things to the network (in total about 70 now) and I need to reboot the Conbee II / deCONZ like every two days since the logs get flooded with delay sending request
& 5 running tasks, wait
entries.
Automations are often stalled/hanging. Sometimes lights just get turned on at minimum brightness (last state) but the command to bring them to 100% is delayed. There are also situations in which only part of a group reacts. And the worst thing is when you come home when it's already dark and nothing reacts at all. Either the sensor events are not getting received or the automation cannot be run due to the (whatever) dead lock.
In a short: this is unusable at the moment to me. I cannot recommend tagging the current v2.24.1-beta
version as stable until this is fixed.
I dunno how to help you guys debug this, so just let me know what I can do.
Thanks a lot for your support!
EDIT: Issue seems to have been caused by me moving something near the Conbee stick which caused it to sit directly on the metal enclosure of the host PC. Adding a 1.5m USB extension and placing the stick somewhere else helped (at least with 2.23.2). Will update to 2.24.1 later and report back
I also see massive freezes after 2.24.1
. For me, not even replugging my Conbee I worked.
I only see a lot of error like 0xDC8E95FFFE52A644 error APSDE-DATA.confirm: 0xE1 on task
.
I have less than 15 devices connected.
What I did:
It worked fine for a couple of hourse, then nothing worked anymore and the Phoscon UI was very slow (clicking on Devices
> Lights
took ~5 seconds to load).
Steps I've tried:
2.23.2
)The only thing that is still working is controlling the 3 IKEA lights with the remotes directly connected to them (the remote shows up as a group in deCONZ).
Using 2.24.1, I created the following debug logs. I hope this helps in pinning down the issue.
2023-11-13_deconz_logs-debug.txt
Thanks!
Hey @Mimiix , I just want to let you know the problem is growing dramatically with the number of devices. I added like 8 more things to the network (in total about 70 now) and I need to reboot the Conbee II / deCONZ like every two days since the logs get flooded with
delay sending request
&5 running tasks, wait
entries.Automations are often stalled/hanging. Sometimes lights just get turned on at minimum brightness (last state) but the command to bring them to 100% is delayed. There are also situations in which only part of a group reacts. And the worst thing is when you come home when it's already dark and nothing reacts at all. Either the sensor events are not getting received or the automation cannot be run due to the (whatever) dead lock.
In a short: this is unusable at the moment to me. I cannot recommend tagging the current
v2.24.1-beta
version as stable until this is fixed. I dunno how to help you guys debug this, so just let me know what I can do. Thanks a lot for your support!
Ive forwarded this. But no response.
@manup can you check in?
EDIT: Issue seems to have been caused by me moving something near the Conbee stick which caused it to sit directly on the metal enclosure of the host PC. Adding a 1.5m USB extension and placing the stick somewhere else helped (at least with 2.23.2). Will update to 2.24.1 later and report back
I also see massive freezes after
2.24.1
. For me, not even replugging my Conbee I worked.I only see a lot of error like
0xDC8E95FFFE52A644 error APSDE-DATA.confirm: 0xE1 on task
.I have less than 15 devices connected.
What I did:
- Upgrade to 2.24.1
Run OTA updates on 3 IKEA bulbs (thats why I'm posting it here, not as a separate issue)
- I actually paired two of the bulbs directly with one IKEA remote and the last one with another remote
- Repaired the IKEA bulbs
It worked fine for a couple of hourse, then nothing worked anymore and the Phoscon UI was very slow (clicking on
Devices
>Lights
took ~5 seconds to load).Steps I've tried:
- Restarting the Docker container
- Restarting the PC the container is running on
- Removing my Conbee I and waiting for 10 minutes before plugging it back in
- Physically turning off the bulb that show error messages (there are some that always show errors, some only once or twice)
- Removing the bulb with most errors via deCONZ GUI (error messages are still shown)
- Downgrading to stable (
2.23.2
)The only thing that is still working is controlling the 3 IKEA lights with the remotes directly connected to them (the remote shows up as a group in deCONZ).
Using 2.24.1, I created the following debug logs. I hope this helps in pinning down the issue.
2023-11-13_deconz_logs-debug.txt
Thanks!
Hi
Prior your edit I was going to say that your issue is related to interference , which you indeed concluded.
It is not related to this issue, so for any more support on that I'd like to ask you to open a forumpost.
just want to let you know the problem is growing dramatically with the number of devices. I added like 8 more things to the network (in total about 70 now) and I need to reboot the Conbee II / deCONZ like every two days since the logs get flooded with delay sending request & 5 running tasks, wait entries.
The delay sending request & 5 running tasks
is related to legacy code perhaps doing something strange. We got many Ikea and Hue DDFs recently which is good, but might need to deactivate more legacy code for these devices. The 2023-11-13_deconz_logs-debug.txt
doesn't show the task logging, would be helpful to see in the logs where the messages appear + the related APS commands to filter out what is queued up here.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
Again this bot just closed an issue which isn't solved. @manup would you mind to re-open? And I'm afraid you mixed the messages with @rikroe since your post comments my one but refers to his debug log?
Again this bot just closed an issue which isn't solved. @manup would you mind to re-open? And I'm afraid you mixed the messages with @rikroe since your post comments my one but refers to his debug log?
The bot is clear on what to do when it expires. If there's no response, it closes. Next time, please follow the bit message.
Reopening on request.
Hi @mimix, thank u for re-opening this. In first place I understood the question was asked to rikroe since his debug log was quoted. That's why I expected him to answer. Then I was off for a few days and didn't see the warning in time.
@manup how can I help you helping me:
but might need to deactivate more legacy code for these devices
Can I do anything here?
would be helpful to see in the logs where the messages appear + the related APS commands to filter out what is queued up here
What do you need exactly and where do I find it? I need a bit more explanation to this.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
bump
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
Does the issue really belong here?
Is there already an existing issue for this?
Describe the bug
I noticed recurrently that devices are inresponsive directly after the OTAU and remain unreachable. It happens with a chance of approx 80% with my IKEA & HUE devices.
So far I didn't see it with other manufacturers - but that doesn't mean anything since the rest is mostly Hue and updated via their app.This is how it looks like in deCONZ (2 bulbs are frozen)
In between I tried to restart deCONZ as well as Conbee II, to see if its related to the high uptime - but it's not.
I have also noticed that bulb updates already in progress are interrupted/slowed down when new bulbs appear on the network that also require an update. I saw 3x "updating" at the same time using kinda round robin. (Dunno if this is a problem, but it slows down the whole thing and is more risky than queueing)
To fix the hick-up, I need to enable Pairing Mode at the gateway and also put the bulbs into pairing. So I am finally good now.
EDIT: I force tried updating HUEs via deCONZ and it got stuck the same way.
Steps to reproduce the behavior
Expected behavior
Devices get updated one by one and behave normal after the process finishes.
Screenshots
No response
Environment
deCONZ Logs
After OTAU:
First re-pairing:
Second re-pairing:
Additional context
Currently I run approx. 60 devices in my network: