Lights not responding sporadically (failed-status: APP_BUSY (0x02))

But what is the “automation” ? It s still your motion sensor in the toilet ? How many receiver it trigger ? Are you using zigbee group (and not third app group)?

1 Like

The APP_BUSY message doesn’t show up anymore?

I haven’t seen this error in the logs since the update :+1:

The 0xE1 (MAC channel access failure) if seen multiple times hints on radio interference, this usually happens when no USB extension cable is used or other nearby devices like USB3/SSD or Bluetooth / WiFi jamming the 2.4 GHz channel.

No USB3 devices nearby and I’m using a USB extension cable. Probably have to throw out my Google Nest WiFi mesh which doesn’t allow changing channels though… :roll_eyes:

The 0xD2 means “broadcast table full” this happens if too many broadcasts/groupcasts are in flight in a short interval.

Wondering what can be done about these 0xD2 errors. I suppose either the broadcast table size needs to be increased (if at all possible) or the number of broadcasts reduced. What influences the number/frequency of broadcasts? Would reducing the number of light groups help for example?

But what is the “automation” ? It s still your motion sensor in the toilet ?

Yes, still the same downlight in the toilet. Have the same problem in other rooms too though. Using Zigbee groups everywhere.

I realy don’t see how you can fill a broadcast table, with a simple sensor and a group with 3/4 bulbs (I don’t think you have more in your toilet).
You are sure it s not from your automation scripts ?

I don’t think the table being full is due to the toilet light specifically, but rather the toilet downlight (and other lights in the house) sometimes fail to turn on because the broadcast table is full from other stuff happening in the house. I have more than 60 Zigbee lights and 27 light groups.

I’m 100% sure that the automation is working fine because the lights always change state to “on” in deCONZ / Home Assistant. Just physically they remain off and then cannot even be turned on manually (without toggling off and then on again) because deCONZ thinks they’re already on.

Did you ever find a solution to those pesky 0xD2? I’m seeing the same symptoms in my setup.

I have the same since a power outage yesterday: none of my deconz groups are working. Adressing the devices individual still works.

Also I have the table full error. Didn’t found a way to clear the tables.

A log when I press a button to control a group of 1 light:

09:40:56:876 rule event /sensors/25/state/lastupdated: 0 -> 0
09:40:56:992 rule event /sensors/25/state/lastupdated: 0 -> 0
09:40:56:993 trigger rule 32 - Rule TOOGLE_ON
09:40:57:066 0x0000000000000000 error APSDE-DATA.confirm: 0xD2 on task
09:40:57:839 Set sensor check interval to 1000 milliseconds

if it helps here is also the http request and APS logging:

Does anybody know how to clear those tables? Or identify on which router the table is full.
I only have 4 groups, and they never work anymore.

Before my power outage (10 days ago) everything worked smooth. Since then not able to control any group.

I tried recreating the groups, no difference.

10:52:18:560 delay sending request 132 dt 0 ms to 0x5C0272FFFE227008, ep: 0x0B cluster: 0x0008 onAir: 1
10:52:18:560 delay sending request 133 dt 0 ms to 0x5C0272FFFE227008, ep: 0x0B cluster: 0x0300 onAir: 1
10:52:18:562 delay sending request 132 dt 0 ms to 0x5C0272FFFE227008, ep: 0x0B cluster: 0x0008 onAir: 1

Can be for exemple the device 0x5C0272FFFE227008

Table are empty al the time, but when you make too much request they are filled faster than they are emptied (it s a queue list), mostly if you have one device that delay request.

You have 4 groups, and every time different devices in it ? and same issue on 4 ? what is the request you make on the group ?

But you are “lucky” there is a dev with the same issue than you, so probably some news about this issue.

I have it on all groups, and members aren’t normally changed.
I even have it on a fresh, new empty group.

log of creating an empty group and trying to switch it on:

172.30.32.2 - - [19/Oct/2022:19:03:24 +0200] "POST /api/DBF3457F89/groups HTTP/1.1" 200 36 "https://x.duckdns.org/api/hassio_ingress/WBd6C4GXRXNPdvVoKSAA3dymtcW-IRmvUgkFXxUPNPY/pwa/index.html?1663617310000&gwid=00212EFFFF063700" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.47"
19:03:24:627 APS-DATA.indication srcAddr: 0x2208, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0B04, lqi: 255, rssi: -72
19:03:24:629 ZCL attribute report 0x2C1165FFFEA2B581 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
172.30.32.2 - - [19/Oct/2022:19:03:24 +0200] "GET /api/DBF3457F89/groups?_=1666198984165 HTTP/1.1" 200 3615 "https://x.duckdns.org/api/hassio_ingress/WBd6C4GXRXNPdvVoKSAA3dymtcW-IRmvUgkFXxUPNPY/pwa/index.html?1663617310000&gwid=00212EFFFF063700" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.47"
19:03:26:512 APS-DATA.request id: 124, addrmode: 0x03, addr: 0x00178801097177ce, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x0B queue: 0 len: 5 tx.options 0x00
19:03:26:556 APS-DATA.confirm id: 124, status: 0x00 SUCCESS
19:03:26:558 APS-DATA.confirm request id: 124 -> erase from queue
172.30.32.2 - - [19/Oct/2022:19:03:26 +0200] "PUT /api/DBF3457F89/groups/23/action HTTP/1.1" 200 59 "https://x.duckdns.org/api/hassio_ingress/WBd6C4GXRXNPdvVoKSAA3dymtcW-IRmvUgkFXxUPNPY/pwa/index.html?1663617310000&gwid=00212EFFFF063700" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.47"
19:03:26:585 aps request id: 124 finished, erase from queue
19:03:26:638 APS-DATA.indication srcAddr: 0xacbc, srcEp: 0x0B dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 252, rssi: -75
19:03:26:640 ZCL got data for node=0xACBC, cl=0x0006, at=0x0000, status=0x00, type=0x10
19:03:26:704 APS-DATA.request id: 128, addrmode: 0x01, addr: 0x0017, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0xFF queue: 0 len: 3 tx.options 0x00
19:03:26:737 0x0000000000000000 error APSDE-DATA.confirm: 0xD2 on task
19:03:26:739 APS-DATA.confirm id: 128, status: 0xD2 

the full log of the event above:

2nd example of 0xD2 with more logging active (line 57):