Add attribute_converter to quirks v2 sensors

[TheJulianJES]

Proposed change

This adds an attribute_converter to the following quirk v2 platforms:

• binary sensor
• sensor

This will allow us to parse a ZCL attribute value in quirks, before passing it to the HA state.

Additional information

If we also add a "unique id suffix suffix" in a future PR, we can even parse the same ZCL attribute in different ways with multiple entities.

Corresponding ZHA PR:

• Implement quirks v2 attribute_converter zha#360

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.44%. Comparing base (ed7d54c) to head (6967ec4).
Report is 2 commits behind head on dev.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev    #1540   +/-   ##
=======================================
  Coverage   99.44%   99.44%           
=======================================
  Files          57       57           
  Lines       11300    11302    +2     
=======================================
+ Hits        11237    11239    +2     
  Misses         63       63           

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

[TheJulianJES]

I've removed attribute_converter support for the switch platform for now, as I don't see any real value in it.
This PR now only adds it for senor and binary_sensor, where it's definitely useful.

[puddly]

For sensors, this is a unidirectional conversion. Should we do bidirectional conversion for attributes (or entities in general) to clean up the attribute cache database?

[TheJulianJES]

Should we do bidirectional conversion for attributes (or entities in general) to clean up the attribute cache database?

I'm not entirely sure I correctly understood what you mean, but here we go:
Most quirks v2 entities that write attributes are just switch, select, or number entities. There, the value on the device already responds to what we have in the attribute cache (except if we convert/translate the attributes in quirks a bit first).

I think we have few devices with ZCL attributes that we convert/translate in quirks first. Tuya devices map their proprietary datapoints to "fake" ZCL attributes on a local cluster and I think that's fine. It's the best and only thing we can do at least.

---

Z2M has an intermediary layer between clusters and the device data that we don't have. Like, they specify a device exposes illuminance, so the entity is always created then, and they parse Tuya DPs to forward them as data["illuminance"] = tuya_dp_value or just have a default "converter" that does that for the ZCL attribute.

Because our ZHA entities really on accessing the zigpy attribute cache, we can't do that at the moment, except if we use local clusters, of course. And I generally think that this solution is fine. I mean, they're per device, so the cluster IDs won't collide. And I guess you could even try and make negative cluster IDs work for entirely fake clusters if you're worried about collisions.

For ZCL-compliant devices, an intermediary layer also doesn't make a ton of sense. For others, maybe.. if we really don't want to use local clusters for some reason. But again, I think they're fine generally and introducing an intermediary layer would probably complicate some things more, only to clean up others a bit.

---

To get back to the quirks where we do convert/translate ZCL attributes, I can think of the IKEA battery divider for older devices. Here, the division could be done on another level (e.g. in an entity or somehow in a converter for the attribute like you mentioned, where the original value stays in the attr cache, but we get another value when reading it and on attribute_updated events?).

But honestly, I don't really see the point in doing that at the moment. The original promise of zha-quirks was to sit in between ZHA and zigpy on a cluster level and present a ZCL-compliant like device to ZHA. I'm just not sure what the real "measurable" benefit of attribute values being fully correct in the DB would be, at least for this case.

A converter for the "friendly/converted values" for attributes could work, I guess, with the raw values only going into the DB. It's at least not as complicated as introducing an intermediary layer now, but not totally sure if there's much to gain from it either.