Add support for PM4 Density

[lyricnz]

At the moment we have support for µg/m³ of PM1, PM2.5 and PM10. I would like to add support for PM4, which is as-provided by the SEN55 sensor, which quotes "Particle size range PM1.0, PM2.5, PM4 and PM10"
https://sensirion.com/products/catalog/SEN55/
https://sensirion.com/media/documents/6791EFA0/62A1F68F/Sensirion_Datasheet_Environmental_Node_SEN5x.pdf

This sensor is used in, for example, the Apollo Automation AIR-1 https://shop.apolloautomation.cloud/products/air-1 (I am just a customer, nothing to do with the company). I would expect this sensor to gain more usage over time.

I have raised PR for this at home-assistant/core#112867 but this requires consensus here.

Thanks.

[MartinHjelmare]

How many integrations would be able to leverage the new device class? Please list the ones you find.

We only add a new device class when there's a common enough use case among our integrations.

[lyricnz]

I only found one explicit mention of pm4 in the codebase
https://github.com/home-assistant/core/blob/dev/homeassistant/components/nam/sensor.py#L302
which relates to a "nettigo air monitor" (NAM) which also uses a (different) Sensiron sensor.
But there may be others like the AIR-1 that work via esphome and may quietly skip the device-class.

But yes, this kind of sensor is fairly new to consumer-space, but there are a few devices and sensors around

• https://infrasensing.com/sensors/sensor_particle.asp
• https://kunakair.com/air-quality-monitor/ - https://kunakair.com/smart-cartridges/particulate-matter/
• https://www.amazon.com.au/Temtop-PMD-351-Handheld-Professional/dp/B0816GKF1F/
• https://nettigo.eu/products/sensirion-sps30-dust-sensor-pm1-pm2-5-pm4-pm10-uart-i2c
  Which typically integrate via modbus or similar/

FWIW, the actual threshold for respiration is pm4, especially silica, but until now scientists appear to have been using pm2.5 as a proxy. Engineered Stone has actually just been banned in my country (AU) due to health risks of silica dust.

• https://www.qld.gov.au/environment/management/monitoring/air/air-programs/other-dust-and-particulates/oxenford/community-meeting-questions-answered
• https://www.researchgate.net/figure/Levels-of-particulate-matter-of-different-sizes-PM1-PM25-PM4-and-PM10-per-each_fig2_351081029
• https://www.tandfonline.com/doi/pdf/10.3155/1047-3289.59.11.1287

[MartinHjelmare]

We need about a handful of integrations that can leverage the device class before we add a new one.

[bharvey88]

+1 requested to add this for any integration wanting to use a sen55 sensor https://sensirion.com/products/catalog/SEN55/

[bharvey88]

tasmota integration using sen55 also has this issue per: https://discord.com/channels/330944238910963714/672220541343760384/1252390040479207528 (home assistant discord link)

[dphotograph]

I run into this "Issue" by use the SEN55 Sensor on an Tasmota (Tasmota 14.1.0 (release-tasmota32)) PM1, PM2.5, PM10 States are have the right state "style" only the PM4 State are missing the right assignment

for example:
SEN5X PM2.5 1,8 µg/m³
SEN5X PM4 1.8

only PM4 is without "µg/m³"

[amaurylam]

The EcoWitt HA Core integration also misses PM4 support to properly fix home-assistant/core#125003

[frenck]

Thanks for creating an architectural proposal; we've decided not to include a device class for this purpose just yet.

While there is clearly potential, considering the listed devices, we currently do not have enough core integrations in our repository that could use this right now (besides some generic protocol ones).

Going to close this one up for now.

../Frenck

[bharvey88]

All we're asking is to support a known-quality-sensor and add like a handful of lines code to core for pm4 support. This is extremely disappointing to say the least - This issue is not resolved it's been ignored.

[frenck]

Sorry to hear you feel that way. That said, your "extremely disappointing" wording seems a bit unnecessarily strong for a device class.

We don't want to add or maintain features in Home Assistant that aren't being utilized by integrations in our code base.

This issue is not resolved it's been ignored.

What is the issue exactly? Because that isn't raised by this architectural proposal...

[bharvey88]

The architectural proposal was pointed to by @MartinHjelmare when he closed home-assistant/core#112867 - i believe the actual "issue" is that because the device class does not exist, the pm4 data cannot be graphed alongside the other pm1/2.5/10 data - I am not sure what other uses this would have.

My argument is simple: if pm1/2.5/10 are supported, and pm4 is a known useful metric, then it should be supported.

edit: what's extremely disappointing is this whole process - not your refusal to complete the request.

[bharvey88]

I've spoke to bdraco and missy about this to try and understand the logic behind why this discussion is even necessary - and i was told in so many words that basically it needs to be supported and therefore needs to have enough "usefulness" to therefore be supported. However, given how many things are already in core, i cannot believe you all are unwilling to do such a small change that wouldn't have any foreseeable negative impact on... anything.

[frenck]

edit: what's extremely disappointing is this whole process - not your refusal to complete the request.

This is just disrespectful IMHO. We've followed the process, what is the case here: You didn't like the answer.

The architectural proposal was pointed to by @MartinHjelmare when he closed home-assistant/core#112867

Correct, which is part of the correct process. It has been considered.

actual "issue" is that because the device class does not exist

Device classes aren't mandatory for any function. Can you please provide a description of the actual issue you are trying to raise?

the pm4 data cannot be graphed alongside the other pm1/2.5/10 data - I am not sure what other uses this would have.

That is not related to any device class. I think you are mixing things up with state classes.

My argument is simple: if pm1/2.5/10 are supported, and pm4 is a known useful metric, then it should be supported.

Sure, if there is a wider use case, we want to support it. But, as the discussion above showed, there is potential, but no wider use case in our codebase at this moment in time.

I've spoke to bdraco and missy about this to try and understand the logic behind why this discussion is even necessary -

That this process is required is documented, you don't have to agree, that is fine. It is here to curate our core foundation of Home Assistant.

This proposal (and the linked PR) changes part of our core codebase (entity model) which we require architectural approval for.

However, given how many things are already in core, i cannot believe you all are unwilling to do such a small change that wouldn't have any foreseeable negative impact on... anything.

Again, we are not unwilling to add this once there is a broader use case. For now, there is not. We are happy to re-evaluate when there is.

../Frenck