BME680 shows wrong ...
 
Notifications
Clear all

[Solved] BME680 shows wrong temperature  

Page 3 / 3
  RSS

tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
May 31, 2020 2:36 pm  

@kylegabriel Yikes! I just tried to upgrade Mycodo to the latest version and got this message when I clicked the Upgrade option.

 

Error 500: Internal Server Error

Something bad happened but it's probably not your fault. Letting the developers know about these issues is crucial to supporting Mycodo. Please submit a new issue on GitHub with the following error traceback (copy the entire traceback):

Error (Full Traceback):

Traceback (most recent call last):
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/app.py", line 2446, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/app.py", line 1951, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask_restx/api.py", line 639, in error_router
    return original_handler(e)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/app.py", line 1820, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/app.py", line 1949, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/app.py", line 1935, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask_login/utils.py", line 261, in decorated_view
    return func(*args, **kwargs)
  File "/home/pi/Mycodo/mycodo/mycodo_flask/routes_admin.py", line 379, in admin_upgrade
    is_internet=False)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/templating.py", line 140, in render_template
    ctx.app,
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/flask/templating.py", line 120, in _render
    rv = template.render(context)
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "/home/pi/Mycodo/mycodo/mycodo_flask/templates/admin/upgrade.html", line 2, in top-level template code
    {% set active_page = "upgrade" %}
  File "/home/pi/Mycodo/mycodo/mycodo_flask/templates/layout.html", line 322, in top-level template code
    {%- block body %}{% endblock -%}
  File "/home/pi/Mycodo/mycodo/mycodo_flask/templates/admin/upgrade.html", line 52, in block "body"
    {% elif current_latest_major_version != current_release.split('.')[0] and
  File "/home/pi/Mycodo/env/lib/python3.7/site-packages/jinja2/environment.py", line 471, in getattr
    return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'current_release' is undefined

ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
May 31, 2020 4:46 pm  

Well, for now I've moved the BME680 back to the original ARM i2c bus1, but I've also set the system baudrate to 10K (I guess the default is 100K) in order to work around the clock stretching issue.

Added the following to /boot/config.txt and rebooted. This seems to have helped others, so we'll see if it's more stable.

dtparam=i2c_arm_baudrate=10000

Unfortunately, all of my attempts at using a software i2c bus with the i2c-gpio module, and a variety of i2c_gpio_delay_us settings (from 1 to 8) all worked poorly, and seemed to lock up the BME680 *faster* than when it was on the original i2c-1 bus, shared with a couple of other devices!

I used 4.7K pull up resistors to for those other attempts to 3.3V, but others online have noted that the RPi built-in pull-up resistors for the ARM i2c bus1 pins are only 1.8K, so perhaps i may try 1.8K as well if I try a software i2c bus again?

Others have also suggested locking the VCU core frequency to get around the clock shift issue as well?

https://github.com/raspberrypi/firmware/issues/1308

https://github.com/raspberrypi/linux/issues/3381

 

In the meantime I'm just setting up a notification to bug me when the sensor goes offline, so I can either reboot the RPi, or possibly see if unloading/reloading the i2c kernel modules will be sufficient to get the sensor to wake up again.

https://www.raspberrypi.org/forums/viewtopic.php?p=539208


ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
May 31, 2020 11:29 pm  

minor update: So, it seems that when the BME680 (using the test2 driver that you sent along) is on the original i2c-1 bus, set to a max of 10,000baud and shared with other devices, it is much more stable than before. It sometimes experiences IOErrors, but usually recovers.

When it doesn't, for now, I've set up an alarm to run every couple of minutes and check for a "None" result for either temperature or humidity , and then email me a notification and reboot the system. (My attempts to have a shell script just stop the mycodo service, and then unload and reload the i2c kernel modules did not result in the BME680 sensor reappearing on the bus -- it seems a soft reboot of the Pi is necessary.)

Since then, it's been rebooting at roughly every 2 hours, and when it finishes booting up it experiences few/no errors for a while.

Curiously, the last couple of times that the system began experiencing errors with the BME680 that were not recoverable (and ultimately led to a notification and a reboot), occurred directly (within one second) after my vent fan timer (currently set to run the exhaust blower fan via one of the relays on the quad relay board for 60seconds, every 900seconds) was activated and then turned off -- in the log files below that corresponds to output command ba8cdaa0.

I thought that perhaps there would be errors caused while the blower fan was running for that 60 second on period, due to inductance on the i2c bus or something like that, but the logs don't seem to support that hypothesis. Also the majority of the time that the vent fan cycles on and off there are no associated errors with the bme680 (or any other i2c sensor) either.

Since the blower-off command would be run every 900+60=960 seconds currently, and the BME680 sensor was currently set to poll at a 15second period, I decided to change them both to prime numbers so they wouldn't coincide as often, to see if that improves stability at all.

Now the blower is on for 71seconds (971 is prime), and the BME680 is set to read every 19 seconds. If I'm right with regards to this crazy idea, then they shouldn't coincide for another 5+ hours ... We'll see.

2020-05-31 17:56:29,886 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - Temp: 23.21, Hum: 90.02, Press: None, Gas: None
2020-05-31 17:56:29,935 - DEBUG - mycodo.controllers.controller_input_36cdf1dd - Adding measurements to InfluxDB with ID 36cdf1dd-29e0-4c3b-884e-5b82f4cae2a1: {0: {'measurement': 'temperature', 'unit': 'C', 'value': 23.21, 'timestamp_utc': None}, 1: {'measurement': 'humidity', 'unit': 'percent', 'value': 90.02, 'timestamp_utc': None}}
2020-05-31 17:56:43,414 - DEBUG - mycodo.controllers.controller_output - output_on_off(ba8cdaa0-7c8e-4fba-bf6f-aaf21bf7ace7, off, 0.0, 0.0, 0.0, True)
2020-05-31 17:56:43,509 - DEBUG - mycodo.outputs.command_ba8cdaa0 - Output on/off off command returned: Status: 0, Output: 'b''', Error: 'None'
2020-05-31 17:56:44,867 - ERROR - mycodo.inputs.bme680_test_02_36cdf1dd - InputModule.get_measurement() method raised IOError: [Errno 121] Remote I/O error
Traceback (most recent call last):
File "/var/mycodo-root/mycodo/inputs/base_input.py", line 127, in read
self._measurements = self.get_measurement()
File "/home/pi/Mycodo/mycodo/inputs/custom_inputs/bme680_test_02.py", line 387, in get_measurement
if not self.sensor.get_sensor_data():
File "/var/mycodo-root/env/lib/python3.7/site-packages/bme680/__init__.py", line 241, in get_sensor_data

 

2020-05-31 19:50:10,873 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - Temp:
23.94, Hum: 90.506, Press: None, Gas: None
2020-05-31 19:50:10,921 - DEBUG - mycodo.controllers.controller_input_36cdf1dd -
Adding measurements to InfluxDB with ID 36cdf1dd-29e0-4c3b-884e-5b82f4cae2a1: {
0: {'measurement': 'temperature', 'unit': 'C', 'value': 23.94, 'timestamp_utc':
None}, 1: {'measurement': 'humidity', 'unit': 'percent', 'value': 90.506, 'times
tamp_utc': None}}
2020-05-31 19:50:24,752 - DEBUG - mycodo.controllers.controller_output - output_
on_off(ba8cdaa0-7c8e-4fba-bf6f-aaf21bf7ace7, off, 0.0, 0.0, 0.0, True)
2020-05-31 19:50:24,797 - DEBUG - mycodo.outputs.command_ba8cdaa0 - Output on/of
f off command returned: Status: 0, Output: 'b''', Error: 'None'
2020-05-31 19:50:25,859 - ERROR - mycodo.inputs.bme680_test_02_36cdf1dd - InputModule.get_measurement() method raised IOError: [Errno 121] Remote I/O error
Traceback (most recent call last):
File "/var/mycodo-root/mycodo/inputs/base_input.py", line 127, in read
self._measurements = self.get_measurement()
File "/home/pi/Mycodo/mycodo/inputs/custom_inputs/bme680_test_02.py", line 387, in get_measurement


ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
June 1, 2020 2:26 pm  

@kylegabriel Another minor update: Since making the timing change yesterday evening such that the vent fan relay is not turned off at the same time that a measurement is read from the bme680, and also setting the Raspberry Pi's i2c baud rate to 10,000 I haven't had further IOError events with the bme680.

I'm still not sure if the guilty party is the bme680 chip itself, the bme680 driver, the Sparkfun Quad relay board's i2c interface (or my crude shell script that just uses i2cget / i2cset commands to talk to it), some electrical interference caused by either relay4 being insufficiently isolated from the i2c bus or an inducted surge when the little 1.5Amp / 110VAC vent blower is turned off, or the Raspberry Pi's i2c clock stretching screwiness, or some combination of these factors.

Curiously, the humidifier being frequently cycled on and off via relay1 on the same quad relay board doesn't seem to cause the bme680 to lock up so far, however there are sometimes other bme680 errors in the logs that it seems to be able to recover from without intervention.

Unless you have other ideas, I was probably going to let it run for another day to see if this timing change makes a difference before changing anything.

I may try moving the ventilation blower to another relay (or even swapping the relay for the humidifier with the blower), or try moving the quad relay board to its own software i2c bus, since the bme680 seemed to behave okay for a week or so of testing when it was only itself and the SHT31D sharing the i2c bus and sitting on a breadboard, before I was able to add the quad relay board and actually start using Mycodo to control any outputs.

I wonder, if it *is* determined that the cause my problems is an combination of quirky i2c devices and unstable clock issues on the Pi and isn't purely an electrical isolation issue, then possibly other combinations of i2c devices that appear to be unstable or give intermittent IO errors could be worked around by delaying or scheduling i2c IO requests to not occur at the same time? Is there an option in Mycodo to not query a given i2c device if *any* other i2c input or output has been requested within the previous X seconds?

Thanks again for the huge help you've been, and for how much you've put into Mycodo! Once I can get some of these mushrooms grown I'll have to send you a box or buy you a beer or something!


ReplyQuote
Kyle Gabriel
(@kylegabriel)
Member Admin
Joined: 5 years ago
Posts: 219
June 3, 2020 12:03 am  

Glad to help. You seem like you have a lot of testing to figure out the issue. Since I don't have this sensor, I unfortunately can't experiment with you, but can provide software to test. Though, it looks like what I made works for a few of your configurations.

Mycodo Developer


ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
June 3, 2020 9:10 am  

@kylegabriel Yes -- absolutely lots of testing to do still. I really wish I had an oscilloscope handy or something to troubleshoot what's actually happening on the i2c bus during / before the lockups that happen!

After doing a ton of reading on i2c, I'm thinking of the following possible problems and solutions that I hope to implement today:

Poor electrical connections:

 - eliminate breadboard, solder sensors to minimal (<5") sections of 20AWG bell wire.

Stray capacitance between SDA and SCL lines:

 - avoid twisted pair wire (apparently it's 50pF/meter, and i2c specifies max of 400pF?), and maintain a 1" gap between sensor wires when possible

Signal attenuation and noisiness due to wire length + stray capacitance:

 - if I have an i2c device on another pair of i2c-gpio pins, and it has a wire length that I can't minimize, possibly try pull-up resistors closer to 1.8K instead of the common 4.7K, in order to decrease the rise time from a low->high state, especially since the RPi is a 3.3V system instead of a 5V system

EMI from either the SparkFun Quad Relay module and/or the load cycling from the attached blower fan:

 - move the relay module as far away from the other i2c modules as possible while minimizing sensor wire length, probably move it onto its own i2c bus, and keep the switched 110V load wiring further away and also perpendicular to any i2c wiring to minimize cross-talk

Other than that I'm not sure what else to do, until any of the other sensors or i2c muxes or relay boards finally show up in the mailbox. The COVID-19 catastrophe has really messed up controller + sensor availability and shipping times due to the ventilator issues!

 

Links for anyone else wanting to troubleshoot i2c quirkiness with "long distances" or EMI, etc:

https://raspberrypi.stackexchange.com/questions/7432/i2c-cable-length-and-type

https://forum.arduino.cc/index.php?topic=57604.15

http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors

https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/

https://www.analog.com/en/technical-articles/i2c-cabling.html#

 

https://www.hackster.io/chipmc/extend-the-reach-of-your-i2c-sensor-simply-and-inexpensively-ea6b53

 

https://reconvolution.blogspot.com/2014/11/memoirs-of-overgrown-i2c-bus.html


ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
June 4, 2020 1:56 pm  

Another update. I soldered both my SHT-31D and BME680 sensors to some bell wire and bypassed the breadboard, connected to the RPi's built-in I2C pins. I tried to put the Sparkfun Quad Relay board on its own separate software i2c bus, however it was unusable -- regardless of clock speeds (still using 4.7kohm pull-up resistors) an i2cdetect -y 3 would show the device 80% of the time but sometimes it would disappear and then return. All i2cget / i2cset commands send to the relay board when connected to the other i2c bus failed!  Since I was running out of time to troubleshoot I ended up putting it back on the original i2c bus, shared with the SHT31D and BME680 sensors for now.

I did manage to move the rearrange the wiring and boards to get the 110VAC side (and the relay board as well) as far away from the i2c sensors and wiring as possible, and also kept the i2c wiring perpendicular to 110VAC wiring, and also kept the I2C SDA / SCL lines separated by 1-2cm from each other as much as possible.

This combination of changes has resulted in no more I2C lockups (tested for the past 18 hours), no more IOError or ERROR entries in the mycodo.log file, and in general great stability.

That being said, the BME680 (using the TEST02 driver) *still* shows some errors, however the softreset() is able to correct them without having the restart the RPi.

Additionally, the handful of times that *do* occur, they appear to still roughly coincide with a relay output being triggered, though not the same one as previously. So it's not clear if it's EMI or the relay board to blame (or just a flaky/sensitive BME680 chip):

For now, I'll keep using the BME680, but I'll make sure to buy SHT31D sensors for future uses, since I don't want to keep chasing down problems with this chip if I don't have to. Also, I am definitely not interested in using the Sparkfun Quad Relay board for future projects either. Perhaps if I had both of those devices on separate i2c extenders and located a good distance from each other it would be a different situation.

log excerpts:

2020-06-04 01:00:08,226 - DEBUG - mycodo.controllers.controller_output - Output 51a63386-08e0-448b-8bea-d30ec7204241 (relay1 v2 Humidifier) on for 24.8 seconds.
2020-06-04 01:00:08,273 - DEBUG - mycodo.outputs.command_51a63386 - Output on/off on command returned: Status: 0, Output: 'b''', Error: 'None'
2020-06-04 01:00:15,465 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: sensor yielded 34.54 C, executing soft_reset() and remeasuring.
2020-06-04 01:00:15,562 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: soft_reset() executed, normal temperature measured: 19.83 C
2020-06-04 01:00:15,563 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - Temp: 19.83, Hum: 92.126, Press: None, Gas: None
2020-06-04 01:00:15,627 - DEBUG - mycodo.controllers.controller_input_36cdf1dd - Adding measurements to InfluxDB with ID 36cdf1dd-29e0-4c3b-884e-5b82f4cae2a1: {0: {'measurement': 'temperature', 'unit': 'C', 'value': 19.83, 'timestamp_utc': None}, 1: {'measurement': 'humidity', 'unit': 'percent', 'value': 92.126, 'timestamp_utc': None}}
--
2020-06-04 01:51:08,245 - DEBUG - mycodo.controllers.controller_output - Output 51a63386-08e0-448b-8bea-d30ec7204241 (relay1 v2 Humidifier) on for 35.2 seconds.
2020-06-04 01:51:08,293 - DEBUG - mycodo.outputs.command_51a63386 - Output on/off on command returned: Status: 0, Output: 'b''', Error: 'None'
2020-06-04 01:51:14,421 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: sensor yielded 34.54 C, executing soft_reset() and remeasuring.
2020-06-04 01:51:14,517 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: soft_reset() executed, normal temperature measured: 19.56 C
2020-06-04 01:51:14,517 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - Temp: 19.56, Hum: 91.761, Press: None, Gas: None
2020-06-04 01:51:14,543 - DEBUG - mycodo.controllers.controller_input_36cdf1dd - Adding measurements to InfluxDB with ID 36cdf1dd-29e0-4c3b-884e-5b82f4cae2a1: {0: {'measurement': 'temperature', 'unit': 'C', 'value': 19.56, 'timestamp_utc': None}, 1: {'measurement': 'humidity', 'unit': 'percent', 'value': 91.761, 'timestamp_utc': None}}
--
2020-06-04 02:58:38,299 - DEBUG - mycodo.controllers.controller_output - Output 51a63386-08e0-448b-8bea-d30ec7204241 (relay1 v2 Humidifier) on for 20.0 seconds.
2020-06-04 02:58:38,347 - DEBUG - mycodo.outputs.command_51a63386 - Output on/off on command returned: Status: 0, Output: 'b''', Error: 'None'
2020-06-04 02:58:41,404 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: sensor yielded 34.54 C, executing soft_reset() and remeasuring.
2020-06-04 02:58:41,501 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: soft_reset() executed, normal temperature measured: 19.29 C
2020-06-04 02:58:41,502 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - Temp: 19.29, Hum: 92.238, Press: None, Gas: None
2020-06-04 02:58:41,557 - DEBUG - mycodo.controllers.controller_input_36cdf1dd - Adding measurements to InfluxDB with ID 36cdf1dd-29e0-4c3b-884e-5b82f4cae2a1: {0: {'measurement': 'temperature', 'unit': 'C', 'value': 19.29, 'timestamp_utc': None}, 1: {'measurement': 'humidity', 'unit': 'percent', 'value': 92.238, 'timestamp_utc': None}}
--

ReplyQuote
not_5
(@not_5)
Eminent Member
Joined: 1 year ago
Posts: 22
June 6, 2020 12:00 pm  

@tico

I have been using a BME680 on mycodo for the last 6+ months.

I haven't really had any of the issues you reported.

I use a quad SSR board that switches 24VAC for an HVAC system.


ReplyQuote
not_5
(@not_5)
Eminent Member
Joined: 1 year ago
Posts: 22
June 6, 2020 12:23 pm  

I say I haven't really had any of the issues you had, until today when I swapped breadboards that had my i2c bus connected.

Now I'm getting measurements that don't make any sense... I think it's a hardware issue though because everything was working fine before.


ReplyQuote
tico
 tico
(@tico)
Eminent Member
Joined: 1 month ago
Posts: 44
June 14, 2020 4:24 pm  

@not_5 Yeah, definitely a hardware issue in my case. I finally received my SSR relay board in the mail, though I haven't been able to hook it up yet.

However, the last changes I made on my post on June 4th have made my system massively more stable. I haven't had a single lockup since then that required my script to reboot the Pi to restore the i2c bus. I still get a ton of errors on the bme680 sensor, however using @kylegabriel 's TEST 02 driver for the bme680 has allowed mycodo to issue soft resets that keep retrying and ultimately are successful in getting useful data.

For reference, from June 5th until today, I've had

0 "ERROR" log entries

0 "IOError" log entries

188 "TEST994" errors, such as:

2020-06-14 14:53:39,756 - DEBUG - mycodo.inputs.bme680_test_02_36cdf1dd - TEST994: soft_reset() executed, normal temperature measured: 21.5 C

 

I'm planning on continuing to move i2c devices as far from 110VAC switching devices as possible and adding any optical isolation possible as well. I just received an i2c mux board as well, so I may try to see if that helps somewhat isolate one troublesome i2c device from another sensitive i2c device. What kinds of errors have you been experiencing with your bme680?


ReplyQuote
not_5
(@not_5)
Eminent Member
Joined: 1 year ago
Posts: 22
June 14, 2020 10:08 pm  

The only issue I have is that my pressure reading is totally inaccurate and reading 999+ Pascal's.


ReplyQuote
Page 3 / 3