v3.4.12 always returns wrong/nonsenical, static number for temperature, humidity, and pressure on first reading. Gas also seems wrong

[puterboy]

Using v3.4.7 of adafruit_bme680.py, I always get reaonable values for: temperature, humidity, pressure and gas.
But v3.4.12 returns non-sensical values for all the above parameters.
Specifically,

1. Temperature is fixed at a high value regardless of actual (indoor) temperature -- typically > 90 degF while actual temperature is in the high 60's
2. Humidity is fixed either at 100% or some other number in the high 90's (even though inside humidity is in the low 30's)
3. Pressure is nonsensical, typically 19-21 inHg
4. Gas varies but is way off

I have tried this with 4 different BME680 modules on several different Raspberry PI's (RPi4, RPi5)

• All work find under 3.4.7
• All fail as above under 3.4.12

The only difference in both the calling routine and in the Python3 setup is the version of adafruit_bme680.py
Using a fresh venv install with pip doesn't solve the problem.

Reverting the v.3.4.7 version of adafruit_bme680.py restores sane values...

[puterboy]

Interestingly, bme680_simpletest.py also seems to show some evidence of this bug.
Under, v.3.4.12, the first output is wildly wrong but then the subsequent outputs (every 1 second) are more rational:

Temperature: 27.6 C
Gas: 85873 ohm
Humidity: 100.0 %
Pressure: 718.270 hPa
Altitude = 2809.61 meters

Temperature: 14.7 C
Gas: 29008 ohm
Humidity: 38.9 %
Pressure: 1005.879 hPa
Altitude = 61.55 meters

Temperature: 14.7 C
Gas: 35313 ohm
Humidity: 38.9 %
Pressure: 1005.909 hPa
Altitude = 61.30 meters

Again under v.3.4.7 everything is reasonable -- even the first reading.

If I modify my routine, to throwaway the first reading of every sensor value, I too get reasonable values on each subsequent read.
Wondering whether v.3.4.12 reads the sensor the first time before sensor is initiatlized/stabilized?

[puterboy]

Any ideas here?

[shamlian]

I can reproduce this, using a BME688. My first reading is always incorrect -- though in my case, the readings are slightly different:

Temperature: 28.0 C
Gas: 56201 ohm
Humidity: 100.0 %
Pressure: 744.713 hPa

After this, subsequent readings are consistent and correct.

[puterboy]

The same thing happens by the way in the Adafruit Arduino version of BME680 -- ver 2.0.2 works but 2.0.4 gives the wrong reading the first time.

[tekktrik]

Do you still get this for the current version (3.7.4)? Still, as far as I can tell with the library, no functional changes were made to the code from 3.4.6 to 3.4.12, so its curious that the versions you mentioned working and not working are like that. Can you also please add information regarding your CircuitPython board and version so that others can try to further replicate? The text at the start of the REPL would be most helpful.

[puterboy]

Do you still get this for the current version (3.7.4)? Still, as far as I can tell with the library, no functional changes were made to the code from 3.4.6 to 3.4.12, so its curious that the versions you mentioned working and not working are like that. Can you also please add information regarding your CircuitPython board and version so that others can try to further replicate? The text at the start of the REPL would be most helpful.

My apologies -- I was a bit "dyslexic" in recording the versions.
3.4.6 works fine
3.7.4 (not 3.4.7) is the one that fails -- so it is the latest version that is creating the problems.

For example:
[3.4.6]

Temperature: 65.733°F [18.741°C]
Humidity: 33.75%
Pressure: 30.31 inHg [1026.33 hPa]
Gas: 2.45 KOhms

[3.7.4]

Temperature: 90.494°F [32.497°C]
Humidity: 100.00%
Pressure: 21.21 inHg [718.27 hPa]
Gas: 47.26 KOhms

Given that I am sitting perfectly dry and comfortably wearing a sweater in a heated home at sea level with freezing temperature outside, the 3.4.6 version is clearly more reasonable than the 3.7.4 :)

[DL3KB]

I have the same issue. The humdidity and temperature values do not change. It works fine with other libraries. I also tested the BME280 and BMP280 with their respective libraries, they all have the same issue.

[puterboy]

Are any of the devs paying attention here? This seems like a major "bug"

[DL3KB]

They just have to rollback the releases. It's pretty annoying spending hours on finding this bug when you expecting a hardware malfunction.

[FoamyGuy]

@DL3KB , @puterboy If you can, please post information about which specific microcontroller and version of Circuitpython (the core circuitpython install, not the library version) was used during your testing?

Also can you confirm which version of the library you've used that is working correctly for you? In some of the prior comments the version 3.4.6 was mentioned but I wanted to double check if that is what you meant. Version 3.4.6 is over two years old (https://github.com/adafruit/Adafruit_CircuitPython_BME680/releases/tag/3.4.6), and there have been many other released versions inbetween then and now.

Right now the current release is 3.7.4, and the previous version before this was 3.7.3. Was anyone's testing on that version?

[FoamyGuy]

I've tested several released versions and narrowed this issue down further.

Version 3.4.13 is the most recent release that does not seem to be affected by this issue. With that version the first reading appears to be a normal dynamic reading of the environment rather than the static value for the first reading.

With version 3.5.0 and all newer releases the first reading seems to always return the same value which doesn't coorelate to the environment it's in. After that first reading then subsequent ones seem to work fine as far as I can tell.

I will try to figure out what the root cause within that change could be and see if we can revert or modify it further to get back to a state where the first reading isn't wrong.

[FoamyGuy]

I've pulled at this thread a bit further and think I've found the root cause, but don't necessarily have the expertise in this type of driver or these sensors generally to know if what I found is accurate.

One of the changes from 3.5.0 was adding a new step inside of the init() function here:

Adafruit_CircuitPython_BME680/adafruit_bme680.py

Line 224 in 41fca05

self.set_gas_heater(320, 150) # heater 320 deg C for 150 msec

Inside of set_gas_heater() it calls _set_heatr_conf() https://github.com/adafruit/Adafruit_CircuitPython_BME680/blob/main/adafruit_bme680.py#L469

_set_heatr_conf() is a new function which was also added with 3.5.0. All of the changes from that release were adaptations of Bosch published code from here https://github.com/boschsensortec/BME68x_SensorAPI/blob/master/bme68x.c if I understand the chain of comments in #61 correctly.

At the end of _set_heatr_conf() it sets the op mode to 'forced'

Adafruit_CircuitPython_BME680/adafruit_bme680.py

Line 513 in 41fca05

self._set_op_mode(_BME68X_FORCED_MODE)

In all honesty I don't really know what that means, but looking at the referenced Bosch code I don't see anything that looks analagous to that inside of it's set_heatr_conf function. The code here: https://github.com/boschsensortec/BME68x_SensorAPI/blob/80ea120a8b8ac987d7d79eb68a9ed796736be845/bme68x.c#L672 is basically the C version of the writes which occur here:

Adafruit_CircuitPython_BME680/adafruit_bme680.py

Line 510 in 41fca05

self._write(_BME68X_REG_CTRL_GAS_1, [ctrl_gas_data_1])

in our python implementation.

I've found that if I remove the call to self._set_op_mode(_BME68X_FORCED_MODE) from here then the first reading goes back to working correctly from what I can tell. With that removed I get real looking values that do depend on the environment and are not the same static values each time I run the code like I see with the currently released version.

I can PR that change, but it would probably be good to get some wider testing done and if possible have someone with more familiarity with this module / driver take a look.