Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent ZHA from creating the OnOff entity for remotes #289

Open
mguaylam opened this issue Nov 5, 2024 · 3 comments
Open

Prevent ZHA from creating the OnOff entity for remotes #289

mguaylam opened this issue Nov 5, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@mguaylam
Copy link
Contributor

mguaylam commented Nov 5, 2024

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

@dmulcahey
Copy link
Contributor

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

@mguaylam mguaylam 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 Nov 5, 2024
@TheJulianJES TheJulianJES added the enhancement New feature or request label Nov 25, 2024
@TheJulianJES TheJulianJES 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 Nov 25, 2024
@TheJulianJES
Copy link
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.

@dmulcahey
Copy link
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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants