Use Radon device class in Airthings BLE - #175388
Conversation
|
Hey there @vincegio, @LaStrada, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
This PR updates the Airthings BLE integration to model radon measurements using Home Assistant’s radon sensor device class and standard radon concentration units, removing bespoke unit-handling code in the integration.
Changes:
- Switch radon average sensors to
SensorDeviceClass.RADONwithUnitOfRadiationConcentration.BECQUEREL_PER_CUBIC_METER. - Remove custom radon unit constants and the per-unit-system unit swapping logic in sensor setup.
- Force the underlying library fetch to use metric radon values so Home Assistant can perform consistent unit conversion for display.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| homeassistant/components/airthings_ble/sensor.py | Uses radon device class + standard unit enum and removes custom unit-mapping logic. |
| homeassistant/components/airthings_ble/icons.json | Removes explicit icon overrides for radon average sensors (now covered by device class behavior). |
| homeassistant/components/airthings_ble/coordinator.py | Always requests metric values from the library to support HA-managed unit conversion. |
| homeassistant/components/airthings_ble/const.py | Removes custom radon unit string constants no longer needed. |
|
overall LGTM - minor non-blocking suggestions [SUGGESTION] tests/components/airthings_ble/test_sensor.py — no test asserts the new behavior. A small test verifying the radon sensors report device_class: radon with Bq/m³ native unit (and ideally one with US_CUSTOMARY_SYSTEM asserting the state renders in pCi/L) would lock in the statistics-continuity behavior this PR relies on. [SUGGESTION] coordinator.py:38-40 — since the library default is already is_metric=True, the argument could be dropped entirely; keeping it explicit with the comment is also defensible given the old code toggled it. Take it or leave it. |
No need, IMO, since we now rely on default behavior (we usually don't add unit conversion tests on integrations).
I prefer to keep that explicit. |
| "radon_1day_avg": AirthingsBLESensorEntityDescription( | ||
| key="radon_1day_avg", | ||
| translation_key="radon_1day_avg", | ||
| native_unit_of_measurement=VOLUME_BECQUEREL, | ||
| device_class=SensorDeviceClass.RADON, | ||
| native_unit_of_measurement=UnitOfRadiationConcentration.BECQUEREL_PER_CUBIC_METER, | ||
| suggested_display_precision=0, |
Proposed change
Replace the custom unit logic with the recently added radon device class.
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: