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

Hedda · February 2, 2024, 2:25pm

If you add a new Zigbee device to Home Assistant and it does not show all expected feature/function entities (attributes) in the UI for the ZHA integration (the native "Zigbee Home Automation" gateway component that is built-in to Home Assistant), even after you tried multiple times to re-pair/re-join that same 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 someone needs to modify an existing ZHA Device Handlers (also known as a “zha-quirks”) to extend it so that it will convert/translate all attributes into standard ZCL (Zigbee Cluster Library) formatting and/or expose all entity (attribute) that are now not yet showing by default in the current version on the ZHA integration.

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

ZHA Device Handlers (quirks) bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices. If the device is similar enough to a previous model that already has a device handler (quirk) for ZHA then most of the time all that will be 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.

Note that if you submit a device request you then need to be patient before a new device handler (quirk) becomes includes in ZHA by default, as even 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).

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
Inside your Home Assistant instance, create a directory/folder for your custom quirks (for example /config/zha_quirks/)
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.
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/
```
Use Home Assistant configuration check to make sure the config will not break your configuration.
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.

Hedda · February 4, 2024, 12:26pm

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

FYI, by default the ZHA integration just creates entities in Home Assistant for features and functions that are standard in the official ZCL (Zigbee Cluster Library) specification, and therefor custom ZHA Device Handlers (zha-quirks) are generally only needed if the device firmware have some manufacturer specific functionality (e.g. features and functions) that is not standard in the ZCL specification, or if the device firmware has implemented ZCL specification incorrectly (i.e. poorly written firmware or a bug in the firmware). So by definition all Zigbee devices that do not use manufacturer specific functionality should be compatible with the ZHA integration out-of-the-box without changes, and if they do have manufacturer specific functionality then the ZHA integration should only need a device handler to expose those specific quirks that are unique to that device or manufacturer.

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

Try to re-pair/re-join the device several times.
Checkout the troubleshooting section.
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:

Hedda · March 26, 2024, 9:12am

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

How to configure the Philips Hue wall module to use push button (momentary) type wall switches [ZHA]

I had the same problem as most of you, but managed to make it working.

Why don’t you see the needed configuration…well you most likely have a newer model named RDM004. Apparently this is not supported yet.

Here are my steps to make it work.

Open you favourite file editor. I use Studio Code Server;
Make a new folder. In my case the folder is named “custom_zha_quirks”;
Make a new file named MYFILE.PY
Paste the following content into it:

"""Signify RDM004 device."""
import logging
from typing import Any, List, Optional, Union

from zigpy.profiles import zha
from zigpy.quirks import CustomCluster, CustomDevice
import zigpy.types as t
from zigpy.zcl import foundation
from zigpy.zcl.clusters.general import (
    Basic,
    Groups,
    Identify,
    LevelControl,
    OnOff,
    Ota,
    PowerConfiguration,
)

from zhaquirks.const import (
    ARGS,
    BUTTON,
    COMMAND,
    COMMAND_ID,
    DEVICE_TYPE,
    DOUBLE_PRESS,
    ENDPOINTS,
    INPUT_CLUSTERS,
    LONG_PRESS,
    LONG_RELEASE,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PRESS_TYPE,
    PROFILE_ID,
    QUADRUPLE_PRESS,
    QUINTUPLE_PRESS,
    RIGHT,
    SHORT_PRESS,
    SHORT_RELEASE,
    TRIPLE_PRESS,
    TURN_ON,
    ZHA_SEND_EVENT,
)
from zhaquirks.philips import PHILIPS, SIGNIFY

DEVICE_SPECIFIC_UNKNOWN = 64512
_LOGGER = logging.getLogger(__name__)


class PhilipsBasicCluster(CustomCluster, Basic):
    """Philips Basic cluster."""

    attributes = Basic.attributes.copy()
    attributes.update(
        {
            0x0031: ("philips", t.bitmap16, True),
            0x0034: ("mode", t.enum8, True),    
        }
    )

    attr_config = {0x0031: 0x000B, 0x0034: 0x02}

    async def bind(self):
        """Bind cluster."""
        result = await super().bind()
        await self.write_attributes(self.attr_config, manufacturer=0x100B)
        return result


class PhilipsRemoteCluster(CustomCluster):
    """Philips remote cluster."""

    cluster_id = 64512
    name = "PhilipsRemoteCluster"
    ep_attribute = "philips_remote_cluster"
    client_commands = {
        0x00: foundation.ZCLCommandDef(
            "notification",
            {
                "param1": t.uint8_t,
                "param2": t.uint24_t,
                "param3": t.uint8_t,
                "param4": t.uint8_t,
                "param5": t.uint8_t,
                "param6": t.uint8_t,
            },
            is_manufacturer_specific=True,
            direction=foundation.Direction.Server_to_Client,
        )
    }
    BUTTONS = {
        1: "left",
        2: "right",
    }
    PRESS_TYPES = {0: "press", 1: "hold", 2: "press_release", 3: "hold_release"}

    def handle_cluster_request(
        self,
        hdr: foundation.ZCLHeader,
        args: List[Any],
        *,
        dst_addressing: Optional[
            Union[t.Addressing.Group, t.Addressing.IEEE, t.Addressing.NWK]
        ] = None,
    ):
        """Handle the cluster command."""
        _LOGGER.debug(
            "PhilipsRemoteCluster - handle_cluster_request tsn: [%s] command id: %s - args: [%s]",
            hdr.tsn,
            hdr.command_id,
            args,
        )

        button = self.BUTTONS.get(args[0], args[0])
        press_type = self.PRESS_TYPES.get(args[2], args[2])

        event_args = {
            BUTTON: button,
            PRESS_TYPE: press_type,
            COMMAND_ID: hdr.command_id,
            ARGS: args,
        }

        action = f"{button}_{press_type}"
        self.listener_event(ZHA_SEND_EVENT, action, event_args)


class PhilipsROM004(CustomDevice):
    """Philips ROM004 device."""

    signature = {
        #  <SimpleDescriptor endpoint=1 profile=260 device_type=2080
        #  device_version=1
        #  input_clusters=[0, 1, 3, 64512]
        #  output_clusters=[3, 4, 6, 8, 25]>
        MODELS_INFO: [(PHILIPS, "RDM004"), (SIGNIFY, "RDM004")],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.NON_COLOR_SCENE_CONTROLLER,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    Identify.cluster_id,
                    DEVICE_SPECIFIC_UNKNOWN,
                ],
                OUTPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    Ota.cluster_id,
                ],
            }
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.NON_COLOR_CONTROLLER,
                INPUT_CLUSTERS: [
                    PhilipsBasicCluster,
                    PowerConfiguration.cluster_id,
                    Identify.cluster_id,
                    PhilipsRemoteCluster,
                ],
                OUTPUT_CLUSTERS: [
                    Ota.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                ],
            }
        }
    }

    device_automation_triggers = {
        (SHORT_PRESS, TURN_ON): {COMMAND: "left_press"},
        (LONG_PRESS, TURN_ON): {COMMAND: "left_hold"},
        (DOUBLE_PRESS, TURN_ON): {COMMAND: "left_double_press"},
        (TRIPLE_PRESS, TURN_ON): {COMMAND: "left_triple_press"},
        (QUADRUPLE_PRESS, TURN_ON): {COMMAND: "left_quadruple_press"},
        (QUINTUPLE_PRESS, TURN_ON): {COMMAND: "left_quintuple_press"},
        (SHORT_RELEASE, TURN_ON): {COMMAND: "left_short_release"},
        (LONG_RELEASE, TURN_ON): {COMMAND: "left_long_release"},
        (SHORT_PRESS, RIGHT): {COMMAND: "right_press"},
        (LONG_PRESS, RIGHT): {COMMAND: "right_hold"},
        (DOUBLE_PRESS, RIGHT): {COMMAND: "right_double_press"},
        (TRIPLE_PRESS, RIGHT): {COMMAND: "right_triple_press"},
        (QUADRUPLE_PRESS, RIGHT): {COMMAND: "right_quadruple_press"},
        (QUINTUPLE_PRESS, RIGHT): {COMMAND: "right_quintuple_press"},
        (SHORT_RELEASE, RIGHT): {COMMAND: "right_short_release"},
        (LONG_RELEASE, RIGHT): {COMMAND: "right_long_release"},
    }

Open configuration. yaml
add the following lines:

zha:
  enable_quirks: true
  custom_quirks_path: /config/custom_zha_quirks

remove the HUE module from you devices;
Restart home assistant;
Go back to devices. Right now alle names mentioned in this topic should be visible.
follow the steps in this blog post: Make the Philips Hue wall switch module work with push button switches in Home Assistant — Rudd-O.com
please note:

Select in Cluster: PhilipsBasicCluster << should be available now
Attributes: MODE (ID: 0x0034) << should be avaible now
Value: enter 2. This value enables a double rocker switch

NOW WAIT
if i’m correct one of the two switches is working, or at lease it should be. You can see it in the log of the device. Figure out which one is working.
Now before you click “write attribute” you first click the button that is working. This wakes up the device. If you don’t do this, HA/Zigbee can’t communicate with the device.
Within half a second after you clicked the button of the device to wake it up, you press write.

All done, you have two rocker type buttons working perfectly.

Hedda · September 13, 2024, 6:44am

@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,

https://github.com/zigpy/zha-device-handlers/tree/dev/zhaquirks/tuya

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

zha-device-handlers/zhaquirks/tuya/ts0601_switch.py at acecf704f2b253c9297d901eed8909dbd589ea97 · zigpy/zha-device-handlers · GitHub

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

https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/tuya/ts0601_switch.py#L508-L513

and

https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/tuya/ts0601_switch.py#L573-L577

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:

https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/tuya/ts0601_switch.py#L737-L740

and

https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/tuya/ts0601_switch.py#L818-L822

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 …

Hedda · December 11, 2024, 1:44pm

Tip if you have Tuya device is to check out this other Tuya specific guide:

My Tuya device doesn't work with ZHA - Or how to build a Tuya Quirk

sullencat · December 24, 2024, 12:34am

@Hedda, this may be a completely different topic, but is there a way to manually apply a quirk to a Zigbee group?

In my case I have a lot of Inovelli 2-1 dimmers and I’d like to set some of their parameters as a Zigbee group action instead of having ZHA send commands to all the dimmers individually. Specifically I’m trying to set the “Local default dimming level” to the brightness level of adaptive lighting, so when a light is turned on it immediately goes to the correct brightness with no too-bright momentary flash or delay because it starts too dim.

Is this doable with ZHA? If not it seems like it could be a very useful feature.

Hedda · December 24, 2024, 7:43am

Not quite sure what you mean but it is not possible to apply a quirk to a ”Zigbee group” (which might not be what you mean), regardless, yes your question asked that way is completely different topic, ”Zigbee groups” has nothing to do with using or creating ZHA Device Handlers (quirks), so please post a new separate thread instead.

TDuffinNTU · May 7, 2026, 6:59pm

I'm a bit lost. I've got a device that appears to be a TS1201 IR blaster, which is already merged into the ZHA device handlers repo. Should it not be accessible in home assistant - why am I copy-pasting the file myself?

Hedda · May 7, 2026, 10:06pm

If a quirk for exact same Zigbee ID (unique device model ID that it exposes via its firmware) has already been merged into the ZHA device handlers repo and is now part of the zha-quirks release updated to be used by Home Assistant's core then you should not have to copy any files yourself, HOWEVER, Tuya being Tuya they are infamously know for now following any standards or logic and usually release several products of the same type of device and name with slightly different variants of Zigbee IDs (device model IDs used in the firmware).

So the fact is that the ZHA device handlers repo actually already have quirks for no less than eight (8!!!) different sub-variants of Tuya "TS1201" IR blaster device models with each having different Zigbee ID, so it could be that your device is another new variant with yet another new Zigbee ID that then needs be added to the ZHA device handlers repo as well. See:

zha-device-handlers/zhaquirks/tuya/ts1201.py at 69bdc1564abbfae2ec1cf086d425fbfe41b7283c · zigpy/zha-device-handlers · GitHub

        MODELS_INFO: [
            ("_TZ3290_7v1k4vufotpowp9z", "TS1201"),
            ("_TZ3290_acv1iuslxi3shaaj", "TS1201"),
            ("_TZ3290_gnl5a6a5xvql7c2a", "TS1201"),
            ("_TZ3290_rlkmy85q4pzoxobl", "TS1201"),
            ("_TZ3290_nba3knpsarkawgnt", "TS1201"),
        ],

        MODELS_INFO: [
            ("_TZ3290_ot6ewjvmejq5ekhl", "TS1201"),
            ("_TZ3290_j37rooaxrcdcqo5n", "TS1201"),
            ("_TZ3290_u9xac5rv", "TS1201"),
        ],

And worse, there are even existing open device support requests in the ZHA device handlers repo for additional new variants of sub-variants of Tuya "TS1201" IR blaster device models, so you just have to search there and add your subvariant as another new device support requests in the ZHA device handlers repo if there is not already and existing open issue for your specific model.

If you are interested becoming a quirk developer and learning more about Tuya then read these:

zha-device-handlers/tuya.md at 69bdc1564abbfae2ec1cf086d425fbfe41b7283c · zigpy/zha-device-handlers · GitHub
- Support new Tuya devices | Zigbee2MQTT
  - https://github.com/Koenkk/zigbee-herdsman/blob/ac057926458c6b199b50596d101825ef2be5d151/docs/Zigbee%20Connection%20Standard_Tuya%20Smart_Documentation.pdf

You could also use more powerful LLM models in Copilot or Claude Code with this help of this:

zha-device-handlers/.github/copilot-instructions.md at 69bdc1564abbfae2ec1cf086d425fbfe41b7283c · zigpy/zha-device-handlers · GitHub

TDuffinNTU · May 7, 2026, 10:11pm

Thanks for the info!

I managed to more-or-less figure out the "signatures" part since posting that original comment. I just added mine to the quirk on git and it got picked up A bit fiddly IMO but not something I'd have to deal with in 99% of scenarios!

Hedda · May 8, 2026, 6:03am

Again, if you have any Zigbee product that pairs with ZHA (i.e. joins the Zigbee network) and goes through device-interview but then do not expose all expected attributes as entities inside ZHA in Home Assistent then always submit an new "device support request" issue to zha-device-handlers if there is not already an issue started for it there (or if there already is one then help contribute info to it instead).

https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices

In summery, this thread in the community forums is the wrong place to report problems with devices device support requests for ZHA, instead always request missing device features via issues in the zha-device-handlers repository on GitHub. That will help ZHA-quirk developers be made aware of that specific device having problems and other users can find + track devices known to be missing entities via issues there as a peristant knowledgebase. Pleaee see here:

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

Note that even if you feel that this is a bug and not a feature request then you should still submit it to the zha-device-handlers repo on GitHub so that there is a record of it that can be tracked and others can find for reference, and that will benefit everyone in the community in the long run.

Like you said, all that is also bit fiddly but not something you have to deal with in 99% of scenarios, and you have to deal with it even less than so if you do not buy devices made by Tuya!