Add flow volume sensor entity for the FlowMeasurement cluster

[benbancroft]

Proposed change

Adds a new "volume flow rate" sensor for discovered FlowMeasurement clusters. This is required for the Sonoff SWV-BSP Smart Water Valve, but likely other devices with FlowMeasurement being a standardised Zigbee cluster.

Raw value of "measured_value" is 10 * flow_rate, as per Zigbee cluster specification for FlowMeasurement.

This feature was requested as part of zigpy/zha-device-handlers#3298

Testing

I have tested this with my Sonoff SWV-BSP Smart Water Valve and the sensor is appearing and being exported to Home Assistant no issues with a sane value that matches the flow of water. I have not tested this with any other device that implements FlowMeasurement cluster, but I assume it should work fine.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.41%. Comparing base (57cc44b) to head (99535cb).
Report is 57 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #187      +/-   ##
==========================================
+ Coverage   95.89%   96.41%   +0.51%     
==========================================
  Files          61       61              
  Lines        9404     9363      -41     
==========================================
+ Hits         9018     9027       +9     
+ Misses        386      336      -50     

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

[fgsch]

This is great!

Is there anything we can do to get this reviewed and merged?

[dmulcahey]

If we are going to implement this we should add the other 3 attributes to the ZCL init attrs on the cluster handler. Also, take note that a measured value of 0xffff means the measurement is unknown and the note from 4.1.3 about how the min and max affect the readings of measured value.

[dmulcahey]

@benbancroft bumping this... can you make the small tweaks from my comment above?

[benbancroft]

Hi @dmulcahey

I've not had the time to address this yet unfortunately - had family over this weekend.
Agree with your comment regarding implementation of cluster constraints. I plan to have a go at addressing this soon (hopefully later this week).

Question: where would you recommend implementing these checks? Are there other examples of where other clusters do similar I can reference?

[dmulcahey]

Hi @dmulcahey

I've not had the time to address this yet unfortunately - had family over this weekend. Agree with your comment regarding implementation of cluster constraints. I plan to have a go at addressing this soon (hopefully later this week).

Question: where would you recommend implementing these checks? Are there other examples of where other clusters do similar I can reference?

I know illuminance does something like this in the formatter:

zha/zha/application/platforms/sensor/__init__.py

Lines 760 to 766 in c99237f

	def formatter(self, value: int) -> int | None:
	"""Convert illumination data."""
	if value == 0:
	return 0
	if value == 0xFFFF:
	return None
	return round(pow(10, ((value - 1) / 10000)))

[benbancroft]

Hi @dmulcahey

Thanks! I've gone ahead and implemented the 0xffff unknown state in the same way via a formatter.

Regarding MinMeasuredValue and MaxMeasuredValue - I've left this as is for now as this looks like a wider issue throughout most other sensors within ZHA (e.g. Temperature Measurement cluster).

I guess strictly speaking, we can largely place trust in the server that it is implementing these constraints for the measured values it reports. The only real use on the client side is enforcing this relationship, or utilising min/max for display of data (e.g. rendering a sliding display). For the latter, as this sensor is exported as a numerical to Home Assistant, it doesn't apply here.

Please let me know your thoughts/suggestions here.

[fgsch]

Can someone review and merge this if it looks OK? 🙏

[benbancroft]

I've just added some more unit tests, so hopefully code coverage issue is now resolved.

[benbancroft]

Hi @dmulcahey,

I don't suppose you've had a chance to review my latest changes yet? I'm hoping this should be nearly ready.