Unhandled APS-DATA.confirm id: 96 status 0xE1

Some of my devices (switches, lights, …) are unreactive from time by time.

Hardware: Raspbee II
Version: 2.13.02 / 10.11.2021
Firmware: 26690700
Channel: 20
Nearby WiFi: Channel 1 and 13

Raspberry Pi 2 is connected by WiFi to the local network.

Debug log:

21:46:35:185 unhandled APS-DATA.confirm id: 73 status 0xE1
21:46:40:480 unhandled APS-DATA.confirm id: 97 status 0xE1
21:47:17:158 unhandled APS-DATA.confirm id: 80 status 0xE1
21:47:20:000 unhandled APS-DATA.confirm id: 96 status 0xE1
21:47:34:002 unhandled APS-DATA.confirm id: 179 status 0xE1
21:48:05:907 unhandled APS-DATA.confirm id: 107 status 0xE1
21:48:08:237 unhandled APS-DATA.confirm id: 119 status 0xE1
21:48:19:223 unhandled APS-DATA.confirm id: 182 status 0xE1
21:48:34:951 unhandled APS-DATA.confirm id: 10 status 0xE1
21:48:38:228 unhandled APS-DATA.confirm id: 28 status 0xE1
21:49:00:188 unhandled APS-DATA.confirm id: 149 status 0xE1
21:49:18:755 unhandled APS-DATA.confirm id: 6 status 0xE1
21:49:25:353 unhandled APS-DATA.confirm id: 42 status 0xE1
21:50:22:795 unhandled APS-DATA.confirm id: 123 status 0xE1
21:50:23:791 unhandled APS-DATA.confirm id: 128 status 0xE1
21:50:24:742 unhandled APS-DATA.confirm id: 133 status 0xE1
21:50:26:769 unhandled APS-DATA.confirm id: 143 status 0xE1
21:50:31:903 unhandled APS-DATA.confirm id: 167 status 0xE1
21:50:31:987 unhandled APS-DATA.confirm id: 166 status 0xE1
21:50:34:134 unhandled APS-DATA.confirm id: 179 status 0xE1
21:50:35:067 unhandled APS-DATA.confirm id: 186 status 0xE1

The WiFi and Zigbee-Channel/Frequencies do not overlap:

What’ the reason for that ?
Would it be helpful to connect the Raspberry Pi by LAN-cable ?

So yes, right its probably interference Zigbee Error Codes in the Log · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

And unfortunately hard to prevent them on Raspbee, you can use a lan cable to make test, but if your system work better with LAN, what can be the solution , give up the Wifi ?

Thank you for that hint.

I’ve disabled WiFi and Bluetooth now:



Additional overlays and parameters are documented /boot/overlays/README


I will report soon, if there is any mitigation.

This is not a bug nor has it to do with phoscon, moving to deconz > general support.

It is of course an issue of phoscon. The Raspbee II gpio board is very close to the WiFi antenna of the Paspberry Pi, that advise on possible interference would be helpful to the users. The problem may not occur with a ConBee II using an extension cable.

After turning of WiFi and BT I’ve currenty no more errors in the debug log.

Phoscon is just a front end. Deconz handles all traffic.

It’s a bug in the USB 3.0 interface that causes interference on 2.4ghz bands.

It is well documented.

NO. There isn’t an overlap of my WiFi- and Zigbee-Channels.

The quoted “documentation” only apply on the ConBee II. I won’t find any word about the problem with the RaspBee II. The only reasonable explanation for the problem I observed is the close distance of the antenna of the RaspBee II and the onboard WiFi of the Raspberry III.

It’s the same.

The USB 3.0 radiation is blocking the 2.4ghz.

Also, wifi is 2.4ghz, so that also affects it.

Either way, I am not sure what you expect.

I am very disapointed, that there is no propper documentation on the known problems with the RaspBee II is available. I have 3 RaspBee II in 3 different locations and all 3 suffer from the same problem with the “unhandled APS-DATA.confirm id”.

Now, after more then 2 years the problem seems to be solved by simply turning of WiFi and BT. My conclusion is, that no RaspBee II works propper with WiFi and BT enabled on a Raspberry Pi.

Any documentation for conbee almost always goes for raspbee too. Nevertheless, we are a community so feel free to contribute to the wiki :slight_smile:

I actually did a search on the same error yesterday after I started noticing them in the logs every now and then (Conbee II in Docker on Syno NAS, with a usb extension cord).

The solution in my case was to move my new TP-Link Deco X50 Wifi Access point away from the closet the NAS is in. I like them, but unfortunately TP-Link automatically decides which channel it uses, and on top of that always uses a wide 40MHz channel for the 2.4GHz band (nothing configurable).

I always thought that interference would not be such a big deal, but turns out it is. :slight_smile:

[Update] I’m still having issues with 0xE1 errors over the last few days. Tried using different extension USB cables & positions away from my NAS (0.5m and 1m), moved the nearby wifi AP to another room but so far it seems to be worse than before. Not sure what has changed. I may try changing the zigbee channel from 25, not sure yet. :frowning:

[Update 2] Suspecting that interference is really an issue I decided to changed the zigbee channel from 25 to 11, and after triggering all Aqara sensors (force a report by pushing the button) the network has become much more responsive, and no more errors!

But you have problem too ?
Because having some errors is not a big problem, zigbee can support/handle somes errors.

I did have some weird issues like delays and missed motion activation, and sometimes I got multiple 0xE1 errors around the same time (already using a USB extension cable). I also noticed that this was less of an issue in the early morning, which would make sense because wifi is not as heavily used as during the day and evening.I also checked using a wifi analyser app, and that confirmed that my wifi APs channel overlapped with zigbee channel 25. And like I said unfortunately the TP-Link Deco series does not allow manual selection of the wifi channel.

In my case there was no overlap of wifi and zigbee. The reason was simply the close distance between tbe RaspBee II and the onboard wifi (and bt) antenna of the Raspberry Pi. Switching off wifi an bt solved the issue.