Add IASZone binary sensors for extra bits

[abmantis]

The new entities are disabled by default since devices do not support all bits and there is no way to automatically find if a device supports each bit.

Requires: home-assistant/core#129706

[puddly]

This PR adds new entities to existing devices so CI is expected to fail.

[abmantis]

I want to discuss how the extra bits on the IASZone should be made available in HA.

Having those bits are specially important for things like smoke or gas sensors, for users to know when battery gets low, for example. Some of those sensors beep when battery get critically low, which gets annoying when it happens at 4am. This in turn makes some people start looking at the code and opening RFC PRs 👀

Since IASZone devices usually do not implement all bits, but there is unfortunately no way to identify which ones are implemented, having them available by default would be wrong and lead users to complain that the values never change.

An alternative would be to have a flag on the quirk, specifying which entities to expose. The downside is that it makes it hard to actually identify bits supported by a device, since users would really have no practical way to track that proactively for new devices.

A mixed approach would be to create the entities disabled by default, and have a quirk flag that would make some of them enabled by default for specific devices. This would make the entities show up for devices that are already known to support them, while still allowing the users to manually enable them for newer devices with no quirk. The downside is that some users may still enabled them for devices that do not support them, and complain.

I was planing to implement the later.
Before moving on with the tests, I would like to have some feedback on this.

[abmantis]

This PR adds new entities to existing devices so CI is expected to fail.

Sorry, I was still writing the comment.

[puddly]

I think entities disabled by default is a good approach, with v2 quirks providing extra metadata to enable them for known-supported devices. We could also possibly explore auto-enabling entities if we ever find that the state ever changes.

[TheJulianJES]

Quick background

We also have the ability to assign one quirk_id to a device. We can enable/create entities in ZHA for multiple quirk IDs.
We currently use quirk_id for a bunch of Tuya quirks*. It allows us to have the configuration entities in ZHA and to create them for the devices that have that Tuya quirk ID assigned.

It's not used too often, but it is very useful in those cases. It also makes sure the quirk is applied before trying to create the entities. Other configuration entities in ZHA just check the model for example. Sometimes, the quirk doesn't even, so they'll error out because the custom cluster they're expecting isn't there.

(*The Tuya plug quirks cannot be converted to v2 quirks due to ignoring manufacturer (so the model in Tuya's case), as the quirks only match per their endpoint/cluster signature.)

Important part (why it's relevant for this)

We should probably allow a quirk to have multiple quirk IDs and we could rename it to something like exposes_features.
For the Tuya plugs, the exposed features will stay "Tuya plug config entities" (or similar).

But for this, we could have exposed features called something along the lines of "IAS tamper" and "IAS trouble".
It would allow us to enable the additional IAS entities in ZHA from quirks.

We could also easily make exposes_features compatible with v2 quirks. If there's the rare case that a device is actually fully standard compliant, we can just have a few lines of code with v2 quirks to enable the entity in ZHA.
(Technically just one line per manufacturer/model, as they could all use the same basic v2 quirk to just set the exposes_features to "IAS tamper" for example).

IMO, this might be worth exploring, especially for this use-case.

[abmantis]

I like the exposes_features approach since it is very versatile.

Could it also be used in negative? For example, for devices that are known to not support something (such as aqara motion sensors not supporting Tamper), could we have a "No IAS Tamper", to prevent the entity from getting created (instead of having it disabled)?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.35%. Comparing base (69abf69) to head (3e6eb90).
Report is 4 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #246      +/-   ##
==========================================
+ Coverage   96.33%   96.35%   +0.01%     
==========================================
  Files          61       61              
  Lines        9388     9429      +41     
==========================================
+ Hits         9044     9085      +41     
  Misses        344      344              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[puddly]

I discussed with the other ZHA maintainers and I think adding the disabled-by-default entities for every IASZone device is going to be too drastic of a change. We're instead going to add a way to expose this feature via quirks per-device. There are so few devices with this feature (I think I have only a single sensor by Bosch that has a microswitch for the battery cover) that it's going to cause more confusion than benefit.

[abmantis]

I discussed with the other ZHA maintainers and I think adding the disabled-by-default entities for every IASZone device is going to be too drastic of a change. We're instead going to add a way to expose this feature via quirks per-device. There are so few devices with this feature (I think I have only a single sensor by Bosch that has a microswitch for the battery cover) that it's going to cause more confusion than benefit.

Thanks for the feedback @puddly !
I do agree that it would add a lot of unnecessary disabled entities (see my comment at the top). My only concern is: how will users/developers identify that a device supports bit X? For tamper, it is easy, but for low battery or problem it would be much harder to identify.
Maybe we could have the entity added when the bit becomes 1?