Proper way to implement other ZHA `IasZone.ZoneStatus` than alarm?
See original GitHub issueThe problem
There are several Zigbee devices that provide the tamper and battery status for the IasZone cluster.
I have work in some quirks that have the attribute, but I’m not sure which way would be the proper one to expose that info in HA.
One way would be to quirk a IasZone cluster for every attribute.
This would require expanding the CLASS_MAPPING with new classes (tamper, battery…):
https://github.com/home-assistant/core/blob/4c7837a5762a741100b07d89803340f53b1d04b1/homeassistant/components/zha/binary_sensor.py#L29-L36
But also the IasZone.ZoneType beyond the standar:
https://github.com/zigpy/zigpy/blob/b94cfe12903b21ed146e556c1e514e2abc16611f/zigpy/zcl/clusters/security.py#L22-L39
Doesn’t seem to me the way to go…
Other approach could be to add support in HA for other IasZone.ZoneStatus than Alarm_1 and Alarm_2:
https://github.com/home-assistant/core/blob/4c7837a5762a741100b07d89803340f53b1d04b1/homeassistant/components/zha/binary_sensor.py#L168-L173
But this would require a full refactor of the IasZone sensor. In fact, it should stop being a binary_sensor to support multiple ‘states’, which may also involve modification at the HA frontend level (this part is not clear to me).
In my opinion, this would be the solution that best fits the nature of the IasZone cluster, but I am not sure if it is the way to go either.
Any suggestion or comment about it?
What version of Home Assistant Core has the issue?
core-2022.5.5
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
ZHA
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Issue Analytics
- State:
- Created a year ago
- Comments:17 (11 by maintainers)

Top Related StackOverflow Question
I had a Bosch sensor that flipped the “tamper” bit when you slid it off its battery cover/mounting plate. I agree though, globally enabling these entities when 95% of deployed motion sensors don’t support them will just create clutter and unnecessary issues.
Having to update both ZHA and quirks in parallel will make contributing new quirks even more difficult than it currently is.
Perhaps we should start extending existing quirks with information about what capabilities a device supports? Or even draft a more general system that separates allowed device actions and state from the restrictive ZCL cluster/endpoint framework?
@Adminiuga it is possible but not as easy as a binary sensor. Another problem with attributes is that you can’t see the history in the core history graph as easy as a standard sensor.
Is it possible to use multiple classes with one channel, e.g. IASZoneTamperSensor? Then every “extra” sensor can be activated by adding the model name.