You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Prevent ZHA from creating the OnOff entity for remotes #289
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?
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.
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
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
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.
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...
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.
Activity
dmulcahey commentedon Nov 5, 2024
No we shouldn’t be. This is a legacy artifact that we need to clean up at some point.
[-]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[/+][-]ZHA Shouldn’t Create an Opening Entity for the On/Off Client Cluster[/-][+]Prevent ZHA from creating the OnOff entity for remotes[/+]TheJulianJES commentedon Nov 25, 2024
Just to clarify, the issue here is that we create the
OnOffentity (often used by window and motion sensors) for all Zigbee devices that have theOnOffentity as an output cluster. Remotes also implement it like that to control other devices.However, we want to make sure the
OnOffentity is not shown for remotes.We should consider if we want to prevent
OnOffentity 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 thedevice_typeby default?We can't remove the
OnOffentity entirely, as it's sometimes the only possible way to get state from some doors sensors and motion sensors.dmulcahey commentedon Nov 25, 2024
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...
TheJulianJES commentedon Jan 4, 2025
We already try to ignore this for remotes here, but apparently that doesn't work very well?
zha/zha/application/discovery.py
Lines 476 to 477 in 91cc37b
elupus commentedon Dec 4, 2025
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.