MallocArray
Support for batch-specific corrections
There is a post on the AirGradient blog called Low Readings from Plantower PMS5003, which explains that a few batches of Plantower sensors are miscalibrated (including mine). They provide some documentation about fixing the view in their own dashboard.
Has anyone else using this configuration dealt with this issue?
It seems that they have "correction formulae" for the values, I assume these could be applied somewhere to adjust the values that are fed into EPA formula - similar to how the correction algorithms are already used. It looks like each batch needs a different correction.
The blog post includes some good information on how to numerically correct the values. Is it possible to add support for correcting the values to this configuration?
I've been following the discussion in the Forums. The current ESPHome sensor entries don't return serial number as far as I know, so automatic selection of the corrections isn't likely, without updating the ESPHome code itself, which I don't have interest in doing myself.
It would be possible to either make additional packages that are copies of the PMS5003 package with the different corrections, or may see if I can come up with some !extend type lines that could be added ad-hoc to apply the corrections.
I've had all of my devices for quite awhile, so I'm not experiencing any of these issues, but the corrections should drastically change the sensor readings, so I should be able to tell if they are doing something to my numbers or not.
In short, I'm considering something, but no plans in the immediate future to work on it. If anyone else comes up with suitable files or extends, let me know and we'll look at adding them into the project.
I tried this myself, but I can't get it working. If I re-write the algorithm from the blog post, I get something like:
pm_2_5:
name: "PM 2.5"
id: pm_2_5
device_class: pm25 # Added to report properly to HomeKit
filters:
- lambda: |-
float scaling_factor = 0.03525;
calibrated_low <- scaling factor * id(pm_0_3um).state;
float calibrated;
if(calibrated_low < 31){
calibrated = calibrated_low;
}else{
calibrated = x;
}
if(calibrated < 0){
calibrated = 0;
}
/* Current EPA correction algorithm code here */
This doesn't work, and results in a circular dependency, since pm_0_3um isn't defined yet - it gets defined by the same platform: pmsx003 block. It's not possible to refer to the other values which will be defined in the same block (this is a similar issue to that described here which affects a different platform).
If you have any other ideas, I'd be happy to try them, and contribute something back if I get these working, but at this moment, I'm out of ideas.
@Mallonbacka I think the plan is going to need to be a new package file and in the main sensor entry, rename the PM2.5 entry to something ending with _raw and don't do any correction. Then make a second new entry named the same as the original where you can do the lambda and you'll have access to the latest pm0.3 data.
I believe that is essentially what is happening with the correction for the OpenAir sensors that are outdoors with the PMS5003T sensor, but I haven't had time to sit and dig in.
If you want to take a look at those packages/sensor_pms5003t.yaml
I had a go at this, using the numbers from the 20231218 batch. You can see the file here, I based it on the extended_life version, which I was using earlier. It seems to work for me so far.
Would anyone like to test this or double-check the logic manually? You can try it by swapping:
pm_2.5: github://MallocArray/airgradient_esphome/packages/sensor_pms5003_extended_life.yaml
for
pm_2.5: github://Mallonbacka/airgradient_esphome/packages/sensor_pms5003_batch_correction.yaml@batch-corrections
If it seems to suit anyone else, I'm happy to create more files (one per batch, I guess) and make a pull request so everything is together here.
Sorry about missing the fact that you had started on this @Mallonbacka I took a slightly different approach, letting the specific scaling factor and offsets be a substitution so we don't need individual files for each batch and hopefully that is still user friendly enough.
It might also be possible to make a separate package for the different batches, but only have the substitutions in it, so we don't have to fully repeat the whole formulas over and over.
Sounds like AirGradient is considering device-specific values, so we wouldn't want to have separate ones for every sensor produced, but having a single place where the values provided by AirGradient can be entered
No worries @MallocArray , I like your approach and I'm looking forward to being able to retire my temporary solution soon!