Add Sonoff water valve leak and supply sensors

[fgsch]

Proposed change

Add sensors for water leaks and supply problems.
While here rename EwelinkCluster to match other Sonoff quirks.

Additional information

Follow-up from #3346.
Supersedes zigpy/zha#189.

Checklist

• The changes are tested and work correctly
• pre-commit checks pass / the code has been formatted using Black
• Tests have been added to verify that the new code works

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.11%. Comparing base (62765a4) to head (0df73ea).
Report is 9 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #3910      +/-   ##
==========================================
+ Coverage   91.00%   91.11%   +0.10%     
==========================================
  Files         328      333       +5     
  Lines       10656    10774     +118     
==========================================
+ Hits         9698     9817     +119     
+ Misses        958      957       -1     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fgsch]

I will move this to open later today when I can test it, but FYI @TheJulianJES .

[fgsch]

Question: Is there any way to define reporting for the water_valve_state attribute and not at the sensor level?
Or does that not work and need to be defined for each separately?

[fgsch]

@TheJulianJES Can you let me know the answer to my question above?
Also, do you know why the sensors come as PROBLEM instead of their name on the UI?

[TheJulianJES]

That is expected if the sensor has a state class due to the way fallback_name is implemented in HA.
It's only an issue when the translation key isn't present in the translations. It will work fine when we PR the changes to Home Assistant. See this for more information: zigpy/zigpy#1523 (comment)

[fgsch]

That is expected if the sensor has a state class due to the way fallback_name is implemented in HA. It's only an issue when the translation key isn't present in the translations. It will work fine when we PR the changes to Home Assistant. See this for more information: zigpy/zigpy#1523 (comment)

Thanks for the information. I thought that might be related but wasn't sure.

Regarding:

Question: Is there any way to define reporting for the water_valve_state attribute and not at the sensor level?
Or does that not work and need to be defined for each separately?

Do you happen to know the answer? I'd like to finish this PR.
Thank you again.

[TheJulianJES]

Only possible to do directly with the sensor function at the moment.

[fgsch]

Only possible to do directly with the sensor function at the moment.

Thanks. I will update this and open It for review.

[fgsch]

Ok, I think this is ready for review now. PTAL.

[fgsch]

@TheJulianJES,

That is expected if the sensor has a state class due to the way fallback_name is implemented in HA. It's only an issue when the translation key isn't present in the translations. It will work fine when we PR the changes to Home Assistant. See this for more information: zigpy/zigpy#1523 (comment)

Does this apply to the entity ID as well? I can see both have binary_sensor.garden_tap_valve_problem.

[abmantis]

@TheJulianJES,

That is expected if the sensor has a state class due to the way fallback_name is implemented in HA. It's only an issue when the translation key isn't present in the translations. It will work fine when we PR the changes to Home Assistant. See this for more information: zigpy/zigpy#1523 (comment)

Does this apply to the entity ID as well? I can see both have binary_sensor.garden_tap_valve_problem.

Yes. The entity will be generated from the name, which will be the fallback_name you specified when it gets integrated in HA.

[TheJulianJES]

Thanks!

[TheJulianJES]

If we didn't have a translation key for this, the name would be "Moisture" due to the device class.
I think we can leave the "Water leak" name here though, since it's a bit more explicit for this device.

[TheJulianJES]

Thanks again!

[fgsch]

Thank you for updating and merging this PR.