Weatherhat discrepancies in temperature values

Hello, I am new here and I just installed the weatherhat on my Pi4B (4GB, Bullseye full OSD). When I got the system up and running, I saw that the readings were very different from my Oregon Scientific device. After some testing and reading, I found out that there was a temperature_offset value, and that fixed the temperature issue.

Now I am putting together a script to read the values programmatically and I am again finding a discrepancy in temperature. With an offset of -15 degrees in, the LCD screen displays the right temperature as 22-23 degrees, however, the temperature value produced by the follwoing code is too low by about the offset value:

What am I doing wrong?

#test get_dew_point(humidity,temperature)
Humidity: {sensor.humidity:0.2f} %
Temperature offset: {sensor.temperature_offset}
Temperature: {sensor.temperature:0.2f} *C
Dew point: {DEWPOINT}

and the output is:
Humidity: 84.33 %
Temperature offset: -7.5
Temperature: 15.81 *C
Dew point: 12.67376442895129

I have seen this “temperature offset” stuff many times on the forums and I am really scratching my head about that. There is nothing in the datasheet that hints that there is a something like a fixed temperature offset. In contrast, if operated correctly, the BME280 is within ± 1°C.

Now the Pi4 produces a lot of heat and is therefore not really suitable as a basis for weather monitoring. And having an offset of -7.5 to -15 clearly shows that you are far away from any sensible value. Depending on what you currently do on your Pi4 you will have random results.

Thanks for your response I must say it makes me scratch my head too because:

  1. the offset does exist, it is used in and is intended to compensate for environmental factors. So if the datasheet doesn’t have that info, it may need to be updated. you can easily check with Python too:
    import time
    import weatherhat

sensor = weatherhat.WeatherHAT()

for attr in dir(sensor):
print(f"(attr): {getattr(sensor, attr)"}

  1. I don’t think that the results should be random as the heat produced by the pi4 is relatively constant and the website advises it is compatible with all 40-pin Pi boards.

I have nevertheless mounted the hat on a spare Pi zero W and while the offset only needs to be -7.5 to produce a valid output on the Hat using, I still have the same discrepancy with the code I posted earlier, it displays 15.81 degrees while it should be around 21, actually, it produces the same result even with an offset of zero, there has to be something wrong in my code to display the temperature. The script also displays 15.81 for temperature, so is doing something different but I cannot determine what it is as my python skills are close to non-existent and that code is a lot more intricate.

PS I tried to open the datasheet from the Pimoroni web site but the link is broken.

OK, I found a way to get a correct reading: if the update interval line is inside a while True loop, the temperature does display correctly. If that is how it is supposed to work, I would file that as a bug because even outside the loop, it should at least give me one correct reading and not a fixed 15.81degrees reading. Is there another way to get a single reading from the BME280 chip?

I’ll keep experimenting but if someone has a code snippet to get a single reading (not using a loop), please do share it.

So the issue was that the update interval needs to be right before the print command. Without an update interval, I get zero-value readings, with an interval set too early in the code, I get a fixed-value wrong reading, with the update interval set right before the print command, I get a correct reading - still not identical to (about 1.5 higher) but I can live with that.

I’ve found that more often than not, I get weird reading with the first read. Then its all good on successive reads. This is with a BME 280 or 680 thats just being used to display values on an LCD in real time. I do track the min and max temperature, and it messes that up on start up.
To get around it I do a read (or two) above my while true loop.

temperature, pressure, humidity, gas, status, _, _ =
temperature, pressure, humidity, gas, status, _, _ =

After that, the first reading that matters in my while true is a good data.

That temperature offset is just some code added to try and mitigate the effects of heat creep from the Pi or Pico. It just subtracts the offset value from the actual reading.

corrected_temperature = temperature - TEMPERATURE_OFFSET

I have not found corrected_temperature in the object attributes, are you sure it exists?

To be precise, it’s temperature + offset, because the offset is a negative value

I saw that too, but if you put the update interval just before the print command, the reading is good first shot

The temperature offset is just something invented by Pimoroni to fix a problem that was created by bad design. Put your stuff into a refrigerator and you will see it won’t help you to get reliable readings. The offset in the fridge will have to be different than the offset at room-temperature.

The datasheet needs no fixing, because it fully describes the sensor and it’s capabilities.

Don’t get me wrong: the weatherhat is a nice piece of hardware which helps you to learn about programming sensors and the display (all in one, no wiring). But it is no basis for serious weather monitoring.

I pulled what I posted above from the Pico Enviro+ code. It may be worded slightly different depending on who at Pimoroni wrote the example code. ;)
I don’t use the offset, I remove that code. I try as best I can to mitigate the heat transfer issue from the Pi or Pico. Most of my builds are clones of the original product. Same hardware but different layout. My BME 280 / 680 is on a QWICC cable, or mounted remotely away from the Pi or Pico.

My Pico Enviro+ has a Proto board between the Pico and Enviro+. It has a stacking header soldered to it. Pico on one side Enviro+ on the other.

You could add a second BME 280, or a BME680. You cut the jumper to change the i2c address from 0x76 to 0x77, and edit your code to read the one on 0x77. Plug it in with a QWICC cable.