Outdoor Temperature and humidity reading correction

We are getting an arctic blast here in Texas and I wanted to correct the temperature and humidity readings on my O-1PP. I was getting a report of 40F (4.44C) when it was 32F (0C) and humidity was off quite a bit, 54% vs 95%. I got these comparative numbers from the local weather reports and an AccuRite weather sensor ( 3N1TXC) I have here at my home. The local weather reports and the AccuRite sensor reported near identical temperature and humidity.

So I attempted to apply the Correction formulas I found for both here on the Forums. I do know they are experimental but I am a tinker and so I started playing around with the code.

So I came up with the following modifications:



So far the information is still off but I am not sure why. Its 20F (-6.66C) and 95% humidity but the Out door Sensor is reporting 33.8F (1C) and 68% humidity. Initially after flashing my modified code the numbers were still very off but it seems to be correcting itself over time.

My question is, are my code modifications are correct? or Is their some sort of calibration for the temp and humidity I am not aware of?

I pulled the temperature corrections from here:

And the humidity one from here:

When we developed the two formula we did not have much low temperature data. So it is not correct in low temperatures like right now. But we are currently recalculating the formula with more data incl. data up to - 15 degrees Celcius. As soon as I have an updated algorithm I will let you know.

I think the temperature correction parameters from the blog should work in your case. Your reading was 4.44 °C, although 0 °C was expected.

(4.44 °C - 4.55 °C) / 0.83 = -0.13 °C

The corrected temperature is quite close to the expected one.

Did you convert your readings to Celsius? The parameters do not work in Fahrenheit.

I’m not sure what the variables in your code relate to. Have you tried…
…instead of…

What are my options here?

Just disregard the temperature feature of the product?

I put mine online last night. Its winter here and the temp has never even been close to the actual temp.
Even with software algo fixes, its still a “guess”.

I wouldn’t say the linear regression algorithm is a “guess” as it is based on comparing reference readings to the sensor readings and coming up with a calculation to compensate.

It is disappointing it has taken this long to get even a minor update to improve the reading. I know work is being done to get even better calculations, but with it being significantly off, the current algorithm from November would be better than what we have now

I got the final Fahrenheit values from the Dashboard after making the adjustments. So the only conversions done would have been on that page.

I’ll try and tweak the code to your suggestion later tonight.

Can you share what the actual temperature and what the measured temperature is (without correction)? I would like to look into that. It is unexpected if the AirGradient temp is not even close to the actual temp.

I converted the correction parameter for Fahrenheit in case you want to try:

(Temp(AirGradient) - 14.5 °F) / 0.83 = Temp(corrected)

Currently my AirGradient on a covered porch on a cloudy day reads 50f.

The cheapo sensor we have used for years directly next to it reads 43. Weather Underground says 40. Accuweather is at 41.

Applying Siriel’s formula would give an value of 42.8F for the AirGradient. Pretty much matching your cheapo sensor.

(50F - 14.5F)/.83 = 42.77F

The value of data1.AMB_TMP is multiplied by ten to allow for a decimal later. That is done later in the postToServer function.

Adjust code to subtract 45.5 instead of 4.55.


Thanks @Achim_AirGradient / @Siriel_AirGradient
I flashed my device with this new code. I’ll watch and report back if anything seems amiss.

I am seeing this as well 35F outside and reading 42.08F

Using the compensation algorithm mentioned in this thread, that would get you 33.2 F which is much closer

This could be near impossible for anyone that hasn’t coded or messed with arduinos.

After the compensation I am still running about 3 degrees warmer than all surrounding neighbors listed on weather underground.

We will include this in the default firmware and are also working on an improved algorithm especially for lower temperartures. I expect I can post it here next week.


I haven’t been able to test out the suggested modifications yet but I’m glad to hear things are still moving along. I hopefully can make the changes on Saturday before another cold front comes in.

I just published an update to my ESPHome configs that adds the compensation for both temperature and humidity for the Outdoor models.

@Achim_AirGradient Does the formula work for both the model with dual PMS5003T sensors and the one with a single one, or is the head load inside of the enclosure different?

Yes. We only see very small deviations between the two models.

Anika, our science lead went through around 300.000 temperature data points (AirGradient and reference stations) ranging from -28C to +37C -so covering a very wide range.

There are two different formulas needed for temperatures below 10C and above 10C as the curve across the whole range of temperatures is not completely linear:

The formulas are the following:

Below 10C: raw*1.327 - 6.738
Above 10C: raw*1.181 - 5.113

As a result we get a well corrected temperature curve as below:

The data points you see on the higher temperatures that are further away from the red line is where the AirGradient monitor is exposed to direct sunlight. So it’s important that it is installed in the shadow.

This is just the pre-information. There will be a more detailed blog post with more background information following but I wanted to publish the formula already as I know that people waiting for this.


For those using ESPHome, those formulas look like this:

      - lambda: !lambda |-
          if (x < 10.0) return (x * 1.327) - 6.738;
          return (x * 1.181) - 5.113;

I assumed that ‘above’ meant ‘equal to or above’.

1 Like