Low-level hardware specialization

[jonatanolofsson]

Specialization cannot be exclusively handled above the zigpy abstraction level as some devices require low-level adjustments. One distinguished example is the IKEA Trådfri devices which need to use the ZHA profile ID in the APS frame in ZCL communication.

[rcloran]

This is basically next on my roadmap — my idea is to be able to register a function with the application object that can return custom device objects. Similar to the way SmartThings has custom handlers. The profile id thing sounds like it may just be a bug, though — should zigpy always echo back the profile id of the device?

[jonatanolofsson]

Unfortunately, the bug is in Trådfri, as they require the "wrong" profile ID to be used.. Replies only will not work as server-initiated communication also requires the ZHA profile ID.

When I implemented this, it turned into a quite large refactorization, as some specialization is required even in the initialization process of a device.

Example: Xiaomi devices does not reply to most of the standard commands, and the best (only) way to identify them is to ask for manufacturer id. As the device object controls the communication with the device, the object needs to be created within the join handler, i.e. a request for the manufacturer needs to be done from within the handler. This is a blocking operation, which means message handlers need to be asynchronous. Meanwhile, more messages will arrive from the device but neither of those can be handled before the device object has been created, so they all need to wait for the return of the manufacturer code, so the device object can know how to interpret them - for example, Xiaomi devices sends its information not as individual attribute updates, but as a special struct with all the sensors' data as a single attribute (special ID 0xFF01) update which needs to be split into the separate attributes (and it doesn't send it on request, it just.. sends it).

(edit: My bad, zcl would presumably in zigpy, removed second example)

[jonatanolofsson]

Also, note that device specialization entails that e.g. attribute_updated events needs to be announced on the device objects instead of the cluster objects.

See e.g. https://github.com/jonatanolofsson/bellows/blob/develop/bellows/zigbee/specialization.py

[Hedda]

@jonatanolofsson I have just started a new Zigpy feature request here #102 to specifically discuss the ZHA Device Handler that @dmulcahey have written (and the quirks handlers for it) and whether or not it or something like it could be integrated into Zigpy. Hopefully, this type of modular ZHA Device Handler approach or something similar is something that the Zigpy project would like to adopt for dealing with the custom / unique exception handling of some devices.