Implement Correction formula for PM2.5

airgradienthq commented 3 months ago

This applies to all models (ONE and Open Air).

We decided on (a rather complex) compensation formula for PM2.5. This will also be implemented on the firmware (only to show on the display) but the same formula should be applied in HA.

Formula and background information can be seen here: https://github.com/airgradienthq/arduino/issues/182

joostlek commented 3 months ago

Since the device already calculates this, would it make sense to have the device return this instead? This also allows for change in the future without a need for change on the integration side. This would also allow other integration platforms like the openhab to use the same logic without code change.

airgradienthq commented 3 months ago

The algorithms might change in the future and having it on the receiving end makes it easier to deal with different firmware versions and ensures that all devices are treated with the same algorithm.

joostlek commented 3 months ago

But that also means it's harder to use a different algorithm when using a different sensor type on a different device in the future.

Not saying I wouldn't do the change, but I'm just pushing back as I believe it should exist in the device firmware instead of the consumer. I mean if you are fine with the consequences that can occur (differences when using new firmware, old HA or new HA, old firmware), I am also fine with it.

airgradienthq commented 3 months ago

We had originally the same idea and implemented the temperature correction on the firmware but then our whole science team got into issues because it wasn't clear anymore which monitors delivered raw data and which not etc etc. so they couldn't do their analytics anymore. Then we rolled back that change.

Additionally for some of the pollutants like PM there might be several different algorithms in future. So having the raw data coming in gives a lot more possibilities.

So on first thought yes it makes sense doing it on the fw side but then we realized it's actually a bad idea and has a lot of unintended consequences.

joostlek commented 3 months ago

Would adding pm25Raw as an attribute help in that use case? Just like with the tvoc and Nox?

airgradienthq commented 3 months ago

Then how do you call the non raw one? You would need to keep track on which firmware version has which algorithm and send that information together with the device or have some mapping ...

We really spend a lot of time thinking this through.

There is no ideal solution but we made a decision some weeks ago and implemented that approach already on our dashboard. So we should keep the same approach for other platforms otherwise things will get really messy.

The approach that we decided on is that we transfer raw data and do the conversions on the receiving end. I know it's not 100% ideal but we got into real troubles with the other one.

joostlek commented 3 months ago

{
    "pm25": 12,
    "pm25Raw": 13,
    ...
}

It could look something like this. This way you can change the algorithm of the pm25 without a change in any consumer.

But hey, you're the experts and no doubt you thought this through. I'm just trying to challenge the requirement :).

airgradienthq commented 3 months ago

@joostlek I got this completely wrong. I will close this issue and make a new one.

airgradienthq / python-airgradient

Implement Correction formula for PM2.5 #110