Add AnalogInput, MultistateInput, use description attribute for fallback_name

[prairiesnpr]

This ensures that the description attribute (0x001C), if present, is used for the fallback_name and sets the translation_key to None. The entity id and name will use the fallback_name and align with the devices value. This is mostly useful for devices using general clusters, if not set, the current functionality is maintained.

Due to testing requirements, this now also updates the cluster handlers for AnalogInput, MultistateInput, and BinaryInput.

Closes: #160

Multistate still requires zigpy/zigpy#1456 to be fully implemented, since the LVLists aren't serialized, we create a default value for now.

AnalogOutput is putting the description in the name twice.

This is due to this logic in core, should we add similar logic to core for the rest of the Entities and remove it from ZHA, keep the logic in ZHA, or have it mixed?

https://github.com/home-assistant/core/blob/f1e4229b23ef7837bb4e46877f55d6533f8d4607/homeassistant/components/zha/number.py#L52C9-L52C58

[codecov]

Codecov Report

Attention: Patch coverage is 99.10714% with 1 line in your changes missing coverage. Please review.

Project coverage is 96.29%. Comparing base (927e249) to head (93f54ad).

Files with missing lines	Patch %	Lines
zha/application/platforms/sensor/__init__.py	97.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #197      +/-   ##
==========================================
+ Coverage   96.27%   96.29%   +0.02%     
==========================================
  Files          61       61              
  Lines        9366     9476     +110     
==========================================
+ Hits         9017     9125     +108     
- Misses        349      351       +2     

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

[puddly]

I wonder: would it be feasible to instead set the translation key to the ZCL description? This could allow the description to be localized.

[prairiesnpr]

I wonder: would it be feasible to instead set the translation key to the ZCL description? This could allow the description to be localized.

That was the approach I started with, unfortunately, when the translation key wasn't found, it would return None for the name and id. I understood it should then fallback, but that's not the result I observed in testing.

[prairiesnpr]

Should this always be measurement? I can see a situation where total or total increasing makes sense, but I don't see a good way to choose based on the attributes we have available.

[TheJulianJES]

There are some restrictions on what we can provide as a translation_key to Home Assistant. AFAIK, we are not allowed to provide translation keys blindly, so not directly from the description attribute, for example.

We'd need to map all known description attribute values to translation keys (and fall-back to a default or untranslated name otherwise).

So, I'm wondering if it would make sense to split this PR into two: one with the translation key changes and one with the added AnalogInput and MultistateInput sensors.

[prairiesnpr]

There are some restrictions on what we can provide as a translation_key to Home Assistant. AFAIK, we are not allowed to provide translation keys blindly, so not directly from the description attribute, for example.

We'd need to map all known description attribute values to translation keys (and fall-back to a default or untranslated name otherwise).

So, I'm wondering if it would make sense to split this PR into two: one with the translation key changes and one with the added AnalogInput and MultistateInput sensors.

We aren't modifying the translation_key here, if a description attribute is provided, we set the key to None and then provide a fallback_name, that way we can use arbitrary values without having a matching translation_key. This follows the same logic currently used for custom quirks https://github.com/home-assistant/core/blob/f1e4229b23ef7837bb4e46877f55d6533f8d4607/homeassistant/components/zha/entity.py#L46

As far as splitting the PR, it was originally planned to have multiple PRs, one for the fallback_name functionality and then additional PRs for each cluster. I ran into issues with writing tests there, since we really needed them to both be present to get the required coverage. That said, I'm not opposed to splitting it, if we have a plan on how best to proceed.

[prairiesnpr]

This will need a zigpy release before tests will pass.

[dmulcahey]

I think we should update the test json files... that's a lot to delete. Also, should we start these off as disabled by default?