Toggle to apply temp/humidity compensations?

[ex-nerd]

After flashing to this firmware, I noticed that the humidity readings on my O-1PPT outdoor model have been very off. It's currently reading 84% when it should be around 60% based on local weather service and a couple other devices I have. Reversing the math for the corrected formula gets ~61% which suggests that at least my particular unit should not be using the x * 1.259 + 7.34 compensation.

I notice that there is an "uncorrected" version of the config, but not one for extended life or for the second sensor. Would it make sense to add a configurable option to disable this calculation?

I also wonder if this is related to the "extended life" config variation, and have posted about it here in the AirGradient forum.

[MallocArray]

It is possible that by turning the fan off, the environment inside of the sensor is no longer stable, so when it does spin back up and takes a reading, it is no longer representative of the outdoor conditions.

I remember when extending the sensor reading time was first discussed, some people proposed something like spinning down for 3 minutes, then spinning up for 20 seconds before taking a reading. ESPHome doesn't support this with the native integration, and I have no desire to write a custom module.

There is a current PR for limiting the humidity reading to a max of 100, I assume because it went over 100 for them and could be related to you. I'm looking at either a clamp filter at 100, or adjust the lambda, weighing ease of readability and efficiency.

On top of all of this, AirGradient made a change in the latest firmware so the standard Temp/Hum reading is the raw reading from the device and created a new API parameter for the corrected value but they plan on doing the corrections in the dashboard site and not on the device, so both values would just be the raw readings with their standard firmware.

So I have to decide how to handle that. Either remove the algorithm from the current sensor IDs that have been used for a long time now and add a new one for the compensated value and everyone would have to update their sensors in HA. Or I can keep the sensors as they are now so the current temp/hum are the most accurate they can be, and create a second sensor that is the raw reading by reversing the algorithm. I need to read up on what a copy sensor does and if that copies the stock values, or a copy of any lambdas I'm applying.

And all of this only applies to the Outdoor model now, but could later apply to indoor, so more fragmentations to deal with if I want to keep API compatibility with their dashboard.

[ex-nerd]

I just switched my device over to the more frequent PM reading config and the recorded humidity levels have dropped from ~85% to ~68% in 20 minutes and it still seems to be slowly dropping. Weather.com says the nearby levels are 66%, so this suggests that the air movement (and heat?) from the PM sensor definitely contributes to the difference in readings.

Update: after about an hour of uptime, things seem to be stabilizing right around the expected 66%.

[jonahwh]

Not to take this issue too off topic, but I'm also having apparent humidity accuracy issues, comparing to local weather stations. The strange thing I'm seeing is that the compensated value is more correct when the humidity is high at night, but far off during the day when humidity is lower

Compare this chart of humidity today from local weather reports

To what the AirGradient has reported today.

Notice from midnight to about 6am, the AirGradient reported ~83% RH, which was more or less in line with the weather reports (87% => 94%), but during the day, weather reports show the RH dropping to just above 40%, but the AirGradient sensor never registered a value below 65%

Reversing the compensation math for the "daytime" values gets the reading more close to what reality appears to be, but would result in too LOW humidity during the evening/early morning.

(This is a PMS5003T, running the standard config - not the extended life one)

[MallocArray]

I see you aren't using the extended life option, so that rules out that.

The compensation algorithms came from AirGradient's research.

You could change your package to sensor_pms5003t_uncorrected.yaml which will return the standard readings from the sensor if you feel they are more accurate in your installation.

With the new firmware from AirGradient and latest HomeAssistant versions, you could try using their stock firmware and still have a new integration with HA to see if the data continues to be off. Possible I don't have something correct, but it should be the same algorithm they are using.