Add support for BME680 #2295
Add support for BME680 #2295
Conversation
code/espurna/sensors/BME680Sensor.h
Outdated
| // The maximum allowed time between two `bsec_sensor_control` calls depends on | ||
| // configuration profile `bsec_config_iaq` below. With these settings, the | ||
| // maximum allowed time is 3s. | ||
| #define SENSOR_READ_INTERVAL 1 |
There was a problem hiding this comment.
@mcspr I don't really like this approach.. do you have better suggestions?
There was a problem hiding this comment.
'Maximum allowed time' meaning we must call it at least every 3 seconds?
There is always tick(), which gets called independently of the reading and can be polled via millis() - last >= timeout_milliseconds / micros() - last >= timeout_microseconds
There was a problem hiding this comment.
Correct. In Low Power (LP) mode, which is the default, a reading must happen at least every 3 seconds.
tick() is exactly what I was looking for. I'll make this modification.
There was a problem hiding this comment.
https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf
4.1 BSEC Software
...
Low power (LP) mode that is designed for interactive applications where the indoor-air-quality is tracked and
observed at a higher update rate of 3 seconds with a current consumption of <1 mA
Technically, we just loose last 3 seconds or readings if we don't? It is still useful though, as we don't have any new data with less than 3 seconds.
There was a problem hiding this comment.
From my observations, if we don't call within 3 seconds, the sensor can never calibrate. The default was at 6 seconds and the readings were stalled. I believe it's part of the algorithm.
ruimarinho
force-pushed
the
enhancement/bme680
branch
2 times, most recently
from
3ee3892
to
f811b36
Compare
|
@mcspr can you help me understand why the web interface is crashing? |
Check out the stack trace? platformio.ini needs espressif8266@2.5.3 as selected platform and you can use exception monitor via serial: Or decode manually from text file: |
|
I did that yes, but unfortunately I can’t figure out the issue. It was in ws.cpp so most likely related to the magnitude topic value. I’ll see if I can paste something here. |
|
Can you try to compile locally and see if it loads for you, even if you don’t have the sensor? Maybe it’s a stupid mistake you can quickly spot :) |
|
I have built it locally, but not seeing the issue. And not really something obvious in the code... magnitude list seems in bounds. |
|
Are you building using latest Core version? |
|
I’m using the default version as defined on platformio.ini to avoid any customization. Your suggestions on the ld script are way beyond my comfort zone, but the concept looks amazing.. is there a way I can help given my hobbyist knowledge of embedded systems? :) |
|
Probably OOM, we are still using espasyncwebserver which buffers large chunks of memory on requests. I tried removing isSensorOk() calls and loaded up error-less sensor... but it still works. Also note about the script - everything is included with PlatformIO, as they ship pyelftools and toolchain is already there, too. We can still use extra script. |
Will give it a try. Does it have more free memory?
I don't think pyelftools is available for me. I had to add it to requirements.txt locally. At least when using platform.io via home-brew on macOS.
Understood. What would they have to change on their side to default to ROM instead? |
4KB more, at least. You may also want to try to change lwip LOW_MEMORY setting in the .ini when using newer Core version. How much memory does it have though? |
|
@mcspr quick update:
|
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
f811b36
to
35a92d9
Compare
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
35a92d9
to
2540bb2
Compare
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
2540bb2
to
786eee9
Compare
|
@mcspr with |
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
aa98eb0
to
dc259b7
Compare
|
I was about to submit the ticket myself :-) the community manager marked as resolved, so we might get some traction there! Update: sent them an email directly as well just to reinforce the message. |
ruimarinho
force-pushed
the
enhancement/bme680
branch
3 times, most recently
from
5438a64
to
07932de
Compare
You would fail Travis test then, it also builds bme680_support with both. So it's either disabling it or ignoring, I'd rather disable |
|
I think that's a bit of a heavy handed approach -- what about disabling |
ruimarinho
force-pushed
the
enhancement/bme680
branch
2 times, most recently
from
a6c5393
to
807a388
Compare
|
I'd still rather not do that. You sure other sensor boards work at all in your configuration? We deal with strange network traffic and bam - no memory. It is not necessarily web's fault, just an OOM sittuation What I meant by Travis issue: https://travis-ci.org/github/xoseperez/espurna/jobs/712391274#L311-L312 |
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
807a388
to
78e974a
Compare
|
Updated with your recommendation. |
|
Thx! When archive is packed back, we cannot use |
|
I like the renamer approach, but |
|
There is also a subtle issue with caching - edit: I have added wip8 as a POC that this is indeed the case |
|
@mcspr thanks for all your help on the patcher! It's looking good - is it working well on Windows? We should probably add it to the OS matrix on Travis. |
|
It does, I was switching between WSL and cmd.exe shells trying this out. Travis would be tricky here. What they propose by default is to select + Touch("$BUILD_DIR/1.txt"),
+ "mv $BUILD_DIR/1.txt $BUILD_DIR/2.txt",Shows However, with normal PIO Windows installation: 🤦 bash.exe kind of defeats the purpose of testing this at all |
|
Maybe GitHub Actions could be an alternative to try. I pushed two new commits, one fixing a bug (incorrect order of values) and some minor comment changes. If it it looks good to you, I can squash into a single commit to prepare for merge. Sounds good? |
|
What did you have in mind with |
Ok. re. environment config, I think I also intended to add
Same with travis, depends on the implementation. Assuming max@git-bash-exe-shell MINGW64 ~
$ powershell -command 'cmd.exe /c where mv'
C:\Program Files\Git\usr\bin\mv.exe
max@git-bash-exe-shell MINGW64 ~
$ cmd //C where mv
C:\Program Files\Git\usr\bin\mv.exe
|
ruimarinho
force-pushed
the
enhancement/bme680
branch
from
94dc1c5
to
ad2f842
Compare
|
Commits squashed. Are Windows users supposed to have WSL2 or MinGW installed? |
|
Btw, there is a good chance GitHub Actions acts differently from Travis. See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell. |
Nope. I just meant to show that running Windows apps via Git bash.exe shell inherits the PATH, which in turn inherits Git's UNIX tools, which Windows does not have by default. PIO on Windows only uses native tools and system's python version - so, only thing required is to fetch python.org's setup and install it. Then, either run VSCode and install PIO extension ( |
|
Ok, fair enough. If pio works out of the box on Windows then that's the sort of support we should be aiming for. Thanks for all your effort on this PR! Learned a lot 👍 |
|
Hello, |
|
btw re to the memory issue |
Add support for BME680 using BSEC's proprietary algorithms for precise Indoor Air Quality (IAQ) measurement. Unlike traditional CO2 sensors - and good ones are expensive - it measures nearly all VOCs compounds in the air (plus other gases) and compensates those measurements with its built-in temperature and humidity sensors to determine indoor air quality.
Overall, the CO2 and VOCs are correlated and both are in the human's exhaled breath. However, VOCs allow detecting other reasons for bad air, like smells or human metabolism.
Source: Bosch Sensortec BME680 Presentation
The BME680 is an expensive sensor (~€15-20) but it's quite amazing in what it does when compared to dedicated CO2 sensors like the SenseAir S8 (~€50).
The most difficult part until now is that to my knowledge, no open source firmware like Espurna, Tasmota or Esphome has ever shipped support for the only reliable IAQ calculation. While several attempts have been made to reverse engineer the formula behind gas resistance/temperature/humidity, none actually matches the quality of the algorithm built by Bosch's BSEC team.
Since there is now an open repository for Arduino directly from Bosch Sensortec on GitHub which includes the proprietary lib compiled for the BME680, in my understanding, as long as we don't deliberately remove any copyright notice (which 3-Clause BSD requires), then there should be no reason not to include it here. Platform.io manages this dependency, so the copyright notice is always downloaded and carried around alongside the compiled library.
This pull request should work a bit like magic - you don't need to edit any configuration to include additional paths for the compiled binary or even change the memory layout. It is all handed automatically for the end user for the best experience possible. Just enable support for this sensor with
BME680_SUPPORT=1.Fixes #1668.
Future improvements: