Wemos D1 mini + BME680 + BSEC/IAQ + MQTT

in the bsec library you downloaded from bosh, see first post where to copy those

i think those files are no longer in the Bosch Library:

i cant find them anywhere.

looks like they have updated their lib, it was in src.
(i have that original one still)

so download new one and make adjustments to the code, should be pretty easy

if there is anybody interested in a BME680 implemention as Homie MQTT Device (works plug&play)…Just ask…I will share the code and settings for PlatformIO.


Hi @kriznik !

Do you mind sharing your files again, please?

I’ve tried all sorts of combination and just give up trying to find out how to make it work.

Best regards and thanks in advance!

Hi @Renato_Troitino,

I was able today to get it compiled and running on a ESP32 today with minimal changes on the current BSEC lib provided by Bosch. There is no need for the “missing” files as apparently that funcionality has been incorporated into the other files of the lib.

One need to:

  1. remove or comment out: #include “bsec_serialized_configurations_iaq.h”
  2. change “iaqSensor.iaqEstimate” to “iaqSensor.iaq”

For ESP32 I switched from #include <ESP8266WiFi.h> to #include <WiFi.h> and removed “WiFi.hostname(wifi_hostname);”

All running fine now. Good luck!

1 Like

Hello, thank you very much for showing your ** OH rule ** here, which helped me a lot, but can you tell me which ** items ** you created for the ** rule **?

Please explain to me how it works.

I am running on a Wemos D1 mini Tasmota and send me the gas value of the BME680 with MQTT to OpenHab (xxx kOhms) does the rule also work with it?

My Items

BME680_Gas // This value for the Item comes from the MQTT (E.g 180.50 kOhms)
BME680_IAQ // This item is for the calculated air quality in OH (E.g 95% (27) it should look like your rule )

Thanks in advance

Hi, I’m using sIAQ for rules and Gas just for display in general info as this is quite abstract number without really good interpretation (i could find).

my current ruleset is this (OH3)
I’ve changed scale from 0-500 as these sensors varies quite a lot so I’m now calculating worst and best values each sensor catch in period of time as top-bottom scale and then calculate “real” air quality in my place

rule "Helpers: Airquality: Create AirLabels for items"
    Member of gAirQTrigger received update
    val basename = triggeringItem.name.split("_").get(0)
    val item_iaq = ScriptServiceUtil.getItemRegistry.getItem(basename + "_sIAQ") as GenericItem

    val timeperiod = now.with(LocalTime.of(0,0,0,0)).minusDays(30)

    val max = (item_iaq.maximumSince(timeperiod).state as Number).floatValue
    val min = (item_iaq.minimumSince(timeperiod).state as Number).floatValue

  // only calibrated output passthrough
    //if(item_ac.state == 3){
        val iaq  = (item_iaq.state as Number).floatValue
        val airq = 100 - (((iaq - min) * 100) / (max - min))

        postUpdate(basename+"_AirQ", String::format("%.0f", airq))
        postUpdate(basename+"_AirLabel", String::format("%.0f %%", airq) + " (" + String::format("%.0f", iaq) + ")")

        var q = 0
        switch iaq {
          case iaq > 0   && iaq <= 50  : q = 1
          case iaq > 50  && iaq <= 100 : q = 1
          case iaq > 100 && iaq <= 150 : q = 2
          case iaq > 150 && iaq <= 200 : q = 3
          case iaq > 200 && iaq <= 300 : q = 4
          case iaq > 300 && iaq <= 500 : q = 5

        postUpdate(basename+"_AirQState", q.toString)

AirQState is just for now not used interpretation of the “Good” “Bad” etc.


i would be interested into the code - if the offer about sharing still exist.

hi kriznik, this looks awesome. even if it’s long time ago, can you share your bsec library files (again). I’m struggeling with the current version from git, as they dont have the mentioned files included :pray:

sure, in the zip you have my current version - VSCode + platformio + all libs
just make your edits in src/settings.h file and build it.
It’s for WemosD1, but I guess all same based chips will work.
expects BME680 to be connected, BME280 is additional if you have 2 connected (as I do at one place), and it works with PIR or 2x PIR if wanted.

MQTT and WIFI and remote update indeed.


1 Like

Hey @kriznik , please forgive me if I’m out of line but I’ve been beating my head around this and since you’ve worked with the bme680, I’m here praying that what I will request isn’t too much work for you.
Bme680 uses bsec v1. Meanwhile there’s a new sensor, bme688 which uses bsec v2.
Physically the Bme680 and bme688 are the same, just the gas sensor appears to be more sensitive. So I wanted to ask if I could somehow have you do the same, but with bsec v2?
Feel free to DM me if you have any questions, I do have a bme688 on hand for tests.

Edit: well nevermind. Managed to compile bsec v2 and an mqtt client to an esp8266. The bme688 sensor is special for sure. Gonna be playing around with it for a bit and might return to describe my findings. Feel free to reach out if anyone has questions.

I can give new library a shot, but it has been quite pain to get previous version working :wink:

1 Like

Oh the new one is really super easy. Bosch handled a lot of the issues quite well. For the 8266 platform you need to add two lines to the platform.txt file (and use arduino ide 1.18.11, the latest bugs out) and you can compile just fine.

One thing though, the Bosch sensortec website has a community now. I don’t think it existed last year? Not sure? It’s super lively there though and devs answer frequently. Went there and they are giving answers and providing a measure of support so maybe it’s not a bad idea to show interest in this sensor there, for a myriad of reasons.

I’ve printed out the datasheet and while reading the code I noticed that we are SEVERELY underutilizing the outputs of this thing, just read the bsec_datatypes.h file and find the outputs and the descriptions of each. Here’s a summary of them that the devs shared at their community:

There’s also a bme ai studio application that works with the x8 board. I tried it out and they are now listing “custom boards” as “available soon. Which means that soon we may be able to customize the sensors to specific applications (think a sensor to detect when food is perishing in the fridge. Or to detect when cats have pooped. Or … crap, this is great and I’m going on a tangent again).
Not sure how much of an interest there is on this but I’m geeking out immensely :smiley: