Skip to content

Prevent ZHA from creating the OnOff entity for remotes #289

Description

@mguaylam

While working on this issue zigpy/zha-device-handlers#3314, I learned that ZHA creates automatically an entity when it sees a contact device with an On/Off cluster. But since, at least my device, has only a client On/Off cluster, should ZHA creates an entity from it?

@STRICT_MATCH(cluster_handler_names=CLUSTER_HANDLER_ON_OFF)
class Opening(BinarySensor):
"""ZHA OnOff BinarySensor."""
_attribute_name = "on_off"
_attr_device_class: BinarySensorDeviceClass = BinarySensorDeviceClass.OPENING

The reasoning being that the ZCL says a client On/Off cluster has no attributes and that it should only transmit commands of the On/Off server cluster.

Meaning that this cluster has no attributes and does not support reporting by implying that. Creating an entity from it works because it does send commands when binding but there can't be reporting.

3.8 On/Off
3.8.3 Client
The client has no cluster specific attributes. The client generates the cluster specific commands received by the server (see 3.8.2.3) , as required by the application. No cluster specific commands are received by the client.

This is an issue because when the command fails to send, the device will not try to send it again. It's really meant to control another device like a lightbulb.

Also, I see the server attributes are defined in the client cluster but there should be none there since it's a client.
image

Activity

  1. dmulcahey commented on Nov 5, 2024

    @dmulcahey
    Contributor

    No we shouldn’t be. This is a legacy artifact that we need to clean up at some point.

  2. changed the title [-]Should ZHA create an opening entity for the On/Off client cluster?[/-] [+]ZHA Shouldn’t Create an Opening Entity for the On/Off Client Cluster[/+] on Nov 5, 2024
  3. changed the title [-]ZHA Shouldn’t Create an Opening Entity for the On/Off Client Cluster[/-] [+]Prevent ZHA from creating the OnOff entity for remotes[/+] on Nov 25, 2024
  4. TheJulianJES commented on Nov 25, 2024

    @TheJulianJES
    Contributor

    Just to clarify, the issue here is that we create the OnOff entity (often used by window and motion sensors) for all Zigbee devices that have the OnOff entity as an output cluster. Remotes also implement it like that to control other devices.
    However, we want to make sure the OnOff entity is not shown for remotes.

    We should consider if we want to prevent OnOff entity creation for remotes in quirks OR if we want to only allow it for the specific devices that need it (also in quirks). We could also decide on the device_type by default?

    We can't remove the OnOff entity entirely, as it's sometimes the only possible way to get state from some doors sensors and motion sensors.

  5. dmulcahey commented on Nov 25, 2024

    @dmulcahey
    Contributor

    We can't remove the OnOff entity entirely, as it's sometimes the only possible way to get state from some doors sensors and motion sensors.

    I am thinking we remove the hard coded hack in ZHA for this and replace it w/ v2 quirks that explicitly create the needed entities. Problem is... I don't have a handle on how many devices are doing this...

  6. TheJulianJES commented on Jan 4, 2025

    @TheJulianJES
    Contributor

    We already try to ignore this for remotes here, but apparently that doesn't work very well?

    if device_type in REMOTE_DEVICE_TYPES.get(profile_id, []):
    return

  7. elupus commented on Dec 4, 2025

    @elupus
    Contributor

    Its also missing actual output events. So this might help out to get rid of this #594

    I did run into this weird onoff stuff when looking at that change. Wanted to add the onoff client cluster too. But the hacks make it somewhat hard. So quirking that would be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Fields

    Priority

    None yet

    Size

    None yet

    Area

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions