Zigbee Guide: How-to add/setup local custom ZHA Device Handlers (also known as ”quirks”) in the ZHA integration

Community Guides
, ,
1

If your new Zigbee device is not showing all expected feature/function entities (attributes) in the ZHA integration (native Zigbee gateway component that is built-in to Home Assistant), even after trying multiple times to re-pair/re-join your new Zigbee device to the ZHA integration, then there is a big chance that your new Zigbee device will either need a new custom ZHA Device Handler (also known as a “zha-quirk”) for that specific device model or modify existing ZHA Device Handlers (also known as a “zha-quirks”) to make it use it to expose all and any entity (attribute) that is now not yet showing by default in the current version on the ZHA integration. Other times all that is needed is to add the device signature (model) of a new device to an existing ZHA Device Handler (quirk) if it basically the same device with different model number.

Sometimes someone else has already written or modified such a custom ZHA Device Handler (zha-quirk) to expose the missing entity/entities it can sometimes still take quite a long time before that specific “quirk” is merged into the mainline ZHA Device Handlers (“zha-quirks”) repository and for it to get added to Home Assistant’s core for automatic inclusion in Home Assistant releases so it is seen by default, therefore until then you will need to manually add the ZHA Device Handler (zha-quirk) yourself to your own instance of Home Assistant.

How to add a ZHA Device Handler (zha-quirk) is not documented in the ZHA integration documentation, which is sad because if you as an end-user is an early-adopter that keep buying the latest brand new Zigbee devices as soon as manufacturers make them available then it is a huge chance are that you sooner or later will probably need to use a manually install a custom ZHA Device Handler (zha quirk), because new experimental ZHA Device Handlers (zha-quirks) will only be added after you have submitted a new device request properly → https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices (and even then you have to wait until someone in the community steps-up to code that quirk and submit it for merger).

Anyway, below is a summary of what you need to do to install a custom quirk after you download it:

How end-users can test a not yet merged custom quirk in ZHA

If you have bought a non-standard Zigbee device that is not yet supported by ZHA but someone have written a ZHA “quirk” module (ZHA Device Handler/Zigbee Converter) that not get been merged into a “ZHA Device Handlers"” library release then you can add that manually as a custom ZHA quirk to your Home Assistant instance, (using something like File Editor or Samba share add-ons in Home Assistant).

  1. Get a copy of an existing “custom quirk” that is meant for your specific device (or code your own custom quirks). Tip is to search for the specific Zigbee device signature among open issues and open pull requests as those might contain experimental custom quirk that have not yet been merged for your Zigbee device, see Issues · zigpy/zha-device-handlers · GitHub and Pull requests · zigpy/zha-device-handlers · GitHub
  2. Inside your Home Assistant instance, create a directory/folder for your custom quirks (for example /config/zha_quirks/)
  3. Copy or create a quirk file in this directory (called it for example “devicemodelzyz_devicetypexyz.py”). This file should contain the Python script for the quirk and its specific Zigbee device signature unique to it.
  4. Add configuration with the full path to the directory that now containing custom quirk module(s) that will override and take precedence over any built-in quirks matching any device that has the same Zigbee device signature. to Home Assistant’s config.yaml
    zha:
   database_path: /config/zigbee.db
   enable_quirks: true
   custom_quirks_path: /config/zha_quirks/
  5. Use Home Assistant configuration check to make sure the config will not break your configuration.
  6. Restart Home Assistant to make the quirk take effect.

Note! If your Home Assistant is running inside a container then you must then you must edit and add the file inside that container, see Editing (ZHA) quirks in a (HA) container or local. · zigpy/zha-device-handlers · Discussion #693 · GitHub

Back-stopy, I initially wrote a guide for how-to manually adding a custom quirk to the ZHA locally as a pull request for the ZHA integration docs but it was not accepted with the argument that it is too advanced for the ZHA integration so I and then resubmitted an update of it for the readme in ZHA Device Handlers (zha-quirks) repository on GitHub, but that has not yet been accepted/merged either → Add a how-to guide for how end-users can use a custom quirk in ZHA by Hedda · Pull Request #2419 · zigpy/zha-device-handlers · GitHub

PS: This question have been asked hundreds of times in the community and previously discussed here:

Link to this and other helpful tips also found in the HA Cookbook:

The Home Assistant Cookbook - Index.

8 Likes
2

Note! If there is not already a quirk (ZHA Device Handler) for your specific Zigbee device in the ZHA integration and/or there already is a quirk there but it is still not exposing all expected attributes as entities inside ZHA UI in Home Assistant you need to then begin by submitting a new device support request as an issue to the ZHA Device Handlers repository on GitHub,requesting a new custom quirk (ZHA Device Handler) in that new issue by filling out the template there with requested information to open a dialogue custom ZHA Device Handler developers with the ZHA quirks community → https://www.home-assistant.io/integrations/zha/#how-to-add-support-for-new-and-unsupported-devices

HOW TO ADD SUPPORT FOR NEW AND UNSUPPORTED DEVICES

If your Zigbee device pairs/joins successfully with the ZHA integration but does not show all of the expected entities

  1. Try to re-pair/re-join the device several times.
  2. Checkout the troubleshooting section.
  3. Still not working? You may need a custom device handler. This handler will have exception handling code to work around device-specific issues.

For devices that do not follow the standard defined in the CSA’s ZCL (Zigbee Cluster Library), the ZHA integration relies on a project called “ZHA Device Handlers (also known as “zha-quirk”)”. It contains device-specific Python scripts called “quirks”. These scripts can resolve compliance and interoperability issues by implementing on-the-fly conversion of custom Zigbee configurations or by implementing manufacturer-specific features for specific devices.

People familiar with other Zigbee gateway solutions for home automation may know similar concepts of using custom Zigbee device handlers/converters for non-standard devices. For example, Zigbee2MQTT (and IoBroker) uses zigbee-herdsman converters and SmartThings Classics (Legacy) platform has Hub Connected Device Handlers.

If you do not want to develop such a “quirk” Python script yourself, you can submit a “device support request” as a new issue to the ZHA Device Handlers project repository on GitHub.

What the heck is a quirk

In human terms you can think of a quirk like Google Translate. I know it’s a weird comparison but let’s dig in a bit. You may only speak one language but there is an interesting article written in another language that you really want to read. Google Translate takes the original article and displays it in a format (language) that you understand. A quirk is a file that translates device functionality from the format that the manufacturer chose to implement it in to a format that Zigpy and in turn ZHA understand. The main purpose of a quirk is to serve as a translator. A quirk comprises several parts:

  • Signature - To identify and apply the correct quirk
  • Replacement - To allow Zigpy and ZHA to correctly work with the device
  • device_automation_triggers - To let the Home Assistant Device Automation engine and users interact with the device

Note! Best to first search existing issues with device signature and track open device support requests:

Note that submitting a new “device support request” does not guarantee that someone else will develop a custom “quirk” for ZHA. The project relies on volunteering developers. However, without “device support requests”, the developers may not be aware that your specific Zigbee device is not working correctly in ZHA.

PS: Fow information on how-to actually code/write your own Zigbee Device Hanler quirks see this related development discussion meant for quirk developers here:

1 Like
3

FYI, @Regenbui also wrote a very detailed instruction on adding a custom quirk in this other thread → How to configure the Philips Hue wall module to use push button (momentary) type wall switches [ZHA] - #27 by Regenbui

1 Like
4

@carlosjusto The thing is that there already are several ZHA Device Handlers (quirks) for many different Tuya switches, so often you just need to add device signature (model) to an existing ZHA Device Handler (quirk), which is something that practically anyone here should be able to do without any coding skills.

That is, if you have a new Tuya device that is similar to existing devices but just uses a (new) different device signature models number (which is very common) then you usually just need to add any new device signature model to the existing ZHA Device Handler (quirk) under the correct device class, which is not something that is relativly easy and do not require coding skills so you can try doing it yourself.

Root cause to thiis the problem is that Tuya not only deviates from Zigbee specifications/standards but more confusingly to end-users uses no logic in their model schema used in their device signatures ( so the ZHA developers can not deduce what similar devices there based on Tuya’s device signature model numbers alone (and that for it is not possible to use wildcards to use a specific ZHA Device Handler quirk for new device signature models that were previously unknown ) + fact is that Tuya is a company that manufactures the same while-label product variants to tens or hundreds of other companies and therefore use different device signature models for what is essentially the same product hardware and same or very similar firmware, with often only the model variant in device signature being different.

The good thing about that is that it makes it relatively easy for you or anyone else to simply test adding additional device signature models to an existing Tuya ZHA Device Handler quirk with the same capability.

Best however is if you open first open a new device request issue regardless so that the specific model can be tracked and you can get help from others in the community → https://github.com/zigpy/zha-device-handlers/issues/new/choose

So what you can do is open each of the existing Tuya “switch” quirks (for OnOff switches) and see if can find a similar one,

Try for example adding that model to this “ts0601_switch.py” ZHA Device Handlers (quirk) code file:

From reading just the non-code text is that file it should be obvious that you for example would want to test adding the device signature model a new 4-gang switch under either the “class TuyaQuadrupleSwitchTO(TuyaSwitch” (section that contain “”“Tuya quadruple channel switch time on out cluster device.”““as description) or theclass TuyaQuadrupleSwitch_GP(TuyaSwitch):(section that contain””“Tuya quadruple channel switch with GreenPowerProxy cluster device.”“”`) depending if your product feature the GreenPowerProxy cluster or not, (you should see that if export diagnostic information as it mentions “PROXY_BASIC” as device_type and a “green_power” attribute. See

and

Today those only have these models but as you probably understand now you can test adding more.

    signature = {
        MODELS_INFO: [
            ("_TZE200_aqnazj70", "TS0601"),
            ("_TZE200_1ozguk6x", "TS0601"),
            ("_TZE200_k6jhsr0q", "TS0601"),
        ],

and

    signature = {
        MODELS_INFO: [
            ("_TZE200_1n2kyphz", "TS0601"),
            ("_TZE200_mexisfik", "TS0601"),  # reported #1634
        ],

The same procesure then goes for your 6-gang (sextuple) switch, see:

and

Those today only list the device signature models for these:

        MODELS_INFO: [
            ("_TZE200_9mahtqtg", "TS0601"),
            ("_TZE200_wnp4d4va", "TS0601"),
        ],

and

    signature = {
        MODELS_INFO: [
            ("_TZE200_9mahtqtg", "TS0601"),
            ("_TZE200_emxxanvi", "TS0601"),
        ],

… and so on …