Add VOC and CO2 string sensors - #48
Conversation
The next commit will add new level names for CO2 and VOC, so make clear that these ranges are specific to radon levels.
This is similar to the Radon level strings, but for VOC. The levels and descriptions were taken from [1]. I merely copied the ranges provided by Airthings and do not claim that they are reasonable, accurate or otherwise. This is convenient as an end-user has no idea what are acceptable measurements, giving them a text sensor makes it easier to spot problems. [1]: https://www.airthings.com/en-ca/contaminants/what-is-voc
This is similar to the Radon level strings, but for CO2. The levels and descriptions were taken from [1]. I merely copied the ranges provided by Airthings and do not claim that they are reasonable, accurate or otherwise. This is convenient as an end-user has no idea what are acceptable measurements, giving them a text sensor makes it easier to spot problems. [1]: https://www.airthings.com/en-ca/contaminants/what-is-carbon-dioxide
|
I vote for this. This is the first thing I did after adding the airthings devices. I had to use template sensors, having them from source would be great. |
|
There's a typo in the PR, "extremelly" should be 'extremely'. I'm also not sure how translations might be handled. I should clarify, I've no involvement in any of these products, just bought a few AirThings BLE devices and looking to capture data. |
| CO2_INDOOR_NORMAL = (400, 999, "indoor normal") | ||
| CO2_HIGH = (1000, 1999, "high") | ||
| CO2_VERY_HIGH = (2000, 4999, "very high") | ||
| CO2_EXTREMELLY_HIGH = (5000, 39999, "extremelly high") |
There was a problem hiding this comment.
| CO2_EXTREMELLY_HIGH = (5000, 39999, "extremelly high") | |
| CO2_EXTREMELY_HIGH = (5000, 39999, "extremely high") |
| CHAR_UUID_WAVE_PLUS_DATA, | ||
| CHAR_UUID_WAVEMINI_DATA, | ||
| CO2_CRITICAL, | ||
| CO2_EXTREMELLY_HIGH, |
There was a problem hiding this comment.
| CO2_EXTREMELLY_HIGH, | |
| CO2_EXTREMELY_HIGH, |
| co2_level = CO2_HIGH[2] | ||
| elif data <= CO2_VERY_HIGH[1]: | ||
| co2_level = CO2_VERY_HIGH[2] | ||
| elif data <= CO2_EXTREMELLY_HIGH[1]: |
There was a problem hiding this comment.
| elif data <= CO2_EXTREMELLY_HIGH[1]: | |
| elif data <= CO2_EXTREMELY_HIGH[1]: |
| elif data <= CO2_VERY_HIGH[1]: | ||
| co2_level = CO2_VERY_HIGH[2] | ||
| elif data <= CO2_EXTREMELLY_HIGH[1]: | ||
| co2_level = CO2_EXTREMELLY_HIGH[2] |
There was a problem hiding this comment.
| co2_level = CO2_EXTREMELLY_HIGH[2] | |
| co2_level = CO2_EXTREMELY_HIGH[2] |
|
It was decided to not include too many things like this in Home Assistant. I think we can still add this, and it's up to HA to include it or not. I think we need to do this a bit differently, we can actually fetch this information from the device itself, at least for Wave Plus/Radon/Mini. This can be really helpful for the new custom threshold feature in the Airthings app. Then it will reflect the same thresholds set by the user in the app. I need some time to think about this 🤔 I'll keep the PR open, and I'll revisit this when I have time. |
5 participants
It is very convenient to have the radon sensors that translate the numeric value into a string ("very low", "low", etc.). As an user, I not necessarily know what are reasonable ranges for the measurements and having these strings makes it easy to know at a glance if I should take action or not.
This is true for VOC and CO2 as well, but the library (and HA) do not have string states for them, only the numeric values. So this PR adds two new sensors (for devices that support it), which are string states for VOC and CO2. The ranges were obtained directly from the Airthings website (CO2, VOC). I copied them almost verbatim, except for the CO2 ranges 0-249 and 5000-39999, which are missing from the Airthings website (I just extrapolate to names that seemed reasonable). I want to make clear that this PR is not my personal endorsement for these ranges, I know nothing about what constitutes good and bad VOC and CO2 levels.
Also, I did not test the part that goes through
_get_service_characteristics(), as the pytests do not go through that function, I just followed what is done for the radon levels. If the maintainers can easily check that this is correct, that would be great.If this gets approved and merged, then I will work in the HA part to expose these them as new entities.