Prevent ZHA from creating the OnOff entity for remotes

[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?

zha/zha/application/platforms/binary_sensor/__init__.py

Lines 167 to 172 in 701f575

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

[dmulcahey]

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

[TheJulianJES]

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]

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...

[TheJulianJES]

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

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

[elupus]

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.