pimoroni / bme680-python

Python library for the BME680 gas, temperature, humidity and pressure sensor.
https://shop.pimoroni.com/products/bme680
MIT License
260 stars 93 forks source link

Temperature offset and humidity issue #20

Open giampiero7 opened 5 years ago

giampiero7 commented 5 years ago

Hi, Pull request #13 adds the possibility to set a temperature offset. In the first comment of the PR you can see that setting a positive offset results in an increased %RH, while a negative offset decreases the %RH. As far as I know, it should be the other way around, plus the difference should be much greater... Am I missing something? Thanks!

Gadgetoid commented 5 years ago

Since the offset is adjusting the raw temperature value used in the humidity compensation, I don't believe these results can be incorrect. But they're awfully unintuitive to rationalise.

It might stand to reason that a device sensing a warmer ambient temperature would compensate the %RH measurements up if we assume that the temperature variation has no affect on the raw value read by the sensor. Or perhaps even an inversely proportional relationship.

I'm not sure how the sensor fundamentally operates, but it doesn't seem crazy to suggest that warmer air holding more moisture would also yield less of that moisture to the sensor thus requiring a proportional increase in the %RH measurement to compensate.

giampiero7 commented 5 years ago

If that is a mere compensation and not a calculation of the RH based on temperature (which implies a decrease in RH when T increases), then, maybe, the offset should not be used in this calculation, since the compensation should in fact be based on the temperature measured by the sensor, not the "offsetted" one. What do you think? Hope I made myself clear...

Gadgetoid commented 5 years ago

That's a pretty good point- but I think we're still on the right track. The offset exists purely for compensating the humidity calculation- it serves no other purpose.

In many cases the temperature read by the sensor will be incorrect for the surrounding air temperature since it's directly heated by the Pi. If it's the temperature of the air that affects the reading, and not the temperature of the sensor itself then that would suggest this offset calculation is correct.

The discussion here https://github.com/pimoroni/bme680-python/issues/11 suggests that BOSCH recommend direct temperature compensation, and supply an API entry point for it. I'm reasonably comfortable our approach is correct.

If you want to offset only the temperature, you can just add a value to the converted output in degrees C and Humidity readings will remain unchanged.

giampiero7 commented 5 years ago

If it's the temperature of the air that affects the reading, and not the temperature of the sensor itself

This is what I'm not sure about and cannot find any information on... do you have any reference?

If that was the case, I would expect their library to include a user defined offset in the calculation too, as it is done here...

Gadgetoid commented 5 years ago

I believe that their library does not- but their unified sensor API does- it’s a separation of concerns that we can’t really implement since their sensor API is closed-source and can’t be ported to Python.

I believe temperature compensation isn’t strictly necessary for humidity and serves only to convert it from “absolute” humidity (the amount of moisture in the air) to “relative” humidity (what this humidity feels like to a person). IE: hot, humid air feels more humid than cold, humid air.

aluchuk commented 4 years ago

I have the Gravity: I2C BME680 from dfrobot and DHT22 both providing readings. Recently I tried calibrating humidity using a saturated salt solution, and had to move the breadboard around... needless to say some things were disconnected. After some troubleshooting the reading from BME680 are way off! I'm going trough Bosch literature and all the Google results, but keep coming back here. I hope some of you can offer a clue. This doesn't look like a simple offset.

here is the past 6 hours. AQ is off because I reduced initial burn-in. image

temp/hum was ok for the past 30 days, but went nuts just now: Screenshot from 2020-01-04 23-34-10