Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
puterboy opened this issue Feb 11, 2024 · 13 comments · Fixed by #71

Comments

@puterboy
Copy link

puterboy commented Feb 11, 2024

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
Copy link
Author

puterboy commented Feb 11, 2024

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 puterboy changed the title v3.4.12 always returns wrong/nonsenical, static number for temperature, humidity, and pressure. Gas also seems wrong v3.4.12 always returns wrong/nonsenical, static number for temperature, humidity, and pressure on first reading. Gas also seems wrong Feb 11, 2024
@puterboy
Copy link
Author

puterboy commented Mar 5, 2024

Any ideas here?

@shamlian
Copy link

shamlian commented Mar 24, 2024

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link

DL3KB commented Apr 2, 2024

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
Copy link
Author

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

@DL3KB
Copy link

DL3KB commented Apr 14, 2024

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

@FoamyGuy
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

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:

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'

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:

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.

@puterboy
Copy link
Author

puterboy commented Jun 9, 2024

Fixed for me! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants