Add device class radiation

[descipher]

Proposed architectural change:

After developing an ESPHome geiger counter component it was identified that various radiation sensor devices could benefit with the addition of a device class specific to radiation within Home Assistant. The radiation class would give users the ability to select from the wide range of measurement standards for a specific location. The additonal class would also enable radiation unit conversion capability.

update: volume based units Bq/m pCi/L removed for separation purposes as per discussions. PR work to follow as time permits.

Integrations/products which would benefit from this:

airthings, ggreg20, gmc320, GRGC1, openuv, pulse_counter (generic CPM), rd200_ble, web based REST sources etc.

Unit of Measure examples

class UnitOfRadiation(StrEnum):
    """Radiation units."""

    COUNT_PER_SECOND = "cps"
    COUNT_PER_MINUTE = "cpm"
    MICROSIEVERT_PER_HOUR = "uSv/h"
    MILLISIEVERT_PER_HOUR = "mSv/h"

Some real radiation sensors that engage with Home Assistant

https://suverent.org/2022/02/24/home-assistant-notification-radiation-levels/
https://www.uradmonitor.com/uradmonitor-home-assistant-a-match-made-in-heaven/
https://github.com/GelidusResearch/grgc1
https://www.airthings.com/en-ca/wave-radon

Draft PR for this discussion

home-assistant/core#90811

[ehn]

The units for MICROSIEVERT_PER_HOUR and MILLISIEVERT_PER_HOUR should be swapped.

Isn't the unit of COUNT_PER_SECOND simply Hz?

[descipher]

Thanks for the input, the order is subject to Black and any other code convention formatting engines if this is ever accepted so they will be sorted by them no matter what is set here. But yes I would sort them by scientific norms otherwise. CPS is not really a form of Hz, Hertz is a regular cycle interval, gamma, beta wave detections etc. do not have a similar regular cycle behaviour.

[descipher]

Oh, I see it now, will swap them, good catch.

[descipher]

Added a comment in the draft pr to swap them, thanks.

[ehn]

You're right. Even though Hz = 1/s, for radionuclide event per second, the derived SI unit is Bq. Wouldn't that be the preferred unit for COUNT_PER_SECOND? Or should there be a unit specifically for becquerel?

[parautenbach]

a device class specific to radiation within Home Assistant

Does ESPHome already have a device class for this? I think that alone would be a strong enough argument for adding it in HA.

Isn't the unit of COUNT_PER_SECOND simply Hz?

Technically yes, but Hz is typically associated with signals (not referring only to sinusoidal signals, of course). You wouldn't refer to the unit for the number of steps you give per day in Hz either – it will just be a count per day which would be a rate per hour/minute/whatever.

[frenck]

So, in general, we don't want to add every possible unit of measurement (constant), but only the ones that at least have a few uses in our Core codebase. However, the list provided in the proposal seems to be big compared to the integrations that can use this now.

So, let's investigate which units are used by each integration that can currently support this (excluding integration that define their own protocol, like rest, mqtt, templates and such).

../Frenck

[descipher]

Agreed, adding dead code is simply not acceptable. I will scan the associated repos and make sure that we are supporting actual instances of those unit constants. Do keep in mind that the upper level code in HA can convert to units not used in any integration where the standard unit for a particular use case or locality is not what was selected by an integration. In those cases it would be useful to provide conversion functions in the upper layers. I will bring forward those specific examples to be considered and possibly supported here. For example radon measurement units do have different unit standards based on locality.

[descipher]

Use case investigations:

RadonEye
https://esphome.io/components/sensor/radon_eye_ble.html
Uses pCi/L (Europe)

Airthings
UNIT_BECQUEREL_PER_CUBIC_METER
Bq/m3 (North America)

https://www.uradmonitor.com/uradmonitor-home-assistant-a-match-made-in-heaven/
Uses µSv/h, cpm and pCi/L (Europe)

https://devices.esphome.io/devices/geiger-counter
Uses µSv/h, cpm, cps

https://iot-devices.com.ua/en/connecting-ggreg20-radiation-sensor-to-home-assistant-server-via-esp-home-integration/
Uses µSv/h

https://github.com/GelidusResearch/grgc1
Uses µSv/h, cpm, cps

Based on actual active iot devices used with HA we can reduce the list to:

BECQUEREL_PER_CUBIC_METER = "Bq/m³" 
PICOCURIE_PER_LITER = "pCi/L"
COUNT_PER_SECOND = "cps"
COUNT_PER_MINUTE = "cpm"
MICROSIEVERT_PER_HOUR = "µSv/h"

Sieverts are clearly the most used.
Radon is ether Bq/m3 or pCi/L based on locality.

[joostlek]

To add to this, both Airthings as Airthings BLE have sensors for Radon. AirQ also has sensors for Radon.

[iotdevicesdev]

Thank you for taking our developments (https://github.com/iotdevicesdev) into account. We do not use mSv/h. Instead, we sometimes used to indicate "mkSv/h", which is short for micro in Ukraine. This was a mistake on our part. The best way to use "uSv/h" is to make it clear and familiar to most people.

[descipher]

Thanks for the clarification, µSv/h is noted.

[epenet]

Are all the units interchangeable?
If they are not, then we should consider multiple device classes (like we did for VOLATILE_ORGANIC_COMPOUNDS / VOLATILE_ORGANIC_COMPOUNDS_PARTS)

[descipher]

No they are not interchangeable when working between pCi/L or Bq/m3 and Sv/h units, these can be converted when known radiation sources are available. I am looking at what was done with VOC’s and to understand what you are suggesting.

[descipher]

After examining your suggestion it becomes clear to me that the addition of a radiation class should be carefully understood to have any useful context when we add it to the code. In general the term radiation is very generic, it represents a wide scope of possible measurement units. The intended class for the discussed use cases are of the "Ionizing radiation" type. Even in this context the application of the device class will have additional scope such as radiation "activity" and "dose". Based on my observation of the code and its use of device classes it clearly keeps categories together where measurement units are interchangable e.g. speed = simple interchangeably compatible units like km/h to mi/h.

Based on this we can consider something more like:

RADIATION_IONIZING_ACTIVITY and RADIATION_IONIZING_DOSE

Where "activity" is based on radition events in volume and "dose" reflects organically absorbed e.g. human tissue.
What gets difficult is the unit of CPM, it can be used in either context but are more commonly used with dose instruments.
I have not observed any class that includes a unit like CPM in multiple contexts but it is possible to do that.

Thoughts?

[descipher]

Keeping this alive ..

[Kirchoff]

Hoping to restart discussion on this topic, I had made a very similar but not identical question posed here: #999

I had made a PR focusing specifically on sensors that measure radon, not radiation measurements in general: home-assistant/core#103709

From reading the discussion above, I see no arguments against standardizing radon measurements as either "Bq/m³" or "pCi/L", just discussion on the wider topic of radiation in general. In my opinion, implementation of this would be lower risk and lower effort than trying to have a single catch-all radiation device class?

It doesn't really address the needs of @descipher though.

[descipher]

@Kirchoff No real needs atm just looking to improve the whole. The challenge with a radiation class is the wide variance of units. They do not fit into a classical unit model however they are all related. The notion of sub class is one of the potential solutions. Alternately we could follow a unit path which is where most of the code lives. that would be more like RADIATION_IONIZING_ACTIVITY and RADIATION_IONIZING_DOSE or a less descriptive RADIATION_ACTIVITY and RADIATION_DOSE.

Here radiation activity is where radon gas would sit. Its a measurement of activity verses exposure per say. This needs to be walked through the use case possibilities in a test of viability, I have not had the time atm.

[jcgillespie]

I created a PR for this too before I knew it needed a discussion first.

Radon sensors measure environmental radioactivity, which aligns with how the IEEE describes it here:

Environmental and biological measurements of radioactivity are generally expressed as concentrations of radioactivity in soil, water, air, or tissue. Examples of units include picocuries per liter, becquerels per cubic meter, picocuries per gram, and disintegrations per minute per 100 square centimeters.

Consequently, I'd suggest that measures of strictly radioactivity be kept separate from "radioactive concentration" environmental/biological measures, as the volume component can change based on the medium. This EPA.gov page on Radiation Terms and Units shows Bq/L as the unit of radioactivity in a volume of water.

Keeping them separate allows for more mix-and-match unit composition, if that is ever needed for a sensor.

[abmantis]

This proposal was discussed during the core meeting and it was agreed that we should split radiation (like Bq or Ci) from radiation concentration (such as Bq/m³).
@descipher could you please update the description of this proposal to focus only on radiation, and provide the list of current integrations that would benefit from it?

Thank you.

[Kirchoff]

@abmantis Thank you for moving this discussion forward. Consequently, would it make sense for a separate PR to be submitted that focuses solely on radiation concentration? I can start work on that if it makes sense to do so.

I closed my discussion #999 on that topic as it seemed to have been covered here.

[jcgillespie]

The PR was closed stale while waiting for the architectural decision, but I had a PR here that we could rebase and reuse if it is helpful.

[abmantis]

@Kirchoff we still need a decision on an architecture discussion regarding that, assuming this one will focus on radiation. I think it can either be radiation concentration or specific for radon, if radon is the only one that we currently have integrations for concentration measurements.
We have this one, but I am not sure if the author still wants to move it forward: #732

[descipher]

@abmantis Will do, lots on the burner so expect some delay. :)