Temperature offset and humidity issue about bme680-python HOT 6 OPEN

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.

from bme680-python.

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...

from bme680-python.

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 #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.

from bme680-python.

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...

from bme680-python.

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.

from bme680-python.

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.

temp/hum was ok for the past 30 days, but went nuts just now:

from bme680-python.