Testing popular ZigBee devices (and coordinators)

[Hedda]

@robmac

@mstormi

Aqara devices are fine in terms of hardware and very cheap so everybody wants to use them hence good candidates.

Have you seen this on the hubitat site? Xiaomi & Aqara Devices - Pairing & Keeping them connected - Devices - Hubitat ?

Hopefully out of date and the more recent devices are not so temperamental.

@chris

These issues are well documented with other systems as well, but the binding is a bit more susceptible for two reasons - firstly it doesn’t use a database so needs to discover all the devices features, and secondly the way the binding currently works is part of the discovery is done on join, but the actual initialisation is done when the thing is created, so the device needs to be awake for both parts. I’m changing the binding so that the initialisation is done during the discover rather than when the thing is created, but this will have other potential issues for devices that are created through the database.

FYI, one of the reason Aqara/Xiaomi devices are relatively stable in Home Assistant’s ZHA and Zigbee2MQTT despite not 100% following standard Zigbee Cluster Library specifications is that those applications both an additional device handler/converter layer for ‘quirk’ workarounds which translate non-standard attributes/parameters into attributes/parameters that are compliant standard ZCL specifications.

ZHA in Home Assistant depends on “ZHA Device Handlers” and zigbee-herdsman (used by Zigbee2MQTT and IoBroker) depends “zigbee-herdsman-converters” for modified Zigbee device compliance which has similar concepts of converting/translating non-compliant device attributes to follow ZCL (Zigbee Cluster Library) standards.

https://github.com/zigpy/zha-device-handlers

https://github.com/Koenkk/zigbee-herdsman-converters

SmartThings Classic (Samsung) support similar custom “Device Handlers” concept for Zigbee devices:

https://docs.smartthings.com/en/latest/device-type-developers-guide/

https://github.com/SmartThingsCommunity/SmartThingsPublic

These concepts of seperating device handlers/converters makes modular and seperate for core apps.

https://github.com/zigpy/zha-device-handlers#what-is-a-device-in-human-terms

Primer

ZHA device handlers and it’s provided Quirks allow Zigpy, ZHA and Home Assistant to work with non standard Zigbee devices. If you are reading this you may have a device that isn’t working as expected. This can be the case for a number of reasons but in this guide we will cover the cases where functionality is provided by a device in a non specification compliant manner by the device manufacturer.

What is a device in human terms

A device is a physical object that you want to join to a Zigbee network: a light bulb, a switch, a sensor etc. The host application, in this case Zigpy, needs to understand how to interact with the device so there are standards that define how the application and devices can communicate. The device’s functionality is described by several descriptors while the device itself contains endpoints and endpoints contain clusters. There are two types of clusters an endpoint contains:

• in_clusters - are “Server” clusters in ZCL terms. These clusters control the device, e.g. a smart plug or light bulb would have an on_off server cluster. in_clusters are also the ones which also send attribute reports and/or you can read an attribute from a in_cluster.

• out_clusters - are “Client” clusters. These clusters control some other device, as “Client” cluster sends commands to “Server” cluster. For example an On/Off remote would have an on_off client cluster and will generate cluster commands and send those to some other device. Zigpy needs to understand all these elements in order to correctly work with the device.

This is how ZHA exception and deviation handling is explained to new users and Zigbee novices:

https://www.home-assistant.io/integrations/zha/#zha-exception-and-deviation-handling

"The ZHA implementation in Home Assistant relies on a library called “ZHA Device Handlers” to resolve issues with Zigbee devices that do not fully conform with the Zigbee standards. The few devices that deviate from the Zigbee specifications set by the Zigbee Alliance may therefore require proper bug reports with debug logs from users to assistant the developers in writing custom ZHA Device Handlers for all of a device functions to work properly with the ZHA integration.

Such a custom “ZHA Device Handler” are Python scripts that internally are also referred to as a “quirk” because they fix “quirks”, like deviations from the standard specifications. ZHA Device Handles do this by transparently, acting as a translator, translating and converting non-compliant device messages and instead present them to the application as coming from a virtual compliant device. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from Zigbee devices. The ZHA Device Handlers that are made can then be reused by all users in future versions of Home Assistant.

The custom quirks implementations for zigpy implemented as ZHA Device Handlers for Home Assistant are a similar concept to that of Hub-connected Device Handlers for the SmartThings Classics platform as well as that of Zigbee-Herdsman Converters (formerly Zigbee-Shepherd Converters) as used by Zigbee2mqtt, meaning they are each virtual representations of a physical device that expose additional functionality that is not provided out-of-the-box by the existing integration between these platforms."