Up to know I don’t use MQTT, but as you said it should be no problem since there is the integrated MQTT server. So I am fine with this solution - for now 
Thanks again for your work. Will keep you updated when mine is running also.
2 Likes
Just a quick note: I made some big changes to the main script tonight. Now, instead of configuration options being in the bsec-conduit script itself, we store them in a separate config file named bsec-conduit.ini. This seemed safer to me. Having users edit an executable script can introduce hard to track bugs if they mistype something. The config parser I’m using does some error checking and I’ve added a bit more to catch basic mistakes (we fallback on default values). Another advantage is it will allow users to easily upgrade to future versions without wiping out their config.
I also fixed a small bug in the underlying BSECLibrary class and cleaned up some of the text in the installer.
@azrael783 Thanks! Let me know how it works for you. I haven’t throughly tested the install script outside of Raspbian/Hassbian, so let me know if error messages appear or anything. (I’ve tried to make the installer script robust and perform checks, so if something it’s expecting [a file, directory, whatever] isn’t there it’ll stop.)
@timothybrown I didn’t forget you. My BME680 already arrived, but I had a broken SD card and I had to set up everything new 
Luckily I had backups from HA and my ZigBee gateway. Next step is to set up the BME
@timothybrown I tried to install, ending up with an error message. I already greated an issue on github … 
Thanks! I’ll check it and get back to you shortly.
I just got a few VMs setup last night with different configurations of Home Assistant (using Hass.io, Debian w/ Python Venv, Ubuntu w/ Venv, etc.) so I can make the installer script support more setups. I should have a fix for your issue tonight or in the morning.
Thank you!
That sounds awesome! Gonne try it out when I find time and will let you know if I encounter any errors Thanks for your work!
No worries! Thank you for the idea. 
In other news, I’m about to release a new version with a few bug fixes (better code for setting the TZ environment variable when launching the bsec_library process, detection of I2C permission errors, a much more OS independent way to detect the processor type and a better way to generate a unique repeatable ID, among other fixes). Testing this script and library for bugs has been challenging. It’s not like I can just setup a dozen VMs with different distros and use automated testing; the reliance on I2C makes that hard to do!
I’m also re-working the installer script. (I’ve removed the part that tries to install the required libraries and am just having it install the Systemd service and download the BSEC source.)
Finally, after some problems installing the script it now works! Thank you @timothybrown! I really appreciate your work
After some days having the BME working, it now doesn’t show the IAQ value.
The “BME accuracy” is showing “stabilizing”. Then every few seconds all values disappear
Anyone an idea? Is the BME 680 broken? I did change some values in the BSEC_conduit.ini file but I changed it already back to default values. This didn’t change anything.
Sorry for the delay in responding. I was sick for a week, then holiday stuff and work, so I’ve been super busy!
Anyway, that seems like it could be an issue with the sensor, so let’s do some debugging.
First off, the underlying bsec-library only reports “Stabilizing” during the initial startup of the sensor. Basically, it gets baseline values by burning in the sensor for several minutes. So, if you’re seeing this it sounds like the program is constantly restarting. Let’s check for that!
What does journalctl -u bsec-conduit.service tell you? Is the BSEC-Conduit service constantly restarting? (It’s setup a bit conservatively, at the first sign of trouble we bail out and allow Systemd to restart the entire process, hoping that fixes things. During my initial debugging I had some issues with static discharges causing the BME680 to go into a weird mode, the fix being a full restart of bsec-library, which re-initializes the sensor to sane defaults. The easiest way to do that was to simply quit and let Systemd restart the bsec-conduit Python program; this guarantees everything comes back correctly.)
Another thing to check is the cables between the Pi and the sensor board. The first thing I’d try is a new set of jumper cables. I’ve had issues with other dev boards where a poor crimp on a jumper cable was causing intermittent connections.
The next thing I’d try is resetting bsec-library: Go into /opt/bsec (or wherever you installed the program) and run sudo systemctl stop bsec-library; sudo rm bsec-library*; sudo systemctl start bsec-conduit. This will delete the bsec-library binary, config and state files. (Fresh ones will be created once bsec-conduit starts back up.)
Check that and let me know what the Journal looks like.
Nevermind, I know this too good.
This is the output of journalctl -u bsec-conduit.service:
pi@phoscon:~ $ journalctl -u bsec-conduit.service
-- Logs begin at Thu 2016-11-03 17:16:42 UTC, end at Fri 2018-12-14 19:08:51 UTC
Dez 13 19:42:42 phoscon systemd[1]: Starting BSEC-Conduit Daemon...
Dez 13 19:42:45 phoscon BSEC-Conduit[307]: BSEC-Conduit v0.3.4
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Found existing BSEC-Library executabl
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Using existing BSEC-Library configura
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Found existing BSEC-Library state fil
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: BSEC-Library started.
Dez 13 19:42:46 phoscon systemd[1]: Started BSEC-Conduit Daemon.
Dez 13 19:42:52 phoscon BSEC-Conduit[307]: Connected to MQTT Broker.
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Watchdog timeout (limi
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Killing process 307 (b
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Killing process 789 (b
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Main process exited, c
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Unit entered failed st
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Failed with result 'wa
Dez 13 19:43:53 phoscon systemd[1]: bsec-conduit.service: Service hold-off time
Dez 13 19:43:53 phoscon systemd[1]: Stopped BSEC-Conduit Daemon.
Dez 13 19:43:53 phoscon systemd[1]: Starting BSEC-Conduit Daemon...
Dez 13 19:43:53 phoscon BSEC-Conduit[1644]: BSEC-Conduit v0.3.4
Dez 13 19:43:53 phoscon BSEC-Conduit[1644]: Connected to MQTT Broker.
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Found existing BSEC-Library executab
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Using existing BSEC-Library configur
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Found existing BSEC-Library state fi
lines 1-23...skipping...
-- Logs begin at Thu 2016-11-03 17:16:42 UTC, end at Fri 2018-12-14 19:08:51 UTC. --
Dez 13 19:42:42 phoscon systemd[1]: Starting BSEC-Conduit Daemon...
Dez 13 19:42:45 phoscon BSEC-Conduit[307]: BSEC-Conduit v0.3.4
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Found existing BSEC-Library executable, skipping build.
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Using existing BSEC-Library configuration [generic_33v_300s_28d].
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: Found existing BSEC-Library state file, skipping creation.
Dez 13 19:42:46 phoscon BSEC-Conduit[307]: BSEC-Library started.
Dez 13 19:42:46 phoscon systemd[1]: Started BSEC-Conduit Daemon.
Dez 13 19:42:52 phoscon BSEC-Conduit[307]: Connected to MQTT Broker.
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Watchdog timeout (limit 30s)!
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Killing process 307 (bsec-conduit) with signal SIGABRT.
Dez 13 19:43:47 phoscon systemd[1]: bsec-conduit.service: Killing process 789 (bsec-library) with signal SIGABRT.
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Main process exited, code=killed, status=6/ABRT
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Unit entered failed state.
Dez 13 19:43:48 phoscon systemd[1]: bsec-conduit.service: Failed with result 'watchdog'.
Dez 13 19:43:53 phoscon systemd[1]: bsec-conduit.service: Service hold-off time over, scheduling restart.
Dez 13 19:43:53 phoscon systemd[1]: Stopped BSEC-Conduit Daemon.
Dez 13 19:43:53 phoscon systemd[1]: Starting BSEC-Conduit Daemon...
Dez 13 19:43:53 phoscon BSEC-Conduit[1644]: BSEC-Conduit v0.3.4
Dez 13 19:43:53 phoscon BSEC-Conduit[1644]: Connected to MQTT Broker.
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Found existing BSEC-Library executable, skipping build.
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Using existing BSEC-Library configuration [generic_33v_300s_28d].
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: Found existing BSEC-Library state file, skipping creation.
Dez 13 19:43:54 phoscon BSEC-Conduit[1644]: BSEC-Library started.
Dez 13 19:43:54 phoscon systemd[1]: Started BSEC-Conduit Daemon.
Dez 13 19:44:26 phoscon systemd[1]: bsec-conduit.service: Watchdog timeout (limit 30s)!
Dez 13 19:44:26 phoscon systemd[1]: bsec-conduit.service: Killing process 1644 (bsec-conduit) with signal SIGABRT.
Dez 13 19:44:26 phoscon systemd[1]: bsec-conduit.service: Killing process 1703 (bsec-library) with signal SIGABRT.
Dez 13 19:44:26 phoscon systemd[1]: bsec-conduit.service: Main process exited, code=killed, status=6/ABRT
Dez 13 19:44:27 phoscon systemd[1]: bsec-conduit.service: Unit entered failed state.
Dez 13 19:44:27 phoscon systemd[1]: bsec-conduit.service: Failed with result 'watchdog'.
Dez 13 19:44:32 phoscon systemd[1]: bsec-conduit.service: Service hold-off time over, scheduling restart.
Dez 13 19:44:32 phoscon systemd[1]: Stopped BSEC-Conduit Daemon.
Dez 13 19:44:32 phoscon systemd[1]: Starting BSEC-Conduit Daemon...
Dez 13 19:44:32 phoscon BSEC-Conduit[1982]: BSEC-Conduit v0.3.4
Dez 13 19:44:32 phoscon BSEC-Conduit[1982]: Connected to MQTT Broker.
Dez 13 19:44:33 phoscon BSEC-Conduit[1982]: Found existing BSEC-Library executable, skipping build.
I already did a power cycle (switched the Pi off, disconnected the power cable, reconnected and restart) but this didn’t change anything. Also your last suggestion didn’t change anything. So I will try to use other cables and come back to you with the result.
Well, it looks like the bsec-conduit process itself is either locking up or your system is under extreme load at some point and the BSEC-Conduit process isn’t able to notify systemd it’s functioning. (Basically, BSEC-Conduit has to report “I’m OK!” to systemd every 30 seconds; if it doesn’t hear from it in that time it assumes there’s a major issue and restarts the process.)
The only time I’ve ever seen BSEC-Conduit fail to update the watchdog is when my system was under an extreme load (I’m talking thousands of processes being spawned, memory full, disk I/O maxed out, etc.), so I’d be interested to find out what’s causing this.
If the cable doesn’t fix it, I’ll give you a special version of BSEC-Conduit with debugging routines that will basically print everything to the journal, so we can figure out what exactly is causing the lockup.
Another thing to try might be disabling the watchdog all together and see what happens. This is easy to do: sudo systemctl edit --full bsec-conduit.service, use the arrow keys to move down to the line that says WatchdogSec=30 and add a hash in-front of it, so it now reads #WatchdogSec=30, then hit CTRL-X, Y, <Enter>. Finally, run sudo systemctl restart bsec-conduit.service and them observe the journal as above.
Sorry, was busy over the weekend. Christmas is too close …
Here is what I did:
- I checked the 3.3V voltage => this is fine.
- I changed the two SPI cables => didn’t change anything
- I hashed the watchdog timer => journalctl still says “Watchdog timeout”
- I unhashed the watchdog timer again => it is still not working
In the meanwhile all values are now gone. If I check with MQTT.fx the topics, I can see only the IAQ/status which is changing from offline to online and back again. All other topics are gone? 
Something seems to be really wired on my Pi …
Just a hint for those, like me, that had to solder the connection pins… If using soldering flux, remember to clean the PCB (avoid the sensor unit) with isopropyl alcohol.
Ive had this mistake and the BME680 IAQ readings were tottaly wrong due the flux fumes interfering with sensor…
Below is an example of board that requires soldering:
1 Like
Hi @ferazambuja could you also post the Arduino ESP32 sketch or process to work with the BME680? Thank you.
1 Like
@ferazambuja Please provide an ESP / Arduino code.
I have BSEC running on an NodeMCU but struggling with MQTT integration.
Not very experienced with all this yet.
Tanks
Eugen
[@timothybrown] great work on integrating BSEC library! No small task by any means and thank you for that.
Would it be possible to make a universal fork without MQTT and non-HA environment? Something like Real-time IoT Data streaming that could be utilised with Power BI or Grafana?
Thank you for all your good work and effort.
Best regards.
B
Sorry for the delay getting back to you, I’ve not been getting thread notifications for some reason.
Yes, for sure that’s possible! All the heavy lifting is already done in the BSEC-Library Python module I created, so it’s just a matter of using that with whatever custom script you want.
I need to sit down and clean up a few things, make a couple of small fixes, create a setup.py and write some documentation. I’ll add that to my list and get to it in the next couple of weeks. Once that’s done, I’ll release the module so it can be installed with PIP.
If you want to send me a PM describing a bit about your use case, I’ll see what I can do to make sure it works for you.
@timothybrown I was running through your nice and clear install steps on your github, but the install.py step was throwing a “HTTP Error 404: Not Found”. It looks like Bosch has updated the library available at the link in the OP, so the install.py needs bsec_ver updated to “BSEC_1.4.7.3_Generic_Release_20190410”. Once I changed this in my local install.py, the command completed without errors.