I recently swapped out the DHT22 in my setup for an Adafruit BME680 and it’s been great so far - proper I2C communication and no random drops. Woo!
I noticed when I set up the BME680 that there are 2 separate Mycodo inputs listed for this device. Looks like one is based on the Pimoroni BME680 Python library and the other is based on Adafruit Circuit Python BME680.
Switching between the two gives me different temperature/humidity/resistance readings. The difference isn’t huge, but with the Adafruit library temps are 2-3 degrees colder (F) and humidity is 3%-4% higher. Overall, this means that my calculated VPD changed from 1.7 to 1.3 which is enough to make a significant difference in plant health, so I want to figure out the discrepancy.
From the Bosch sensor datasheet it specifies that the “right” way to use the sensor is to use the Bosch-provided C interface, and then use the BSEC software on top of that. The BSEC software isn’t open source, and requires entering a valid email to download, but does look like it has a binary for Raspberry Pi 3 & 4. Separately, Bosch provides open source BME68x.c/h files on Github, but I’m not sure what the difference is between these and the BSEC software. It looks like Adafruit has included the Bosch BME68x.h/c files in their C bindings for the BME680, but has written the circuit python bindings independently. Presumably they based the Python bindings off the C bindings, but I’m not sure. The Pimoroni library has no link I can find to the original Bosch interface, but presumably could have copied from there as well.
My question then is: should I be using the Adafruit or the Pimoroni input library? And how hard would it be to create a third input using the closed-source Bosch BSEC software? I’m pretty comfortable with Pybind11, I wonder if it would be possible to create a thin Python wrapper around BSEC and then a custom input to use that from Mycodo.
After some more reading through docs and code I’ve discovered some things:
First, looks like the Bosch BSEC library is for sensor fusion and higher-level signal processing. The basic device API should be adequate to get accurate readings without this.
Comparing the Adafruit and Pimoroni libraries, it looks like they are doing roughly equivalent calculations, but using some techniques to improve precision/avoid overflow which could cause differences in output. Both libraries use garbage variable names (i.e. var1, var2) in calculations and stuff all the logic into a single file. Interestingly, Adafruit is using floats for some constants where Pimoroni is using ints.
Also noticed that the interfaces are different in Mycodo - Pimoroni exposes the gas heater temp and profile options, Adafruit does not.
Still interested in folks thoughts on which is accurate, and also curious if the interface difference is a tech limitation or just an accidental difference.
I don’t own this sensor, so I couldn’t even test if I wanted to (I also don’t really have time for testing individual sensors). The interface differences are mainly the result of how much effort I put in when creating the Input modules, based on the availability of documentation when I created them, and time. Some modules were created by other users, but I created the vast majority, so it’s likely I created it. Without a specific need for certain features, I didn’t expend energy coding it into the Mycodo module. Anyone is welcome to add functionality and submit a pull request on Github if it can be confirmed to work and not break backwards compatibility for current users. This is the reason for many duplicate modules that either use different libraries or alternate calculation methods.
Sounds good! I’ll keep looking into the difference a bit. If it turns out the Adafruit code is better, I’ll work on adding the extra features to that input module and make a PR. Appreciate your thoughts on this!