Moin,
ich hatte ja hier (https://forum.fhem.de/index.php?topic=96241.0) einen sensor zur Raumluftüberwachung vorgestellt und verfolge das auch weiter.
Ab und an erreichen mich pm's dazu wo user andere Projekte im Zusammenhang mit verschiedenen tVoc Sensoren umsetzen. Meist geht's um die Interpretation der Werte. Nun weiß ich das es auch hier verschiedene Projekte gab/gibt. Wird also wohl einige User geben die auch Erfahrungen haben und wir können uns hier mal austauschen.
Ohne jetzt sofort in die Tiefe zu gehen: meine Erfahrungen beziehen sich auf den BME680 (den ich dann wieder verworfen habe) und den AMS IAQ Core. Davon habe ich mehrere über Monate im Einsatz. Fazit: die sind gut um kurzzeitige Störungen zu sehen. Um dauerhaft absolute tVOC Werte zu bekommen um zB eine Lüftung zu steuern sind auch die ungeeignet. Je nach Environment (hauptsächlich Wetter: Luftfeuchte, Temp) driften auch die. Zeigen also mal unplausibel hohe Werte an. Speziell im Vergleich zu reinen CO2 Sensoren (hier MH-Z19) sind die absoluten Werte oft wenige plausibel.
Im Netzt findet man viele Beiträge (Foren, blogs) die sich nur mit dem Anschluss (Raspi, ESP) beschäftigen (ohne Erfahrung Dauerbetrieb) oder eben die Leute die Probleme damit haben. Freue mich also hier auch auf den Austausch mit USern die eben auch schon Erfahrungswerte aus längerem Betrieb haben - vielleicht ja auch ganz andere Erfahrungen.
vg
Joerg
Super Sache ....
Wieso hast den bme wieder verworfen ?
Ich nutze das ganze jetzt ein paar Tage kann aber mit dem VOC wert nicht wirklich etwas anfangen .
Frisch gelüftet Fenster war über Nacht auch auf , lag der Wert zwischen 560 und 620 ca
Heute Abend nicht gelüftet bei ca 430-490 .
Mir war so ,als ich ihn draußen getestet hatte, lag der Wert bei 30?!
Werd es draußen nochmal testen ....
Gruß
Bei stark gelüftetem Raum ist der Wert über 620.
Okay
Also ein ran Tasten ist angesagt .
Ich bin dabei für mich ein Gehäuse zu bauen .
Dachte damit der Sensor nicht draußen hängt baue ich , erstmal provisorisch , ein Röhrchen .
Was in das Gehäuse kommt .
Temperatur und feuchte bleiben unverändert .
Aber der VOc wert sinkt auf einmal auf 430.
dieser Wert hab ich sonst bei geschlossenem Fenster .
Kommt nix mehr rein in das Röhrchen oder verfälscht das Holz das ganze?
Plastik oder Metall nutzen ?
Hallo Jörg,
ich möchte gerne Deine Initiative zu "Langzeiterfahrungen" mit dem BME680-Sensor (https://oshpark.com/shared_projects/LXuNziGd) aufgreifen.
Den BME habe ich bereits einige Jahre bei mir im "Einsatz".
Die letzte Implementierung in der OLED-Wetterstation war meiner Meinung nach die "Umgängigste" mit Einbindung
verschiedener anderer Wetterinformationen.
Dort hatte ich Deinen BME-Code gekapselt mit in die OLED-ES8266-Wetterstation (https://forum.fhem.de/index.php/topic,52403.msg934892.html#msg934892) mit eingebunden.
Allerdings sehe ich für meinen Teil nicht den Bedarf für 100% absolut stimmige CO2-Werte, da ja bei mir keine Lüftung präzise gesteuert werden muss.
Die Tendenz ist allerdings schon informativ genug und für mich völlig ausreichend um mal das Fenster zu öffnen und frische Luft hereinzulassen ...
Im Sommer ist das nicht unbedingt das Problem, allerdings im Winter bei geschlossenen Fenstern + Heizung schon eher.
Anbei ein paar Bilder meines Aufbaus und muss zu meiner Schande gestehen, dass ich noch kein passendes 3D-Design hatte ersinnen können um die Elektronik
passend unterzubringen. Aber kommt Zeit kommt Tat ;-)
Zur Beeinflussung der Sensor-Meßgrößen wäre noch hinzuzufügen, dass ich diese unten angesiedelte Verbauung des Sensors so gewählt habe um einen möglichst guten
Luftfluss außerhalb des Temperatur-Abstrahlraumes des TFT-Displays und des ESP8266 zu bekommen.
Dennoch lässt sich hier die Abstrahlung von Wärme auch nicht ganz unterdrücken: 0.5 .. 0.7 °C sind leider immer noch im offenen Raum da ;-)
Viele Grüße,
Jürgen
@MC_Arthur: Du erwähnst leider nicht, mit welcher Methode/Firmware Du den Sensor eingebunden hast. Bzw. mit welcher Methode tVOC/IAQ/PPM/Widerstand etc. Dein Meßwert zustande kommt ;-)
Schönes Projekt. Mensch, wusste gar nicht das der BME code dort noch lebt - das freut mich sehr, damit war die Arbeit nicht umsonst. Schön.
Mir ging es nicht so sehr um den BME im speziellen sondern auch mal so unterschiedliche ...
Bei dürfte es so sein dass die Werte sich von Tag zu Tag (oder Woche zu Woche) unterscheiden aber kurzfristige Tendenzen eben sichtbar sind. Die absoluten Werte sind also eher weniger aussagekräftig, kurzfristige (Stunden) aber absolut ok. Ist auch mein Fazit.
Der BME wird ja vtml auch mit den Bosch Libs irgendwo laufen, vielleicht hat der eine oder andere auch den CC811 im Einsatz. Mal gespannt wie es da so aussieht und ob sich noch weitere Erfahrungen finden
Ich habe das ganze mit esp easy und dem Wemos realisiert und dazu das Plugin playground P119 bme 680 gewählt und kompiliert und auf den Wemos geladen .
https://github.com/letscontrolit/ESPEasyPluginPlayground/blob/master/_P119_BME680.ino (https://github.com/letscontrolit/ESPEasyPluginPlayground/blob/master/_P119_BME680.ino)
Hier der Link
wenn ich das richtig sehe dann wird da nur der Widerstandswert ausgegeben. Kann man so machen - wird dann halt Kacke.
UserVar[event->BaseVarIndex + 3] = bme.gas_resistance / 1000.0;
Oder auf deutsch: dieses Reading ist wertlos. Verändert sich halt. Wenn die tVoc sich ändert. Oder die Temperatur. Oder die Luftfeuchte. Und auch grundlos, einfach über die Zeit (Kein Scherz). ...
Okay. Also kann man mit dem Wert wenig anfangen .
Also eine Alternative .
Hatte irgendwo etwas von tasmota gelesen , das diese Software empfohlen wird .
Stimmt das ?
———-
Hab das mal installiert , also da steht dann auch das der Wert in kOhm angegeben wird .
Also auch nicht weiter zu gebrauchen
Hallo Jörg,
ich habe im Code noch einen gleitenden Mittelwert zur Stabilisierung des Azeigewertes verwendet.
Allerdings habe ich hier die Implementierung eines Kalman-Filters gefunden, der sich hier beim BME680 auch einfach anwenden lässt.
https://github.com/denyssene/SimpleKalmanFilter (https://github.com/denyssene/SimpleKalmanFilter)
https://www.youtube.com/watch?v=4Q5kJ96YYZ4 (https://www.youtube.com/watch?v=4Q5kJ96YYZ4)
Da dieses adaptiv reagiert, wäre er wohl noch besser geeignet als die reine gleitende Mittelwertbildung ... :D
Zitat von: MC_Arthur am 17 August 2019, 23:16:03
Ich habe das ganze mit esp easy und dem Wemos realisiert und dazu das Plugin playground P119 bme 680 gewählt und kompiliert und auf den Wemos geladen.
Könntest Du bitte das kompilierte binary einstellen?
Danke + Gruß
Peter
(@Peter: ich möchte Deinen Enthusiasmus nicht bremsen aber der reine Widerstandswert ist nutzlos. Der Einfluss von Temperatur und Luftfeuchte überlagert den tVOC Wert bei diesen Sensoren um ein vielfaches. Wenn der nicht rausgerechnet wird hast Du im Extrem den einen Tag 150, dann 50, dann vielleicht 80 - alles bei gleicher "Luftqualität", spricht tVOC Anteil. Dazu kommen noch physikalische Effekte auf der Sensoroberfläche)
Das ist ja auch mein Problem ....
Was könnte ich den nutzen und hochladen.?
Fertige Sachen wie tasmota und ESPEasy klappt ja wohl nicht :/
Zitat von: herrmannj am 18 August 2019, 12:43:11
(@Peter: ich möchte Deinen Enthusiasmus nicht bremsen aber der reine Widerstandswert ist nutzlos. Der Einfluss von Temperatur und Luftfeuchte überlagert den tVOC Wert bei diesen Sensoren um ein vielfaches. Wenn der nicht rausgerechnet wird hast Du im Extrem den einen Tag 150, dann 50, dann vielleicht 80 - alles bei gleicher "Luftqualität", spricht tVOC Anteil. Dazu kommen noch physikalische Effekte auf der Sensoroberfläche)
Ich weiß ;), aber dann könnte ich zwei Sensoren (einen mit Algorithmus und einen ohne) mit zwei verschiedenen Bibliotheken parallel laufen lassen und mal schauen, was der Widerstandswert zwischen den beiden Sensoren macht.
Gruß Peter
Zitat von: MC_Arthur am 18 August 2019, 12:57:48
Das ist ja auch mein Problem ....
Was könnte ich den nutzen und hochladen.?
Fertige Sachen wie tasmota und ESPEasy klappt ja wohl nicht :/
Das Projekt von juergs (oben) könntest du verwenden.
Werd das ganze wohl mal nutzen .
Led Anzeige ist ja dabei .
Brauche nur das Display nicht .
Anbindung an Thingspeak muss ich mir dann nochmal raussuchen .
Und wo ich sein Code laden kann .
Bei Gelegenheit .
Hallo Peter,
nach dem ESPEasy nun nicht ganz leicht zu compilieren ist ...
hatte ich schon mit Atom+Platformio unter Windows 100 aufgegeben ... da er sich aus einer Endlosschleife nicht bei den Dependencies erholt hat ...
Mit VSCode und dem PlatformIo-Plugin konnte ich EspEasy aber ohne Größeren Aufwand compilieren:
HowTo: https://www.youtube.com/watch?v=Yb-HOBynJdc (https://www.youtube.com/watch?v=Yb-HOBynJdc)
https://docs.platformio.org/en/latest/platforms/espressif8266.html (https://docs.platformio.org/en/latest/platforms/espressif8266.html)
Probiere dann mal Jörgs Code als EspEasy-Plugin einzubinden.
Environment minimal_core_242_ESP8266_1M_OTA [SUCCESS]
Environment minimal_core_242_ESP8285_1M_OTA [SUCCESS]
Environment minimal_core_252_ESP8266_1M_OTA [SUCCESS]
Environment minimal_core_252_ESP8285_1M_OTA [SUCCESS]
Environment normal_core_241_ESP8266_1M [SUCCESS]
Environment normal_core_242_ESP8266_1M [SUCCESS]
Environment normal_core_252_ESP8266_1M [SUCCESS]
Environment normal_ESP8285_1M [SUCCESS]
Environment normal_WROOM02_2M [SUCCESS]
Environment normal_core_252_WROOM02_2M256 [SUCCESS]
Environment normal_ESP8266_4M [SUCCESS]
Environment normal_core_241_ESP8266_4M [SUCCESS]
Environment normal_core_252_ESP8266_4M [SUCCESS]
Environment normal_core_252_ESP8266_16M [SUCCESS]
Environment minimal_IRext_ESP8266_1M [SUCCESS]
Environment normal_IRext_ESP8266_4M [SUCCESS]
Environment test_core_242_ESP8266_4M [SUCCESS]
Environment test_core_252_ESP8266_4M [SUCCESS]
Environment normal_core_260_sdk2_alpha_ESP8266_4M [SUCCESS]
Environment normal_core_260_sdk222_alpha_ESP8266_4M [SUCCESS]
Environment test_core_260_sdk2_alpha_ESP8266_4M [FAILED]
Environment test_core_260_sdk222_alpha_ESP8266_4M [SUCCESS]
Environment test_core_260_sdk3_alpha_ESP8266_4M [FAILED]
Environment test_core_252_ESP8266_16M [SUCCESS]
Environment normal_core_260_sdk2_alpha_ESP8266_16M [SUCCESS]
Environment normal_core_260_sdk222_alpha_ESP8266_16M [SUCCESS]
Environment test_core_260_sdk2_alpha_ESP8266_16M [FAILED]
Environment test_core_260_sdk222_alpha_ESP8266_16M [SUCCESS]
Environment test_core_260_sdk3_alpha_ESP8266_16M [FAILED]
Environment test_ESP8266_4M_VCC [SUCCESS]
Environment test_core_260_sdk2_alpha_ESP8266_4M_VCC [FAILED]
Environment dev_ESP8266_4M [SUCCESS]
Environment hard_SONOFF_POW_4M [SUCCESS]
Environment hard_core_252_SONOFF_POW_4M [SUCCESS]
Environment hard_other_POW_ESP8285_1M [SUCCESS]
Environment hard_core_252_other_POW_ESP8285_1M [SUCCESS]
Environment hard_core_252_Shelly_1_2M256 [SUCCESS]
Environment hard_Ventus_W266 [SUCCESS]
Wer's mag.... :o ::)
Grüße,
Jürgen
spannend. Lass mich wissen ob ich helfen kann. In den BME code könnte ich mich ja einlesen ;)
Mal was anderes: ich habe den BME680 "damals" fallenlassen weil ich erkannt hatte dass die Genauigkeit für Temp/Hum nicht ausreichen um den Effekt aus dem VOC rauszurechnen. OK, waren corner case. Wie ist den so die Bandbreite der Werte in Praxis so in subjektiv vergleichbaren Situationen? So plus minus 50ppm? oder mehr/weniger?
Zitat von: herrmannj am 19 August 2019, 22:50:21
spannend. Lass mich wissen ob ich helfen kann. In den BME code könnte ich mich ja einlesen ;)
Mal was anderes: ich habe den BME680 "damals" fallenlassen weil ich erkannt hatte dass die Genauigkeit für Temp/Hum nicht ausreichen um den Effekt aus dem VOC rauszurechnen. OK, waren corner case. Wie ist den so die Bandbreite der Werte in Praxis so in subjektiv vergleichbaren Situationen? So plus minus 50ppm? oder mehr/weniger?
Schaue mir den Code am Wochenende doch mal genauer an. Genauso wie das EspEasy-Sensor-Template.
Mal schauen, wenn sich der Aufwand in Grenzen hält ....😏
Hallo,
musste mit noch etwas mit Platformio + Lib-Handling "anfreunden".
Der PlatformIO-Compile (
ESPEasy-mega-20190817) mit dem BME680-Plugin und der aktuellen Adafruit BME680 Lib lief schon mal durch.
Die Firmware läuft bei mir auf dem
Wemos D1 D2 mini. Wemos+D1+Mini+mit+ESPEasy+flashen (https://www.loxwiki.eu/display/LOX/Wemos+D1+Mini+mit+ESPEasy+flashen)
user: admin |
pwd: configesp (ESPEasy-Standard) |
Den BME680 habe ich bei meinem Breakout-Board auf SDO
Low=0x76, High=0x77 ==>
0x76 gestellt.
Wie gehabt, unter AP mit Addresse 192.168.4.1 fürs eigene WLAN konfigurieren.
Dann im eigenen WLAN den BME parametrieren. (Leider sind einige Resets nötig, bis es mal richtig funktioniert...)
@Peter, falls noch in anderer Config benötigt, bitte Bescheid geben. :D
Für das Plugin habe ich die aktuelle ADAFRUIT_BME680-Lib verwendet.
Dann schaue ich mir mal Jörgs Code wieder mal genauer an ... ;)
Grüße,
Jürgen
ich kann unterstützen.
Habe mich auch gerade eben mal auf eine Stunde ran gesetzt, auch getrieben von Deinem grundsätzlich positiven Langzeit feedback.
Was mich beim BME280/680 ebenfalls stört ist dass Temp und Hum so ungenau sind. Daher schaue ich mir mal die Adafruit Lib vs Bosch Referenz genauer an. Da sind ja dutzende Korrekturwerte in die auf T/H angewendet werden. Mal schauen ob ich da Unstimmigkeiten in der Adafruit Lib finde. (Temp weicht in meinen Versuchen ca 2°, RH ca 5% ab ... )
In der Folge würden genauere T/H Werte dann die VOC Werte deutlich stabiler machen.
Hallo Jörg,
gerne!
ZitatAdafruit Lib vs Bosch Referenz genauer an. Da sind ja dutzende Korrekturwerte in die auf T/H angewendet werden.
Hatte ich auch schon gesehen.
Woher nimmst Du Deine "genauen" Hum-Werte?
Das Delta-T durch Eigenerwärmung + Wärmestrahlung des ESPs wären schon einfacher erklärbar.
Leider liefert ESPEasy nur ein Sensor-Typ mit maximal 4 Messwerten (SENSOR_TYPE_QUAD) mit. D.h. dann Widerstand oder PPM.
Mal schauen vielleicht geht das anders, habe aber an der Stelle noch zu wenig Erfahrung mit ESPEasy-Plugins etc .. :(
case PLUGIN_DEVICE_ADD:
{
Device[++deviceCount].Number = PLUGIN_ID_119;
Device[deviceCount].Type = DEVICE_TYPE_I2C;
Device[deviceCount].VType = SENSOR_TYPE_QUAD;
Device[deviceCount].Ports = 0;
Device[deviceCount].PullUpOption = false;
Device[deviceCount].InverseLogicOption = false;
Device[deviceCount].FormulaOption = true;
Device[deviceCount].ValueCount = 4;
Device[deviceCount].SendDataOption = true;
Device[deviceCount].TimerOption = true;
Device[deviceCount].GlobalSyncOption = true;
break;
}Habe die Code-Basics mit den Algorithmen für die bessere Übersicht zusammengefasst.
T/H "Referenz", vorhandene Thermometer. Wissenschaftlich sicher nicht korrekt aber einfache Rechnungen. 2 Thermometer unterschiedlicher Hersteller zeigen fast gleiche Werte an, der BME weicht um mehr als 5% Hum ab.
Abwärme MCU: offen auf dem Schreibtisch, kann also nicht das Hauptproblem sein.
Ich habe mir gestern Abend nochmal angeschaut was auf Github zum Stichwort BME680 so alles liegt - da ist nichts sinnvolles. Der überwiegende Anteil gibt nur den Widerstand aus. Zwei Libs machen noch ein wenig vodoo. Da wird 75% Widerstand und 25% RH verrechnet (nicht korrigiert) und daraus ein AIQ Index gewürfelt. Da kann aber imho nicht reelles rauskommen.
Ich komme mehr und mehr zu dem Eindruck das es in der freien Wildbahn gar keine funktionierenden Anwendungen gibt, zumindest im Sinne von dauerhafter Messung und Wertung des VOC. Das deckt sich ein Stück weit auch dem Feedback in diesem thread. Außer uns beiden scheint es auch hier niemanden zu geben der VOC Messungen sinnvoll produktiv im Einsatz hat. (Reines Widerstandswert anschauen zähle ich da nicht dazu)
ZitatIch komme mehr und mehr zu dem Eindruck das es in der freien Wildbahn gar keine funktionierenden Anwendungen gibt, zumindest im Sinne von dauerhafter Messung und Wertung des VOC.
Das deckt sich ein Stück weit auch dem Feedback in diesem thread.
Stimmt ...
ZitatReines Widerstandswert anschauen zähle ich da nicht dazu)
Ja, sehe ich auch so.
Mich stört die Versions-Vielfalt bei BSEC und der Aufwand, den man bei jedem Versionswechsel treiben muss, um die Static-Lib unterzubringen ... das nervt ...
(BSEC + platformio wäre auch noch so ein besonderes Thema für sich !!!)
Zur Genauigkeit der HUM-Werte im Hobby-Bereich wäre z.B. der DHT22-Sensors anzuführen, die Sensoren weichen bei meinen um mindestens +/- 25% ab.
Also auch nichts Genaues. Genaue HUM-Messungen sind auch ein Fall für sich ... (Kalibrieren + Korrigieren?)
Apropos "Korrigieren": da wird einem
param.t_offset und
param.h_offset wieder gewahr ... ;)
Zitat2 Thermometer unterschiedlicher Hersteller zeigen fast gleiche Werte an, der BME weicht um mehr als 5% Hum ab.
Wäre interessant zu wissen ob der BME wenigsten die Änderungen der Luftfeuchte analog zu den anderen Meßgeräten anzeigt.
Also nur Offsetbehaftet ist.
Gegencheck:
Samstag, 24.08.2019, 14:36 Uhr
Lufttemperatur
27,0 °C
Fühltemperatur
29,5 °C
Luftdruck
1005,1 hPa (1022 bezogen auf NN)
Luftfeuchtigkeit
40,8 %
Niederschlag
0,0 mm (in den letzten 10 Minuten)
0,0 mm (heute insgesamt)
Windstärke
3 Bft bzw. 11,35 km/h (Mittel der letzten 10 Minuten, Maximum war 15,3 km/h)
Windrichtung
Nordost (32°)
Globalstrahlung
744,52 W/m²
ESPEasy-Werte:
Temperature:25.55
Humidity: 51.50
Pressure: 1007.35
Gas:32.75
Na ja, innerhalb der Wohnung könnte der höhere HUM-Wert erklärbar sein ...
Angefügt "SLINK"... = Dein Algorithmus [PPM] und die LaCrosse-Gateway-Variante [IAQ], Wetterstation + Serial-BME680-Modul (Vermutlich mit BSEC).
Im Vergleich macht Dein Algorithmus doch eine gute Figur, oder? (Spiegelt meiner Meinung nach auch die Gegebenheiten gut wieder: z.B. Rolladen öffnen etc. )
Hallo Jörg,
bin etwas weiter ...
Hier der gestraffte Algo.
Fürs Reengineeren fehlen Deine Meßreihen ... ;)
Das Filtern und die Approximation muss ich mir noch anschauen.
Dann kann ich eine Arduino-Library daraus machen, welche sich dann einfacher in Projekte (ESPEasy) einbinden lässt ....
Das würde in dieser Form auch schon gehen, ggf. würde ich den Kalman-Filter einsetzen wollen ... ;)
Jürgen
Die Messreihen habe ich auch schon lange entsorgt. Approximation kommt daher dass ich die ganzen Messreihen in Wolfram Alpha getankt habe. Je nach Messreihe gab es da natürlich eine Varianz und der gemittelte Wert war etwas krummer. Die 1250 waren und sind aber gut genug. Die Kunst liegt ja viel mehr in der baseline und der Kompensation von T und H.
in den Bild oben, der Lacrosse, läuft der mit der BSH LiB? Der Zacken wäre ja echt total unrealistisch .. (?)
Wie lange läuft die Slink Variante denn so schon durch (in Tagen, Wochen, Monaten :D) ? Die ppm Werte da sind ja im Bereich wo man sie auch erwartet. Wenn der schon lange so läuft dann ist die Kompensation wirklich gut. Wenn das Monate sind dann schlägt das auch den IAQ Core ...
ZitatWie lange läuft die Slink Variante denn so schon durch (in Tagen, Wochen, Monaten :D) ?
Würde sagen seit Ende 2018 (20.11.2018) und das sehr zuverlässig und gut ....
ZitatDie ppm Werte da sind ja im Bereich wo man sie auch erwartet. Wenn der schon lange so läuft dann ist die Kompensation wirklich gut.
Ja korrekt! ;) :D
Die Zacken in der Gateway sind komischerweise nur tagsüber vorhanden. Möglicherweise überschneiden sich da Telegramme
mit anderen LaCrosse-Sensoren (868 MHz). Das sind 2 BME680 Sensoren nanoLGW (https://forum.fhem.de/index.php/topic,51329.180.html) die mit LGW-Universalsensor und einer älteren SW-Variante mit speziellem Sketch.
Dann benötigen wir Meßreihen zu den HUM-Werten ...
Nur um Missverständnissen vorzubeugen: ich meine durchgehend laufen. Das heißt die Baseline Korrektur arbeiten fast 8 Monate am Stück... Und tut ihren Job
Mehrere Tage...
Zur Ehrenrettung der LGW-Senoren: sie liegen auf dem Fensterbrett mit unruhigeren Luftverhältnissen ... ;)
Perfomance-technisch stößt mein Raspi3 für die Auswertung hier an Grenzen ....
Kannst du eventuell einen vergleichbaren Plot aus Feb Mär oder so erzeugen. Hauptsache halt mit komplett anderem Wetter. Kalt und trocken wären ideal
Zitat von: juergs am 19 August 2019, 22:02:04
... nach dem ESPEasy nun nicht ganz leicht zu compilieren ist ...
komisch, ich habe am Freitag mal alle Bibliotheken in meine (portable) Arduino IDE installiert, den MAX44009 und noch ein Plugin installiert und compiliert - ging problemlos. Ich muss mal schauen, ob ich wirklich die richtige ESPEasy Version genommen habe 8)
Gruß Peter
Hallo Peter,
hatte bei meiner Arduino-Ide so viele Fehlermeldungen, dass ich das aufgegeben habe.
.. und ich meine nicht die Standard-Edition, sondern die Version mit Extra-Plugin aus dem Playground... da fingen die "Probleme/Hürden" an ;D
Der Vorteil bei platformio ist, dass man libs auch lokal, quasi als Versions-Momentaufnahme im Projektverzeichnis halten kann.
Das scheint mir ein großer Vorteil gegenüber statischer zentraler Libraries zu sein ...
D.h. man muss nicht wie bei Arduino-Projekten üblich die richtigen Libs in der richtigen Version zusammensuchen,
damit es passt. Meist werden die Quellen der Libs und deren Version einfach "vergessen" mit anzugeben ....
Immerhin habe ich mich auf platformio mit VSCode eingearbeitet, welches wegen der CodeCompletion und Projektstruktur bei größeren Projekten schon sehr hilfreich sein kann.
Für MS-Nichtmöger: https://vscodium.com/ (https://vscodium.com/) ;)
Moin,
ich habe am Wochenende das ganze mal mit dieser Anleitung versucht. https://wiki.dfrobot.com/Gravity__I2C_BME680_Environmental_Sensor__VOC,_Temperature,_Humidity,_Barometer__SKU__SEN0248 (https://wiki.dfrobot.com/Gravity__I2C_BME680_Environmental_Sensor__VOC,_Temperature,_Humidity,_Barometer__SKU__SEN0248)
nur leider bekomme ich diverese Fehler beim Kompilieren was bsec angeht.
schade
Hallo Mc_Arthur,
wenn immer alles so einfach wäre!
Einige Dinge gehen nicht ohne eigene Anstrengungen!
Z.B. hier im Forum mal nach "BSEC" suchen, ich denke da wirst Du mit Sicherheit fündig, wie man das installiert.
Lib: https://github.com/DFRobot/DFRobot_BME680 (https://github.com/DFRobot/DFRobot_BME680)
BSEC: https://github.com/BoschSensortec/BSEC-Arduino-library (https://github.com/BoschSensortec/BSEC-Arduino-library)
https://www.bosch-sensortec.com/bst/products/all_products/bsec (https://www.bosch-sensortec.com/bst/products/all_products/bsec)
https://github.com/t-pi/Octopus_BSEC (https://github.com/t-pi/Octopus_BSEC)
ime(ms) :268766
temperature(C) :52.00
pressure(Pa) :100374.00
humidity(%rh) :0.00
altitude(m) :93.68
calibrated altitude(m) :179.37
gas resistance :220062.00
IAQ not ready, please wait about 5 minutes
time(ms) :628830
temperature(C) :52.00
pressure(Pa) :100374.00
humidity(%rh) :0.00
altitude(m) :93.68
calibrated altitude(m) :179.37
gas resistance :228299.00
IAQ :27.00 good
time(ms) :1303951
temperature(C) :52.00
pressure(Pa) :100378.00
humidity(%rh) :0.00
altitude(m) :93.34
calibrated altitude(m) :179.03
gas resistance :225332.00
IAQ :43.00 good
time(ms) :2046582
temperature(C) :53.00
pressure(Pa) :100389.00
humidity(%rh) :0.00
altitude(m) :92.42
calibrated altitude(m) :178.12
gas resistance :220652.00
IAQ :72.00 average
Anbei das Binary für I2C-Addresse: 0x76 und Wemos D1 mini (ESP8266, 115200Bd)
Ein neuer Sensor muss ca. 4 Tage "einbrennen". Direkt nach dem Start zeigt er nach ca. 5 Minuten IAQ= 25 an, geht dann auf 0 und kommt erst nach weiteren 2-3 Minuten mit dem gemessenen IAQ.
Den Fehler mit der Feuchtigkeit+Temperatur konnten sie immer noch nicht beseitigen ;-(
Ich hatte mich noch nicht weiter auf die Suche gemacht... Danke werd ich mal schauen.
Habe aber u.a. diese Lib installiert.....https://github.com/DFRobot/DFRobot_BME680 (https://github.com/DFRobot/DFRobot_BME680)
mehr noch nicht. aber danke werde dann die anderen die du aufgelistet hast mal installieren und dann testen.
hatte ich das jez richtig verstanden, das ihr an einer ESP EASY version dran seid ?
Bekomme das normale BME680 auf den Wemos ohne Probleme .
Wenn es aber an das iaq geht ... bekomm ich wegen dem bsec nur Fehler . Obwohl die Libs drin sind .
Auch glaube ich macht mir der Umgang mit meinem MacBook etwas zu schaffen . Bin das noch nicht ganz gewöhnt ....
Lasst uns bitte aufpassen das wir den thread für "tVOC Sensoren / Erfahrungen" offen lassen. Lasst uns doch bzgl Themen zur Implementierungen jeweils neue threads öffnen.
Bezüglich neuen Implementierungen:
Die Arduino-Library ist da: https://forum.fhem.de/index.php/topic,78619.msg971012.html#msg971012 (https://forum.fhem.de/index.php/topic,78619.msg971012.html#msg971012)