Repository navigation
Set a suggested display precision of one decimal for humidity sensors - #915
zigpy-review-bot wants to merge 2 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #915 +/- ##
=======================================
Coverage 97.22% 97.22%
=======================================
Files 61 61
Lines 10657 10661 +4
=======================================
+ Hits 10361 10365 +4
Misses 296 296 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Wouldn't it be more sensible to contribute this to Core? Was humidity deliberately omitted? |
|
Yes, the bot got stuck and didn't comment that part yet 😅 |
|
@zigpy-review-bot Find session that was about this PR and home-assistant/core#145584. It already started preparing HA Core branch, continue my instructions from there. |
|
Core-side version of this is on a branch: https://github.com/TheJulianJES/core/tree/zigpy-bot/humidity-default-display-precision (diff against Core It adds Was humidity deliberately left out? I found no sign of it. home-assistant/core#145013, which introduced the table, describes it as a default precision "for each of Sensor's device classes" and says nothing about humidity in its description or review. Yet more than 20 other numeric device classes are also missing from the table, including battery, CO2, illuminance and the PM classes. That reads like gaps in coverage rather than a decision about humidity. Is it the better fix? For the root cause, yes: one table entry covers every integration, including Matter, which has the same two decimals for the same Verification
|
3 participants
Proposed change
ZHA's humidity-type sensors report
measured_value / 100, so their state carries two decimals (e.g.72.39), and they set nosuggested_display_precision. Home Assistant has no default display precision for thehumidity(ormoisture) device class either, so the frontend falls back to showing as many decimals as the state happens to have:72,39 %. That is what is still open in home-assistant/core#145584.This sets
_attr_suggested_display_precision = 1on the four sensors that divide a ZCL percent value by 100:Humidity0x0405)humiditySmartThingsHumidity0xFC45)humidityLeafWetness0x0407)humiditySoilMoisture0x0408)moistureAnalogInputSensorcan also end up with thehumiditydevice class (application typeRelative_Humidity_Percent), but it is left alone: it has no/100scaling and already derives its precision from the cluster'sresolutionattribute.Only the display default changes. The state is still the unrounded value, a Display precision the user picked for an entity still wins, and Home Assistant recomputes the stored suggestion whenever the entity is added, so existing installs pick this up without a migration. The HA integration already forwards the library's value (
homeassistant/components/zha/sensor.pycopiessuggested_display_precisionfrom the entity state when it is notNone), so no change is needed there beyond the usual ZHA bump. Core's ZHA tests only assert the humidity state ("10.0"), not a precision or registry options, so the bump should not need test changes either.Related: home-assistant/core#145584
Background
Sensorhad_decimals = 1and rounded the state, so temperature and humidity both came out with one decimal. Replace decimals with suggested_display_precision + remove rounding #408 replaced that withsuggested_display_precisionand dropped the rounding, butHumidity,SoilMoistureandLeafWetnessdid not get a precision.UNITS_PRECISIONinhomeassistant/components/sensor/const.py, which brought temperature back to one decimal.SensorDeviceClass.HUMIDITYandSensorDeviceClass.MOISTUREare not in that table (still true on Coredevtoday), soSensorEntity._get_adjusted_display_precision()returnsNonefor them and nothing is written to the entity registry.TUYATEC-qun7vq14RH3052) show exactly this:Humiditywithnative_value: 72.28andsuggested_display_precision: null, and the entity's Display precision dropdown reads "Default (72,39)".Core not defining a default for the percent-based device classes is the actual gap, and a fix there would cover every integration at once. Until that exists, each integration has to set it itself. If Core adds one later, these attributes become redundant but harmless, since an integration-supplied precision takes priority over the table.
Why one decimal (open for discussion, hence draft)
1for the samemeasured_value / 100, and so does Shelly.This is a display choice, not something the spec dictates: ZCL R8 §4.7.2.1.1 defines
MeasuredValueas 100 × the water content in percent, with a maximum resolution of 0.01 %, for all three standard clusters.The alternative is
0(whole percent). Typical sensors are specified at ±2 to 3 % RH, so there is an argument for it, but it would show less than ZHA ever did.What other Core integrations do
An AST scan of
homeassistant/componentson Coredev(a1e35b34f0a) for sensor entity definitions usingSensorDeviceClass.HUMIDITYfinds 225 statically declared definitions in 134 integrations. It counts entity descriptions and_attr_device_classclass attributes; selectors, trigger/condition specs and integrations that pick the device class at runtime or from a lookup table (Tuya's DP tables, KNX, Tasmota, …) are not counted, and a precision assigned at runtime shows up as "not set" (nibe_heatpumpandtplinkdo that).suggested_display_precision1airly,airthings_ble,ambient_network,deconz,epion,imou,microbees,nam,point,shelly)2altruist,lacrosse_view)0airthings,weatherflow,weatherflow_cloud)"Not set" does not always mean two decimals on screen, because many of those integrations deliver a whole or pre-rounded number. The ones closest to ZHA:
1humidity / 1001accuracy_decimalsMeasuredValue / 100, so it has the same two decimals as ZHA today; the Matter sensor platform sets a precision on many other sensors, but not on its standardTemperatureSensorandHumiditySensordescriptionssuggested_display_precisionon any sensor; the state has whatever precision the device reportshumidity_precision)Quirks
dev(d6fcec59), none of the 50.sensor()and 66.tuya_sensor()calls defines a humidity- or moisture-class sensor. Tuya quirks expose humidity through.tuya_humidity()(10 uses) and.tuya_soil_moisture()(4 uses), which map the datapoint onto the standard RelativeHumidity / SoilMoisture clusters, so those devices get ZHA'sHumidity/SoilMoistureentities and are covered here. The same goes for v1 quirks that replace these clusters, and for the Third Reality soil sensor, which only changes the device class of ZHA'sHumidityentity tomoisture.QuirkBuilder.sensor()has asuggested_display_precisionparameter (default1, from Implement suggested display precision for sensors zigpy#1586) that is stored onZCLSensorMetadatabut never applied._platform_kwargs()inzhaquirks/builder/discovery.pydoes not forward it andSensor.__init__has no such parameter;Sensor._init_from_quirks_metadata(), which did this job before Migrate quirks out of zigpy and provide direct entity access #762, did not read it either. So a quirk-defined sensor currently always ends up withNone, whatever the quirk passes (no quirk passes it today). Wiring it up needs a change in both repos, and the builder default would have to becomeNonefirst: otherwise every quirk sensor would get one decimal at once, and Home Assistant raises for a sensor that has a suggested precision but a non-numeric value.Testing
async_test_humiditynow also checks that a report of4853gives a state of48.53(not rounded) withsuggested_display_precision == 1, andtest_sensorruns it forSoilMoistureandLeafWetnessas well asHumidity.tests/data/deviceswithpython -m tools.regenerate_diagnostics: 79 snapshots change, each by exactly one line ("suggested_display_precision": nullto1) — 70Humidity, 8SoilMoisture, 1SmartThingsHumidity. No device in the corpus has aLeafWetnessentity, so that one is covered by the unit test only.