Why does pairing ZHA devices not always works the first time?

Hello!

It’s quite common situation for me, when adding new ZigBee devices that some of them don’t pair properly on first try. It even happened when I was adding multiple of the same devices. 2 of them paired fine first try, 1 I had to remove and add again, because it did not pick up all entities properly and didn’t properly identify the device.

My question is… how is this possible? Why does this happen? Like on a low level of communication, how can it be that device is not fully identified? In my mind it should fail and ask to re-pair itself but not act like it’s paired but just does not recognize the device. It causes confusion of whether it’s a device support issues or something else.

Sometimes it is buggy firmware on the Zigbee device (common issue if from Tuya or Aqara/Xiami), or buggy firmware on the Zigbee Coordinator which is why should upgrade firmware on it, but many other times it is due to bad/poor reception due to EMF/EMI/RMI interference, which is why should ready and follow this guide here → https://github.com/zigpy/zigpy/wiki/Generic-best-practice-tips-on-improving-Zigbee-network-range-and-general-stability

Especially be sure to connect the Zigbee Coordinator USB adapter via a long shielded USB extension cable and then the USB extension cable to a USB 2.0 port on the computer, if needed buy and use a powered USB 2.0 hub if computer only got USB 3.0 ports as that will convert it to USB 2.0, and then place your Zigbee Coordinator USB adapter as far away from your comouter and other USB devices as well as any other sources of EMF/EMI/RMI interference.

Understand that the whole purpose of using a long shielded USB extension cable is to get the Zigbee Coordinator USB adapter as far away from both the Raspberry Pi and the SSD harddrive (as well as any other sources of electromagnetic fields, which includes Wi-Fi Access Points / WiFi Routers and power-supplies) as the goal is to avoid the electromagnetic interference that electrical devices and appliances generate which cause signal reception problem for Zigbee and other low-power radios.

This is all good, thank you for the explanation, but it does not quite answer my question.

I’m talking protocol design here. Isn’t it supposed to validate if all the data was received properly, and things like that?

That is a very good question. I am using Ethernet Zigbee coordinator, and I can move a device very close to the antenna, so I don’t believe RF issues are the problem.
I easily connect two Philips Tap Dial Switches, but I can’t connect Philips Smart Button nor Xiaomi Light Sensor.
I am trying to debug the paring process, but I can’t find enough useful information in the logs. I am using:

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    bellows.zigbee.application: debug
    bellows.ezsp: debug
    zigpy: debug
    zigpy_deconz.zigbee.application: debug
    zigpy_deconz.api: debug
    zigpy_xbee.zigbee.application: debug
    zigpy_xbee.api: debug
    zigpy_zigate: debug
    zigpy_znp: debug
    zhaquirks: debug

Are there any additional low-level debugs I can use to understand the problem?

Yes but some Zigbee devices do not fully/probably comply with all sets of official Zigbee specifications, read → https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling (“ZHA EXCEPTION AND DEVIATION HANDLING” section in ZHA documentation).

FYI, that in turn is very much related to this → https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported (“KNOWING WHICH DEVICES ARE SUPPORTED” section in ZHA documentation).

That is the reason why some devices need ZHA Device Handlers → https://github.com/zigpy/zha-device-handlers/

In summary; at least joining/pairing compatibility would not be an issue for Zigbee if all manufacturers understood and diligently followed all sets of official Zigbee specifications. However interoperability would still remain an issue as Zigbee specifications allow manufacturers to add additional custom manufacturer cluster and attributes than are not part of the standard Zigbee specifications by default.

If think problem is deeper try asking zigpy developers → https://github.com/zigpy/zigpy/discussions

Zigbee sniffing using Wireshark is what developers use to capture (record) to analyze traffic between a Zigbee device and the Zigbee Coordinator using a separate Zigbee sniffer adapter to sniff, see links:

https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html

https://github.com/zigpy/zigpy/wiki/Sniffing-Zigbee-traffic

https://github.com/zigpy/zigpy/discussions/692

1 Like