Seit einiger Zeit beobachte ich das Geschehen um CO2/VOC-Luftgüte-Sensoren, auch um den relativ neuen BME680 Sensor von Bosch sensortec,
mit diesen Eckdaten (https://download.mikroe.com/documents/datasheets/BME680.pdf):
Zitat
Bosch BME680 Integrated Environmental Sensor (Air Quality, Humidity, Pressure and Temperature)
Temperature Sensor -40...85°C
Pressure Sensor 300...1100hPa (+9000...-500m above/below sea level)
Humidity Sensor 0...100%
Accuracy tolerance: +/-3 % relative
Hysteresis: <1.5% relative
Gas Sensor for Air Quality (IAQ)
SPI Interface (up to 10MHz)
TWI/I2C Interface (address 0x76 when SDO=0 or 0x77 when SDO=1, CS=1 for I2C)
3.3V - 5V Power Supply and Logic Level
Hardware: BME680-Breakout (https://github.com/watterott/BME680-Breakout) oder nur 3V3-Typ oshpark DIY (https://oshpark.com/shared_projects/LXuNziGd)
Da es aber Softwaremässig eher bescheiden um den Sensor bestellt ist, möchte ich Euch mein Projekt
schon in der Anfangsphase vorstellen.
Die von Sensortec vorgestellte Software BME680_driver (https://github.com/BoschSensortec/BME680_driver) ist durchaus etwas
zu "kompliziert", umfangreich und zu allgemein gehalten, um gleichzeitig auch in die Tiefen von I2C und dem Sensor einzusteigen.
Deshalb hier erst mal die "einfachere" Lösung mit Breakboard und Arduino NANO um in das Thema einzusteigen.
Software:1. Schritt: Implementierung der Grundfunktionalität für das Breakout-Board.
Hardware setup:
VCC ----------------------- NANO.5V
SDA ----------------------- NANO.A4 = PC5
SCL ----------------------- NANO.A5 = PC4
CS ------------------------ High (select i2c-Interface)
GND ----------------------- NANO.GNDErstes-Ergebnis:
ZitatOpening port
Port open
Scanning...
Ok, I2C device found at address 0x77 !
done
BME680 I am: 61 I should be 61
Calibration coeficients:
dig_T1 =26583
dig_T2 =26571
dig_T3 =3
dig_P1 =35016
dig_P2 =-10322
dig_P3 =88
dig_P4 =5660
dig_P5 =17
dig_P6 =30
dig_P7 =19
dig_P8 =200
dig_P9 =-3762
dig_P10 =30
dig_H1 =773
dig_H2 =1011
dig_H3 =0
dig_H4 =45
dig_H5 =20
dig_H6 =120
dig_H7 =-100
dig_GH1 =-29
dig_GH2 =-13303
dig_GH3 =18
gas wait time = 0x59
resistance Heat = 20
CTRL_GAS_1 = 0x10
gas wait = 0x59
res heat = 0x20
New data in field 0!
Gas measurement Index = 0
gas range = 4
BME680:
Altimeter temperature = 21.84 C
Altimeter temperature = 71.31 F
Altimeter pressure = 1007.93 mbar
Altitude = 145.55 feet
Altimeter humidity = 49.0 %rH
Gas Sensor raw resistance = 0
Gas Sensor resistance = 806516.4 Ohm
New data in field 0!
Gas measurement Index = 0
Field 0 gas data valid
Gas measurement Index = 0
Field 0 gas data valid
gas range = 0
BME680:
temperature = 21.87 C
temperature = 71.37 F
pressure = 1007.85 mbar
Altitude = 147.74 feet
humidity = 48.9 %rH
Gas Sensor raw resistance = 0
Gas Sensor resistance = 12917166.0 Ohm 2. Schritt: Abwägen der existierenden Libraries.
Hier die Library für das Breakout-Board:
BME680_Library (https://github.com/vicatcu/BME680_Breakout/tree/master/BME680_Library). Das ist der gesuchte Wrapper um den (original) BME680_driver (https://github.com/BoschSensortec/BME680_driver)
In "BME680_V2" (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=87706) hab ich die BME680-Library zusammen gepackt und etwas "angepasst".
3.Schritt. Umschwenken auf BSEC mit dem ESP8266(nodeMCU)
macht noch Ärgen mit fiesem WDT-Fehler ... Erst mal ausgesetzt.
4. Schritt: Datenübertragung mittels Standard- 433MHz-OOK-Sender an FHEM:
Der Prototyp mit 433 MHz Lacrosse Protokoll ist fertig.
Der Sender wird an D13 angeschlossen, wenn D10 gegen GND gejumpert wird dann zeigt der Serial-Output auch ein Timestamp an.
Der CO2-Wert pegelt sich bei mir um die 120.000 ein, deshalb teile ich dur 10.000 um in den übertragbaren Wertebereich zu kommen.
Die Datenübermittling wird per Interrupt alle 30 Sekunden übertragen, da sich heraus gestellt hat, dass der Sensor häufiger abgefragt werden muss,
wohl um seine Betriebstemperatur zu stablisieren...
Der Sensor baut zwei Devices auf:
ID 100 - Kanal 1: Temperatur
Kanal 2: Luftfeuchte
ID 101- Kanal 1: CO2 Widerstand als Roh-Sensor-Wert
Kanal 2: als gemittelter Sensorwert.
Hardware:
D13 => | 433MHz-OOK-Modul-DATA-Pin |
D10 => | Jumper gegen GND = Debugausgaben mit Text, offen = nur Zahlen für Plotanzeige |
Die Werte für Temperatur, Luftfeuchte sind nicht gemittelt. Den Luftdruck habe ich erst mal zu Gunsten
der CO2-Ausgabe geopfert. In Zukunft wird sich aber der gemittelte Wert eher anbieten.
Dann werde ich den Luftdruck mit übertragen.
Das ist mal die erste Variante mit einem Nano, bis ich den WDT-Fehler beim ESP gefunden habe.
Evtl. lassen sich dann auch die Relation Richtung IAQ und ppm finden ...
Verbesserte Variante in der Version 2.1.
Schritt 5: Einbindung AMS iAQ-core Sensor, der ebenfall Resistance, CO2 [ in ppm] und tvoc - nach intern implementierten Algorithmus schon überarbeitete Daten liefert.
Um die Ausgaben des BME680 korrelieren zu können. Ebenfalls Einbindung über TX3-LaCrosse-Protokoll bis dato.
Den passenden Code "iAQ-NANO-LACROSSE-TX3" dazu habe ich hier hier bei Github (https://github.com/juergs/iAQ_NANO_328_LaCrosse) veröffentlicht.
Schritt 6: Überarbeitung des BME680-Codes und Anpassung auf den ESP8266, um die Ausreißer-Werte und das nervige WDT-Problem (https://forum.fhem.de/index.php/topic,78931.0.html) zu eliminieren ...
/edit 20181226: Implementierung als "UniversalSensor" mit RFM69CW/868Mhz und LaCrosseGateway: https://forum.fhem.de/index.php/topic,78619.msg876544.html#msg876544 (https://forum.fhem.de/index.php/topic,78619.msg876544.html#msg876544)
/edit 20190430: Einbindung BME680 in OLED-Wetterstation (https://forum.fhem.de/index.php/topic,52403.msg934892.html#msg934892) mit TFT-Display.
/edit 20190921: Implementierung mit ESPEasy (MQTT + SLINK) + WLAN. Mit entsprechender Konfigurationsmöglichkeiten und Filterung.
https://forum.fhem.de/index.php/topic,78619.msg974829.html#msg974829 (https://forum.fhem.de/index.php/topic,78619.msg974829.html#msg974829) und
hier: https://forum.fhem.de/index.php/topic,78619.msg984732.html#msg984732 (https://forum.fhem.de/index.php/topic,78619.msg984732.html#msg984732)
ESPEasy-Code + Erläuterungen dazu: https://github.com/juergs/ESPEasy_BME680_TVOC (https://github.com/juergs/ESPEasy_BME680_TVOC)
Für
UDP-SLINK-Betrieb ein
define slink SLink für Device autocreate definieren.
Für
MQTT2 ein mqtt2_client-Device definieren:
Internals:
BUF
DEF 127.0.0.1:1883
DeviceName 127.0.0.1:1883
FD 4
FUUID 5d96097a-f33f-xxxx-9d65-6809e95ca4eddf32
NAME mqtt2_client
NR 144
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId mqtt2_client
lastMsgTime 1570286545.49909
nextOpenDelay 5
READINGS:
2019-10-03 17:57:11 state opened
Attributes:
room MQTT2_DEVICE Basierend auf diesem Device den MQTT2_CLIENT mit entsprechenden Topic-RegEx definieren:
ZitatInternals:
CID mqtt2_client
DEF mqtt2_client
DEVICETOPIC MQTT2_mqtt2_client
FUUID 5d83c849-f33f-72b0-xxxx-d8648a4fbbcc7191
IODev mqtt2_client
LASTInputDev mqtt2_client
MSGCNT 11296
NAME MQTT2_mqtt2_client
NR 131
STATE ???
TYPE MQTT2_DEVICE
mqtt2_client_MSGCNT 11296
mqtt2_client_TIME 2019-10-05 16:44:20
READINGS:
2019-10-05 10:44:59 ESP_Easy connected!
2019-10-05 16:44:20 Humidity 48.1
2019-10-05 16:44:20 Pressure 999.1
2019-10-05 16:44:20 TVOC 259.6
2019-10-05 16:44:20 Temperature 20.1
Attributes:
IODev mqtt2_client
disable 0
readingList mqtt2_client:fhem/out/LWT:.* LWT
mqtt2_client:Test/Temp:.* Temp
mqtt2_client:Connect:.* Connect
mqtt2_client:ESP_Easy:.* ESP_Easy
mqtt2_client:ESP_Easy/bme680/Temperature:.* Temperature
mqtt2_client:ESP_Easy/bme680/Humidity:.* Humidity
mqtt2_client:ESP_Easy/bme680/Pressure:.* Pressure
mqtt2_client:ESP_Easy/bme680/TVOC:.* TVOC
room MQTT2_DEVICE
Regex basierend auf MQTT-Definitionen im ESP_Easy-Device in der MQTT-Definitin der zu übertragenden Meßwerten:
Attribute:
readingList
mqtt2_client:fhem/out/LWT:.* LWT
mqtt2_client:Test/Temp:.* Temp
mqtt2_client:Connect:.* Connect
mqtt2_client:ESP_Easy:.* ESP_Easy
mqtt2_client:ESP_Easy/bme680/Temperature:.* Temperature
mqtt2_client:ESP_Easy/bme680/Humidity:.* Humidity
mqtt2_client:ESP_Easy/bme680/Pressure:.* Pressure
mqtt2_client:ESP_Easy/bme680/TVOC:.* TVOC/edit 202301151.) FHEM-Implementierung mit CC-Modul:
CustomSensor-Implementierung (@hdgucken) mittels LaCrosse-Gateway:
Zusammenfassung bzw. letzter Stand der CustomSensor (CC)-Implementierung und erforderliche FHEM-Module.
Hinweis: Diese Module sind
nicht Bestandteile des aktuellen FHEM-Repositorys und könnten bei einem Update überschrieben werden!
Deshalb lohnt es sich immer ein
Backup davon in Reserve zu halten! :(
In der noch aktuell + letzten Version befinden sich alle Sketche, Bins und Module in der angehängten Zip-Datei:
BME680_CC_SENSORAchtung: Auto-Erkennung der CCs ist in den Modulen nicht implementiert. D.h. manuell die Definition der CC-Devices selbst
manuell in der Fhem-Kommando-Zeile anlegen!
Beispiel der Konfiguration ist in der Zip-Datei enthalten. Die Dateien sind nach der übertragung noch auf User/Gruppe
fhem/dialout mittels
Zitatsudo chown fhem:dialout 36_*.pm
zu ändern.
2.) FHEM-Implementierung mit
SLINK-Modulen über WLAN/LAN mit ESPEasy
siehe Beschreibung:
/edit 20190921
[/list]
Eventuell sollten wir uns zusammentun.
Ich bin gerade hier
https://forum.fhem.de/index.php/topic,78128.msg700815.html#msg700815
dabei, den BME680 in das LaCrosseGateway zu integrieren.
Das läuft so weit auch schon, nur die Umrechnung des Widerstandswerts in die IAQ, fehlt noch.
Die Formel verrät Bosch seltsamerweise nicht.
Hallo HCS,
Danke fürs Feedback.
Für mich war heute erst Mal die Anbindung über I2C wichtig.
Morgen schaue ich mir Mal die Driver_FW genauer zu dem Thema an.
Hast Du schon einen weiteren SW-Stand?
Da können wir gerne zusammen kommen. :-)
Grüße
Jürgen
Hallo zusammen,
ich bin gerade am Komplettieren meines nano LGWs. Dauer leider ein bisschen, weil zu viele (unversandte) Platinen und Zeugs rumliegen :(
Gruß Peter
Hier die Arduino-Library für das Breakout-Board:
BME680_Library (https://github.com/vicatcu/BME680_Breakout/tree/master/BME680_Library). Das ist der gesuchte Wrapper um den BME680_driver (https://github.com/BoschSensortec/BME680_driver). Sowie Beispiele dazu.
Ebenfalls hier (https://github.com/DFRobot/DFRobot_BME680) und hier (https://github.com/kriswiner/BME680/blob/master/BME680_t3.ino).
Feines Projekt ! Freue mich auf Fortschritte und Endergebnis. Bin selber zu verhaftet in Betty, Samsung, Feinstaub.... und letzteres als Innensensor. Den BME680 direkt an den Wemos anschließen ?
Grüße Markus
Hallo Markus,
ZitatDen BME680 direkt an den Wemos anschließen
das wird gehen.
Habe mich aber noch nicht auf ein Transport-Medium festgelegt.
Hier gibt es z.B. ja auch noch: Vorgänger-Threads (https://forum.fhem.de/index.php/topic,20956.0.html) und hier AMS-IAQ (https://forum.fhem.de/index.php?topic=60204.0)
oder CUL_TX, Asksin, LGW, ESP etc. (mal schauen, zum gegebenen Zeitpunkt, was für FHEM mehr Sinn macht.)
Hier die Version mit der "Orginal"-Lib basierend auf dem sensortec-Code.
Habe alles in ein Verzeichnis gelegt um ein eigenständiges Projekt (ohne Arduino-Repository-Verweise) zu erzeugen.
In den Libs musste ich noch einiges anpasssen, dass sie unter VisualMicro compiliert werden können,
bzw. nicht dauernd Fehler (zB. int8_t unbekannt) anzeigen.
ZitatOpening port
Port open
BME Initialization...Succeeded!
Configuring Forced Mode...Succeeded!
Temperature(degC),Relative_Humidity(%),Pressure(hPa),Gas_Resistance(Ohms)
22.57,51.37,1004.47,0
22.72,51.43,1004.21,121377
22.69,51.30,1004.25,125656
22.66,51.26,1004.29,127570
22.65,51.27,1004.35,128451
22.63,51.27,1004.37,128648
Einige Dinge kann klar noch noch verbessern: z.B. die Normalisierung des Luftdrucks auf Meereshöhe ...
Diese Lib scheint die bessere Version zu sein. Jetzt geht es erst ma wieder ans Datenblatt um wie HCS schon erwähnte
die Bedeutung der Widerstandswerte herauszufinden und ob der Forced-Mode die richtige Betriebsvariante ist.
Nach Durchlesen der BME680-Dokumentation, werden Lösungen mit zwei "Ausbaustufen" : IAQ + ALL
mit den entsprechenden Algorithmen als Arduino-Code. (siehe S.21, Datasheet) :)
BSEC-code (https://www.bosch-sensortec.com/bst/products/all_products/BSEC) "Bosch Sensortec Environmental Cluster"
bsec_integration.c
bsec_integration.h
bsec_iot_example.c
bsec_iot_example.ino
doc_bsec_step_by_step.md
Zitat
C:.
├───algo
│ └───bin
│ ├───ARM_CORTEX
│ │ ├───ARMCC
│ │ │ └───IAQ_OUT
│ │ │ ├───Cortex_M0
│ │ │ ├───Cortex_M0+
│ │ │ ├───Cortex_M3
│ │ │ ├───Cortex_M4
│ │ │ └───Cortex_M4F
│ │ └───GCC
│ │ └───IAQ_OUT
│ │ ├───Cortex_M0
│ │ ├───Cortex_M0+
│ │ ├───Cortex_M3
│ │ ├───Cortex_M4
│ │ └───Cortex_M4F
│ ├───ESP8266
│ └───RL78
├───API
├───config
│ └───iot_lp_3_3v
├───Doc
└───example
Zitat- Available binaries for download - ARM CortexM0+,M3,M4,M4F,x86,x64
... und Arduino mit ESP ;)
@HCS:
Hier sollte die Vorgehensweise der Umrechnung beschrieben sein (siehe auch S.9 + 18ff. Datasheet) :
Zitat[300345.00] T: 33.30| rH: 22.73| IAQ: 25.00 (3)
[303346.00] T: 33.30| rH: 22.76| IAQ: 26.30 (3)
[306346.00] T: 33.26| rH: 22.81| IAQ: 27.90 (3)
[309346.00] T: 33.26| rH: 22.84| IAQ: 19.72 (3)
[312346.00] T: 33.20| rH: 22.93| IAQ: 25.02 (3)
[315346.00] T: 33.19| rH: 22.94| IAQ: 20.70 (3)
[318346.00] T: 33.14| rH: 22.97| IAQ: 28.80 (3)
=>Widerstandswert
=> IAQ_Index [0-50,51-100,101-150,151-200,201,300,301-500]
=> Air_Quality [good,average,little bad, bad, worse, very bad]
Aber: CO2-LED-Ampelanzeige: (bis 800 ppm: grün, 800-1200 ppm: gelb, über 1200 ppm: rot)
Mal schauen... und den "
BSECIntegrationGuide" (PDF im \Doc-Verzeichnis) durchwälzen...
Zitat von: juergs am 29 Oktober 2017, 14:09:57
... und Arduino mit ESP ;)
Hast Du eine Idee, wie man die libalgobsec.a einbindet?
Meiner Meinung nach gibt es die Berechnung der IAQ nur in precompiled libs.
https://github.com/BoschSensortec/BME680_driver/issues/6#issuecomment-337134651
Zitat von: juergs am 29 Oktober 2017, 14:09:57
Hier sollte die Vorgehensweise der Umrechnung beschrieben sein (siehe auch S.9 + 18ff. Datasheet) :
Das beschreibt nur, wie man den Senosr heizt und den Widerstandswert ausliest und berechnet.
Aber nicht, wie die IAQ daraus berechnet wird.
Hallo HCS,
ja sieht in der Tat so aus:
Zitatbsec_do_steps()
scheint nur in den precompiled libs zu existieren.
Dort werden die IAQ Berechnungen durchgeführt ...
Ich muss mich durch den "BSEC Integration Guide" duchkämpfen.
Was mich wundert ist, dass ein explizites Arduino-Beispiel mitgeliefert wird.
So eine adhoc Idee wäre, durch Referenzmessungen, sich einfach eine Funktion zu erstellen, welche
die Widerstandswerte in die IAQ-Kategorien umwandelt. (airco2ntrol (https://maker-tutorials.com/guenstiges-co2-messgeraet-airco2ntrol-im-test-1-raspberry-pi-fhem-usb/))
Vielleicht hast Du da schon mehr Erfahrungswerte in Bezug auf der Widerstands-Ausgabe ?
Letztendlich kommt es da nicht auf den IAQ-Absolutwert an (?) ...
Zitat von: juergs am 29 Oktober 2017, 18:33:10
Vielleicht hast Du da schon mehr Erfahrungswerte in Bezug auf der Widerstands-Ausgabe ?
Ein wenig. Siehe hier: https://forum.fhem.de/index.php/topic,78128.msg700815.html#msg700815
Ich kann zumindest ablesen (angehängtes Chart), wann meine Frau gekocht hat und wann gelüftet wurde.
Ich müsste mal die Fenster zu lassen, bis ich umkippe, um den Grenzwert zu ermitteln ;D ;D
Zitat von: juergs am 29 Oktober 2017, 18:33:10
Letzendlich kommt es da nicht auf den IAQ-Absolutwert an (?) ...
Denke ich auch. Wir brauchen ja nicht unbedingt eine "Bosch-Kompatible" IAQ, wenn die nicht verraten wollen, wie man sie berechnet.
ZitatIAQ, wenn die nicht verraten wollen, wie man sie berechnet.
Ja, magic... und ein riesen Aufwand für das Framework.
Die scheinen Angst vor den Chinesen zu haben ... :( :( :(
Über den "gas_range" scheint die Werteausgabe auch nicht kontinuierlich zu sein. (Siehe Seite 20, Tabelle 12) ...
Dann baue ich mal die Chart-Ausgabe für die Arduino-IDE ein und analysiere die Ergebnisse wie hier (https://forum.fhem.de/index.php/topic,60204.15.html) und hier (https://forum.fhem.de/index.php/topic,13166.0.html) mit Modul (https://forum.fhem.de/index.php/topic,41750.0.html)
vielleicht auch parallel mit dem IAQ-Sensor von AMS.
ZitatIch müsste mal die Fenster zu lassen, bis ich umkippe, um den Grenzwert zu ermitteln
Beim CO2-Sensor(Velux etc.) genügen 1-2 Zigaretten ;)
Zitatgenügen 1-2 Zigaretten
Das beste Beispiel für VOCs (Organic Volatile Compounds) :)
CO2-LED-Ampelanzeige: (bis 800 ppm: grün, 800-1200 ppm: gelb, über 1200 ppm: rot)
Die precompiled Libs wären z.B. für den STM32 (STM32F103CB) aus dem MapleCul möglicherweise geeignet ...
Dann wäre ein Umschwenken auf den Maple wohl sinnvoll ...
Zitat von: juergs am 29 Oktober 2017, 20:01:52
Dann wäre ein Umschwenken auf den Maple wohl sinnvoll ...
Für das LaCrosseGateway definitiv nicht. Aber eventuell um Referenzwerte zu produzieren.
Der erste Plot-Output mit Raw- und gleitendem Mittelwert.
https://www.umweltbundesamt.de/sites/default/files/medien/pdfs/kohlendioxid_2008.pdf (https://www.umweltbundesamt.de/sites/default/files/medien/pdfs/kohlendioxid_2008.pdf)
Apropos Chinesen: Modul-Luft-Air-Quality-Staub-Sensor-LCD-Anzeige-Monitor (https://www.ebay.de/itm/Haushalt-PM2-5-Detektor-Modul-Luft-Air-Quality-Staub-Sensor-LCD-Anzeige-Monitor-/122638587529?&_trksid=p2056016.l4276)
Kommentar:
Zitat
Im Alltag ist der CO2 Wert in einem Wohnraum meist im roten Bereich, ohne sich Sorgen machen zu müssen, sprich die Skala ist sehr streng ausgelegt).
AIQ-Index: https://en.wikipedia.org/wiki/Air_quality_index (https://en.wikipedia.org/wiki/Air_quality_index)
https://forum.mysensors.org/topic/7788/bosch-bme680-sensor (https://forum.mysensors.org/topic/7788/bosch-bme680-sensor)
@HCS: Einbindung precompiled libs
ZitatThe last step we need to do is to ensure that the pre-build `libalgobsec.a` library is linked when we compile our project. Unfortunately, this process is somewhat tricky when it comes to Arduino IDE. We first need to find where the board support package for our board is installed.
On Windows, this could be for example in `<USER_HOME>\AppData\Local\Arduino15\packages\esp8266\hardware` or in `<ARDUINO_ROOT>\hardware`. Once we found the location, we need to perform the following steps. Please keep in mind that the target paths might differ slightly depending on the ESP8266 package version you are using.
1. We need to copy the file `binaries\staticlib\ESP8266\libalgobsec.a` from the BSEC package into the `hardware\esp8266\2.3.0\tools\sdk\lib` folder.
2. The linker file found at `hardware\esp8266\2.3.0\tools\sdk\ld\eagle.app.v6.common.ld` needs to be modifed by inserting the line `*libalgobsec.a:(.literal .text .literal.* .text.*)` after the line `*libm.a:(.literal .text .literal.* .text.*)`.
3. Finally, we need to change the linker argument, telling the linker to include BSEC. This is achieved by adding the argument `-lalgobsec` to the line `compiler.c.elf.libs=-lm -lgcc ...` found in `hardware\esp8266\2.3.0\platform.txt`.
Dann sollte eine Vergleichs-Variante mit dem ESP8266 (http://fab-lab.eu/octopus/) möglich sein. :)
Zitat von: juergs am 30 Oktober 2017, 11:12:43
Dann sollte eine Vergleichs-Variante mit dem ESP8266 möglich sein
Ja, ich habe den BSEC gestern Abend auf dem 8266 zum laufen bekommen.
Und gleich festgestellt, dass meine Widerstandsberechnung auch nicht stimmt.
Aber damit kann man evtl. Vergleiche anstellen, wie sich die IAQ bezüglich Widerstand und rH verhält.
Habe sie noch erweitert, um den Widerstand mit auszugeben (Gas:).
Es dauert einige Minuten, bis die BSEC anfängt, eine IAQ zu liefern.
Sieht dann so aus:
[459268.00] T: 20.69| rH: 53.80| IAQ: 37.18 (3)| Gas: 1705.81
[462268.00] T: 20.70| rH: 54.05| IAQ: 47.76 (3)| Gas: 1686.11
[465268.00] T: 20.69| rH: 54.24| IAQ: 57.98 (3)| Gas: 1668.97
[468268.00] T: 20.68| rH: 54.41| IAQ: 64.52 (3)| Gas: 1657.38
[471268.00] T: 20.69| rH: 54.50| IAQ: 69.20 (3)| Gas: 1649.06
[474269.00] T: 20.68| rH: 54.60| IAQ: 71.25 (3)| Gas: 1644.93
[477269.00] T: 20.67| rH: 54.70| IAQ: 77.16 (3)| Gas: 1635.71
[480269.00] T: 20.65| rH: 54.86| IAQ: 78.94 (3)| Gas: 1632.66
[483269.00] T: 20.66| rH: 54.88| IAQ: 84.28 (3)| Gas: 1623.58
[486269.00] T: 20.65| rH: 54.95| IAQ: 85.60 (3)| Gas: 1621.58
[489269.00] T: 20.63| rH: 55.04| IAQ: 88.93 (3)| Gas: 1616.59
[492269.00] T: 20.62| rH: 55.11| IAQ: 89.28 (3)| Gas: 1615.59
[495269.00] T: 20.84| rH: 55.60| IAQ: 250.00 (3)| Gas: 909.62
[498269.00] T: 21.12| rH: 57.56| IAQ: 388.20 (3)| Gas: 606.41
[501269.00] T: 21.36| rH: 58.37| IAQ: 437.31 (3)| Gas: 521.63
[504269.00] T: 21.53| rH: 59.59| IAQ: 476.07 (3)| Gas: 461.52
[507269.00] T: 21.45| rH: 60.56| IAQ: 492.55 (3)| Gas: 439.29
[510270.00] T: 21.56| rH: 59.64| IAQ: 500.00 (3)| Gas: 427.84
[513270.00] T: 21.46| rH: 58.98| IAQ: 500.00 (3)| Gas: 423.98
[516270.00] T: 21.36| rH: 57.85| IAQ: 500.00 (3)| Gas: 426.18
[519270.00] T: 21.23| rH: 57.01| IAQ: 500.00 (3)| Gas: 431.21Ich habe den Sensor mal heftig eingenebelt, um eine Reaktion hervorzurufen.
Anbei die firmware, damit könnt ihr selbst mal testen.
Hallo HCS, super!
4 Tage "BurnIn"-Zeit für den Sensor sind zu veranschlagen. :D
ZitatThe IAQ scale ranges from 0 (clean air) to 500 (heavily polluted air). During operation, the algorithms automatically calibrate
and adapt themselves to the typical environments where the sensor is operated (e.g., home, workplace, inside a car, etc.).
This automatic background calibration ensures that users experience consistent IAQ performance. The calibration process
considers the recent measurement history (typ. up to four days) to ensure that IAQ ~ 25 corresponds to "typical good" air
and IAQ ~ 250 indicates "typical polluted" air.
ZitatEs dauert einige Minuten, bis die BSEC anfängt, eine IAQ zu liefern.
Ja, wegen Ringpuffer ...
So, habe die BIN geflasht und an den Raspberry Pi rangehängt. Diesmal ist die Baudrate 115200 baud ;), d.h. der Code lautet:
sudo stty -F /dev/ttyUSB1 115200
sudo cat /dev/ttyUSB1 > /tmp/bme680.txt &
dann kommt (ohne das > ...) Folgendes raus:
[126249.00] T: 28.88| rH: 31.40| IAQ: 0.00 (0)| Gas: 68330.16
[129249.00] T: 28.85| rH: 31.46| IAQ: 0.00 (0)| Gas: 68497.20
[132249.00] T: 28.81| rH: 31.55| IAQ: 0.00 (0)| Gas: 69287.61
Gruß PeMue
Edit:
Lüften scheint echt zu helfen (IAQ zwischen 1 700 000 und 2 400 000) ;D bzw. vorher kurz dagegengeblasen. Ich sollte den Raspberry Pi vielleicht mal im Schlafzimer aufstellen ???
Zitat von: PeMue am 30 Oktober 2017, 15:45:23
Diesmal ist die Baudrate 115200 baud
Das habe ich vergessen zu sagen ... :)
Zitat von: PeMue am 30 Oktober 2017, 15:45:23
Lüften scheint echt zu helfen
Das hätte ich dir auch ohne BME680 sagen können ;D ;D ;D
Der Kalibrierungsprozess von vier Tagen ist mir noch etwas suspekt. Das kann ja die Werte der vier Tage nur im RAM haben. Bedeutet das, dass, wenn man die Spannugsversorgung getrennt hatte, eneut vier Tage Kalibrierung erforderlich sind?
Lotet der algo vier Tage lang die obere und untere Grenze aus?
Eventuell sollten wir versuchen herauszubekommen, welcher Widerstandswert wieviel ppm Schadstoff entspricht und dann unsere eigenen Schlüsse ziehen.
Die libalgobsec.a und das irre framework von Bosch scheiden für das LGW eh aus.
Zitat von: HCS am 30 Oktober 2017, 17:40:57
... herauszubekommen, welcher Widerstandswert wieviel ppm Schadstoff entspricht und dann unsere eigenen Schlüsse ziehen.
Die libalgobsec.a und das irre framework von Bosch scheiden für das LGW eh aus.
Zitatbsec_codegen_do_steps.o/
bsec_codegen_get_configuration.o/
bsec_codegen_get_state.o/
bsec_codegen_get_version.o/
bsec_codegen_init.o/
bsec_codegen_reset_output.o/
bsec_codegen_rtwutil.o/
bsec_codegen_sensor_control.o/
bsec_codegen_set_configuration.o/
bsec_codegen_set_state.o/
bsec_codegen_update_subscription.o/
bsec_interface.o/
constructor_bsec.o/
convertHumidity.o/
ExpSmoothingBsec.o/
GasHumidityBaselineTracker.o/
GasHumidityPreProcessor.o/
HumidityTemperatureCorrector.o/
normalizeFilterBw.o/
RingBufferBsec.o/
SensorHeatCompensator.o/
SensorStatusTracker.o/
absHum.o/
Da ist Temperatur und Feuchte ebenfalls darin "vermauschelt".
Das wird mathematisch interessant. ;)
Entäuschend, dass sensortec nur die 32-Bitter im Fokus hat...
Der ESP-Compile ist mir jetzt endlich auch gelungen!
:D
Liebe Boschler, das wäre auch
einfacher zu machen gewesen!
ZitatOnce we are set with our hardware and development environment, we need two pieces of software to get the most out of our BME680 sensor
Das hat mich in die Irre geleitet und hatte die bme680.c + .h aus dem BME680-Driver genommen.
Ist nicht notwendig: die Richtigen Basis-Dateien liegen im "\API"-Verzeichnis des BSEC-Frameworks.
Dann muss ich noch schauen, ob ich mein ESP8266 endlich geflasht bekomme.
@Peter, HCS
Wie habt Ihr den ESP verbunden?
Grüße
Jürgen
Zitat von: juergs am 30 Oktober 2017, 22:13:03
@Peter, HCS
Wie habt Ihr den ESP verbunden?
Ich habe einen nanoCUL, der aber dieselbe Beschaltung hat wie z.B. der NodeMCU. Dann per USB mit dem NodeMCU Flasher oder dem ESPTool flashen.
Gruß PeMue
Meiner läuft jetzt schon einige Stunden mit. Fing mit IAQ Werten um 25-30 an ging dann hoch bis 180,
jetzt ist er wieder bei ca. 110. Schwingt sich wohl gerade ein :)
Bild vom aktuellen Stand:
Zitat von: KölnSolar am 29 Oktober 2017, 19:21:05
Beim CO2-Sensor(Velux etc.) genügen 1-2 Zigaretten ;)
Ich weiss ja nicht was du rauchst, aber der einfachste Weg das Ding auf Anschlag zu bringen, ist den Sensor kurz an der Spiritus-Flasche schnüffeln zu lassen.
tutorial-multiple-values-in-the-arduino-ide-serial-plotter (https://www.norwegiancreations.com/2016/01/tutorial-multiple-values-in-the-arduino-ide-serial-plotter/)
ZitatWhen the serial plotter receives a line break, it plots all values on that line as one time step. Each variable need to be seperated by either a comma, tab or a space (might work with other characters as well).
oder TelemetryViewer (http://www.farrellf.com/TelemetryViewer/) zum Speichern der Daten als CSV.
Beispiel: Öffnen- und Schließen des Fensters.
Zitat von: juergs am 30 Oktober 2017, 18:37:07
Da ist Temperatur und Feuchte ebenfalls darin "vermauschelt".
Das wird mathematisch interessant. ;)
Mir ist noch unklar, ob Temperatur und Feuchte zur Kompensation oder als Wohlfühlanteil eingerechnet werden.
Jetzt wäre zu klären, was wir eigentlich als Ergebnis wollen. Mir schwebt da eher die reine Schadstoffkonzentration vor.
Einen Wohlfühlwert kann man dann in FHEM immern noch aus VOC, rH und Temperatur berechnen, sofern man will.
ZitatJetzt wäre zu klären, was wir eigentlich als Ergebnis wollen. Mir schwebt da eher die reine Schadstoffkonzentration vor.
Einen Wohlfühlwert kann man dann in FHEM immern noch aus VOC, rH und Temperatur berechnen, sofern man will.
Ja, wäre der übernächste Schritt (nach Funkanbindung). Auch die PPM-Angabe wäre interessant, da sie konkreter zu schein scheint
wie der IAQ-Wert. (kaum hat man den IAQ-Wert, schon will man mehr... ;) )
Hatte aus Zeitmangel, nicht intensiver in Euer ESP-LGW-Projekt geschaut.
D.h. muss mich mit dem ESP erst mal (wieder) im Info-Dchungel dazu orientieren
und baue mir ein neues ESP-System auf. Mein NodeMCU scheint nicht reagieren zu wollen.
Zur Klarheit, für mich als ESP-(Wieder-)Einsteiger:
Nodemcu Firmware-Programmer auf Dev-Kit1:
1.) die "Test680.bin"-Datei auf Adresse 0x00000 flashen
2.) mit folgenden Einstellungen: Bitrate 115200, Flashsize 4M, Flashspeed 80MHz, SPImode DIOKommen die Debug-Ausgaben über eine andere Serielle?
Bin mir nicht sicher, ob vorher noch nodemcu.bin geflasht werden muss oder nicht...
Da mein System keine Ausgaben mehr danach macht.
Habe allerdings den Sensor noch nicht angeschlossen. Also fange ich erst mal mit "Blink" an. :'(
Zitat//
... //--- globales Objekt
movingAvg IAQ;
....
---hier der gleitende Mittelwert in loop()
IAQ.reading(bme680.getGasResistance());
Serial.print(IAQ.getAvg()); // int
Serial.println();
Anbei die angepasste Lib.
Ah, ... und die Includes nicht zu vergessen:
#include "utility\movingAvg.h"
@juergs: meine NodeMCU wollte mit der zweiten Firmware von HCS auch erst nicht so richtig, nach dem dritten flashen gings dann.
Einfach zwei drei mal probieren. Im NodeMCU Flasher alles auf "standard" lassen, die *.bin ab Adresse 0x00000 laden
bei "default" ist die Baudrate 230400, Speed 40MHz, müsste aber auch mit 115200 und 80 MHz gehen.
Hallo Jürgen,
Zitat von: juergs am 31 Oktober 2017, 09:25:27
1.) die "Test680.bin"-Datei auf Adresse 0x00000 flashen
2.) mit folgenden Einstellungen: Bitrate 115200, Flashsize 4M, Flashspeed 80MHz, SPImode DIO
Passt, siehe auch das angehängte Bild.
Zitat von: juergs am 31 Oktober 2017, 09:25:27
Kommen die Debug-Ausgaben über eine andere Serielle?
Nein, aber ggf. den NodeMCU stromlos machen.
Zitat von: juergs am 31 Oktober 2017, 09:25:27
Bin mir nicht sicher, ob vorher noch nodemcu.bin geflasht werden muss oder nicht...
Nein, ist nicht notwendig. Falls der NodeMCU schon öfter geflasht wurde, lohnt es sich, den Speicher komplett zu löschen.
Zitat von: juergs am 31 Oktober 2017, 09:25:27
Da mein System keine Ausgaben mehr danach macht. Habe allerdings den Sensor noch nicht angeschlossen. Also fange ich erst mal mit "Blink" an. :'(
Ich denke, dann kommt auch nichts über die serielle Schnittstelle. Also Sensor anschließen und nochmal probieren.
Sind denn momentan alle BME680
breakout boards verkauft :o?
Gruß Peter
Edit:Angehängt die Ergebnisse von gestern bis heute morgen. Man sieht, wann das Wohnzimmer (radikal) gelüftet wurde. Ich komme immer mehr zu dem Schluss, dass der BME680 doch noch funktioniert ;D
Vielen Dank an alle ! :D
Hatte den ESP doch schon etwas länger vernachlässigt ... :'(
Hatte auch die Buttonlogik noch außen vor gelassen (Flash + Reset).
Zitatden Speicher komplett zu löschen
mit
INTERNAL://BLANK vermutlich....
ZitatSind denn momentan alle BME680 breakout boards verkauft?
Uuups !!! ???
Ich habe mir das Octopus-Board als Alternative bestellt:
https://www.tindie.com/products/FabLab/iot-octopus-badge-for-education-and-innovation/ (https://www.tindie.com/products/FabLab/iot-octopus-badge-for-education-and-innovation/)
Allerdings für 35,50 € teurer als das Breakboard aber mit
BME680 + BME280 on board .... :'(
Der Lieferant sitzt übrigends in Stuttgart ... ;)
Wollte nicht warten, deshalb läuft der Lötkolben heiß ... ;D
Oder die OSH-Park-Platinen #1 (https://oshpark.com/shared_projects/yRIhJcpg) + #2 (https://oshpark.com/shared_projects/LXuNziGd) selbst bestücken (https://forum.fhem.de/index.php/topic,78593.0.html), woher bekommt man die BME-Chips in kleineren Stückzahlen?
Wobei die #1-Variante eine "von Hand" Lötbarkeit suggeriert?
Zitat von: juergs am 31 Oktober 2017, 11:29:52
mit INTERNAL://BLANK vermutlich....
ich würde es mit
epstool --port COM3 erase_flash
machen
Mit der seltsamen NodeMCU-Software hat es kürzlich schon mal jemand nicht richtig leer bekommen.
NodeMCU_V1-I2C-Pinout:
Zitat
I2C Backpack to NodeMCU Connections
I2C Backpack GND Pin to NodeMCU GND Pin
I2C Backpack VSS Pin to NodeMCU 5Vin / 5V 3V3 Pin
I2C Backpack SCL Pin to NodeMCU D1 Pin
I2C Backpack SDA Pin to NodeMCU D2 Pin
?
ZitatThe default pins are defined in variants/nodemcu/pins_arduino.h as SDA=4 and SCL=5, but those are not pins number but GPIO number, so since the pins are D1=5 and D2=4.
Anyway, you can also choose the pins yourself using the I2C constructor Wire.begin(int sda, int scl);
?
Wire.begin(); also Default-Belegung.
https://www.haustechnikdialog.de/Forum/t/197255/Schlafzimmer-CO2-Wert-von-408-auf-2900 (https://www.haustechnikdialog.de/Forum/t/197255/Schlafzimmer-CO2-Wert-von-408-auf-2900)
@juergs: NodeMCU_V1-I2C-Pinout: ?
Ja, D1 ist SCL, D2 ist SDA.
@PeMue:
Zitat von: PeMue am 31 Oktober 2017, 10:22:07
Sind denn momentan alle BME680 breakout boards verkauft :o?
Ja, scheint so. Wollte auch noch ein zwei BlueDot's bestellen, ausverkauft :'(
Zitat von: juergs am 31 Oktober 2017, 12:39:56
NodeMCU_V1-I2C-Pinout: ?
Ja, D1 ist SCL, D2 ist SDA.
Ja, I2C (mit HCSs + meinem Compile) läuft (bekanntes Signalbild, aber "schlechter" als beim Nano), aber es kommen (noch) keine seriellen Ausgaben über USB ...
Zitat von: juergs am 31 Oktober 2017, 13:47:43
... aber "schlechter" als beim Nano), aber es kommen (noch) keine seriellen Ausgaben ...
Ich vermute mal, Du hast sie dran, aber prüfe lieber noch mal, ob Du die zwei 4,7 k PullUp Widerstände irgendwo drauf hast ...
Gruß PeMue
Zitat von: PeMue am 31 Oktober 2017, 14:34:23
Ich vermute mal, Du hast sie dran, aber prüfe lieber noch mal, ob Du die wzei 4,7 k PullUp Widerstände irgendwo drauf hast ...
Gruß PeMue
Hallo Peter,
auf dem Watterot-Breakoutboard sind Level-Shifter mit jeweils 2*Rs und FET gegen 3V3. Auf dem NANO waren 5V mit TTL-Level gegen den den BME.
Eigentlich sollten die Pullups reichen ... 5V und 3V3 Betrieb sind möglich. Bei 3V3 muss dessen Spannungsregler aber wirklich LowDrop sein...
https://github.com/watterott/BME680-Breakout/blob/master/hardware/BME680-Breakout_v10.pdf (https://github.com/watterott/BME680-Breakout/blob/master/hardware/BME680-Breakout_v10.pdf)
Hallo Zusammen,
... tja, kleine Ursache ... große Wirkung. Für alle die auch suchen (http://www.instructables.com/id/Programming-ESP8266-ESP-12E-NodeMCU-Using-Arduino-/) sollten...
Die Arduino-Ide stand noch auf "Generic ESP" und nicht auf "nodeMCU", dann passt das Pin-Mapping nicht.
Ebenso funktioniert dann auch die Serielle via USB nicht. Aua!
Hat mich heute doch etwas Zeit gekostet, bin dafür wieder im ESP eingearbeitet, wenn auch nicht gerade freiwillig ;)
Dann werde ich mich wieder dem Thema zuwenden können. ;-)
Vielen Dank für die Hilfe.
Grüße
Jürgen
@HCS:
dann müssten wir noch klären für welche HW-Konfiguration Deine Bin-Datei kompiliert wurde...
Bzw. welche Settings?
Momentan habe ich die wdt-Outputs wie hier (https://forum.fhem.de/index.php/topic,43672.msg356095.html#msg356095)
... ich wusste, warum mir der ESP nicht so behagt....
Grüße,
Jürgen
Im Moment will die FW noch nicht so richtig auf dem ESP:
Opening port
Port open
ets Jan 8 2013,rst cause:4, boot mode:(1,6)
wdt reset
rll��|�l�| ...
Setup bevor bsec_init ...
Setup nach bsec_init ...
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld
Setup bevor bsec_init ...
Setup nach bsec_init ...
Werde noch mal die gesamte Konfiguration prüfen ... :'(
Die Prüfung der Linker-Konfiguration ergab: OK!
Zum Testen, ob es systematisch mit dem ESP unter 3V3 funktioniert kompilierte ich den Sketch ohne BSEC-Aufrufe.
... und siehe da, vermutlich reicht der LDO-Output bei 3V3 nicht ganz aus?
Verträgt es der ESP-Port, wenn der Pullup mit 4K7 gegen 5V statt 3V3 betrieben wird? Wenn das Breakoutboard mit 5V versorgt würde?
Checken werde ich auch noch, ob es an meinem Steckbrettaufbau mit evtl. zu langen Leitungen liegt ...
https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/ (https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/)
Es ist nicht die Hardware:
Opening port
Port open
Succeeded!
Configuring Forced Mode...Succeeded!
Temperature(degC),Relative_Humidity(%),Pressure(hPa),Gas_Resistance(Ohms), Gas_Resistance_Average (Ohms)
22.68,42.94,1015.71,0,0
22.78,42.96,1015.53,117709,19618
22.66,42.78,1015.75,118207,39319
22.56,42.73,1015.97,117875,58965
22.48,42.74,1016.09,117379,78528
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld
BME Initialization...Succeeded!
Configuring Forced Mode...Succeeded!
Temperature(degC),Relative_Humidity(%),Pressure(hPa),Gas_Resistance(Ohms), Gas_Resistance_Average (Ohms)
22.13,43.16,1016.66,0,0
22.27,43.21,1016.38,94072,15679
22.26,43.13,1016.42,98529,32100
22.25,43.09,1016.44,103077,49280
22.24,43.04,1016.46,105946,66937
Vielleicht hilft das hier https://forum.fhem.de/index.php?topic=44603.0 (https://forum.fhem.de/index.php?topic=44603.0)
Crash Diagnose (http://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html)
esp8266-nodemcu-v1-0-and-wdt-resets (https://community.blynk.cc/t/solved-esp8266-nodemcu-v1-0-and-wdt-resets/7047)
Zitat von: juergs am 01 November 2017, 07:47:28
Verträgt es der ESP-Port, wenn der Pullup mit 4K7 gegen 5V statt 3V3 betrieben wird? Wenn das Breakoutboard mit 5V versorgt würde?
Das würde ich nicht tun.
Der TS9011-LDO (http://www.mouser.com/ds/2/395/TS9011_H1608-1115585.pdf) ist gut genug.
Bei der geringen Belastung durch den Sensor regelt der LDO sehr gut aus.
Der Prototyp mit 433 MHz Lacrosse Protokoll ist fertig.
Der Sender wird an D13 angeschlossen, wenn D10 gegen GND gejumpert wird dann zeigt der Serial-Output auch ein Timestamp an.
Der CO2-Wert pegelt sich bei mir um die 120.000 ein, deshalb teile ich dur 10.000 um in den übertragbaren Wertebereich zu kommen.
Die Datenübermittling wird per Interrupt alle 30 Sekunden übertragen, da sich heraus gestellt hat, dass der Sensor häufiger abgefragt werden muss,
wohl um seine Betriebstemperatur zu stablisieren...
Der Sensor baut zwei Devices auf:
ID 100 - Kanal 1: Temperatur
Kanal 2: Luftfeuchte
ID 101- Kanal 1: CO2 Widerstand als Roh-Sensor-Wert
Kanal 2: als gemittelter Sensorwert.
Die Werte für Temperatur, Luftfeuchte sind nicht gemittelt. Den Luftdruck habe ich erst mal in favor
der CO2-Ausgabe geopfert. In Zukunft wird sich aber der gemittelte Wert eher anbieten.
Dann werde ich den Luftdruck mit übertragen.
Das ist mal die erste Variante mit einem Nano, bis ich den WDT-Fehler beim ESP gefunden habe.
Evtl. lassen sich dann auch die Relation Richtung IAQ und ppm finden ...
Viel Spaß beim Testen.
Jürgen
Der Einfluss der Senderoutine macht sich bemerkbar!
... da ich während des Interrupts (quasi asynchron) auch direkt den Sensor auslese.
Das lässt sich aber einfach beheben ... in der nächste Version. ;)
Jürgen
Zitat von: juergs am 01 November 2017, 14:08:27
Der Prototyp mit 433 MHz Lacrosse Protokoll ist fertig.
das hört sich sehr interessant an ! Habe selbst auch einige LaCrosse Sensoren aufgebaut,
einen mit zwei Kanälen (2xDS18B20) und mehrere mit einem Kanal (DHT22). Das ganze auf Basis
des ATTiny84 + RFM69CW auf 868,3MHz, laufen sehr zuverlässig.
Für den BME680 bietet sich ja da eher das KeyValueProtokoll an, da kann man alle Werte auf einmal übertragen,
inklusive z.B. Batteriespannung 8)
Hallo hdgucken,
die Varianten:
- des ATTiny84 + RFM69CW auf 868,3MHz (davon habe ich die 433 OOK-Varianten ;) )
- Für den BME680 bietet sich ja da eher das KeyValueProtokoll an, da kann man alle Werte auf einmal übertragen.
interessieren mich ebenfalls. Der RFM sendet ja FSK. Das K-V-Protokoll seriell übertragen?
Jürgen
Könnte aber auch der Einfluss des OOK-Senders auf den AD-Wandler sein, ist direkt hinter dem Breakoutboard angeordnet.
Werde mal den Sender Weiter weg platzieren oder komplett abschirmen....
Dann noch mal checken ...
Hallo zusammen,
so ganz komme ich mit den Daten noch nicht klar. Folgende Fragen:
- Das Sendeintervall ist 3 s, stimmt das? Also die Zahl am Anfang / 1000?
Was mir auffällt:
- Der IAQ Wert geht hoch, wenn gekocht wird und geht extrem runter wenn gelüftet wird. Das ist soweit auch richtig. ABER:
- Kurz nach dem Lüften ging der IAQ-Wert wieder extrem hoch. Vielleicht war der Geruch der Gans heute unangenehm ;D
- Was man machen könnte, ist einfach mal den IAQ Wert mit dem Gaswert korrelieren, ggf. noch unter Berücksichtigung der Temperatur.
@HCS:
Wenn die 3 s korrekt sind, könntest Du bitte eine Firmware bauen mit 60 s oder sogar noch längerer Zeit? Und alle [], | bei der Gelegenheit auch noch weglassen ;).
Oder habt Ihr ein Programm zur Visualisierung, das mit den Zeichen klarkommt? Ich meine, ich hätte einmal ein Programm zur Visualisierung von Kurven von Batterieladegeräte gehabt, das ganz gut war, da muss ich mal suchen gehen ...
Danke + Gruß
Peter
Hallo Peter,
der Einfluss des Senders macht sich bei mir bemerkbar.
Auch scheint die Zylkluszeit des Messens ein Faktor zu sein.
Zum Visualisieren benutze ich den TelemetryViewer. Der erwartet durch Leerzeichen getrennte Werte ohne Text.
Ich habe den zusätzlichen DebugText in der seriellen Ausgabe einfach per Jumper abschaltbar gemacht.
Liegt D10, auf Masse dann kommen timestamp und weitere Debugausgaben ... ;)
Bei dem "komischen" Verhalten des Sensors muss ich noch forschen ... :(
Allerdings ist die Tendenz immer richtig: Fenster zu - fallend, Fenster auf - steigend.
Man bräuchte zum Kalibrieren ein Vergleichsgerät, welches ggf. IAQ und PPM CO2-Gehalt anzeigt.
Dann Draußen als niedrige (konstante?) Referenz und als obere Referen eine CO2-Quelle. (CO2-Patrone...)
Interessant ist, dass beim Fensteröffnen der Luftdruck bei mir steigt, die Luftfeuchte geht bei trockener Luft dann runter.
Also genau so wie vermutet... ;)
ZitatWas man machen könnte, ist einfach mal den IAQ Wert mit dem Gaswert korrelieren, ggf. noch unter Berücksichtigung der Temperatur.
Ja, das ist der Plan ....
Ich schaue mal ob ich das Ganze in der BSEC-Form auf den MiniMaple verdröselt bekomme.
Evtl. funktioniert das ähnlich wie beim ESP, aber ohne WDT-Problem....
Die korrigierte und ergänzte SW-Version für den Nano (ohne BSEC) habe ich diesmal im ersten Post dieses Threads verankert. (V2.1).
Zitat von: PeMue am 01 November 2017, 17:24:14
Was mir auffällt:
- Der IAQ Wert geht hoch, wenn gekocht wird und geht extrem runter wenn gelüftet wird. Das ist soweit auch richtig. ABER:
- Kurz nach dem Lüften ging der IAQ-Wert wieder extrem hoch. Vielleicht war der Geruch der Gans heute unangenehm ;D
- Was man machen könnte, ist einfach mal den IAQ Wert mit dem Gaswert korrelieren, ggf. noch unter Berücksichtigung der Temperatur.
Ich bin auchn noch am rätseln. Ich hatte den Fall, dass IAQ heftige Änderungen gemacht hat, der Widerstand aber konstant blieb.
Fende es blöd, das Bosch nicht verrät, was die IAQ-Berechnung eigentlich macht.
Zitat von: PeMue am 01 November 2017, 17:24:14
@HCS: Wenn die 3 s korrekt sind, könntest Du bitte eine Firmware bauen mit 60 s oder sogar noch längerer Zeit? Und alle [], | bei der Gelegenheit auch noch weglassen ;).
Ich könnte für die Vergleichsfirmware, die auf BSEC basiert, ein Ausgabeformat machen, das ein gplot in FHEM verarbeiten kann.
Ich habe auch fast ein LGW incl. dem kompletten Datenpfad bis ins LaCrosse-Modul rein, gibt es in Kürze im anderen Thread dann.
.. auch ein Grund ein LGW aufzubauen :) :)
Zitat von: juergs am 01 November 2017, 17:50:27
.. auch ein Grund ein LGW aufzubauen :) :)
Es gibt 512 Gründe, eins zu bauen. ;D ;D ;D
Zitat von: HCS am 01 November 2017, 17:53:03
Es gibt 512 Gründe, eins zu bauen. ;D ;D ;D
Jürgen überlegt schon, wie viele Platinen er haben will ;D ;D ;D
Zitat von: PeMue am 01 November 2017, 17:24:14
@HCS:
Wenn die 3 s korrekt sind, könntest Du bitte eine Firmware bauen mit 60 s oder sogar noch längerer Zeit? Und alle [], | bei der Gelegenheit auch noch weglassen ;).
Anbei erst mal eine BSEC basierte Test-Firmware, die Deinen Wünschen entspricht.
Gibt alle 60 Sekunden eine Messung raus.
Ist jetzt wieder 57600 baud.
Format ist nun so:
TS: 60 T: 33.6 H: 28.0 P: 995.9 Gas: 2460 IAQ: 0
TS: 120 T: 33.3 H: 28.4 P: 995.9 Gas: 2474 IAQ: 0
TS: 180 T: 33.3 H: 28.4 P: 995.9 Gas: 2502 IAQ: 0
TS: 240 T: 33.8 H: 27.7 P: 995.9 Gas: 2524 IAQ: 0
TS: 300 T: 34.2 H: 27.2 P: 995.9 Gas: 2546 IAQ: 0
TS: 360 T: 34.1 H: 27.2 P: 995.8 Gas: 2561 IAQ: 28
TS: 420 T: 34.1 H: 27.2 P: 995.8 Gas: 2576 IAQ: 25
TS: 480 T: 34.1 H: 27.1 P: 995.8 Gas: 2589 IAQ: 24
TS: 540 T: 34.2 H: 27.0 P: 995.8 Gas: 2607 IAQ: 25
TS: 600 T: 34.1 H: 27.2 P: 995.9 Gas: 2615 IAQ: 25
TS: 660 T: 34.2 H: 27.0 P: 995.9 Gas: 2628 IAQ: 30
TS: 720 T: 34.0 H: 27.2 P: 995.9 Gas: 2644 IAQ: 25 TS: Sekunden seit Start
T: Temperatur in °C
H: Feuchte
P: Druck (nicht auf NN normalisiert)
Gas: Widerstand vom Gas-Sensor
IAQ: von BSEC gelieferte IAQ
Die Lib, die ich gerade für das LGW baue, liefert andere Werte als die BSEC, wird wohl doch noch etwas dauern, bis das passt.
... dann bin ich mal gespannt, wann es wieder verfügbare Breakboards gibt. :-\
Zitat von: juergs am 01 November 2017, 21:43:00
... dann bin ich mal gespannt, wann es wieder verfügbare Breakboards gibt. :-\
Bei Amazon
.de gibt es noch verfügbare Blue-Dot-Boards ! (Heute Mittag 14, jetzt noch 10) ....
Allerdings kosten die deutlich mehr, als die von Watterott...
Ich habe mich dazu entschlossen meinen AMS-iAQ-Core (https://www.allaboutcircuits.com/projects/build-an-arduino-ble-enabled-air-quality-monitor/) wieder zu beleben und parallel zum BME680 zu betreiben (Infos (https://forum.fhem.de/index.php/topic,60204.msg521218.html#msg521218)). Der iAQ-core besitzt einen sog. Prediction-Wert der nach der AMS-internen Formel den IAQ-Wert wiederspiegeln soll und ebenfalls einen Widerstandswert ausgeben, der mit dem CO2-Gehalt korreliert. Somit hätten wir eine "Referenz" zu den BME-Werten. (Beispielcode (https://github.com/lycannon/ajwrs/tree/master/amsRenesasSensorBoard/src))
Quasi zeitgleich hat AMS auch ihren CCS811 (https://media.digikey.com/pdf/Data%20Sheets/Sparkfun%20PDFs/AirQualityMeasurementswith_CCS811_Web.pdf) herausgebracht, der etwa zum gleichen Preis des BME alleine den CO2-Wert misst. Also ohne T/HUM/P-Messung. Lesenswert der Abschnitt über
"CO2 equivalent units".
Deshalb ist der BME natürlich unschlagbar. Aber der Chip wäre ebenfalls eine Betrachtung wert ( + BME280 ;) ).
ZitatBut before I show you the few readings that I took, there's so
mething I want to point out. You may have noticed in the comments of
the code above that this sensor requires a 48-hour "burn in" period when it's first installed. Beyond that, every time the sensor
is powered on, it requires 20 minutes of "run-in" before the
readings are considered usable. At the time that these pictures were
taken, the sensor had only burned in for about 15 hours so the readings aren't necessarily accurate
Im Screenshot ist die heutige "Ausbeute" allerdings
ohne CO2-Erzeuger und hereingestelltem Fenster ;).
Man sieht auch einige Ausreißer (https://forum.fhem.de/index.php/topic,76654.msg686889.html#msg686889), deren Ursache ich noch erforschen muss. Evtl. können die auch von FHEM weggerechnet werden. Die angezeigten Werte sind alle gleitent gemittelt.
Zitat von: HCS am 01 November 2017, 21:33:34
Anbei erst mal eine BSEC basierte Test-Firmware, die Deinen Wünschen entspricht.
Vielen Dank dafür. Mein nanoLGW rennt mit der neuen Software.
Nun müsste man noch soviel Unix/bash können, um mit
date -I bzw. einer entsprechenden Formatierung folgendes davor hängen zu können:
2017-11-02_19:37:03 dann könnte man mit FHEM die Plots machen. Aber ich arbeite dran ;D
Gruß PeMue
Edit1:
Mit
date '+%Y-%m-%d_%H:%M:%S'kommt zumindest das Datum im korrekten Format. Jetzt muss das nur noch vorne dran :-\
Edit2:
Mit
echo `date +%Y-%m-%d_%H:%M:%S` `vcgencmd measure_volts`kommt ein Datum vor die Messung:
2017-11-03_23:40:38 volt=1.2000V
aber wenn ich statt dessen folgendes mache
echo `date +%Y-%m-%d_%H:%M:%S` `cat /dev/ttyUSB0`kommt gar nichts >:(
Ich habe noch mal Richtung AMS - CCS811 geforscht.
Es gibt dieses Breakoutboard (https://www.sparkfun.com/products/14193) nur mit dem CCS811 bestückt, für ca. 19.95$ und
die Kombi mit CCS811 + BME280 für 29.95$, also eigentlich teurer als der BME680, der insgesamt All-in-One bietet. Geschmackssache,
die Doku dazu ist aber überragend ;), im Vergleich zum BME.
Betrachtet man die Kombi CCS+BME280, dann ergibt sich das, preislich gesehen, dennoch als eine denkbare Alternative.
Der BME680 erfordert die Einbindung einer precompilierte Lib um die IAQ-Werte berechnet zu erhalten, der CCS geht einen anderen Weg: über Beschreiben von Registern
um die Umwelteinflüsse intern verrechnet mit in die Ausgabe mit einzubeziehen (Finde ich fast attraktiver (https://learn.sparkfun.com/tutorials/ccs811-air-quality-breakout-hookup-guide) als der BME). Dh. man kann von einem NTC über einen Dallas-Sensor bis zum BME280
alles mit zur Kompensation mit einzubeziehen. Die Ausgabe erfolgt als [ppm] und [tVOC] (Anmerk.: Total Volatile Org. Compounds). CCS811_Air_Quality_Breakout_Source (https://github.com/sparkfun/CCS811_Air_Quality_Breakout)
Grüße,
Jürgen
Adafruit hat eine neue Version seiner Lib veröffentlicht:https://github.com/adafruit/Adafruit_BME680
Grüße Jörg
Hallo Jörg,
... interessant + umfangreich ...
Mit SPI-Interface-Nutzung.
Grüße,
Jürgen
Zitat von: juergs am 03 November 2017, 18:37:37
interessant. Umfangreich ...
Und auch nicht weiter als wir, keine IAQ Berechnung.
Zitat von: HCS am 03 November 2017, 18:41:48
Und auch nicht weiter als wir, keine IAQ Berechnung.
Die Frage wird sein, ob Bosch die verwendeten Algorithmen jemals open source stellen wird. Irgendwie scheint der Sensor mit der Library von Bosch verheiratet zu sein. Frei nach dem Motto: Die Berechnung hat leider nicht mehr in den Sensor gepasst.
Grüße Jörg
Zitat von: PeMue am 02 November 2017, 21:12:19
aber wenn ich statt dessen folgendes mache
echo `date +%Y-%m-%d_%H:%M:%S` `cat /dev/ttyUSB0`
kommt gar nichts >:(
Ich bin auch nicht der Linux-Profi, aber versuch mal folgendes:
echo `date +%Y-%m-%d_%H:%M:%S` > /dev/ttyUSB0Muss nicht stimmen, aber irgendwie so in der Richtung müsste es gehen
(umleiten von Console nach seriellem Gerät).
P.S.: hab mir noch zwei BlueDot Module von amazon gesichert ;)
Gruss Thomas
Der AMS-iAQ-core mag gerade mal nicht (https://arduino.stackexchange.com/questions/21850/what-does-it-mean-in-i2c-nack-received) ... :'(
Geht doch, brauch wohl etwas interne "Verweildauer" ...
Nein .... SDA + SCL waren vertauscht (Levelshifter dazwischen) .. ;)
Zitat
CO2 [ppm] , resistance, TVOC
1583,19588,437
1590,19147,439
1590,19147,439
1590,19147,439
1590,19147,439
1590,19147,439
1595,18854,441
1595,18854,441
1595,18854,441
1595,18854,441
1595,18854,441
1598,18708,442
1598,18708,442
1598,18708,442
1598,18708,442
1598,18708,442
1598,18708,442
1600,18562,442
1600,18562,442
1600,18562,442
1600,18562,442
1600,18562,442
1605,18270,443
1605,18270,443
1605,18270,443
Werte sehen schon mal gut und realistisch aus ... :D
Ich versuche mal den Code auf dem ESP8266 zum Laufen zu bringen ...
Hallo Thomas,
Zitat von: hdgucken am 04 November 2017, 10:40:12
echo `date +%Y-%m-%d_%H:%M:%S` > /dev/ttyUSB0
Muss nicht stimmen, aber irgendwie so in der Richtung müsste es gehen
(umleiten von Console nach seriellem Gerät).
nein, so geht es nicht. Das schreibt das Datum auf die serielle Schnittstelle.
Mit folgendem Skript geht es:
#!/bin/sh
# reads data from nanoLGW and adds FHEM readable date in the first column
while read -r line < /dev/ttyUSB1; do
echo `date +%Y-%m-%d_%H:%M:%S` $line
done Das unter bme680read.sh speichern, Rechte anpassen und dann so laufen lassen:
./bme680read.sh >> /tmp/bme680-2017-11.log &Irgendwie will er (trotz sudo) noch nicht, wenn man in /opt/fhem/log speichern will >:(
Heraus kommt folgender Dateiinhalt:
2017-11-04_20:32:12 TS: 170820 T: 29.9 H: 31.6 P: 982.3 Gas: 139407 IAQ: 93
2017-11-04_20:33:12 TS: 170880 T: 29.9 H: 31.6 P: 982.3 Gas: 138832 IAQ: 94
2017-11-04_20:34:12 TS: 170940 T: 29.8 H: 31.7 P: 982.3 Gas: 139176 IAQ: 93
2017-11-04_20:35:12 TS: 171000 T: 30.0 H: 31.4 P: 982.3 Gas: 138261 IAQ: 94
2017-11-04_20:36:12 TS: 171060 T: 31.3 H: 29.3 P: 982.3 Gas: 137021 IAQ: 98
2017-11-04_20:37:12 TS: 171120 T: 31.3 H: 29.5 P: 982.2 Gas: 136576 IAQ: 101Sollte mit SVG darstellbar sein ;)
Gruß Peter
Edit1:Ersten Plot angehängt, morgen gibt es eine Feier mit >10 Personen im Raum. Mal sehen, was da passiert ;D
Edit2:Nächsten Plot angehängt mit ein paar mehr Daten ...
Hallo Peter,
das sieht ja schon ganz gut aus ... :D
Bei mir läuft der iAQ-core ebenfalls, vermutlich macht er gerade seine Burn-In-Phase.
Mal schauen wie er sich weiter verhält...
Die Plausibilität der iAQ-Werte muss ich noch mal mit den Registerwerten vergleichen und prüfen.
Interessant wäre noch darauf eine Temperatur-Kompensation zu legen, bzw. zu erfassen, wie sich das auswirken würde.
Hallo Peter,
Zitat von: PeMue am 04 November 2017, 20:38:50
nein, so geht es nicht. Das schreibt das Datum auf die serielle Schnittstelle.
Ups, stimmt natürlich, war wohl nicht ganz bei der Sache ;)
Aber das Script sieht gut aus ! Könnte ein Linuxprofi auch nicht besser ;D
Bin ja mal auf die morgigen Messwerte (Feier) gespannt ...
Gruß Thomas
So, der Referenzwert-Sender über LaCrosse für den iAQ-core-Sensor ist ebenfalls fertig und funkt seine Werte an FHEM. :D
Man kann schon erkennen, der iAQ hat schon wesentlich
besseren Glättungs-Algorithmus eingebaut.
Beim BurnIn zeigte er etwas "abstruse" Werte an, die sich nach einiger Zeit in realistische Werte-Bereiche änderten.
Status 4 ist nicht im Datenblatt (http://www.mouser.com/ds/2/588/iAQ-core_Datasheet_EN_v1-775852.pdf) ...
ZitatCO2:1458, Status:4, Resistance:28062, TVoC:403
2017-11-04 19:36:23 Message BurnIn?
Die Grafik zeigt mal wieder die bekannten Fenster-Öffnen-Aktionen und die Reaktion des Sensors darauf.
Jetzt müssen doch noch Langzeitwerte gesammelt werden. Man sieht auch, dass die Werte von CO2 + TVOC (https://www.umweltbundesamt.de/sites/default/files/medien/pdfs/TVOC.pdf) eigentlich korrelieren.
So dass sich je nach Gusto noch ein Dallas18B20 oder BME280-Sensor zur möglichen Temperatur-Kompensation anbieten würde.
In der Zwischenzeit kümmere ich mich um die
Außreißer der BME680-Werte, die die SVG-Grafik ungünstig skalieren.
Mal schauen, ob das per FHEM/Perl oder eher im Code passieren kann.
Als Option wären dann Status-Icons, die abhängig vom CO2 farblich den Zustand anzeigen sinnvoll. In FHEM habe ich Entsprechendes schon gesehen ...
Den passenden VisualMicro-Code "iAQ-NANO-LACROSSE-TX3" dazu habe ich hier bei Github (https://github.com/juergs/iAQ_NANO_328_LaCrosse) veröffentlicht.
Voreingestellt ist die SensorID: 92.
Anbei ein paar CSV-Daten zum analysieren ...
PS: Bei Amazon sind die BME-Breakboards wech ... :'(
Beim 3D-Drucken...
Zu erkennen ist:
Einfluß der Temperatur-Gradienten auf den TVOQ, sowohl iAQ-Core als auch BME.
Fenster öffnen und wieder Fenster zu und Heizung an. Der Sensor befindet sich in Nähe des Fensters.
Zwei Störende Pearl Funksensoren habe ich die Batterien entfernt um deren Einfluß bei der Übertragung zu minimieren.
Sie haben kurze Intervallzeiten und viele Repetitions. Evtl. hat das zu den fehlenden Daten geführt ...
Zumindest beim iAQ wird man nicht um eine Temperatur-Kompensation herumkommen.
Besonders bei großen Delta-T's, da reagiert der iAQ empfindlich.
Beim BME habe ich testweise eine Ausreißer-Erkennung in die Resistance-Ausgabe eingebaut.
Mal schauen, ob sich die SVG-Grafik dadurch verbessert.
Zitat von: hdgucken am 04 November 2017, 23:25:03
Bin ja mal auf die morgigen Messwerte (Feier) gespannt ...
Da war CO2/IAQ-mäßig (und auch sonst ;D) ziemlich was los, siehe Anhang.
Ich hatte die Gelegenheit, mit einem "Insider" zu sprechen:
- Der BME680 sollte eine ähnliche Charakteristik haben, wie der AMS Sensor.
- Der BME680 braucht etwa 4 Tage (eigentlich sollte es weniger sein), bis er sich kalibriert hat (soll vermutlich heißen, die Einschaltdrift ausgeregelt hat).
- Der IAQ ist mathematisch nicht definiert, d.h. jeder Hersteller kann den Wert irgendwie berechnen.
- So wie es scheint, macht der BME680 auch eine Driftkorrektur (nach unten), wenn lange im Raum nichts passiert (warum auch immer).
Gruß PeMue
Hallo zusammen,
bin neu hier und komme von der IP Symcon Fraktion. Wir versuchen gerade auch dem BME680 anständige CO2/ppm Werte zu entlocken. Meine ersten Versuche den BME680 parallel zum iAQ laufen zu lassen, empirisch anzugleichen, könnt ihr hier sehen. https://www.symcon.de/forum/threads/32284-Modul-zur-Nutzung-der-Raspberry-Pi-GPIO?p=340551#post340551 (https://www.symcon.de/forum/threads/32284-Modul-zur-Nutzung-der-Raspberry-Pi-GPIO?p=340551#post340551)
Gruss
Bernd
Hallo Bernd,
Schön auf gleichgesinnte Mitstreiter zu treffen :)
Schau gerne mal dort bei Euch vorbei ...
Die Interpretation der Messergebnisse steht erst mal im Raum.
Sowie eine Verbesserung der Ausgaben .... Strategie?
Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?
Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ
Grüße,
Jürgen
Zitat- So wie es scheint, macht der BME680 auch eine Driftkorrektur (nach unten), wenn lange im Raum nichts passiert (warum auch immer).
Vielleicht denkt er dann, er sei auf einem Prüfstand. ;D ;D ;D ;D
Zitat von: juergs am 07 November 2017, 07:13:45
.... Strategie?
Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?
Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ
Grüße,
Jürgen
Hallo Jürgen,
genau das war auch meine Idee. Ich lasse jetzt mal den BME680 und den iAQ mehrere Tage am selben Ort laufen, ich schaue mir das dann mal näher an. Das mit der Driftkorrektur macht es nicht einfacher. Bei meine ersten Kurven habe ich schon so etwas vermutet.
Hoffnung ist aber immer noch, dass Bosch die Umrechnungsformel von Widerstand auf CO2/ppm oder TVOC/ppm bereit stellt.
Gruss
Bernd
Zitat von: icey am 07 November 2017, 09:45:47
Hoffnung ist aber immer noch, dass Bosch die Umrechnungsformel von Widerstand auf CO2/ppm oder TVOC/ppm bereit stellt.
Das wäre wirklich hilfreich. Die Bosch-IAQ ist eigentlich nutzlos, wenn man nicht weiß, wie sie zustande kommt.
Nur zu sagen "die Luft ist gut" ohne die Grenzwerte zu "schlecht" zu kennen macht wenig Sinn.
Ich habe eine Test-Firmware laufen, die auf der Bosch BSEC basiert.
Die habe ich etwas erweitert, dass ich auch den Widerstand und die Heizparameter für die hotplate bekomme (weil mir auch noch völlig unklar ist, welchen Einfluss die Zieltemperatur, die zwischen 200 und 400 °C liegen kann, hat).
So wie es aussieht, heizt die BSEC immer auf 320°C mit einer Heizdauer von 192ms.
Was man erkennen kann ist, dass der Widerstand kontinuierlich steigt und die IAQ sich nur ändert, wenn der Widerstand nicht mehr der ursprünglichen Steigung folgt.
Ich lasse das jetzt mal einige Tage laufen, um zu sehen, wo das hinführt. Der Widerstand kann ja nicht unendlich steigen.
Momentan ist die Messreihe noch zu kurz und nicht lange genug gelaufen, um da schon was vernünftig rauszuinterpretieren.
Und ich habe den Eindruck, dass die gemessene Temperatur nicht so deutlich zu hoch liegt, wie bei den BME280, die ich habe. Das scheint beim BME680 besser zu sein.
Vielleicht sollten wir eine "was noch unklar ist" Liste führen. Zusammengetragen könnten die bereits gefundenen Antworten dann mit etwas Glück ein Bild ergeben.
Hallo Ihr fleißigen Entwickler,
Zitat von: juergs am 07 November 2017, 07:13:45
Hallo Bernd,
Schön auf gleichgesinnte Mitstreiter zu treffen :)
Schau gerne mal dort bei Euch vorbei ...
Die Interpretation der Messergebnisse steht erst mal im Raum.
Sowie eine Verbesserung der Ausgaben .... Strategie?
Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?
Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ
Grüße,
Jürgen
Ich würde gerne Unterstützung anbieten durch Bereitstellen meiner Messdaten.
Habe bislang eine Messreihe der letzten sechs Tage, erstellt mit der "Test680.bin" von HCS vom 30.10. (aus diesem Thread).
Wäre vielleicht gut, wir würden alle die selbe 'Firmware' verwenden, welche hier genannten Ansprüchen genügt.
@HCS: würdest du Deine aktuelle FW wieder zur Verfügung stellen (oder habe ich diese übersehen)?
Habe drei BME680 zur Verfügung und würde wirklich gerne mit den Logs weiterhelfen (mehr kann ich nicht)
Grüße, Bernd
Zitat von: blehnert am 07 November 2017, 13:05:40
@HCS: würdest du Deine aktuelle FW wieder zur Verfügung stellen (oder habe ich diese übersehen)?
Ja, klar, heute Abend oder so. Muss die Normaliserung vom Luftdruck auf meine Meereshöhe für euch wieder ausbauen.
Mit "Resistance_iAQ | IAQ_iAQ" kann ich nicht dienen, weil ich diesen Sensor nicht habe.
Die Firmware läuft auf einem ESP8266 und liefert auf der Seriellen dieses Format:
TS: 52620 T: 19.8 H: 57.5 P: 1020.1 Gas: 5472 IAQ: 71 HT: 320 HD: 197 AC: 3
TS: 52680 T: 19.8 H: 57.4 P: 1020.1 Gas: 5467 IAQ: 72 HT: 320 HD: 197 AC: 3TS: Zeitstempel
T: Temperatur
H: Feuchte
P: Druck
Gas: Widerstand
IAQ: von Bosch berechete IAQ
HT: Zieltemperatur hotplate (von BSEC gesetzt)
HD: Heizdauer hotplate (von BSEC gesetzt)
AC: Genauigkeit IAQ (1...3) (von BSEC geliefert)
Es wird alle 60 Sekunden ein Datensatz rausgegeben.
Mit dem bash script vom PeMue setze ich es in ein Logfile für FHEM um, auf dem der SVG von weiter oben läuft.
HD: 197 passt nicht für ein 60s Intervall.
Die Heizdauer bei der BSEC ist abhängig vom Messintervall auch die internen Berechnungen bauen auf diese Timings auf.
ca 190ms beim LP Mode also alle 3s. Bei ULP sind es ca 2s und Messintervall 5min.
Bugs
Zitat von: djbugs am 07 November 2017, 15:41:44
HD: 197 passt nicht für ein 60s Intervall.
Die Messung findet alle drei Sekunden statt, aber es wird nur ein mal pro Minute der Wert übermittelt, um das log im Zaum zu halten.
ZitatDas wäre wirklich hilfreich. Die Bosch-IAQ ist eigentlich nutzlos, wenn man nicht weiß, wie sie zustande kommt.
Nur zu sagen "die Luft ist gut" ohne die Grenzwerte zu "schlecht" zu kennen macht wenig Sinn.
Das macht nur Sinn wenn die Werte generell vergleichbar wären. Ich glaube [ppm] ist da Aussage-kräftiger.
ZitatIch habe eine Test-Firmware laufen, die auf der Bosch BSEC basiert.
Worauf basiert Deine Lösung?
ZitatVielleicht sollten wir eine "was noch unklar ist" Liste führen. Zusammengetragen könnten die bereits gefundenen Antworten dann mit etwas Glück ein Bild ergeben.
Sehr guter Vorschlag. "
was noch unklar ist" Liste => Github?
Zitatblehnert
Gerne.
Bei mir kann ich schon mal anfangen, fallls es Sinn, macht den iAQ sinnvoll als Referenz mit einzubinden, dazu muss ich es schaffen den Resistance-Wert des BMEs zu glätten
(oder den möglichen Fehler zu finden :( ... )
Vielleicht ist es im Vorfeld aber auch egal, wenn CSV-Werte vorliegen. Das lässt sich dann in der Tabellen-Kalulation besser prüfen bzw. ausblenden.
@HCS
Habe den Fehler bei meiner nodeMCU gefunden: I2C-Standard ist nicht auf D4/D5 (Weil GPIO) sondern auf D1 (SCL) / D2 (SDA).
War wohl in meiner Doku nicht sofort ersichtlich was "D"-Port und was GPIO ist ...
Versuche dann mal mein Compile ohne die WDT-Problematik durch zu bekommen ... oder Deine (neue) BIN einzusetzen. ;)
Frage: Deine BIN ist für die gesamte LaCrosseGateway-Infrastrucktur oder nur für den BME? Falls ja, läuft das ohne den RFM69 nicht ...
Dann muss ich noch nachrüsten ...
Heute ist das bestellte BlueDot-Board gekommen, dann kann ich zusätzlich die ESP-Version ans laufen bringen.
Wegen dem CSV-Format würde ich für einen Standard plädieren, sonst muss man jedesmal umbauen ... oder Skripte dafür schreiben... :'(
@bugs
ZitatHD: 197 passt nicht für ein 60s Intervall.
Die Heizdauer bei der BSEC ist abhängig vom Messintervall auch die internen Berechnungen bauen auf diese Timings auf.
ca 190ms beim LP Mode also alle 3s. Bei ULP sind es ca 2s und Messintervall 5min.
Sobald bei mir die BSEC-Version läuft, werde ich mir die Timing-Details noch genauer anschauen. Danke für den Hinweis.
Heute reicht es bei mir leider nicht zu mehr ...
Grüße,
Jürgen
Zitat von: juergs am 07 November 2017, 21:18:14
Das macht nur Sinn wenn die Werte generell vergleichbar wären. Ich glaube [ppm] ist da Aussage-kräftiger.
Ja, wenn wir wüssten, wie sich der Widerstand in ppm umrechnet.
Aber vielleicht ist das ja gar nicht möglich, siehe unten.
Zitat von: juergs am 07 November 2017, 21:18:14
Worauf basiert Deine Lösung?
https://www.bosch-sensortec.com/bst/products/all_products/bsec
Zitat von: juergs am 07 November 2017, 21:18:14
Wegen dem CSV-Format würde ich für einen Standard plädieren, sonst muss man jedesmal umbauen ... oder Skripte dafür schreiben... :'(
Ich kenne mindestns zwei, die das ins Log-Format von FHEM bringen wollen, das klappt mit dem aktuellen Format und dem PeMue-Script prima.
Wenn mir jemand einen Vorschlag für das "Standard-Format" macht, dann mache ich gerne auch eine zweite Version, die die Daten in diesem Format liefert.
Zitat von: juergs am 07 November 2017, 21:18:14
dazu muss ich es schaffen den Resistance-Wert des BMEs zu glätten
Ich würde vorerst nichts glätten. Die realen Werte sind erst mal interessanter. Hatte gerade zu Beginn vom Lüften einen heftigen IAQ-Peak nach oben (also schlechter) und so etwas sollte man erst mal sehen und verstehen und nicht glattrechnen.
Dieser Satz aus der Bosch-Doku gibt mir zu denken:
ZitatIndoor-air-qualiy estimate [0-500]. Indoor-air-quality (IAQ) gives an indication of the relative change in ambient TVOCs detected by BME680.
Will Bosch uns hier mitteilen, dass es gar keinen Absolutwert gibt sondern nur die Information, ob es besser oder schlechter wird?
Und:
ZitatNote
The IAQ scale ranges from 0 (clean air) to 500 (heavily polluted air). During operation, algorithms automatically calibrate and adapt
themselves to the typical environments where the sensor is operated (e.g., home, workplace, inside a car, etc.).This automatic background calibration ensures that users experience
consistent IAQ performance. The calibration process considers the recent measurement history (typ. up to four days) to ensure that IAQ=25 corresponds to typical good air and IAQ=250 indicates typical polluted air.
Somit ist dann IAQ=25 der beste und IAQ=250 der schlechteste reale Wert, der in den vier Tagen zufällig auftrat, was auch immer das dann konkret war?
Wenn ich das jetzt nicht völlig falsch interpretiere, dann ist die Aussagekraft der IAQ sehr begrenzt, um es mal Bosch-freundlich zu formulieren.
Anbei wie versprochen das binary.
Und das Chart mit dem Rest des heutigen Tages. Das gibt mir auch Rätsel auf.
Aber es kann ja noch realistisch werden, wenn die vier Tage rum sind :)
ZitatWenn mir jemand einen Vorschlag für das "Standard-Format" macht, dann mache ich gerne auch eine zweite Version, die die Daten in diesem Format liefert.
Dachte da eher an Excel-freundlich als Rohdaten ohne redundante String-Info ...
Aber kein Problen, dann wndle ich die CSV-Daten vorher um ... ;)
ZitatUnd das Chart mit dem Rest des heutigen Tages. Das gibt mir auch Rätsel auf.
Dann brauchen wir auch noch eine Meßwert-Interpretationsliste ...
Aber wie beim iAQ-core. Hohe Flankensteilheit der Temperaturwerte, sowohl nach oben als auch nach unten sind Gift für die Messungen
bzw. Kompensation ...
Bei mir ist lange etwa gleiches Temperaturverhalten bis zum Gradienten, dann reagiert der iAQ wieder etwas sensibel
und braucht recht lange um sich aus der Situation zu erholen (fast 1 Stunde !).
Der BME aber komischerweise nicht so stark wie bei Dir, abgesehen von den Ausreißern, die noch beseitigt werden müssen ...
Hallo Zusammen,
@HCS: zunächst mal danke für die FWs.
anbei mal drei (unaufbereitete) Logs der BME680 mit den FWs von HCS.
bme680Sensor_war_neu_FW_HCS20171020.txt : seinerzeit jungfräulicher Sensor mit der HCS-FW vom 30.10., Sensor lief ca sechs Tage ohne Unterbrechung.
bme680Sensor_alt_FW_HCS20171107.txt : derselbe Sensor nun mit der HCS-FW vom 07.11. (läuft jetzt seit einer Std)
bme680Sensor_neu_FW_HCS20171107.txt : jungfräulicher Sensor mit HCS-FW vom 07.11. (zeitgleich gestartet mit dem zweiten)
Bemerkenswert für mich die Korrelation zwischen 2. und 3. betr. Temp, Hum und Pressure, zum Rest kann ich nix sagen.
Werde die Sensoren mal drei/vier Tage ununterbrochen laufen lassen und die Logs dann anhängen.
Hoffe, ich kann so ein bisschen helfen,
danke,
Bernd
Hallo Bernd,
anbei erstmal (..aus Zeitmangel), meine fhem-log-Datei (leider noch mit Ausreißer) .
Der bearbeitete Rest folgt noch ...
Grüße,
Jürgen
Zitat von: HCS am 07 November 2017, 22:09:16
Anbei wie versprochen das binary.
Vielen Dank, rennt seit ca. 20 Minuten (TS: 1140) und hängt die Daten an die vorigen ran. Irgendwie hat mein gplot noch Schwierigkeiten mit der Feuchte, warum auch immer. Gestern ist auch das BlueDot Modul gekommen. Ich gehe mal davon aus, dass die Firmware keinen RFM69CW braucht, um zu laufen, oder?
Aber jetzt muss ich erst mal Leiterplatten eintüten ???
Gruß PeMue
Hallo PeMue,
habe die FW einfach auf meine NodeMCU Dev V2 geflashed. Sie logen munter über den USB Anschluss (virtueller COM) zum Raspberry (57600),
Bernd
Hallo PeMue,
ha, auch BlueDot? ! ;D :D
ZitatSo far I didn't manage to calculate the IAQ index (Indoor Air Quality), based on the measured gas resistances.
Die haben einfach die CO2-Messung in Ihrem Beispiel zur Lib (https://github.com/BlueDot-Arduino/BlueDot_BME680/blob/master/BlueDot_BME680.cpp) weggelassen!
float readGas(void);
void calculateHotPlateRes(void);
void calculateHotPlateTime(void);
void setHotPlateProfile(void);ist aber im Header vorhanden.
Habe es gerade bei mir in ein nodeMCU eingebunden bekommen.
War doch etwas verwirrt, wo auf dem ESP jetzt endlich I2C heraus kommt, wenn der Standard-Konstruktur ohne Parameter verwendet wird.
In der Doku sind meist verschiedene Ports erwähnt (D-Ports oder GPIOs) ....
Beim NodeMCU ist es letztendlich doch D1 (SCL) / D2 (SDA) zuständig. Manchmal kommt in der Doku auch D4/D5 vor ....
Dann ist beim Bluedot die Doku noch auf Stand BME280 ... >:(
Ob nun bei High auf CS die Adresse 0x76 oder 0x77 erscheint... ist auch widersprüchlich angegeben...
Diese Frage beschäftigt mich auch:
ZitatIch gehe mal davon aus, dass die Firmware keinen RFM69CW braucht, um zu laufen, oder?
Ich vermute HCS hat die LaCrosseGateway-Konfiguration genommen mit D1=SCL und D2=SDA ?
Da ich noch kein RFM angeschlossen habe, funktioniert da bei mir noch nichts ... :'(
Dann werde ich dann doch mein ESP-Compile am Wochenende glattziehen müssen ...
Das Watchdog-Problem lässt sich wirklich durch mehr oder weniger geschickte Platzierung von
yield() vermeiden :)
Dann mache ich mal den Steckbrettaufbau RFM-tauglich (https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=41968;image), reicht da ein RFM Modul aus?
@blehnert
ZitatNodeMCU Dev V2 ?
Heute komme ich da nicht weiter .... doch zu viele Baustellen ...
Grüße,
Jürgen
PS: Anbei die BIN mit dem Output der BlueDot-Lib mit CO2.
D1 = SCL
D2 = SDA
nodeMCU-Belegung. Analog zum ESP12E-Modul.
Zitat von: juergs am 08 November 2017, 21:45:44
Die haben einfach die CO2-Messung in Ihrem Beispiel zur Lib (https://github.com/BlueDot-Arduino/BlueDot_BME680/blob/master/BlueDot_BME680.cpp) weggelassen!
Wie alle anderen auch ...
Zitat von: juergs am 08 November 2017, 21:45:44
Ich vermute HCS hat die LaCrosseGateway-Konfiguration genommen mit D1=SCL und D2=SDA ?
Richtig vermutet, er hat.
Und ein RFM69 ist nicht erforderlich.
@HCS
ich kann zwar die I2C Zugriffe sehen, aber es kommt nichts über die Serielle :-\
115200 und 57600 Baud als Bitrate, kommen keine Werte ...
Zitat von: juergs am Heute um 21:45:44
Ich vermute HCS hat die LaCrosseGateway-Konfiguration genommen mit D1=SCL und D2=SDA ?
Richtig vermutet, er hat.
Und ein RFM69 ist nicht erforderlich.
Und fürs Bluedot mit HCS-FW gilt:
SCL=SCK=D1
SDA=SDI=D2
CS=high (enable i2c)
SD0=low (0x76)
so läufts jedenfalls bei mir,
Bernd
Hallo Bernd,
Die Adresse 0x76 ist der Knackpunkt gewesen.... ;)
Beim BlueDot kann man CS für high unbeschalten lassen.
Im Code hätte man nachschauen können..... Schade, hätte Zeit sparen können. :'(
Danke!
Jürgen
Zitat von: juergs am 09 November 2017, 06:56:46
Die Adresse 0x76 ist der Knackpunkt gewesen.... ;)
Beim BlueDot kann man CS für high unbescholten lassen.
Hab von Anfang an den BlueDot gehabt, war bei mir auch das ,,Problem" mit der Adresse 0x76,
die Doku hatte mich aber schnell drauf gebracht. Hab gestern noch 2 Stück von A...n dazu bekommen.
Im Moment versuche ich, die Bibliotheken in Arduino einzubinden um das ganze mal mit z.B. dem CustomSensor Protokoll über einen RFM69 zu versenden. KeyValueProtokoll geht ja nur seriell am LGW.
Hab nur recht begrenzt Zeit :(
kleiner Zwischenstand nach zwei Tagen:
BME680"alt":
TS: 170040 T: 21.6 H: 46.2 P: 985.9 Gas: 156250 IAQ: 242 HT: 320 HD: 197 AC: 3
TS: 170100 T: 21.6 H: 46.1 P: 985.9 Gas: 156396 IAQ: 242 HT: 320 HD: 197 AC: 3
TS: 170160 T: 21.6 H: 46.2 P: 985.9 Gas: 155093 IAQ: 246 HT: 320 HD: 197 AC: 3
TS: 170220 T: 21.7 H: 46.2 P: 985.8 Gas: 155959 IAQ: 242 HT: 320 HD: 197 AC: 3
TS: 170280 T: 21.7 H: 46.2 P: 985.8 Gas: 154094 IAQ: 249 HT: 320 HD: 197 AC: 3
TS: 170340 T: 21.7 H: 46.1 P: 985.9 Gas: 155669 IAQ: 243 HT: 320 HD: 197 AC: 3
BME680"neu":
TS: 169860 T: 21.5 H: 44.7 P: 985.6 Gas: 96653 IAQ: 230 HT: 320 HD: 197 AC: 3
TS: 169920 T: 21.5 H: 44.7 P: 985.5 Gas: 97725 IAQ: 224 HT: 320 HD: 197 AC: 3
TS: 169980 T: 21.6 H: 44.7 P: 985.6 Gas: 96821 IAQ: 229 HT: 320 HD: 197 AC: 3
TS: 170040 T: 21.6 H: 44.8 P: 985.5 Gas: 95879 IAQ: 233 HT: 320 HD: 197 AC: 3
TS: 170100 T: 21.7 H: 44.7 P: 985.5 Gas: 96209 IAQ: 232 HT: 320 HD: 197 AC: 3
TS: 170160 T: 21.7 H: 44.6 P: 985.5 Gas: 96933 IAQ: 228 HT: 320 HD: 197 AC: 3
IAQ scheinen sich einander anzupassen, Gas auch ein wenig...
schaun wir mal weiter.
Sensoren sind unmittelbar nebeneinander,
Bernd
Zitat von: blehnert am 10 November 2017, 13:01:32
kleiner Zwischenstand nach zwei Tagen
Solltest jetzt doch mal lüften ... ;D ;D
dachte, ich soll vier Tage garnix machen :P
also Lüften startet "alt" TS:174240 und endet 174720 ("neu" hat TS Offset von -180):
alt:
TS: 174240 T: 21.9 H: 47.1 P: 985.5 Gas: 157129 IAQ: 218 HT: 320 HD: 197 AC: 3
TS: 174300 T: 21.9 H: 47.1 P: 985.5 Gas: 158019 IAQ: 215 HT: 320 HD: 197 AC: 3
TS: 174360 T: 21.6 H: 47.2 P: 985.6 Gas: 162464 IAQ: 202 HT: 320 HD: 197 AC: 3
TS: 174420 T: 20.3 H: 48.1 P: 985.5 Gas: 183864 IAQ: 140 HT: 320 HD: 197 AC: 3
TS: 174480 T: 19.3 H: 49.3 P: 985.5 Gas: 196906 IAQ: 101 HT: 320 HD: 197 AC: 3
TS: 174540 T: 19.0 H: 49.6 P: 985.5 Gas: 208367 IAQ: 67 HT: 320 HD: 197 AC: 3
TS: 174600 T: 18.5 H: 50.7 P: 985.5 Gas: 213361 IAQ: 54 HT: 320 HD: 197 AC: 3
TS: 174660 T: 18.4 H: 50.9 P: 985.5 Gas: 214613 IAQ: 48 HT: 320 HD: 197 AC: 3
TS: 174720 T: 18.7 H: 50.2 P: 985.5 Gas: 217160 IAQ: 43 HT: 320 HD: 197 AC: 3
TS: 174780 T: 18.9 H: 49.9 P: 985.4 Gas: 217160 IAQ: 43 HT: 320 HD: 197 AC: 3
TS: 174840 T: 19.2 H: 49.2 P: 985.4 Gas: 215737 IAQ: 47 HT: 320 HD: 197 AC: 3
TS: 174900 T: 19.5 H: 48.4 P: 985.5 Gas: 217734 IAQ: 43 HT: 320 HD: 197 AC: 3
TS: 174960 T: 19.9 H: 47.7 P: 985.5 Gas: 216020 IAQ: 49 HT: 320 HD: 197 AC: 3
neu:
TS: 174060 T: 21.9 H: 45.5 P: 985.2 Gas: 97611 IAQ: 218 HT: 320 HD: 197 AC: 3
TS: 174120 T: 21.9 H: 45.6 P: 985.2 Gas: 97725 IAQ: 217 HT: 320 HD: 197 AC: 3
TS: 174180 T: 21.7 H: 45.9 P: 985.2 Gas: 100420 IAQ: 203 HT: 320 HD: 197 AC: 3
TS: 174240 T: 20.5 H: 46.2 P: 985.2 Gas: 120504 IAQ: 110 HT: 320 HD: 197 AC: 3
TS: 174300 T: 19.6 H: 47.2 P: 985.0 Gas: 134107 IAQ: 49 HT: 320 HD: 197 AC: 3
TS: 174360 T: 19.1 H: 47.9 P: 985.2 Gas: 143654 IAQ: 16 HT: 320 HD: 197 AC: 3
TS: 174420 T: 18.7 H: 48.8 P: 985.2 Gas: 150494 IAQ: 5 HT: 320 HD: 197 AC: 3
TS: 174480 T: 18.5 H: 49.3 P: 985.1 Gas: 152550 IAQ: 11 HT: 320 HD: 197 AC: 3
TS: 174540 T: 18.7 H: 48.7 P: 985.1 Gas: 152273 IAQ: 25 HT: 320 HD: 197 AC: 3
TS: 174600 T: 18.9 H: 48.3 P: 985.1 Gas: 150901 IAQ: 32 HT: 320 HD: 197 AC: 3
TS: 174660 T: 19.2 H: 47.6 P: 985.1 Gas: 151859 IAQ: 30 HT: 320 HD: 197 AC: 3
TS: 174720 T: 19.6 H: 46.9 P: 985.1 Gas: 150224 IAQ: 36 HT: 320 HD: 197 AC: 3
TS: 174780 T: 19.8 H: 46.3 P: 985.1 Gas: 147968 IAQ: 44 HT: 320 HD: 197 AC: 3
Auch eine Variante (SW+HW):
https://github.com/closedcube/ClosedCube_BME680_Arduino
So, anbei die Logs der beiden bme680.
Beide Sensoren haben die letzten sechs Tage ununterbrochen Seite an Seite verbracht.
Die Logs sind nicht aufbereitet und entstammen der HCS-FW vom 06.11.
"alt" bedeutet: der Sensor war zuvor schon einige Tage in Betrieb, wurde aber natürlich neu gestartet.
"neu" bedeutet: der Sensor war (bei mir) noch nie in Betrieb.
Sensor "neu" wurde drei Min. später gestartet, daher TimeStamp offsett 180.
Grüße, Bernd
ich habe mal "versucht" bestimmte Kurven-Abschnitte zu kategorisieren.
(Danke @blehnert für die bereitgestellten Daten.)
Ich kann im Moment folgendes Verhalten zwischen IAQ und rel. CO2-Wert erkennen
(trotz Auseinanderlaufen der X-Sklalierung):
1. der CO2-Wert lässt durchaus stabile Zonen mit steitiger Steigung erkennen.
2. Temperatur-Differenzen haben einen destabilisierenden Einfluß. (Mit und ohne Lüften...)
3. Temperatur-Einfluß für sich muss nochmal separat (https://www.youtube.com/watch?v=SLcUALXZcLY) betrachtet werden (am besten bei konstanter CO2-Menge).
Ansonsten sieht das nach einer Skalierung und Spiegelung der Y-Achsenwerte um einen abschnittsweisen Median aus?
(In Annäherung an einen möglichen Algorithmus für CO2 -> IAQ).
Die Kurve in SVG_CUL_TX_92 soll CO2 in ppm sein. Die liegt irgendwo bei 50ppm, was eigentlich nicht sein kann, da man selbst draußen in frischer Landluft schon mindestens 400ppm CO2 hat.
In SVG_CUL_TX_91 ist die Y-Achse "CO2 rel in Ohm"
Der Widerstand beim BME680 ist aber definitiv nie in Bereich von 30 Ohm. Eher irgendwo zwischen 2000 Ohm und 10000 Ohm.
ZitatDie Kurve in SVG_CUL_TX_92 soll CO2 in ppm sein. Die liegt irgendwo bei 50ppm, was eigentlich nicht sein kann, da man selbst draußen in frischer Landluft schon mindestens 400ppm CO2 hat.
In SVG_CUL_TX_91 ist die Y-Achse "CO2 rel in Ohm"
Der Widerstand beim BME680 ist aber definitiv nie in Bereich von 30 Ohm. Eher irgendwo zwischen 2000 Ohm und 10000 Ohm.
Das sind einfach "Anpassungen" an das LaCrosse-Protokoll, welches nur einen eingeschränkten Wertebereich übertragen kann ...
Müsste es dann in FHEM wieder zurückrechnen .... ;)
Zitat von: juergs am 14 November 2017, 08:58:52
Müsste es dann in FHEM wieder zurückrechnen .... ;)
Und wieviel sind die 50ppm dann wirklich?
Wie erklärt Ihr Euch die Unterschiede zwischen den beiden Sensoren? Hätte noch einen dritten jungfräulichen.
Wenn ich mit Messungen unterstützen kann, sagt bitte was ich tun soll.
Grüße, Bernd
Zitat von: blehnert am 14 November 2017, 09:55:37
Wenn ich mit Messungen unterstützen kann, sagt bitte was ich tun soll.
Es wäre hilfreich, charts zu erzeugen (logfile wie von PeMue beschrieben für FHEM produzieren) und diese zu kommentieren, was bei Änderungen der IAQ zu demZeitpunkt passiert ist oder wo Du der Ansicht bist, dass die Werte nicht mir der Realität übereinstimmen.
Im Anhang ein Beispiel.
Der Sensor steht im Arbeitszimmer, die Tür zum Schlafzimmer ist fast immer offen, um die Ecke geht es zu einem Badezimmer.
Muss jetzt wohl mein Leben offenlegen :o ;D ;D
Um 00:00 in Bett gegangen, um 07:30 sind wir aufgestanden und haben geduscht. Danach kurz gelüftet. Ab 08:15 war bis 19:30 niemand da (außer die Katze vielleicht mal)
Und nun frage ich mich: warum wird nach dem Lüften, wenn dann keiner mehr da war, die IAQ erst mal schlechter?
Und warum wurde sie nachts erst kurz schlechter und dann wieder besser?
Und wie stark geht die Luftfeuchtigkeit ein? Eigentlich uinteressiert mich, wie hoch der Schadstoffgehalt in der Luft ist. Ob sie mir zu trocken ist, beurteile ich lieber separat mit einem Hygrometer.
Ich bekomme die Kurven noch nicht so recht in Einklang mit dem, was sich im Haus abspielt.
ich will nicht völlig ausschließen, dass die Luftqualität wirklich diesen Verlauf hat aber seltsam ist es.
Darum wäre es hilfreich wenn Du auch so vorgehen würdest, also Kurven produzieren und dazu beschreiben, wie es mit dem realen Leben übereinstimmt.
Den Zusammenhang zwischen gemessenem Widerstand und IAQ zu ergründen ist dann nochmal ein ganz anderes Thema.
Die Daten der "HCS-FW" werden übrigens von den original Bosch-Routinen incl. der geheimen libalgobsec.a IAQ-Formel geliefert, da kommt also genau das raus, was Bosch sich als IAQ vorgestellt hat.
ZitatUnd wieviel sind die 50ppm dann wirklich?
Der iAQ-core kann 450-2000 ppm CO2 equivalents und 125-600 ppb TVOC equivalents messen.
Für den CO2-Wert dividiere ich durch 10. Das passt zwar nicht komplett mehr in den oberen Werten ...
reicht aber erst mal für diesen Anwendungsfall. Für TVOC wird ebenfalls durch 10 dividiert.
Für den BME, um in den Wertebereich von [-40..120] zu kommen:
LaCrosse.t = (float) bme680_gas / 10000;Anmerkung von hier (https://www.allaboutcircuits.com/projects/build-an-arduino-ble-enabled-air-quality-monitor/):
ZitatThe iAQ-Core indoor air quality sensor module is the heart of the project and is used to provide CO2 and total volatile organic compounds (TVOC) equivalent predictions. The sensing range from the datasheet is as follows: 450-2000 ppm CO2 equivalents and 125-600 ppb TVOC equivalents. "Equivalents" are somewhat vague units and are not defined as well as I would have liked.
From doing a little background reading, it seems like a CO2 equivalent unit includes CO2 and other "greenhouse" gasses, apparently scaled to a property of CO2. TVOC equivalent units also appears to be a somewhat vague measure. It seems that there are a number of compounds considered to be VOCs with particular relevance to indoor air quality and these are totaled and expressed as some standardized measure.
In all fairness, I have seen the use of these "equivalent" units on several commercial indoor air monitors. Still, I would have liked to have seen a more rigorous definition.
Zitat von: juergs am 14 November 2017, 17:40:51
Der iAQ-core kann 450-2000 ppm CO2 equivalents und 125-600 ppb TVOC equivalents messen.
OK, aber wieviel ist es denn in Deinem Chart, das Du angehängt hast, wenn die Kurve bei 50ppm lang läuft, tatsächlich?
500?
iAQ-core nach dem Einschalten:
*** Running.
CO2 [ppm] , resistance, TVOC
450;1820;125
450;1820;125
450;1820;125
450;1820;125
450;1820;125
450;11964;125
450;11964;125
450;11964;125
450;11964;125
450;11964;125
450;17046;125
450;17046;125
450;17046;125
450;17046;125
450;17046;125
450;19358;125
450;19358;125
450;19358;125
909;2205;252
909;2205;252
909;2205;252
[462.79] Timer-Interrupt! = LaCrosse senden.
[462.79] CO2: 90.90 TVOC: 25.20
909;2205;252
909;2205;252
909;2205;252
909;2205;252
BME680: CO2 gespiegelt an der X-Achse, im Vergleich zu BME-IAQ.
Der zweite Screenshot war der Versuch den Offset und die Skalierung des CO2-Wertes
anzupassen. Man sieht aber deutlich, die Kurven bei Skalierung mit konstantem Faktor nicht 100%ig übereinstimmen.
Überlegungen:
1.) Spiegelung wäre einfach, dann aber den Korrektur-Offset herauszufinden ...
(Mittelwert, Median oder doch immer konstanter Offset ....)
2.) Dann die Skalierung in den IAQ-Bereich .... dann Temperatur, Luftdruck + Luftfeuchtekompensation.
Ideen, Vorschläge?
Ich habe dieses Thema mit Hilfe von Google translate verfolgt und nutze es auch, um hier zu antworten. Ich habe 2 Module, die ich von Pimoroni gekauft habe. Ich bin kein Experte, aber ich bin bereit, bei jedem Test zu helfen. Ich habe ein unbenutztes Modul und eines, das ich ein paar Tage benutzt habe. Das ist das einzige Thema, das ich finden konnte, das wirklich lebendig ist. Ein weniger lebhaftes Thema findet sich hier https://github.com/DFRobot/DFRobot_BME680/issues/5
Hello sebswed,
thank you, for joining us and politely translating to german... :)
You are welcome!
Pointing out to the new BCE-capable dfrobot-Lib (https://github.com/DFRobot/DFRobot_BME680) was great. :D :D :D
They had done that special job, that Bosch was not doing so far ...
bme680 test
[55.00] T: 23.04| rH: 40.21| P: 101374.80| IAQ: 0.00 (0) | gas: 3993.10
[3055.00] T: 22.32| rH: 41.17| P: 101369.15| IAQ: 0.00 (0) | gas: 4278.49
[6055.00] T: 22.30| rH: 40.80| P: 101370.21| IAQ: 0.00 (0) | gas: 4699.27
[9055.00] T: 22.27| rH: 40.54| P: 101369.99| IAQ: 0.00 (0) | gas: 5114.61
[12055.00] T: 22.27| rH: 40.28| P: 101368.87| IAQ: 0.00 (0) | gas: 5538.87
[15055.00] T: 22.26| rH: 40.11| P: 101367.79| IAQ: 0.00 (0) | gas: 5923.12
Now i was able to compile the BCE-Code completely and at the same time realized how my nodeMCU
is ticking against a new flashed Firmware. Apparently it is not sufficient to reset the the device,
but also necessary to do a cold reset:
After compile and flashing by Arduino IDE with DTE-soft-reset, only "bme test" from setup-function is appearing through serial monitor and nothing else -> hang + WDT-error.
After switching off and on power supply (usb) the program is running surprisingly how expected....
So that's the difference, why HCSs-Binary apparently was not running at my system,
not having noticed enough this circumstance ... my fault! (ESP newbie + sorry HCS) :'(
I2C-Address for this LIB is 0x77 by leaving SDO open on my BlueDot-breakout-board. (Otherwise SDO connected to GND will be 0x76.)
... passing some time, IAQ is appearing:
[267057.00] T: 22.24| rH: 38.77| P: 101368.09| IAQ: 0.00 (0) | gas: 14137.41
[294058.00] T: 22.23| rH: 38.47| P: 101366.61| IAQ: 0.00 (0) | gas: 14330.94
[297058.00] T: 22.23| rH: 38.38| P: 101368.09| IAQ: 0.00 (0) | gas: 14321.14
[300058.00] T: 22.23| rH: 38.37| P: 101368.63| IAQ: 25.00 (3) | gas: 14340.75
[303058.00] T: 22.22| rH: 38.37| P: 101366.02| IAQ: 19.61 (3) | gas: 14429.70
[306058.00] T: 22.22| rH: 38.41| P: 101367.09| IAQ: 25.00 (3) | gas: 14370.28
[309058.00] T: 22.23| rH: 38.47| P: 101366.72| IAQ: 25.67 (3) | gas: 14350.58
[312058.00] T: 22.23| rH: 38.54| P: 101369.59| IAQ: 23.93 (3) | gas: 14380.15
[315058.00] T: 22.24| rH: 38.57| P: 101368.81| IAQ: 25.00 (3) | gas: 14370.28
[318058.00] T: 22.24| rH: 38.58| P: 101369.83| IAQ: 23.47 (3) | gas: 14409.84
[321058.00] T: 22.23| rH: 38.48| P: 101366.20| IAQ: 25.00 (3) | gas: 14419.77
... and i can imagine, why this behavior would happen .... initially filling up a complete ringbuffer with data for further
analysis ...
Ok, some little error-corrections are needed, regarding airpressure... and this
[1035072.00] T: 22.63| rH: 38.59| P: 101354.81| IAQ: 26.44 (3) | gas: 17105.80
[1038072.00] T: 22.64| rH: 38.56| P: 101354.08| IAQ: 27.47 (3) | gas: 17091.84
[1041072.00] T: 22.63| rH: 38.55| P: 101353.67| IAQ: 25.00 (3) | gas: 17147.83
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld
bme680 test
[57.00] T: 22.58| rH: 38.81| P: 101356.97| IAQ: 0.00 (0) | gas: 15934.17
[3057.00] T: 22.62| rH: 38.74| P: 101354.65| IAQ: 0.00 (0) | gas: 16031.78
[6057.00] T: 22.64| rH: 38.67| P: 101355.83| IAQ: 0.00 (0) | gas: 16230.62
regards,
Juergen
Oh, da ist mir jemand für den MapleMini zuvorgekommen ... ;)
indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/ (https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/)
Mit ein paar wertvollen Hinweisen ...
Der Einfluss der Luftfeuchte scheint stärker gewichtet zu sein wie den der Temperatur. (CO2, nicht der IAQ-Wert).
Zum Aufpeppen der ESP-BME680-Ergebnisse als Grundlage/Anregung:
wlan-lufttemperatur-und-feuchte-logger-mit-grafischer-darstellung-fuer-esp8266/ (https://blog.thesen.eu/wlan-lufttemperatur-und-feuchte-logger-mit-grafischer-darstellung-fuer-esp8266/)
https://github.com/G6EJD/ESP8266-Autonomous-Graphing-Data-Logger (https://github.com/G6EJD/ESP8266-Autonomous-Graphing-Data-Logger)
oder diese Controls:
SteelSeries-Canvas (https://github.com/vsky279/SteelSeries-Canvas)
Nach einigen Versuchen ist mir der Compile für den
MapleMini STM32 ARM M3 ebenfalls gelungen:
*** Setup Bosch Maple
*** bsec_iot_init
[2509.00] T: 22.21| rH: 39.76| IAQ: 0.00 (0)
[5509.00] T: 22.22| rH: 39.75| IAQ: 0.00 (0)
[8509.00] T: 22.21| rH: 39.78| IAQ: 0.00 (0)
[11509.00] T: 22.20| rH: 39.78| IAQ: 0.00 (0)
[284509.00] T: 22.35| rH: 39.67| IAQ: 0.00 (0)
[287509.00] T: 22.35| rH: 39.68| IAQ: 0.00 (0)
[290509.00] T: 22.35| rH: 39.69| IAQ: 0.00 (0)
[293509.00] T: 22.35| rH: 39.70| IAQ: 0.00 (0)
[296509.00] T: 22.35| rH: 39.69| IAQ: 0.00 (0)
[299509.00] T: 22.35| rH: 39.68| IAQ: 0.00 (0)
[302509.00] T: 22.34| rH: 39.69| IAQ: 0.00 (0)
[305509.00] T: 22.35| rH: 39.70| IAQ: 25.00 (3)
[308509.00] T: 22.36| rH: 39.68| IAQ: 25.00 (3)
[311509.00] T: 22.35| rH: 39.71| IAQ: 25.00 (3)
[314509.00] T: 22.35| rH: 39.70| IAQ: 25.17 (3)
[317509.00] T: 22.35| rH: 39.70| IAQ: 25.28 (3)
[320509.00] T: 22.35| rH: 39.69| IAQ: 25.31 (3)
[323509.00] T: 22.35| rH: 39.69| IAQ: 25.31 (3)
[326509.00] T: 22.35| rH: 39.67| IAQ: 25.30 (3)
[329509.00] T: 22.35| rH: 39.68| IAQ: 25.38 (3)
[5558509] T: 22.59| rH: 40.09| IAQ: 248.11 (3)
[5561509] T: 22.60| rH: 40.09| IAQ: 247.76 (3)
Dann erwarte ich mal die OLED-Displays... :)
ZitatC:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM6 1 1EAF:0003 <path>bme680__BSEC_Bosch_Maple[0x77].ino.bin
I2C1 mit PIN 15 SDA und PIN16 SCL
So, da bin ich mal wieder. Hab einiges geschafft, letzte Woche, mein Sensor läuft, samt Anbindung an FHEM :D
Protokoll: CustomSensor, sendet auf 868,3 MHz über RFM69CW. Musste "nur" noch das Modul 36_CustomSensor.pm
erstellen :o Das hat mich doch etwas aufgehalten :-[ Aber es läuft erstmal. Jetzt kann ich mal ein wenig loggen ...
Anbei mal ein paar Impressionen 8)
Gruß Thomas
P:S: Das Log ist noch "etwas komisch" am Anfang, ist noch vom testen, aber ich wollte es Euch nicht vorenthalten ;)
So, hier kurz das Log von heute...
Kurz vor sieben gings los, aufstehen. Im Nachbarraum Fenster geöffnet.
Kurz vor acht, Fenster wieder zu. Dann kaum Bewegung im Raum, alle Türen offen.
Von 16 -20 Uhr wieder etwas Bewegung. 20 Uhr dann kurz lüften im Nachbarraum,
diesmal geht der IAQ nach unten ?!
Hallo hdgucken,
ZitatProtokoll: CustomSensor, sendet auf 868,3 MHz über RFM69CW.
könntest bitte zu Deinem verwendeten Protokoll "CustomSensor" nähere Angaben machen?
Jürgen
Na klar ;)
Der Aufbau ist so:
OK CC ID T1 T2 HH P1 P2 I1 I2 L1 L2 UB G1 G2 G3 CRC
100er + 10er bedeutet linkes Nibble 100er, rechtes Nibble 10er usw. (BCD Code) !
OK CC - fest für CustomSensor Protokoll
ID - Sensor ID (0-FF)
T1 - (Temp + 40 * 10): 100er
T2 - (Temp + 40 * 10): 10er + 1er
HH - humidity 1-99
P1 - pressure = 1000er + 100er
P2 - pressure = 10er + 1er
I1 - IAQ = 100er
I2 - IAQ = 10er + 1er
L1 - LightLevel = 1000er + 100er
L2 - LightLevel = 10er + 1er
UB - BatteryVoltage * 10 = (0-255; 3,3V = 33)
G1 - gas resistance = 100.000er + 10.000er
G2 - gas resistance = 1.000er + 100er
G3 - gas resistance = 10er + 1er
CRC - crc byte
IAQ muss ich evtl. noch auf 100er, 10er und 1er Stelle ändern.
erledigt ;)
Gruß Thomas
Neue BSEC LIb ist verfügbar mit weiteren Controller-Libs:
https://www.bosch-sensortec.com/bst/products/all_products/bsec (https://www.bosch-sensortec.com/bst/products/all_products/bsec)
Inklusive Raspi und 8Bit-AVR-Support:
AVR_8bit AVR-GCC 41k 1k MegaAVR, XMEGA
Z.B. AVR-XMEGA mit Oled:
https://www.element14.com/community/docs/DOC-71436 (https://www.element14.com/community/docs/DOC-71436)
und Arduino-Integration: Xmegaduino (https://github.com/Xmegaduino/Xmegaduino)
Hier gibt es weitere Anleitungen BSEC Library Version 1.4.5.1 vom 16.11.2017:
bme680-mit-nodemcu-an-ttn (https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/) in LoRaWAN (https://www.bjoerns-techblog.de/2017/08/lorawan-gateways-fuer-ttn-eine-uebersicht/)-Ausführung.
uftguetesensor-mit-bme680-und-mh-z14a (https://www.bjoerns-techblog.de/2017/11/luftguetesensor-mit-bme680-und-mh-z14a/)
In puncto 8Bit-Controller eine interessante Alternative zur Berechnung/Bewertung des Widerstandwertes ohne BSEC-Lib
unter Einbeziehung von Temperatur und Luftfeuchte: BME680-Example (https://github.com/G6EJD/BME680-Example)
Schöne Korrelation zwischen Widerstand-Reading BME und CO2-Wert AMS-iAQ-core.
Welche Einheit/Skalierung haben die Werte?
BME in kOhm? Und IAQ-Core?
Hier meine Aufzeichnung von gestern, die Spitzen sind evtl. "heftige Luftbewegungen" in der Nähe des Sensors,
können aber auch von FHEM Neustarts stammen, bin noch am arbeiten mit "Firmata" und dem ESP8266. Auch nicht ganz unproblematisch :)
Hab noch ein kleines Problemchen mit der Übertragung beim CC-Protokoll:
Ab und zu gibt es CRC-Fehler. Obwohl mein Sensor wirklich alle Werte korrekt verarbeitet und auch richtig an den RFM69 übergibt, kommen am LGW einige Pakete mit CRC Fehler raus.
Bin schon am suchen, auch im LGW Code, konnte aber bisher nichts verdächtiges finden. Vielleicht gehen Sie ja auch "over the air" verloren.
Aber im großen und ganzen funktioniert es sehr gut.
Wenn jemand Interesse am Quellcode hat, einfach bescheid sagen ;)
@PeMue: Meine Platinen sind gestern angekommen, vielen Dank !!!
Gruß Thomas
Hallo Thomas,
"Bescheid" ;) :D :D :D ;D
Habe mir mal einige RFMs bestellt ;)
Grüße,
Jürgen
@SusisStrolch
ich benutze ja OOK mit dem LaCrosse Protokoll zum Übertragen.
Leider bleibt es bei den Wertigkeiten etwas beschränkt, so dass ich die Orginalwerte im Moment duch 10 teilen muss.
Bei Werten über 110 gibt es leider noch ein Problem, das ich noch lösen muss.
Als Alternative wäre auch eine Division durch 100 möglich.
Bem iAq sind es CO2- in ppm, beim BME ist es der Resistance-Wert.
Diese Werte sind start Luftfeuchte und Temepratur-Gradientabhängig, so dass man eigentlich nur bei stabilen Rahmenbedingungen
vernünftige Werte zum Auswerten bekommt. Bei starken Delta-T und -HUMs müsste man über z.B. Standardabweichung oder Varianz
die starken Schwankungen herausrechnen. Der iAQ nimmt Schwankungen in den Rahmenbedingungen eher etwas länger übel.
Die reinen Absolutwerte sind, meiner Meinung nach, eher von geringerem Interessse, sondern eher die Tendenz (Steigung) und das Erreichen von Schwellwerten.
Mal schauen ob ich das in einen kompakten Sensor packen kann...
Grüße,
Jürgen
Hier dann mal was zum basteln, viel Spaß ;)
Hallo Thomas,
vielen Dank fürs Teilen.
Bin leider noch in der Warteschleife für die RFMs ....
Grüße,
Jürgen
Hallo Jürgen,
kein Problem, hoffentlich kommen die RFM's bald :)
Oder Du kommentierst das Senden und RFM init zum testen mal aus.
Gruß Thomas
So, war fleißig :)
Version 1.5 ist fertig, hab die neue Version der BSEC Software eingebunden (Ver. 1.4.5.1 vom 16.11.2017).
Neu ist, daß der IAQ jetzt am Anfang als "25" ausgegeben wird, nach ca. 5,5 Minuten kommen dann die berechneten Werte.
Dann hab ich noch eingebaut, daß man jetzt direkt im Sketch die I2C Adresse des BME680 einstellen kann. Viel bequemer !
Außerdem hab ich noch die fertige Binärdatei zum direkten flashen beigelegt 8) (diese läuft mit Adresse 0x77 !)
Na dann viel Spaß damit !
Gruß Thomas
So sieht es gleich nach dem Start des Sensors und dann nach gut 5 Minuten aus:
Der Log von heute sieht irgendwie viel besser aus, die neue Lib scheint "geschmeidiger" zu berechnen,
die Werte springen nicht mehr ganz so schlimm hin und her.
Heute sieht es auch nicht schlecht aus, ganz ordentliche Kurve :D
Anbei der aktuelle Stand von heute, hab noch ein paar Kleinigkeiten überarbeitet und aktualisiert.
Dieses mal sind auch zwei fertige Binärdateien dabei, einmal mit Adresse 0x76 und einmal 0x77,
beide ohne debug Ausgaben, nur Messwerte.
Gruß Thomas
Habe die Tage mein Fhem vom RaspberryPi 2 auf einen RaspberryPi 3 übertragen,
hier nun ein Log vom neuen System :)
Gegen 1:15 ins Bett, 7:00 aufgestanden, gegen 8:15 etwas länger Haustür geöffnet, das
gleiche gegen 10:45. 21:15 - 22:00 mehrere Leute im Raum.
Sieht eigentlich alles sehr plausibel aus, finde ich.
@juergs: sind die RFM's schon eingetroffen, konntest Du schon mal etwas testen ?
Die können übrigends auch OOK ;)
Gruß Thomas
Hallo Thomas,
sind eingetroffen und werden am WoE verbaut. ;)
HCS's neue LIB-Version liefert bei mir, sagen wir mal etwas "komische"
bzw. schwer zu interpretierende Ergebnisse.
Zitat von: juergs am 14 Dezember 2017, 09:46:15
HCS's neue LIB-Version liefert bei mir, sagen wir mal etwas "komische"
meinst Du damit die Test-Firmware oder die LGW-Beta?
Hallo HCS,
die LGW-FW mit der Bosch 1.4 BSEC-Lib.
Grüße,
Jürgen
Hier die Gegenüberstellung iAQ-core-Readings gegen BME-Readings.
Das Verhalten auch gegenüber gegenüber der Bosch-Lib-Vorversion kann ich nicht erklären ...
@Jürgen: sind ganz schöne Sprünge, eigenartig.
Bei mir sah es heute so aus:
(kaum zu Hause gewesen, Werte sind plausibel)
Hallo Thomas,
sieht sehr plausibel und gut aus.
Bei meinem LGW nicht so... Stetigkeit diesmal ok und plausibel, aber der Sprung von 250 auf 50 ... ?
Zitat von: juergs am 15 Dezember 2017, 17:01:29
Bei meinem LGW nicht so...
Ja, die Kurven, die ich vom LGW bekomme sind auch sehr seltsam. Irgndwie passt da was nicht.
Das ist auf dem LGW aber auch etwas heikel um das Timing vernünftg hinzubekommen.
Zitat von: hdgucken am 14 Dezember 2017, 23:33:35
Bei mir sah es heute so aus:
(kaum zu Hause gewesen, Werte sind plausibel)
Aber eine IAQ von knapp 500, Du müsstest eigentlich direkt umkippen, wenn Du reingehst.
@HCS: Umgekippt bin ich bis jetzt noch nicht ;D
IAQ ist die rote Kurve, der Wert lag bei max. 259, das ist eigenartigerweise immer dann so hoch, wenn die Haustür etwas länger offen ist !?
Die Kurve von heute sieht auch ganz ordentlich aus (ähm gestern ;)):
Zitat von: hdgucken am 16 Dezember 2017, 01:45:19
@HCS: Umgekippt bin ich bis jetzt noch nicht ;D
IAQ ist die rote Kurve, der Wert lag bei max. 259, das ist eigenartigerweise immer dann so hoch, wenn die Haustür etwas länger offen ist !?
Bei mit ist rot der Widerstand und grün IAQ. Hatte die Beschriftung nicht angeschaut :-[
Ich habe gestern Abend mal die Test-Firmware von weiter oben auf Bosch 1.4 hochgezogen, da kommen tatsächlich ganz andere Werte als vom LGW.
Zitat von: HCS am 16 Dezember 2017, 09:44:27
Bei mit ist rot der Widerstand und grün IAQ. Hatte die Beschriftung nicht angeschaut :-[
Kein Problem, hab die Farben gleich geändert, weil irgendwie logischer, wenn die Luftqualität grün dargestellt wird ;)
Zitat von: HCS am 16 Dezember 2017, 09:44:27
Ich habe gestern Abend mal die Test-Firmware von weiter oben auf Bosch 1.4 hochgezogen, da kommen tatsächlich ganz andere Werte als vom LGW.
Das ist mir auch aufgefallen, als ich auf die neue Bosch 1.4 umgestellt habe, berechnet irgendwie plausiblere Werte. Allerdings auf meinem CC Sensor,
wollte meinen LGW damit nicht weiter belasten :)
Ich habe mal versucht meine Ergebnisse der Vergleichsmessungen BME680 mit iAQ-core
gegenüberzustellen.
Die oberen beide Graphen T/H und Resistance eines BME680 (ohne Lib) praktisch die direkten Werte per CUL_TX-Protokoll versendet (ohen Temperatur und Luftdruck-Einfluss).
(Das Protokoll verarbeitet leider nur Werte bis 110)
Die beiden mittleren Graphen zeigt die Messungen eines AMS-iAQ-core .
Der Untere Graph zeigt die Werte des zweiten BME680 an LGW mit Bosch 1.4 Lib.
Es scheint durchaus Abschnitte zu geben, die sich ähnlich verhalten (R und IAQ verlaufen gegensinnig),
dann aber unterschiedliche Reaktionen zw. iAQcore und BME.
Morgen Dann werde ich mich an Thomas Variante versuchen....
Außerdem habe ich diesen Algorithmus gefunden, der sich vielleicht für das Auswerten des Verhaltens des BME680 eignet:
https://www.codeproject.com/Articles/999650/Signal-Segmentation-Algorithm-of-Radhakrishnan-et (https://www.codeproject.com/Articles/999650/Signal-Segmentation-Algorithm-of-Radhakrishnan-et)
Improved Signal Segmentation Using Moving Average and Savitzky-Golay Filter (http://file.scirp.org/pdf/JSIP20120100004_82726895.pdf)
Den werde ich mir mal mit meiner Maple-Variante genauer anschauen und die Verwendbarkeit prüfen.
Grüße,
Jürgen
Zitat von: hdgucken am 05 Dezember 2017, 22:10:42
Anbei der aktuelle Stand von heute, hab noch ein paar Kleinigkeiten überarbeitet und aktualisiert.
Dieses mal sind auch zwei fertige Binärdateien dabei, einmal mit Adresse 0x76 und einmal 0x77,
beide ohne debug Ausgaben, nur Messwerte.
Hast Du an der 36_LaCrosseGateway.pm, die im ZIP ist, Anpassungen gemacht?
Ja, bei "$clients" und bei der matchlist. Müsste so stimmen, funktioniert was nicht ?
Anbei die aktuellen Dateien von "jetzt" ;)
Hab mir mal ein userreading "gas_kOhm" erstellt, dann sind die Zahlen im SVG Plot nicht so lang, siehe Bild :)
Zitat von: hdgucken am 17 Dezember 2017, 23:05:12
Ja, bei "$clients" und bei der matchlist. Müsste so stimmen, funktioniert was nicht ?
Alles gut. Wollte nur wissen, ob es was gibt, das ich offiziell reinnehmen müsste.
clients und matchlist könnte ich so übernehmen und einchecken, das ist eigentlich universell für jeden customsensor, der so arbeitet.
Zitat von: HCS am 18 Dezember 2017, 00:21:28
Alles gut. Wollte nur wissen, ob es was gibt, das ich offiziell reinnehmen müsste.
clients und matchlist könnte ich so übernehmen und einchecken, das ist eigentlich universell für jeden customsensor, der so arbeitet.
Das wäre super, dann muss man nicht nach dem Update seine Dateien wieder reinkopieren ;)
Gruß Thomas
Zitat von: juergs am 16 Dezember 2017, 18:22:31
Morgen Dann werde ich mich an Thomas Variante versuchen....
Hallo Jürgen, konntest Du was erreichen, funktioniert Dein Sensor ?
Hallo Thomas,
war noch mit anderen Projekten beschäftigt. Dann widme ich mich wieder dem Thema.
Muss noch die LGW-Platine V1.2 von PeMue mit den RF69CW aufbauen.
Hab leider gerade nur zwei NodeMCU zur Verfügung, aber kein OLED-Display.
Warte auch noch auf NodeMCU-Platinen mit integriertem OLED-Display, die ich bestellt habe.
Das würde genau passen, wenn die demnächst kommen. (;-)
Mal schauen wie ich die RFMs separat auf eine Trägerplatine bekomme....
ESP-12-Module habe ich genügend...
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs am 18 Dezember 2017, 21:00:56
Warte auch noch auf NodeMCU-Platinen mit integriertem OLED-Display, die ich bestellt habe.
hast Du davon einen Link? Klingt echt interessant.
Danke + Gruß
PeMue
Hallo Peter,
diese hier, Wemos:
https://www.ebay.de/itm/wemos-esp-wroom-02-Hauptplatine-WiFi-Modul-ESP8266-18650-Batterie-0-96-OLED-/362094206879 (https://www.ebay.de/itm/wemos-esp-wroom-02-Hauptplatine-WiFi-Modul-ESP8266-18650-Batterie-0-96-OLED-/362094206879)
Gäbe es auch noch ohne die 18650-Option:
0-96-OLED-NODEMCU-Wemos-Wifi-ESP8266-ESP-12F-CP2102-Micro-USB-Development-Board (https://www.ebay.de/itm/0-96-OLED-NODEMCU-Wemos-Wifi-ESP8266-ESP-12F-CP2102-Micro-USB-Development-Board/222688392851?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D2%26asc%3D49571%26meid%3D454a5d85ef674757bcf130a1857b1d1f%26pid%3D100623%26rk%3D5%26rkt%3D6%26sd%3D362094206879&_trksid=p2047675.c100623.m-1)
Die würde genau für den Anwendungszweck passen ...
Halter für die 18650 habe ich massive Überbestände ... ;D
Hallo Jürgen,
Zitat von: juergs am 18 Dezember 2017, 21:00:56
war noch mit anderen Projekten beschäftigt...
Das kenne ich ;)
Zitat von: juergs
Warte auch noch auf NodeMCU-Platinen mit integriertem OLED-Display, die ich bestellt habe.
Das würde genau passen, wenn die demnächst kommen. (;-)
Mal schauen wie ich die RFMs separat auf eine Trägerplatine bekomme....
Hab mir gerade die NodeMCU Platinen mit dem OLED Display angeschaut,
die sind ja wie geschaffen für das Sensorprojekt ! Den RFM bekommt man
schon irgendwie mit "angeheftet" :)
Gruß Thomas
ZitatPlease allow 1-2cm error due to manual measurement
In China ist man präzise ;D ;D ;D
Zitat von: juergs
In China ist man präzise ;D ;D ;D
Ja genau, Pi * Daumen * Fensterkreuz , passt ;D
Hab hier noch ein Log von heute:
(IAQ jetzt grün und Gas in kOhm, sieht viel besser aus ;))
Hallo Thomas,
noch eine Frage zu Deiner Software: würde diese auch auf einem Atmega328p (mit RFM69, BH1750, etc.) laufen? Da müsste man vermutlich einen anderen Teil der BSEC Library einbinden ...
Im LaCrosse Thread habe ich ja schon zusammengefasst, wie es weitergehen könnte.
Welche I2C Adresse des BME680 sollte gewählt werden, oder ist das ggf. egal?
Bin gespannt auf Deine Antwort.
Gruß Peter
Hätte die Bosch-Aussage im anderen Thread gleich komplett zitieren sollen :)
https://github.com/BoschSensortec/BME680_driver/issues/6#issuecomment-351274972
ZitatWe will not disclose the exact nature of how the IAQ index can be calculated. In order to achieve the same performance as our BSEC algorithm, the code will not fit on Arduino boards based on the Atmel AVR series that have 32kB flash and 2kB of RAM.
Zitat
noch eine Frage zu Deiner Software: würde diese auch auf einem Atmega328p (mit RFM69, BH1750, etc.) laufen? Da müsste man vermutlich einen anderen Teil der BSEC Library einbinden ..
STM32 (MapleMini) geht. Läuft bei mir mit CUL_TX (https://forum.fhem.de/index.php/topic,78619.msg718917.html#msg718917).
Hallo Peter,
Zitat von: PeMue
würde diese auch auf einem Atmega328p (mit RFM69, BH1750, etc.) laufen? Da müsste man vermutlich einen anderen Teil der BSEC Library einbinden ...
Diese Frage hat HCS ja schon beantwortet, geht leider nicht, vermutlich aber auf nem ATMega 644 oder 1284, müßte man mal testen.
Zitat von: PeMue
Welche I2C Adresse des BME680 sollte gewählt werden, oder ist das ggf. egal?
Das läßt sich in der Software auswählen, standard ist 0x77, einstellbar ist aber auch 0x76 ;)
Gruß Thomas
Zitat von: juergs am 20 November 2017, 20:12:10
Nach einigen Versuchen ist mir der Compile für den MapleMini STM32 ARM M3 ebenfalls gelungen ...
Und was braucht der an Hardware? Maple mini + BME680? Oder auch noch das OLED?
Gruß PeMue
ZitatUnd was braucht der an Hardware? Maple mini + BME680? Oder auch noch das OLED?
Ich wollte nur die BOSCH - ARM Lib - Variante prüfen. (MapleCUL-Aufbau mit dem STM32F103 + Erweiterungsmöglichkeiten nach Bedarf)
Ich vermute sogar, dass hdgucken's FW in dieser Variante ebenfalls laufen würde ...
Wie es von da aus weitergeht ist ja offen. Das CUL-TX-Protokoll verträgt Werte bis max. um die 110. Dann müsste man IAQ/10 übertragen
und in FHEM wieder zurückrechnen, geht ja mit Userreadings.
Als weitere Möglichkeit mit der NewASKSIN-Library classTHSensor (http://trilu2000.github.io/NewAskSin/classTHSensor.html) auf CC1101-Basis mit einem Arduino zu agieren.
Mit Homematic kenne ich mich aber nicht aus, vielleicht kann mich da jemand auf's Gleis heben...
Prinzipiell sehe ich auch die Firmware von hdgucken als bereits existierenden und guten Weg IAQ-Werte zu übertragen.
Mittlerweile habe ich zwei der ESP-OLED-Module bekommen und werde die mit hdguckens FW bestücken und über die LGW empfangen ...
Ggf. mit den Platinen-Resourcen erweitern Joggle-Button etc.
Dann versuche ich den BME-Resistancewert ohne BME-Lib mit Temp + Hum über CUL_TX-Protokoll zu berücksichtigen (mit dem SegmentedSignal-Algorithmus).
Das Ergebnis wäre wohl ein iAQ-ähnlicher Wert. Aber eigentlich reicht auch nur eine Einstufung des Signals in
Tendenz und eine Unterteilung in "sehrgut", "gut", "annehmbar", "schlecht", "sehr schlecht" aus.
Also nur eine momentane Beurteilung der Luftqualität ... Je nachdem wie man den Output verwerten möchte (Regelung/Visualisierung?)
Diese LoRa (http://www.kh-gps.de/lora.htm)-Variante fände ich auch interressant: http://www.kh-gps.de/lora_bt.htm (http://www.kh-gps.de/lora_bt.htm) Schaltung (http://www.kh-gps.de/lora_uni_rx.jpg). (tnx@ranseyer)
Da stellt sich aber wieder die Gateway-Frage....
Und da wäre noch die djbugs-BLE-Variante: https://forum.fhem.de/index.php/topic,78098.15.html (https://forum.fhem.de/index.php/topic,78098.15.html). Leider hat er seine Ergebnisse bisher noch nicht veröffentlicht....
Schauen wir mal, wie man die Prios verteilen kann ... :D
Jürgen
Apropos Pläne:
Interessehalber hatte ich auch ein AMS-CCS811 (http://ams.com/eng/Products/Environmental-Sensors/Air-Quality-Sensors/CCS811)-Breakout (https://www.banggood.com/CJMCU-8128-CCS811-SI7021-BMP280-Carbon-Dioxide-CO2-VOCs-Temperature-Humidity-Gas-Pressure-Sensor-p-1167432.html?cur_warehouse=CN) bestellt (~10..17€, Kombi mit CCS811+SI7021 (https://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf)+BMP280).
air-quality-sensors (https://www.tindie.com/products/onehorse/air-quality-sensors/)
Nach den guten Erfahrungen mit dem iAQ-core ...
Der kam leider mit abgehobenem Gehäuse an >:(.
ZitatNo need for continuous monitoring in software
Vielleicht funktioniert er trotzdem....
Für die Wemos® D1 Esp-Wroom-02 Motherboard ESP8266 Mini-WiFi-Boards (https://www.banggood.com/Wemos-D1-Esp-Wroom-02-Motherboard-ESP8266-Mini-WiFi-NodeMCU-Module-p-1224577.html?cur_warehouse=CN) (ohne OLED) (https://www.ebay.de/itm/Esp-Wroom-02-WeMos-D1-Motherboard-ESP8266-Mini-WiFi-Nodemcu-Module-18650-Battery-/192272587744) gibt es wohl kein Schaltplan (!) ....
Zitatscheme is not available, libraries is here: https://github.com/LilyGO/ESP32-OLED0.96-ssd1306 (https://github.com/LilyGO/ESP32-OLED0.96-ssd1306)
Hier mal die OLED-LIB für die Demo dazu ( nach langer Sucherei gefunden):
https://github.com/squix78/esp8266-oled-ssd1306 (https://github.com/squix78/esp8266-oled-ssd1306)
Funktioniert ...
ZitatProgrammable LED, you can use GPIO16
OLED's SDA and SCL connect to the D1 pin and the D2 pin respectively.
The five buttons are controlled by FLASH, RSET, D5, D6, and D7 respectively.
Auf den Boards ist das "
SSD1306SimpleDemo" geladen ... ;)
LiPo (https://myesp8266.blogspot.de/2017/07/battery-powered-wemos-d1-with-wemoss.html)
PacketMonitor (https://github.com/spacehuhn/PacketMonitor)
Board-Varianten (https://www.tindie.com/stores/lspoplove/)
Antenne (https://www.aliexpress.com/item/IPEX-2dBi-wire-Antenna-for-ESP-07-ESP32-Wrover/32846319018.html?spm=2114.10010108.100009.4.44770d5dmM0HBV&traffic_analysisId=recommend_2037_null_null_null&scm=1007.13482.91320.0&pvid=ad7c8e89-3b4b-4faa-8788-504e37ebf5d4&tpp=1)
Die vorkompilierte-BSEC-Lib "libalgobsec.a" ist immer noch vom 16.11.2017.
Die Adafruit-OLED-Lib die von hdgucken verwendet wird, läuft nicht auf dem Board.
Diese funktioniert für die Verwendung von display.println:
https://github.com/klarsys/esp8266-OLED (https://github.com/klarsys/esp8266-OLED)
@hdgucken:
wird die INT-Port-Verbindung DIO0 (http://thebillplease.net/play/esp8266-with-rfm69-using-lowpowerlab/) zum Senden beim RFM69CW benötigt?
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs
Die Adafruit-OLED-Lib die von hdgucken verwendet wird, läuft nicht auf dem Board.
Diese funktioniert für die Verwendung von display.println:
https://github.com/klarsys/esp8266-OLED (https://github.com/klarsys/esp8266-OLED)
Da musst Du nur in \libraries\Adafruit_SSD1306\Adafruit_SSD1306.h Zeile 81: "#define SH1106" auskommentieren,
da auf Deinem Board der SSD1306 verwendet wird, ich hab den SH1106 Controller ;)
Zitat
@hdgucken:
wird die INT-Port-Verbindung zum Senden beim RFM69CW benötigt?
eigentlich definitiv nicht, da der Sensor ja nichts empfangen muss (ist bei mir auch nicht angeschlossen, muss ich in der Doku ändern) :-[
Gruß Thomas
Hallo Thomas,
vielen Dank.
Der Controllertyp ist schon eingestellt (http://arduino-er.blogspot.de/2016/04/hello-world-nodemcu-esp8266-128x64-i2c.html), vermute aber, dass I2C auf SCL/SDA mit D1,D2 nicht zieht....
I2C wir nur mittels Konstruktor mit OLED_RESET und Adresse eingestellt...
Vielleicht finde ich noch die Stelle in der Lib um das ggf. vom
Default D4/D5 (ist ja ESP und soll nodeMCU komp. sein ...) wegzubekommen.
Vermutlich bei
Wire.begin (); im Konstruktor....
/*=========================================================================
SSD1306 Displays
-----------------------------------------------------------------------
The driver is used in multiple displays (128x64, 128x32, etc.).
Select the appropriate display below to create an appropriately
sized framebuffer, etc.
SSD1306_128_64 128x64 pixel display
SSD1306_128_32 128x32 pixel display
SSD1306_96_16
-----------------------------------------------------------------------*/
#define SSD1306_128_64
// #define SSD1306_128_32
// #define SSD1306_96_16
/*=========================================================================*/Ggf. implentiere ich die
display.println()-Funktion in der Lib, die geht, nach und verzichte auf die Adafruit-Variante.
Die Hardware-Verdrahtung des RFM69CWs habe ich so ausgeführt:
Zitat
RFM.MISO [8] = ESP.D9 [GPIO3]
RFM.NSS [7] = ESP.D8 [GPIO15]
RFM.SCK [6] = ESP.D4 [GPIO14]
RFM.MOSI [5] = ESP.D3 [GPIO0]
RFM.GND [3] = ESP.GND [15]
RFM.3V3 [2] = ESP.VCC [8]
Den (belegten) OLED-I2C Anschluss für den BME muss ich noch auf dem Board suchen
und separat herausführen ... Reicht evtl. direkt den
ESP.D1 und
ESP.D2 -Anschluss zu nehmen.
Das LGW mit den RFMs ist aufgebaut und muss noch in Betrieb genommen werden,
dann den Sensor-Sender prüfen .....
Doch etwas aufwändiger, als ich dachte ...
Einfach Mist, wenn weder Schaltplan noch Infos dazu geliefert werden ...
Edit: oder man findet einen Ähnlichen (https://github.com/lspoplove/D-duino/blob/master/D-duino-V3.pdf) :D
Grüße,
Jürgen
Die Adafruit-LIB geht auch, wenn:
Zitat// OLED display TWI address
#define OLED_ADDR 0x3C
Adafruit_SSD1306 display(-1);
der Konstruktor so definiert wird. Tssss. :o
@Jürgen: ich hatte die Adafruit Lib extra für meine Zwecke (SH1106) verändert, deshalb müsstest Du dort die Zeile 81 auskommentieren,
oder noch einfacher die original SSD1306 Lib von Adafruit verwenden.
Zitat von: juergs
Die Adafruit-LIB geht auch, wenn:
der Konstruktor so definiert wird. Tssss. :o
interessant ...
Hallo Thomas,
hatte die Orginal-LIB heruntergeladen und benutzt ... :)
Zitat von: juergs
Die Hardware-Verdrahtung des RFM69CWs habe ich so ausgeführt:
SPI läuft in meiner Config über Hardware, also D5,D6,D7 und D8 vom ESP.
Ich hatte das mal als Softwarevariante genutzt, müsste man in den RFMxx Dateien ein paar Sachen anpassen.
Dann kann man die SPI Pins im Sketch nach Wunsch definieren :)
Zitat
Den (belegten) OLED-I2C Anschluss für den BME muss ich noch auf dem Board suchen
und separat herausführen ... Reicht evtl. direkt den ESP.D1 und ESP.D2 -Anschluss zu nehmen.
Genau.
Gruß Thomas
Hier die Lösung für die ADAFRUIT-Bibliothek und den OLED-SSD1306-Controller:
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#define OLED_RESET D0 // RST-PIN for OLED (not used)
#define OLED_SDA D1 // SDA-PIN for I2C OLED
#define OLED_SCL D2 // SCL-PIN for I2C OLED
Adafruit_SSD1306 display(OLED_RESET);
Und das wars (!):
// initial I2C bus and OLED display
Wire.begin(OLED_SDA, OLED_SCL);
Wire.setClock(400000);
// by default, we'll generate the high voltage from the 3.3v line internally! (neat!)
display.begin(SSD1306_SWITCHCAPVCC, 0x3C); // initialize with the I2C addr 0x3C (for the 128x64)
// init done
Wire.begin(OLED_SDA, OLED_SCL);
Wire.setClock(400000);
Deshalb liefen die Adafruit-Beispiele nicht.
Hallo Jürgen,
so müsste es auch funktionieren:
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
Adafruit_SSD1306 display();
// initial I2C bus and OLED display
Wire.begin();
Wire.setClock(400000);
// by default, we'll generate the high voltage from the 3.3v line internally! (neat!)
display.begin(SSD1306_SWITCHCAPVCC, 0x3C); // initialize with the I2C addr 0x3C (for the 128x64)
// init done
Hab die Tage auch etwas an meiner Software gearbeitet:
Beim starten des Sensors wird die BSEC Version angezeit.
Vcc Messung ist jetzt, ebenso wie das OLED Display, abwählbar.
Dann hatte ich ja ab und an CRC-Fehler bei der Übertragung, das lag am SPI Clock (RFM69),
der war zu hoch, bin jetzt runter auf 400kHz, seitdem keine Fehler mehr :D
anbei die aktuelle Version :)
P.S.: hab eben die 36_CustomSensor.pm noch korrigiert und mit eingepackt ...
Hallo Thomas,
dann kann ich an dem System auch weitermachen.
Ich denke das ist der Knackpunkt gewesen:
Wire.setClock(400000); Interessant ist auch, dass die Einstellung zufällig beim Ausprobieren verschiedener Libs bestehen bleibt.
Schaltet man komplett aus und wieder ein, funktioniert plötzlich nichts mehr ...
Die Einstellung gehört eigentlich in den Konstruktor ...
Ursache war eigentlich die Suche nach
display.println ... (Wenn jetzt die Adafruit-Lib geht ...)
Weder in der Lib noch in der GFX.h ist diese Methode enthalten. (print.h?)
In der OLED Lib für den STM32 sind noch einige zusätzliche Methoden zum Anzeigen von Float mit dabei ....
Bei mir unter:
ZitatC:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\OLED_I2C
Bei den WEMOS-Esp-Wroom-02-Modulen mit integriertem OLED-Display kommt jetzt das Problem hoch, dass sich die Seriellen immer wieder
ab- und einschalten. Vermutlich Resetten die CP2102 (https://www.sparkfun.com/datasheets/IC/cp2102.pdf) oder es ist das USB-Kabel... :(
Edit: Flashen bei eingelegtem 18650 Akku mag die Schaltung wohl nicht, ohne 18650 ist der Reset-Effekt weg.
Grüße,
Jürgen
OK, die display.println zickt:
BME680 wireless sensor V1.5
Protocol: CustomSensor
BSEC Version: 1.4.5.1
NODE-ID : 6
begin init Wire.
init wire done.
init OLED.
basic inits OLED done.
before yield.
Hatte die display.println-Statements auskommentiert. Vorher kam die Exception vor den println-Statements.
Der compiler meckert nicht (?).
Yield hatte ich in die 8 Sekunden Warteschleife eingebaut.
Hallo Jürgen,
Zitat von: juergs am 21 Dezember 2017, 15:55:57
STM32 (MapleMini) geht. Läuft bei mir mit CUL_TX (https://forum.fhem.de/index.php/topic,78619.msg718917.html#msg718917).
Du bekommst aber die Daten über die USB Schnittstelle an FHEM, oder? Bei Thomas werden die Daten über den RFM69 geschickt (denke ich mal).
Danke + Gruß
Peter
Hallo Peter,
war ja nur eine Machbarkeitsstudie, da ich Probleme mit den ESP-Exceptions hatte (... yield) .
Aber: den RFM69 an den Maple (bzw. den F103) anzuschließen sollte auch einfach gehen.
War eigentlich mein erster Plan. Als Basis könnte man ebenfalls hdgucken's Sketch nehmen.
Die Einbindung der BSEC-vorkompilierten Libs beim Maple geht ja.
Mit fehlen bis jetzt nur die separaten OLED-Displays, deshalb bin ich gerade dabei den WEMOS
mit integrierten OLED anzubinden. Wie man sieht mit einigen Hürden ;)
Anbei eine mögliche Implementierung für OLED für den Maple mit Anbindung eines BMP085/180 und I2C von hier (https://www.hackster.io/rayburne/oled-temperature-barometer-for-10-b81b28):
ZitatThis is a hacked version of the official library only I2C1 on Maple Mini
oder dieses Beispiel:
ZitatC:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\OLED_I2C
Der Maple mit RFM und OLED mit BME680 wäre das nächste Ziel, wenn das Wroom2-Board soweit zum Laufen zu bringen ist .... ;)
BME680 wireless sensor V1.5
Protocol: CustomSensor
BSEC Version: 1.4.5.1
NODE-ID : 6
begin init Wire.
init wire done.
init OLED.
basic inits OLED done.
before yield.
after yield.
begin init RFM.
Immerhin etwas weiter ....
Hallo Jürgen,
Zitat von: juergs am 28 Dezember 2017, 19:14:48
Anbei eine mögliche Implementierung für OLED für den Maple mit Anbindung eines BMP085/180 und I2C von hier (https://www.hackster.io/rayburne/oled-temperature-barometer-for-10-b81b28):
oder dieses Beispiel:
Der Maple mit RFM und OLED mit BME680 wäre das nächste Ziel, wenn das Wroom2-Board soweit zum Laufen zu bringen ist .... ;)
ich hätte da vorher ziemliche Probleme, die Entwicklungsumgebung für den maple Mini zu installieren. Daher bleibe ich erst mal bei der Arduino IDE für Atmega's bzw. ESP8266 ;D
Gruß PeMue
ZitatProbleme, die Entwicklungsumgebung für den maple Mini zu installieren
Die Arduino-Maple-HW oder die BOSCH-BSEC-LIBS?
Zitat von: juergs am 28 Dezember 2017, 19:35:08
Die Arduino-Maple-HW oder die BOSCH-BSEC-LIBS?
eher (erstmal) ersteres, aber ich habe es auch nicht wirklich ernsthaft probiert ...
Gruß PeMue
Arm- / Maple ja eigentlich nur, weil Bosch die 8-Bitter nicht unterstüzt ... schade.
Aber im Prinzip geht ja der BME-Wiederstand über CUL_TX in 433MHz-OOK. ;)
Hmm, habe die Originl-Libs von https://learn.adafruit.com/adafruit-oled-featherwing/usage (https://learn.adafruit.com/adafruit-oled-featherwing/usage) Adafruit heruntergeladen ....
... und siehe da: Das Beispiel stürzt beim ersten
display.println ebenfalls ab.
Ein Diff auf Thomas Lib-Version zeigt nur die
/* --- SH1106 --- */ - Patchs ... sonst eigentlich identisch.
Ist es die ESP-SDK-Version ?
ZitatArduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26
Aha, hier:
https://github.com/sparkfun/SparkFun_Micro_OLED_Arduino_Library/issues/5 (https://github.com/sparkfun/SparkFun_Micro_OLED_Arduino_Library/issues/5)
OK, diese hier funktioniert bei dem Wemos-D1-Board:
https://github.com/greiman/SSD1306Ascii (https://github.com/greiman/SSD1306Ascii)
wegen http://www.esp8266.com/viewtopic.php?f=29&t=7841 (http://www.esp8266.com/viewtopic.php?f=29&t=7841) und https://github.com/adafruit/Adafruit_SSD1306/issues/54 (https://github.com/adafruit/Adafruit_SSD1306/issues/54)
trotz:
src/SSD1306AsciiWire.h:61:2: warning: #warning set400kHz() disabled for this CPU. [-Wcpp]
#warning set400kHz() disabled for this CPU.Fragezeichen, und staune ! (Edit: Wire-Setting auf 400KHz reicht aus)
Das Board und die OLED-Lib-Fehler/Unzulänglichkeiten nerven schon etwas....
Dann werfe ich die Adafruit-Lib bis auf Weiteres raus ... :'(
BME680 wireless sensor V1.5
Protocol: CustomSensor
BSEC Version: 1.4.5.1
NODE-ID : 6
begin init Wire.
init wire done.
init OLED.
basic inits OLED done.
text display tests.
Test OLED done.
before yield.
after yield.
begin init RFM.
RFM69 failed, stop!
Soft WDT reset
Hatte den RFM noch nicht angeschlossen, das Display zeigt den Text an ... :)
Bei angeschlossenem RFM geht nichts mehr, also erst mal Aufbau, Verdrahtung und die Soft-SPI-Funktionalität prüfen...
Hallo Jürgen,
Zitat von: juergs am 28 Dezember 2017, 20:09:44
Arm- / Maple ja eigentlich nur, weil Bosch die 8-Bitter nicht unterstüzt ... schade.
Aber im Prinzip geht ja der BME-Widerstand über CUL_TX in 433MHz-OOK. ;)
wenn ich mir die BSEC Library anschaue, dann müsste aber der ATXMEGA32 eigentlich funktionieren, oder?
Meine Idee ist es, Dirk's Innensensor (https://wiki.fhem.de/w/images/2/28/Universalsensor-CC1101-Innen_platine.jpg) um einen Atxmega 32 bzw. einem BME680 zu erweitern, ggf. noch einen RFM69 draufzumachen und zu schauen, ob die Sache auch mit Batteriebetrieb funktionieren könnte. Ggf. findet sich ja auch jemand, der sich um die Homematic Software kümmert ...
Gruß PeMue
Hallo Peter,
hatte die XMega-Variante auch gesehen, aber noch nicht eingeordnet ...
ZitatDirk's Innensensor
Falls das geht, wäre das eine super Lösung.
Ich habe hier noch zwei ATXMega32-A4-AU hier auf DIP-Extention-Boards herumliegen.
War damals ein Fehlkauf, hatte sie mit ATMEGA32-U4 "verwechselt" :'(
Zum Testen kann ich sie Dir gerne zuschicken ...
Mir ist in der neuen Doku aufgefallen, dass sie die Beschreibung für den Einbau der vorkompilierten Libs in Arduino herausgenommen haben ....
In der Release_20171214 ist auch der megaAVR mit dabei, also nicht unbedingt XMega. :D
Unter
BSEC_1.4.5.1_Generic_Release_20171214\algo\bin\avrZitatAVR32
AVR8_megaAVR
AVR8_XMEGA
Dann müsste ja auch ein NANO usw. direkt mit der Innensensor-Platine gehen ...
Hallo Jürgen,
Zitat von: juergs am 28 Dezember 2017, 22:17:04
Mir ist in der neuen Doku aufgefallen, dass sie die Beschreibung für den Einbau der vorkompilierten Libs in Arduino herausgenommen haben ....
hast Du die alte Beschreibung noch irgendwo?
Danke + Gruß
PeMue
Zitat von: juergs am 28 Dezember 2017, 22:17:04
Mir ist in der neuen Doku aufgefallen, dass sie die Beschreibung für den Einbau der vorkompilierten Libs in Arduino herausgenommen haben ....
Möglicherweise weil man ab der kommenden Aduino-Version (> 1.8.5) wohl compiled libs ohne Gebastel verwenden können soll
Hallo Peter,
https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=87791 (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=87791) habe ich das PDF abgelegt.
Und die Einbindung für den ESP8266:
https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/
Könnte ähnlich für den AVR zu handhaben sein ...
Eclipse-Variante (http://andybrown.me.uk/2010/10/24/the-arduino-library-compiled-and-ready-for-linking/)
ZitatThe Arduino IDE now supports .a and .so files in libraries. See instructions in the precompiled property documentation here:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format.
Ausschnitt:
precompiled - (feature not yet released, will be available in arduino-builder >1.3.25) set to true to allow the use of .a (archive) and .so (shared object) files.
The .a/.so file must be located at src/{build.mcu} where {build.mcu} is the architecture name of the target the file was compiled for.
Ex: cortex-m3 for the Arduino DUE. The static library should be linked as an ldflag.
ZitatLong story short, binary libraries are more complex than you think and you should avoid them in open source projects, especially when using C++
Hallo Jürgen,
bin bei den vielen Beiträgen in den letzten Stunden gar nicht recht hinterher gekommen ;D
Also,
Zitat von: juergs
Ist es die ESP-SDK-Version ?
Nein, habe die selbe Version: 1.20.0-26
src/SSD1306AsciiWire.h:61:2: warning: #warning set400kHz() disabled for this CPU. [-Wcpp]
#warning set400kHz() disabled for this CPU.Das habe ich nicht ! Vielleicht mit etwas geringerem Takt probieren ?
Zitat
Bei angeschlossenem RFM geht nichts mehr, also erst mal Aufbau, Verdrahtung und die Soft-SPI-Funktionalität prüfen...
Hier ist SoftSPI angesagt, damit Du die Pins frei wählen kannst. Musst aber bestimmt einige Warteschleifen einfügen,
habe SoftSPI bei 8MHz Systemtakt verwendet, beim ESP sind es jetzt aber 80MHz !
Gruß Thomas
Hallo Thomas,
danke für die Infos.
Habe das Gefühl: OLED und ESP ist ein richtig kniffliges Thema.
Verwendet man verschiedene Libs beeinflussen die sich gegenseitig. Schaltet man aus und wieder ein, funktioniert es plötzlich nicht mehr ...
Dieser Fehler ist tückisch:
Zitatespcomm_sync failed error: espcomm_open failed
Der schließt und öffnet die Serielle im Sekundentakt....
Ich versuche eine passende Soft-SPI-Lib u finden, die das für den ESP regeln kann ....
Heute habe ich Wemos D1 und separate OLED-Module bekommen, diese laufen allerdings mit Adresse 0x78 ....
... und habe sie noch
nicht zum Laufen gebracht ....
Jürgen
Hallo Jürgen,
Zitat
Dieser Fehler ist tückisch: Der schließt und öffnet die Serielle im Sekundentakt....
Das könnte an der Verdrahtung von GPIO3 (ESP.D9) bei Dir liegen, das ist RXD0 der Seriellen,
den und GPIO1 = TXD0 (D10 an Deinem Board) darfst Du nicht verwenden, wenn die Serielle verwendet wird :o
Ich fürchte, Du mußt den RFM doch direkt and den ESP löten, wäre aber auch nicht weiter tragisch, denke ich ;)
Gruß Thomas
Hallo Thomas,
das Board bekommt man in der Arduino-IDE in dem Modus nicht wieder zurück...
Mit dem
ESP8266Flasher nur, wenn man den ricchtigen Zeitpunkt erwischt ....
War schon am Überlegen, den ESP auszulöten und zu ersetzen.
Aktueller Stand: OLED auf dem Wroom2-Board funktioniert, mit Wemos-D1 und 128x64-OLED
geht noch nicht. Habe auch die Info gefunden, dass der Controller SSD1106 auch verbaut sein könnte.
ZitatOLED screen, internal drive chip: SH1106 (Operation and SSD1306 same)
Mühsam nährt sich das Eichhörnchen... :o
/EDIT: Habe mal versuchsweise ESPEASY auf dem D1 installiert. Das OLED konfiguriert (0x3C ist Standard-Einstellung)
Und siehe da, Display geht mit I2C-Adresse 0x3C. Trotz auf dem Display aufgedruckte I2C-Adresse 0x77 (!?).
Ich probiere mal die Initialisierung des OLEDS von ESPEASY aus....
Hallo Jürgen,
auf dem WEMOS D1 mini mit dem SH1106 Controller, sollte meine Software laufen, schon mal probiert ?
Ohne BH1750 und RFM69 müsstest Du im Setup halt
for (;;); // spin fo rever
vorrübergehend auskommentieren (beim RFM69 und BH1750) und mal sehen, was dann passiert 8)
Gruß Thomas
Hallo Thomas,
mit der Adafruit-Lib funktionieren (bei mir) die
display.println Methoden-Aufrufe nicht.
Die Original-Lib hat vermutlich Problem beim Zugriff auf das pgm_read-Makro (nur Warning).
Unter der ESP-Infrastruktur reicht es aus ein
#include <pgmspace> zu setzen.
Dann ist zwar das Warning des Compilers weg, Textausgabe funktioniert trotzdem nicht.
Ich weiß jetzt, dass die println-Methode als Vererbung auf die Print-Klasse zur Verfügung steht.
Diese verlangt eigentlich "nur" die Implementierung von zwei abstrakten write-Methoden.
Die Ursache, warum das mit meiner (original) Adafruit-Version nicht klappt .... schwierig herauszufinden.
Deshalb wird das bei mir wohl mit Deiner Version (mit meinem Compile) wohl nicht klappen.
Der Diff auf Deine LIB ergab bei mir nichts wesentlich unterschiedliches.
Compiliere mit Arduino-Version 1.8.3.
Dann muss ich eine abgespeckte Version von Deinem Code erstellen ...
Ich habe ein kleine OLED-Lib bei der man die Cursor-Position setzen muss um Text auszugeben,
aber auf den Komfort der println-Methode verzichten muss. (Zumindest im Moment.)
Diese hier bietet ein Menü: https://github.com/lexus2k/ssd1306 (https://github.com/lexus2k/ssd1306)
ist aber etwas umfangreich ...
Die hier ist klein:
https://github.com/bentor/oled/tree/master/OzOLED (https://github.com/bentor/oled/tree/master/OzOLED)
Oder diese hier: https://github.com/greiman/SSD1306Ascii (https://github.com/greiman/SSD1306Ascii) funktioniert ebenfalls.
Die sehen vielversprechend aus. Die SSD1306Ascii hat auch ein println implementiert. Funktioniert aber nicht mit dem D1 ... :-\
/Edit:
//Wire.begin(D1,D2);
Wire.begin();Die LIB "SSD1306Ascii" mag die Initialisierung von Wire nicht: Konstruktor mit explizit D1 und D2 gesetzt. ::)
Bei den verschiedenen Libs ist die Reihenfolge im Konstruktor auch SCl und SDA gedreht ...
Kann jetzt also die "
SSD1306Ascii" verwenden! :D
Prüfe auch noch mal auf dem WROOM2-Board nach ...
Schwierig, sich nicht zu verzetteln ...
Auch hier nutzbar:
Zitat/**
* Attiny85 PINS
* ____
* RESET -|_| |- 3V
* SCL (3) -| |- (2)
* SDA (4) -| |- (1)
* GND -|____|- (0)
*
* Atmega328 PINS: connect LCD to A4/A5
*/
Widme mich jetzt dem RFM69 und SPI auf dem D1-mini ....
Wenn das geht, auch das Wroom2-Board ...
Grüße
Jürgen
Sorry, wenn ich wegen dem OT-OLED-Gedöns nerve:
Beim D1-mini-Board funktioniert eine Anzeige nur mit:
Wire.begin();
Beim Wroom2-Board nur mit
Wire.begin(D1,D2);
Jeweils mit der gleichen Arduino Board-Einstellung auf "WEMOS D1 R2 & mini" und dem gleichen Code!
Das OLED-Display erwartet 400KHz I2C-Takt. 100 KHz geht nicht.
Das D1-Board regiert sehr sensibel mit Resets und "USB-Port busy" Meldungen.
Ist schwierig, es wieder zum "Kooperieren" zu überzeugen ...
Irgendwie hat sich auch die Autoreset-Funktion verabschiedet ... Vielleicht nützt ein 100nF an Reset.
Das sollte es jetzt gewesen sein. Ein "println" ist also mit "SSD1306Ascii" machbar.
Hallo Jürgen,
alles gut, bei den Problemen würde ich auch verrückt werden ;)
Habe gerade nachgeschaut, ich arbeite mit Arduino 1.8.5,
das esp Paket "esp8266 by ESP8266 Community" ist Version 2.3.0.
RFM auf dem D1 mini sollte ja eigentlich relativ problemlos gehen 8)
Auf dem Wroom2 würde ich direkt an das esp Modul löten.
So, dann viel Erfolg ...
Gruß Thomas
Hallo Zusammen,
ein gutes neues Jahr !
@hdgucken:
bin jetzt mit dem D1-mini soweit, dass alles geht!
Bis auf die fehlermeldung in FHEM:
Zitat
2018.01.01 19:37:04 0: Server started with 1055 defined entities (fhem.pl:15676/2017-12-23 perl:5.014002 os:linux user:fhem pid:22900)
2018.01.01 19:37:29 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/36_CustomSensor.pm line 217.
2018.01.01 19:37:29 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/36_CustomSensor.pm line 218.
2018.01.01 19:37:29 1: ERROR: empty name in readingsBeginUpdate
2018.01.01 19:37:29 1: stacktrace:
2018.01.01 19:37:29 1: main::readingsBeginUpdate called by ./FHEM/36_CustomSensor.pm (226)
2018.01.01 19:37:29 1: main::CustomSensor_Parse called by fhem.pl (3702)
2018.01.01 19:37:29 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (686)
2018.01.01 19:37:29 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (460)
2018.01.01 19:37:29 1: main::LaCrosseGateway_Read called by fhem.pl (3487)
2018.01.01 19:37:29 1: main::CallFn called by fhem.pl (685)
2018.01.01 19:37:29 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4416.
...
Zitat2018.01.01 19:37:29 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4151.
2018.01.01 19:37:29 1: ERROR: >06< returned by the CustomSensor ParseFn is invalid, notify the module maintainer
2018.01.01 19:38:07 1: PERL WARNING: Bareword found where operator expected at (eval 222) line 1, near "] CO2"
2018.01.01 19:38:07 3: eval: { LGW [BME680] CO2 }
2018.01.01 19:38:07 1: PERL WARNING: (Missing operator before CO2?)
2018.01.01 19:38:07 3: eval: { LGW [BME680] CO2 }
2018.01.01 19:38:07 1: ERROR evaluating { LGW [BME680] CO2 }: syntax error at (eval 222) line 1, near "LGW ["
Daten und IAQ werden erzeugt
Zitat[647233] P: 987.03| T: 20.67| rH: 41.70| IAQ: 30 30 (1)| Gas: 111.62| UBat: 3.27V| Light: 0lx
[650233] P: 987.01| T: 20.67| rH: 41.72| IAQ: 33 31 (1)| Gas: 111.25| UBat: 3.27V| Light: 0lx
[653233] P: 986.94| T: 20.67| rH: 41.76| IAQ: 36 33 (1)| Gas: 110.88| UBat: 3.27V| Light: 0lx
[656233] P: 987.01| T: 20.67| rH: 41.79| IAQ: 34 34 (1)| Gas: 110.95| UBat: 3.27V| Light: 0lx
[659233] P: 987.01| T: 20.67| rH: 41.80| IAQ: 37 35 (1)| Gas: 110.66| UBat: 3.27V| Light: 0lx
[662233] P: 986.97| T: 20.67| rH: 41.80| IAQ: 37 35 (1)| Gas: 110.66| UBat: 3.27V| Light: 0lx
[665233] P: 986.92| T: 20.68| rH: 41.82| IAQ: 32 35 (1)| Gas: 110.95| UBat: 3.27V| Light: 0lx
[668233] P: 986.86| T: 20.67| rH: 41.85| IAQ: 37 36 (1)| Gas: 110.51| UBat: 3.27V| Light: 0lx
Habe noch eine Mittelwert-Bildung hinzugefügt, mit dem Risiko das BSEC-Timing zu stören ....
Steigt aber nach einiger Zeit mit einem WDT-Error aus.
Grüße,
Jürgen
EDIT: nach FHEM Update:
Zitat2018.01.01 20:11:07 3: LGW: Unknown code OK CC 6 6 8 42 9 135 0 98 0 0 0 17 0 96 , help me!
2018.01.01 20:14:24 3: LGW: Unknown code OK CC 6 6 8 42 9 135 0 37 0 0 0 6 116 52 , help me!
2018.01.01 20:20:24 3: LGW: Unknown code OK CC 6 6 9 42 9 135 0 41 0 0 0 16 137 96 , help me!
2018.01.01 20:22:57 3: mapleCUL433: Unknown code P12#7511BA7BFF7F7F8F, help me!
2018.01.01 20:27:22 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 113 99 , help me!
2018.01.01 20:27:22 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 113 99 , help me!
2018.01.01 20:29:53 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 68 100 , help me!
2018.01.01 20:31:28 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 102 128 , help me!
2018.01.01 20:31:28 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 102 128 , help me!
Hier meine Code-Änderungen für das D1-mini Board.
Sowie ein vorläufiger Draft-Schaltpan dazu.
Die SSD1306ASCII-Lib und eine Bin-Datei ist mit beigefügt.
Erweitert: Vcc für den ESP und Mittelwertbildung für IAQ mit 6 Readings.
Die Unterscheidung Adafruit- und SSD1306ASCII-Lib ist nur auf letztere ausgeprägt, baue ich aber ein.
Falls es keine Probleme mit der Adafruit-Lib geben sollte, kann man switchen.
Funktionierende VCC-Messung für ESP mit Workaround eingebaut. (Siehe Kommentare in Code)
BME680-Breakout: Watterot
OLED-Modul: weiss .
Der WDT-Fehler kommt sporadisch nach unterschiedlichen Zeiten ...
Mein D1mini ist allerdings auch sehr unstabil ... :o
Evtl. spendiere ich noch ein 100µF Elko auf die 3V3-Leitung oder einen separaten 3V3-LDO-Regler auf 5V.
Spezieller Dank an hdgucken.
Zitat von: juergs am 01 Januar 2018, 20:04:59
Hier meine Code-Änderungen für das D1-mini Board.
Bis auf das OLED macht der nano LGW (https://forum.fhem.de/index.php?action=dlattach;topic=51329.0;attach=86429) das gleiche (oder war's dasselbe ????).
Gruß PeMue
Zitat von: PeMue am 01 Januar 2018, 20:08:26
Bis auf das OLED macht der nano LGW das gleiche (oder war's dasselbe ????).
Gruß PeMue
Nun ja, wir essen die gleiche Birne, können unser aber die selbe nur teilen ;)
Grüße Jörg
Zitat von: PeMue am 01 Januar 2018, 20:08:26
Bis auf das OLED macht der nano LGW das gleiche (oder war's dasselbe ????).
Gruß PeMue
Hallo PeMue,
ja im Prinzip vom Schaltplan her schon, ist aber für die CustomSensor-Implementierung von hdgucken.
Aber auch die Vorstufe für das andere WROOM2-Board, welches wohl nur mit Soft-SPI läuft.
Leider nur Draft-Version .. mit Adapter für das D1+OLED-Board und Verkabelung für den RFM69 ;)
Für den Fall, dass es jemand interessieren sollte... :D
Zitatnano LGW
Schau mir den mal an ...
ZitatNun ja, wir essen die gleiche Birne, können unser aber die selbe nur teilen ;)
Softwaretechnisch: gleiche = Typ und selbe = Instanz
Automobiltechnisch: SachNummer und IdentNummer .... ;)
Zitat von: PeMue am 01 Januar 2018, 20:08:26
Bis auf das OLED macht der nano LGW (https://forum.fhem.de/index.php?action=dlattach;topic=51329.0;attach=86429) das gleiche (oder war's dasselbe ????).
Habe oben den Link zum aktuellen Schaltplan eingefügt.
Gruß PeMue
Zitat von: PeMue am 01 Januar 2018, 21:56:43
Habe oben den Link zum aktuellen Schaltplan eingefügt.
Gruß PeMue
Danke, sehr hilfreich. (BME ist auch Watterot wg. SD0...)
Sind da (noch) Platinen verfügbar? ;D
Das nächste Objekt mit limitierten Resourcen an der Stiftleiste, aber mit Taster für Menü-Option + 18650 (inkl. Laderegler + Schutz):
(...kommt auch noch ein 3D-Gehäuse dazu ...)
Hallo Jürgen,
Zitat von: juergs
Hier meine Code-Änderungen für das D1-mini Board.
Sowie ein vorläufiger Draft-Schaltpan dazu.
Die SSD1306ASCII-Lib und eine Bin-Datei ist mit beigefügt.
hab mir gerade Dein geändertes Projekt angesehen, gefällt mir auch sehr gut ;)
Zitat
Funktionierende VCC-Messung für ESP mit Workaround eingebaut. (Siehe Kommentare in Code)
Hatte ich auch schon getestet, war aber ca. 0.4V daneben, vermutlich wegen dem externen Spannungsteiler auf den NodeMCU und D1 mini Board's ?!
Da ich aber einen zusätzlichen externen Spannungsteiler dran hab, bin ich wieder auf die normale Analogmessung zurück gegangen. Aber mit dem Korrekturfaktor
spart man sich natürlich die externen Bauelemente, muß ich nochmal testen ;D
Zitat
Evtl. spendiere ich noch ein 100µF Elko auf die 3V3-Leitung oder einen separaten 3V3-LDO-Regler auf 5V.
Einen kleinen Elko und 100nF Abblock-C hab ich auch mit dran, trotzdem sieht man den Messrythmus des BME680 ganz leicht am Display,
die Helligkeit bricht alle 3 Sek. kurz etwas ein. Ein externer 5V nach 3.3V LDR wäre bestimmt die bessere Wahl ;D
Zitat
Spezieller Dank an hdgucken.
Sehr gerne, Danke auch Dir und HCS, man lernt immer wieder dazu :)
Was machen eigentlich Deine Perl Warnungen ? Sind die jetzt weg ?
Ich hänge Dir nochmal meine aktuellen Dateien mit ran:
Gruß Thomas
Hallo Jürgen,
Zitat von: juergs
EDIT: nach FHEM Update:
2018.01.01 20:11:07 3: LGW: Unknown code OK CC 6 6 8 42 9 135 0 98 0 0 0 17 0 96 , help me!
2018.01.01 20:14:24 3: LGW: Unknown code OK CC 6 6 8 42 9 135 0 37 0 0 0 6 116 52 , help me!
2018.01.01 20:20:24 3: LGW: Unknown code OK CC 6 6 9 42 9 135 0 41 0 0 0 16 137 96 , help me!
2018.01.01 20:22:57 3: mapleCUL433: Unknown code P12#7511BA7BFF7F7F8F, help me!
2018.01.01 20:27:22 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 113 99 , help me!
2018.01.01 20:27:22 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 113 99 , help me!
2018.01.01 20:29:53 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 68 100 , help me!
2018.01.01 20:31:28 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 102 128 , help me!
2018.01.01 20:31:28 3: LGW: Unknown code OK CC 6 6 16 42 9 135 0 37 0 0 0 6 102 128 , help me!
Da fehlen die zwei Änderungen in der 36_LaCrosseGateway.pm:
Zeile 10 am Ende > :CostumSensor" < einfügen und
Zeile 19 > "7:CustomSensor" => "^OK\\sCC\\s", < einfügen. Dann geht's wieder ;)
Gruß Thomas
Hallo Thomas,
Zitat von: hdgucken am 31 Dezember 2017, 01:03:01
Habe gerade nachgeschaut, ich arbeite mit Arduino 1.8.5,
das esp Paket "esp8266 by ESP8266 Community" ist Version 2.3.0.
ich setze gerade meine Arduino IDE neu auf, ich bekomme die v2.4.0 angeboten. Spricht was gegen diese Version?
Danke + Gruß
Peter
Hallo Thomas,
ich habe mit Deiner Backup-Version immer noch den mehrfachen Fehler:
Zitat2018.01.02 20:00:59 1: readingsUpdate(,gas,45640) missed to call readingsBeginUpdate first.
2018.01.02 20:00:59 1: stacktrace:
2018.01.02 20:00:59 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (251)
2018.01.02 20:00:59 1: main::CustomSensor_Parse called by fhem.pl (3703)
2018.01.02 20:00:59 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.02 20:00:59 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.02 20:00:59 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.02 20:00:59 1: main::CallFn called by fhem.pl (687)
2018.01.02 20:00:59 1: ERROR: >06< returned by the CustomSensor ParseFn is invalid, notify the module maintainer
Habe probiert das:
$hash->{AttrList} = "$readingFnAttributes"; mal so zu ersetzen:
$hash->{AttrList} = . $readingFnAttributes;oder so:
$hash->{AttrList} = "IODev ".$readingFnAttributes;Aus Code-Beispiel (https://github.com/jowiemann/DBPlan-for-Fhem/blob/master/FHEM/98_DBPlan.pm) Zeile 65 und Beispiel2.pm (https://github.com/jowiemann/fhemduino_modules/blob/master/14_FHEMduino_Gas.pm) Zeile 147
@PeMue
ich habe diese Version im Einsatz:
https://github.com/esp8266/Arduino/releases/download/2.4.0-rc1/package_esp8266com_index.json,
Vermutlich bereitet mir diese etwas ältere RC-Version Probleme muss aber nicht bei der stable-Edition (1.8.3) sein.
Ein Ersetzen durch die stable Community-Edition resultierte bei mir in einer Neuinstallation der Arduino-IDE, weil dananch nichts mehr ging ...
Da passte dann die Infrastruktur nicht mehr (Windows 10) weil ich unter %APPDATA% installiert hatte und nicht im Hardware-Ordener der IDE.
Das bewahrt einem bei einer neuen Version der Arduino-Ide vor einer Neuinstallation des ESP-Packages....
Evtl. resultieren meine WDT-Fehler auch daraus. Probiere das auf einer VM mal neu aus ...
Grüße,
Jürgen
36_CustomSensor (2).pm ist Deine Backup-Version unten im Diff.
Hallo Jürgen,
Zitat von: juergs am 02 Januar 2018, 20:09:23
@PeMue
ich habe diese Version im Einsatz:
https://github.com/esp8266/Arduino/releases/download/2.4.0-rc1/package_esp8266com_index.json,
Vermutlich bereitet mir diese etwas ältere RC-Version Probleme muss aber nicht bei der stable-Edition (1.8.3) sein.
Ein Ersetzen durch die stable Community-Edition resultierte bei mir in einer Neuinstallation der Arduino-IDE, weil dananch nichts mehr ging ...
Da passte dann die Infrastruktur nicht mehr (Windows 10) weil ich unter %APPDATA% installiert hatte und nicht im Hardware-Ordener der IDE.
ich nehme immer die ZIP Datei der IDE, extrahiere sie und erzeuge da, wo ich sie extrahiert habe, ein Verzeichnis portable. Damit ist die komplette IDE portabel und ich muss nicht schauen, wo ich was installieren muss ...
Gruß PeMue
Zitat... releases/download/2.4.0-rc1
Den Ordner gibt es nicht mehr.... :-\
Also ebenfalls neu installieren ... ???
Hatte damals wohl eine andere Lösung erwischt ...
Hallo Jürgen,
Zitat von: juergs
ich habe mit Deiner Backup-Version immer noch den mehrfachen Fehler:
Habe probiert das:
$hash->{AttrList} = "$readingFnAttributes";
mal so zu ersetzen:
$hash->{AttrList} = . $readingFnAttributes;
oder so:
$hash->{AttrList} = "IODev ".$readingFnAttributes;
so müsste es richtigerweise sein, hab ich auch gleich mal geändert: ;)
$hash->{AttrList} = $readingFnAttributes;@Peter:
Zitat von: PeMue
Hallo Thomas,
ich setze gerade meine Arduino IDE neu auf, ich bekomme die v2.4.0 angeboten. Spricht was gegen diese Version?
Nicht das ich wüßte, sollte funktionieren :)
Gruß Thomas
Hallo Jürgen,
Zitat von: juergs am 01 Januar 2018, 22:06:55
Sind da (noch) Platinen verfügbar? ;D
aber klar doch, und auch (in homöopatischen Mengen) die zugehörigen Sensoren ...
Gruß Peter
Hallo,
bin immer noch am Rätseln wo das Problem liegen könnte:
ERROR: empty name in readingsBeginUpdate
2018.01.03 18:20:50 1: stacktrace:
2018.01.03 18:20:50 1: main::readingsBeginUpdate called by ./FHEM/36_CustomSensor.pm (212)
2018.01.03 18:20:50 1: main::CustomSensor_Parse called by fhem.pl (3703)
2018.01.03 18:20:50 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.03 18:20:50 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.03 18:20:50 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.03 18:20:50 1: main::CallFn called by fhem.pl (687)
2018.01.03 18:20:50 1: readingsUpdate(,temperature,20.5) missed to call readingsBeginUpdate first.ZitatERROR: empty name in readingsBeginUpdate
2018.01.03 18:53:50 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4152.
2018.01.03 18:53:50 1: ERROR: >06< returned by the CustomSensor ParseFn is invalid, notify the module maintainer
2018.01.03 18:53:50 5: LGW: dispatch OK 9 8 1 4 66 106
2018.01.03 18:53:50 4: LaCrosse: Unknown device 08, please define it
2018.01.03 18:53:53 5: LGW: dispatch OK 22 124 12 0 66 225 242 0 9 247 81 0 0 15 37 0 5 62 213 0 0
2018.01.03 18:53:54 5: LGW: dispatch OK 9 8 1 4 66 106
2018.01.03 18:53:54 4: LaCrosse: Unknown device 08, please define it
2018.01.03 18:53:58 5: LGW: dispatch OK 22 124 12 0 66 225 247 0 9 247 86 0 0 15 37 0 5 62 213 0 0Zitat2018.01.03 19:10:51 5: LGW: dispatch OK CC 6 6 17 38 9 146 0 37 0 0 0 9 85 118
2018.01.03 19:10:51 3: LGW: CustomSensor-Frame: OK CC 6 6 17 38 9 146 0 37 0 0 0 9 85 118
2018.01.03 19:10:51 1: ERROR: empty name in readingsBeginUpdate
2018.01.03 19:10:51 1: stacktrace:
2018.01.03 19:10:51 1: main::readingsBeginUpdate called by ./FHEM/36_CustomSensor.pm (220)
2018.01.03 19:10:51 1: main::CustomSensor_Parse called by fhem.pl (3703)
2018.01.03 19:10:51 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.03 19:10:51 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.03 19:10:51 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.03 19:10:51 1: main::CallFn called by fhem.pl (687)
Hallo Jürgen,
Zitat von: juergs
ERROR: empty name in readingsBeginUpdate
2018.01.03 18:20:50 1: stacktrace:
2018.01.03 18:20:50 1: main::readingsBeginUpdate called by ./FHEM/36_CustomSensor.pm (212)
2018.01.03 18:20:50 1: main::CustomSensor_Parse called by fhem.pl (3703)
2018.01.03 18:20:50 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.03 18:20:50 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.03 18:20:50 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.03 18:20:50 1: main::CallFn called by fhem.pl (687)
2018.01.03 18:20:50 1: readingsUpdate(,temperature,20.5) missed to call readingsBeginUpdate first.
2018.01.03 18:53:50 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4152.
2018.01.03 18:53:50 1: ERROR: >06< returned by the CustomSensor ParseFn is invalid, notify the module maintainer
2018.01.03 18:53:50 5: LGW: dispatch OK 9 8 1 4 66 106
2018.01.03 18:53:50 4: LaCrosse: Unknown device 08, please define it
2018.01.03 18:53:53 5: LGW: dispatch OK 22 124 12 0 66 225 242 0 9 247 81 0 0 15 37 0 5 62 213 0 0
2018.01.03 18:53:54 5: LGW: dispatch OK 9 8 1 4 66 106
2018.01.03 18:53:54 4: LaCrosse: Unknown device 08, please define it
2018.01.03 18:53:58 5: LGW: dispatch OK 22 124 12 0 66 225 247 0 9 247 86 0 0 15 37 0 5 62 213 0 0
Bin ebenfalls am rätseln, welche LGW Firmware verwendest Du, V1.30 ?
Sieht so aus, als wenn Deine "36_CostumSensor.pm" irgendwie verändert wurde.
Irgendwo bei den Zeilen 217-219. Da wird das temperature Reading gesetzt.
Fehlt evtl. Zeile 212 oder ist anders als:
readingsBeginUpdate($rhash);Gruß Thomas
Hallo Thomas,
LGW-Version:
ZitatLaCrosseITPlusReader.Gateway.1.30
Mittlerweile bin ich hier angekommen:
Zitat2018.01.03 20:56:40 5: LGW: dispatch OK CC 6 6 7 37 9 147 0 37 0 0 0 21 86 112
2018.01.03 20:56:40 3: LGW: CustomSensor-Frame: OK CC 6 6 7 37 9 147 0 37 0 0 0 21 86 112
2018.01.03 20:56:40 3: LGW: ID: 06 | T: 20.7 | H: 37 | P: 993 | L: 0 | V: 0 | G: 155670 | I: 25
2018.01.03 20:56:40 3: LGW: Unknown device 06,please define it!
2018.01.03 20:56:40 3: LGW: Unknown code OK CC 6 6 7 37 9 147 0 37 0 0 0 21 86 112 , help me!
Habe https://forum.fhem.de/index.php/topic,39920.0.html (https://forum.fhem.de/index.php/topic,39920.0.html) mit dem CustomSensor-Sample von HCS gefunden.
Ich hab mal im Perl-Code herumgepfriemelt und rumprobiert und geändert, bin aber jetzt mit meinem Perl-Latein am Ende,
da ich die FHEM-Archtektur nicht kenne und meine Freundschaft zu Perl ... naja!
Das hier scheint das Grundproblem zu sein:
ERROR: empty name in readingsBeginUpdate $rhash->{NAME} fehlt?
Dann ist mir aufgefallen: habe ja VCC geändert ... aber die 0 kommt ja durch ...
ZitatLGW: Unknown device 06,please define it!
Kein autocreate ?
Dein vdd im Sketch muss bei bytes[12] als Wert in etwa 33 enthalten (für 3.3V) da stimmt die Berechnung bei Dir nicht:
/*** BATTERY VOLTAGE ***/
bytes[12] = (vdd + 5) / 10; //was vcc = 330mV at 3,3V
Dein vdd Wert ist float und ich meine ca. 3.04, müsste also so sein:
(vdd + 0.05) * 10
bytes[12] = (vdd + 5) / 10; Ok,ja stimmt!
bytes[12] = ((uint8_t) vdd + 5 ) * 10; Sollte aber das Protokoll nicht stören da in bytes[12] ein x-beliebiges Byte stehen würde (im Log = 0 )
und nicht die Ursache des problems mit "readingsBeginUpdate" ....
Schaust Du mal meinen geänderten CustomSensor-Code (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=92760) an?
Beispiel:
ZitatreadingsBeginUpdate($hash);
readingsBulkUpdate($hash,'state','Initialized');
readingsEndUpdate($hash,1);
Sollte so OK sein (aus anderen Beispielcodes)...
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs
bytes[12] = (vdd + 5) / 10;
Ok,ja stimmt!
bytes[12] = ((uint8_t) vdd + 5 ) * 10;
Sollte aber das Protokoll nicht stören da in bytes[12] ein x-beliebiges Byte stehen würde (im Log = 0 )
und nicht die Ursache des problems mit "readingsBeginUpdate" ....
Ist nicht das Problem und stört auch nicht das Protokoll, stimmt, ist mir nur beim drüberschauen aufgefallen ;)
Das Problem ist, das "ReadingsBeginUpdate..." muß weiter nach oben,
vor den ersten Aufruf von "ReadingsBulkUpdate...", so etwa:
Log3 $name, 3, "$name in ID ==6 vor readingsBeginUpdate";
readingsBeginUpdate($rhash);
# write temperature, humidity, ... Das sollte es gewesen sein, deckt sich auch mit den Fehlermeldungen :)
Gruß Thomas
Hallo Thomas,
habe ich so in der "Transaktions"-Klammer:
readingsBeginUpdate($rhash);
readingsBulkUpdate($rhash, "state", $state) if( Value($rname) ne $state );
readingsBulkUpdate($rhash, "temperature", $temperature);
readingsBulkUpdate($rhash, "humidity" , $humidity);
readingsBulkUpdate($rhash, "pressure" , $pressure );
readingsBulkUpdate($rhash, "iaq" , $iaq );
readingsBulkUpdate($rhash, "lux" , $lux );
readingsBulkUpdate($rhash, "battery" , $vcc );
readingsBulkUpdate($rhash, "gas" , $gas );
readingsEndUpdate($rhash,1);
Im Moment sorgt dieser Teil dafür, dass der Fehler nicht auftritt:
if ( !$modules{CustomSensor}{defptr}{$raddr} )
{
Log3 $name, 3, "$name: Unknown device $rname,please define it!";
my $iohash = $rhash->{IODEV};
return undef;
}
Der Code-Teil ist in HCS's Beispiel mit drin und sorgt dafür dass der weitere Teil des Codes nicht aufgerufen wird.
Da kenne ich mich leider zu wenig aus ... :-\ und muß mich in Perl + Hashes etwas aufschlauen...
War der Hoffnung, es funktioniert einfach... ;)
Wo ist der Unterschied zu Deiner (laufenden) Implementierung?
Hast Du weniger LaCrosse-Sender in der Umgebung als ich?
Sorry, nach der Nachtschicht ist man einfach nicht mehr ganz so fit ::)
Hab die ganzen "#" völlig übersehen, autsch 8)
Muss nochmal in Ruhe schauen ...
Ich glaub, ich habs:
In Zeile 199 am Ende muss "$id" statt "$raddr" stehen, so:
my $rhash = $modules{CustomSensor}{defptr}{$id};
Dann sollte Zeile 202 bis 207 nicht mehr nötig sein.
Hab noch mal mit meiner Datei verglichen.
ZitatNachtschicht
... verständlich :)
Das Thema hat auch sein Gutes: so muß ich mich auch noch in das CustomSensor-Modul einarbeiten.
Ich orientiere mich am: https://forum.fhem.de/index.php/topic,78385.msg703398.html#msg703398 (https://forum.fhem.de/index.php/topic,78385.msg703398.html#msg703398)
Sind halt noch ein paar Punkte zu klären...
Zitat von: hdgucken am 04 Januar 2018, 16:02:01
Ich glaub, ich habs:
In Zeile 199 und 200 am Ende muss "$id" statt "$raddr" stehen, so:
my $rhash = $modules{CustomSensor}{defptr}{$id};
my $rname = $rhash?$rhash->{NAME}:$raddr;
Dann sollte Zeile 202 bis 207 nicht mehr nötig sein.
Ja, hatte ich schon, da ich $id $raddr zuweise:
Zitatmy $raddr = $id;
my $rhash = $modules{CustomSensor}{defptr}{$raddr};
ist das gleichwertig, aber überflüssig .. ;)
$id wird aus
$id = sprintf( "%02X", $bytes[0] );gebildet. Dort steht "06" drin.
Dann habe ich ein CustomSensor Device 06 zu definieren:
ZitatInternals:
DEF 0.0 0.0
ID 0.0
NAME bme680_cc
NR 112
STATE Initialized
TYPE CustomSensor
corrH 0
corrT 0.0
Attributes:
Edit:
Zitatbme680_cc: unknown attribute ID. Type 'attr bme680_cc ?' for a detailed list.
Dort ist die ID "0.0", die kann ich nicht manuell per Attribut verändern ...
Damit es damit passt:
my $rhash = $modules{CustomSensor}{defptr}{$raddr};
LaCrosse Sensoren hab ich 7 plus CC Sensor plus LGW KVP. Dann schwirren noch diverse Funkthermometer von Nachbarn mit rein :)
Sollen noch mehr werden :)
Zitat von: juergs
Ich orientieren mich am: https://forum.fhem.de/index.php/topic,78385.msg703398.html#msg703398 (https://forum.fhem.de/index.php/topic,78385.msg703398.html#msg703398)
Auch interessant ... :)
Zitat################################################
define bme680_cc CustomSensor 0.0 0.0
attr bme680_cc ID 06
################################################
@Thomas, wie sieht deine Def aus?
Hier mal meine Sensor Definition aus der fhem.cfg:
Vielen Dank!
Zitatdefine BME680_CS_06 CustomSensor 06
da war ich (fast) auf dem richtigen Weg. Die ID fehlte ....
Das CustomSensor-Device muss
manuell angelegt werden!?
Hallo Leute,
... schwere Geburt: Der Sensor muss manuell angelegt werden ..... (!)
So einfach, trivial ist das ...
Na ja, immerhin weiß ich jetzt wie ein neuer Sensor implementiert wird,
dann hat das auch was Gutes ;) ;) ;)
Super, das es jetzt bei Dir funktioniert !
Hatte gar nicht mehr daran gedacht, daß ich den Sensor von Hand angelegen mußte,
wäre ein entscheidener Hinweis gewesen, sorry.
Das autocreate müsste noch eingepflegt werden, bin ich noch nicht dazu gekommen :o
Gruß Thomas
P.S.: Anbei noch ein aktuelles Bild von meiner config.
Das Reading "dewpoint" kommt von fhem, ist universell für alle Temperatur/Feuchte Sensoren im System,
siehe hier https://wiki.fhem.de/wiki/Dewpoint (https://wiki.fhem.de/wiki/Dewpoint)
Zitat von: hdgucken am 04 Januar 2018, 17:59:21
Das autocreate müsste noch eingepflegt werden, bin ich noch nicht dazu gekommen :o
Ok, dann warte ich solange, bis das erledigt ist bzw. es eine Anleitung für "Dummies" gibt ;D ;D ;D
Aber es ist spannend, bei Euch mitzulesen ...
Gruß PeMue
Hallo Peter,
Sensor anlegen geht im Moment eigentlich auch recht einfach.
Einfachdefine BME680_CS_06 CustomSensor 06
und fertig.
Wobei die 06 durch Deine eigene beliebige ID (1-255) ersetzt wird.
Dann noch ein paar Attribute nach Wahl und gut is ;)
Oder meine Vorlage benutzen und in die fhem.cfg kopieren und abändern.
Aber ich werde mich mal noch um's autocreate kümmern, wäre schon besser ;)
Gruß Thomas
Hallo Thomas,
Zitat von: hdgucken am 04 Januar 2018, 18:27:04
Sensor anlegen geht im Moment eigentlich auch recht einfach.
...
ich fürchte, das ist nicht das Problem. Die Firmware auf dem WemosD1 mini (oder was auch immer) könnte das Thema sein:
Gibt es schon eine fertige .bin, die auf einem WeMos D1 mini inkl. RFM69CW und BME680, aber ohne OLED bzw. Helligkeitssensor läuft? Ich vermute, das ist die letzte (1.5B2-prel irgendwas von Jürgen) 8) 8) 8)? Oder muss ich gar selber compilieren und Code ändern ??? ::)?
Ich schau mir gerade den nano LGW an, ob da der LM75 runter und der BH1750 draufgeht ;)
Danke + Gruß
Peter
Hallo Peter,
hier mal meine aktuelle Version fertig kompiliert für NodeMCU nur mit RFM69,
NodeID 6, serielle Ausgabe 115200 Baud, BME680 auf 0x77.
Sollte auch mit D1 mini gehen.
Versuch doch mal ... ;)
Gruß Thomas
Hallo Zusammen,
ich habe heute noch die Installation der ESP-Lib auf die 2.4 hochgehoben und die BSEC für den ESP
auf meinem Laptop installiert, außer den einfachen Hürden bei der Konfiguration nachzujagen. ;) ;) ;)
Ziel: Abhängigkeit der WDT-Fehler zum verwendeten 2.4RC-Package zu prüfen.
Leider ohne Erfolg. Es kommen immer noch zu viele WDT-Resets zustande, aber in geringerer Häufigkeit ....
Dann habe ich heute die 18650-Powerbank-Platinen (https://www.ebay.com/p/Raspberry-Pi-WeMos-18650-Battery-Shield-V3-Esp32-for-Arduino/23005990202) bekommen, die ein StepUp-Regler für 5V (5A) und einen für 3V3 (3A) haben ...
Jetzt lassen sich die WemosD1 auch autark über längere Zeit betreiben.
Dann probiere ich auch mal hdgucken's BIN-Version aus:
Edit: geht nicht mit D1 mini + 0x77 + oled ...
Grüße,
Jürgen
By-the-way "Deep Sleep": https://myesp8266.blogspot.de/2017/07/battery-powered-wemos-d1-with-wemoss.html (https://myesp8266.blogspot.de/2017/07/battery-powered-wemos-d1-with-wemoss.html)
Hallo Jürgen,
Zitat von: juergs
Dann probiere ich auch mal hdgucken's BIN-Version aus:
Edit: geht nicht mit D1 mini + 0x77 + oled ...
Ist nur NodeMCU(D1mini) und RFM69, ohne OLED usw., kommt was auf der seriellen ?
Gruß Thomas
Nein, immer das "Aufhäng"-Problem: bläst gefühlt 80MHZ auf D3 raus... New Serial im Sekundentakt.....
Schwierig den Mini da wieder herauszubekommen. Geht nur manchmal mit "Blank" über den ESP6288-Flasher ...
OK, nicht schön.
Dann teste ich morgen mal ein wenig,
mal sehen ob es auf einer NodeMCU läuft.
Gruß Thomas
Kein Problem ...
Man sollte über ein Auto-Config nachdenken ...
Was mich noch stört ist, dass bei Dir die Adafruit-Lib geht ....
Für Peter kann ich gerne eine Version ohne OLED bauen ...
Jürgen
So, nur als Gag:
https://www.neowin.net/news/microsoft-unveils-pre-order-information-on-the-windows-10-glas-thermostat (https://www.neowin.net/news/microsoft-unveils-pre-order-information-on-the-windows-10-glas-thermostat)
Kostet nur 319$
So, hab jetzt mal zwei Binarys kompiliert, einmal für NodeMCU und einmal für D1 mini.
Jeweils nur mit BME680 und RFM69. Ohne OLED und Lichtsensor, keine Vcc Messung.
Vielleicht klappt es ja jetzt mit dem D1 mini :)
Gruß Thomas
Edit: für NodeMCU funktioniert es bei mir:
Hallo Thomas,
D1 mini geht, aber (auch) WDT-Problem:
ZitatBME680 wireless sensor V1.6
Protocol: CustomSensor
BSEC Version: 1.4.5.1
NODE-ID : 6
RFM69 found.
RFM69 initialized.
BME680: try init on 0x77 ... done.
Ready, start measuring ...
[3091.00] P: 988.27| T: 17.48| rH: 51.32| IAQ: 25.00 (0)| Gas: 115885.00
[6091.00] P: 988.25| T: 17.48| rH: 51.33| IAQ: 25.00 (0)| Gas: 123246.00
[9091.00] P: 988.25| T: 17.50| rH: 51.18| IAQ: 25.00 (0)| Gas: 129060.00
[12091.00] P: 988.27| T: 17.51| rH: 51.06| IAQ: 25.00 (0)| Gas: 132126.00
[15091.00] P: 988.25| T: 17.52| rH: 50.98| IAQ: 25.00 (0)| Gas: 135450.00
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
ve9e0c112
~ld
Grüße,
Jürgen
Ich habe noch mal das Bosch-Original-Beispiel laufen lassen (ausser: Luftdruck noch in die serielle Ausgabe gepackt)
Zitat[213275.00] T: 16.49| rH: 56.84| P: 98837.00| IAQ: 25.00 (0)
[216275.00] T: 16.49| rH: 56.83| P: 98835.00| IAQ: 25.00 (0)
ets Jan 8 2013,rst cause:4, boot mode:(1,6)
wdt reset
Was zu beweisen war ... :'(
Daraufhin habe ich geprüft, wie die sleep-Methode aus der Lib aufgerufen wird:
Zitat[12082.00] T: 16.56| rH: 57.51| P: 98825.00| IAQ: 25.00 (0)
sleep: 2756
sleep: 218
sleep: 5
sleep: 5
sleep: 5
sleep: 5
[15082.00] T: 16.57| rH: 57.42| P: 98825.00| IAQ: 25.00 (0)
sleep: 2755
Der Wert "sleep: 2756" mit ca. 2.7 Sekunden ist mit den anderen Aktivitäten OLED und RFM sehr nahe an den kritischen 3.6 Sekunen!
Mit micros() Auflösung:
Zitat*9* [6.32] T: 16.76| rH: 57.35| P: 98746| IAQ: 25.00 (0)
*10* [9.32] T: 16.78| rH: 57.06| P: 98744| IAQ: 25.00 (0)
*9* [12.32] T: 16.80| rH: 56.68| P: 98744| IAQ: 25.00 (0)
*10* [15.32] T: 16.80| rH: 56.49| P: 98746| IAQ: 25.00 (0)
*195* [18.32] T: 16.81| rH: 56.29| P: 98744| IAQ: 25.00 (0)
*10* [21.32] T: 16.81| rH: 56.18| P: 98744| IAQ: 25.00 (0)
*9* [24.32] T: 16.83| rH: 56.02| P: 98746| IAQ: 25.00 (0)
*9* [27.32] T: 16.82| rH: 55.89| P: 98744| IAQ: 25.00 (0)
*10* [30.32] T: 16.82| rH: 55.74| P: 98746| IAQ: 25.00 (0)
*9* [33.33] T: 16.83| rH: 55.64| P: 98746| IAQ: 25.00 (0)
*10* [36.33] T: 16.84| rH: 55.63| P: 98746| IAQ: 25.00 (0)
*9* [39.33] T: 16.83| rH: 55.70| P: 98746| IAQ: 25.00 (0)
*9*
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld
Lib sleep-Anforderungen mit
yield():
Zitat*2756046µS, 2756mS *
*218045µS, 218mS *
*5035µS, 5mS *
*5026µS, 5mS *
*5028µS, 5mS *
*5028µS, 5mS *
[27.60] T: 16.86| rH: 58.12| P: 987| IAQ: 25.00 (0)
Zitat/*!
* @brief System specific implementation of sleep function
* @param[in] t_ms time in milliseconds
* @return none
*/
void sleep(uint32_t t_ms)
{
int32_t duration = 0;
int32_t duration_all = 0;
int32_t start = micros();;
yield();
delay(t_ms);
yield();
duration_all = (micros() - start);
Serial.print("*");
Serial.print(duration_all);Serial.print("µS, \t");
Serial.print(t_ms);Serial.println("mS *");
}
2 *
yield() läuft bisher am "stabilsten"...
Umsonst, nach 24 Sekunden:
Zitat[3] T: 17.3 | rH: 57.6 | P: 987 | IAQ: 25 (0)
[6] T: 17.3 | rH: 57.6 | P: 987 | IAQ: 25 (0)
[9] T: 17.3 | rH: 57.4 | P: 987 | IAQ: 25 (0)
[12] T: 17.3 | rH: 57.4 | P: 987 | IAQ: 25 (0)
[15] T: 17.3 | rH: 57.3 | P: 987 | IAQ: 25 (0)
[18] T: 17.3 | rH: 57.3 | P: 987 | IAQ: 25 (0)
[21] T: 17.3 | rH: 57.3 | P: 987 | IAQ: 25 (0)
[24] T: 17.3 | rH: 57.2 | P: 987 | IAQ: 25 (0)
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld
Wegen den WDT-Fehlern habe ich versucht, mal ohne den ESP8266 auszukommen
und habe einen ehemaligen MapleCUL (MapleMini (http://wiki.stm32duino.com/images/2/26/Maple_mini_clone_schematic.JPG)) wieder auf den Arduino-DFU-Bootloader "zurückgeholt",
(was wirklich nicht einfach ist...) und den BME680_CC-Sketch auf STM32-MapleMini gehievt.
Es ist noch ohne Senden über RFM und Vcc-Erkennung implementiert, funktioniert soweit mit 100 KHz I2C
an I2C-Schnittstelle 1 des Maples. Das lässt sich wahrscheinlich noch optimieren ...
Wichtig ist ja die 4-Tage-Einlaufphase .... (Mit WDT-Fehlern beim ESP wird das nichts...)
Mal schauen, wie es auf dieser Plattform funktioniert.
Dann kommt der RFM noch hinzu....
Zitat[2555705] P: 991.67| T: 20.79| rH: 50.39| IAQ: 26 30 (1)| Gas: 181.28| UBat: 3.59V| Light: 0lx
[2558705] P: 991.69| T: 20.78| rH: 50.36| IAQ: 36 31 (1)| Gas: 180.11| UBat: 3.59V| Light: 0lx
[2561705] P: 991.65| T: 20.79| rH: 50.29| IAQ: 32 32 (1)| Gas: 180.69| UBat: 3.59V| Light: 0lx
[2564705] P: 991.65| T: 20.79| rH: 50.29| IAQ: 28 31 (1)| Gas: 181.47| UBat: 3.59V| Light: 0lx
Hey, das sieht doch mal gut aus ;)
Habe heute auch meine Software überarbeitet, hatte einen kleinen Verrechnungsfehler beim Gas Wert entdeckt :o,
ist aber behoben. Bin jetzt doch auf die Vcc intern Methode gegangen, entsprechend korrigiert,
sieht ganz gut aus. Debug für den RFMxx etwas erweitert, einige Kleinigkeiten korrigiert, alle Extras sind jetzt An/Abwählbar.
Muss alles noch ordentlich verpacken ;D Stelle ich Euch morgen früh zur Verfügung :)
Gruß Thomas
Soft-SPI für das Wroom2.Board:
https://github.com/gieemek/RFM69_softSPI (https://github.com/gieemek/RFM69_softSPI)
Hier wie versprochen das komplette Paket auf dem neuesten Stand (V1.7):
Gruß Thomas
Guten Morgen Thomas,
vielen Dank. Zwei Punkte von meiner Seite:
- Was ist der Unterschied zwischen NodeMCU und WemosD1 mini?
- Könntest Du die beiden bitte noch für 0x76 (ist leider bei meinem nanoLGW eingestellt, der Jumper ist unter dem ESP8266 (ich könnte den Layouter killen ::) ::) ::))) compilieren?
Danke + Gruß
Peter
Guten Morgen Peter,
hier nochmal die Versionen mit Adresse 0x76 und 0x77 ;)
D1 mini und NodeMCU sind eigentlich fast identisch, D1 mini hat weniger Pins nach außen geführt und die LED sitzt woanders,
und die USB Chips sind verschieden, aber da baut ja eh jeder Hersteller was anderes ein :o
Edit: die LED an GPIO16 (D0) der NodeMCU gibt es beim D1 mini nicht.
Für Jürgen hab ich auch was zusammengestellt, die Version mit SoftSPI !
Funktioniert, hab bei mir getestet :D
Änderungen sind im Sketch und den Dateien RFMxx.h / RFMxx.cpp.
Edit: einfach im Sketch die gewünschten Pins für MOSI,MISO,SCLK und CS eintragen, fertig :)
Gruß Thomas
Hallo Thomas,
das ist ja ein Service, vielen Dank! :D
Mein Maple-Aufbau ist diese Nacht durchgelaufen und reagiert
(was hätte man anders erwartet!) stabil mit durchaus plausiblen Werten.
Auch mit schneller Reaktion z.B. beim Fenster öffnen (von 150 wieder auf 30 zurück) ....
Da muss ich aber die BurnIn-Phase von 4 Tagen noch abwarten ... :)
Nach dem die SW auf dem ESP nicht mehr bei der Analyse her gibt. Müsste ich mich noch auf den I2C-Bus konzentrieren.
Vielleicht liegt da das Problem ...
Dann kann ich den Code schon mal im Wroom-Board einbauen ....
Grüße,
Jürgen
Macht es Sinn?
https://forum.fhem.de/index.php/topic,52921.135.html (https://forum.fhem.de/index.php/topic,52921.135.html)
https://forum.fhem.de/index.php/topic,52921.msg527954.html#msg527954 (https://forum.fhem.de/index.php/topic,52921.msg527954.html#msg527954)
Zitatch habe auch diverse NodeMCUs (v0.9, v2, v3) und ESP12, ESP12e, z.T. mit den unterschiedlichsten Problemen. Nachdem ich aber das BIOS ESP8266_NONOS_SDK_V2.0.0 (http://bbs.espressif.com/viewtopic.php?f=46&t=2502) aufgespielt habe, sind meine Probleme alle weg.
Maple-Mini: Soft SPI scheint mal zu "zucken"
#if (HAS_RFM_MODULE)
/* RFM69, PIN-config SPI (GPIO XX): */
#define RFM_SS PA4 //(15,D8) SS -> RFM69 (NSS)
#define RFM_MISO D12 //(12,D6) MISO <- RFM69 (MOSI) //only used by soft spi
#define RFM_MOSI D11 //(13,D7) MOSI -> RFM69 (MISO) //only used by soft spi
#define RFM_SCK D13 //(14,D5) SCK -> RFM69 (SCK) //only used by soft spi
#define RFM_IRQ PB0 //(2,D4) IRQ <- RFM69 (DIO0) (Not Connected)
//--- create rfm instance
RFMxx rfm(RFM_MOSI, RFM_MISO, RFM_SCK, RFM_SS, RFM_IRQ);
#endif
LGW empfängt aber noch nichts .... muss noch gegen den ESP checken ...
ESP8266-SPI
Der Maple (~96KHz) taktet den SPI doppelt so schnell wie der ESP (~40KHz) ...
Na, geht doch... ;D
DeviceId=7
Während der ESp immer noch schön WDT-resettet ... :(
Noch zum Thema "WDT-Reset":
https://www.hackster.io/rayburne/esp8266-turn-off-wifi-reduce-current-big-time-1df8ae (https://www.hackster.io/rayburne/esp8266-turn-off-wifi-reduce-current-big-time-1df8ae)
Das sollte die Lösung sein:
1) Include a minimum of the below before setup(void)
// ------------------begin ESP8266'centric----------------------------------
#define FREQUENCY 160 // valid 80, 160
//
#include "ESP8266WiFi.h"
extern "C" {
#include "user_interface.h"
}
// ------------------end ESP8266'centric------------------------------------
2) Include a minimum of the below in setup(void)
/* Initializations */
// ------------------begin ESP8266'centric----------------------------------
WiFi.forceSleepBegin(); // turn off ESP8266 RF
delay(1); // give RF section time to shutdown
system_update_cpu_freq(FREQUENCY);
// ------------------end ESP8266'centric------------------------------------
3) Include a minimum of the below in loop(void)
// ------------------begin ESP8266'centric----------------------------------
// patch the watchdog timer
wdt_reset();
// ------------------end ESP8266'centric------------------------------------
In unserem Fall also in Funktion output_ready :D
Und läuft seit einer Stunde ohne WDT-Reset! :D :) :)
(.. obwohl ich das Frequenzsetting auf 160 belassen hatte, sollte 80 sein ...)
EDIT:
Der ESP ist die ganze Nacht ohne WDT-Reset durchgelaufen ! :D :)
Hallo Jürgen,
Zitat von: juergs
https://www.hackster.io/rayburne/esp8266-turn-off-wifi-reduce-current-big-time-1df8ae (https://www.hackster.io/rayburne/esp8266-turn-off-wifi-reduce-current-big-time-1df8ae)
Das hatte ich mir auch schon angesehen, könnte tatsächlich die Lösung sein.
Wobei dieses hier "ESP8266_NONOS_SDK_V2.0.0" sich noch besser anhört, finde ich, weil man da offensichtlich
nichts mehr weiter am Programm machen muss. Für mich hört sich das so an, als ob mit dieser Firmware der
ESP8266 ohne WiFi im Hintergrung läuft, wenn das überhaupt machbar ist ?!
Gruß Thomas
Hi,
läuft immer noch ... :)
Die Stromreduzierung sollte auch beachtlich sein ...
Schaue mir das morgen früh mal an, wie stabil das Ganze jetzt ist ....
Der BME muss auch mit dem ESP mal Laufzeit zum BurnIn bekommen ...
Edit: Läuft stabil! (Laut Log, die gesamte Nacht ohne WDT-Reset) :)
Das Thema "ESP8266_NONOS_SDK_V2.0.0" werde ich mal in Ruhe separat betrachten ;)
Grüße,
Jürgen
Hallo hdgucken,
hatte Deine Anmerkung im Thread:
https://forum.fhem.de/index.php/topic,78128.msg740119.html#msg740119 (https://forum.fhem.de/index.php/topic,78128.msg740119.html#msg740119)
gesehen und werde mal mit dem Maple etwas experimentieren müssen ...
Hallo Jürgen,
beim Maple wäre es mal interessant, wie hoch man mit dem SPI Takt kommt, laut Datenblatt sollte der RFM69CW bis 10MHz können !
Ich denke, 1MHz bei der Hardware-SPI Variante sollte kein Problem sein (1MHz ergibt sich beim ESP8266, wenn man keine Frequenz vorgibt),
bei mir (mit Hardware-SPI) geht es tatsächlich nur mit 400kHz, hab gestern mal mein neues "Spielzeug" ausprobiert, siehe Bild :)
Gruß Thomas
Ist der Lüfter des Rigols auch so laut wie mein DS? :(
Ja, leider. Ist mir auch gleich als erstes sehr unangenehm aufgefallen :-[
Ich habe mir eine Haube 3D-gedruckt, die den Luftstrom nach hinten ablenkt ....
Jetzt ist das Geräusch auf Dauer erträglicher ... ;)
Aber trotzdem, dass die Rigol'er das nicht besser können ....
Schön, mit Seriell-Modul .... :)
Anmerkung zum Wroom2-Oled-Board:
/* init I2C */
#if (IS_WROOM2_BOARD)
//--- für Wroom2-Board geht nur diese Variante(!):
//--- Grund: https://github.com/esp8266/Arduino/blob/master/libraries/Wire/Wire.cpp
//--- Konstruktor: TwoWire::begin(int sda, int scl)
//--- ESP8266-Hardware: SDA = D2 und SCL = D1, ergo: auf dem Wroom2-Board ist die Standard-I2C-Belegung verdreht!
Wire.begin(D1,D2);
#else
Wire.begin();
#endif
Deswegen funktioniert die übliche Variante nicht.
Hallo Jürgen,
auf die Drehung der Signale hatte ich gar nicht geachtet, hab nur D1 und D2 gesehen und dachte paßt :o
Hab jetzt für den BME680 automatische Erkennung auf 0x76 oder 0x77 beim Universalsensor eingebaut,
endlich ist das Problem auch gelöst ;)
Siehe hier:https://forum.fhem.de/index.php?topic=78128.msg745634#msg745634 (https://forum.fhem.de/index.php?topic=78128.msg745634#msg745634)
Gruß Thomas
Zitathatte ich gar nicht geachtet, hab nur D1 und D2 gesehen und dachte paßt
ja, so ging's mir auch. Man wundert sich nur dass der Sketch für OLED nicht geht. Klar wenn die Signale gedreht sind...
Im Moment suche ich noch Pins für den RFM. Irgendwie wollen die, die ich verwende, nicht ...
Da Board benutzt 2 LEDS D4 + D0, dann noch I2C mit D1 + D2
Eigentlich sollten:
SCK = D5
MISO = D6
MOSI = D7
SS = D8
des ESPs funktionieren....
Ja, D5-D8 wäre optimal, Hardware SPI. Das klappt nicht ?
Versuch mal, wenn Du Soft-SPI benutzt, die GPIO Nummern zu verwenden, also für D5: 14, D6: 12, D7: 13 und D8: 15.
Vielleicht will es deswegen nicht.
Hallo zusammen,
welche Einstellungen nehmt Ihr zum Kompilieren?
Generic ESP module
Flash mode: DIO
Flash size: 4 MB/1MB SPIFFS
Ist das so ok? Zumindest habe ich mal die IDE eingerichtet, dass Thomas' Projekt compiliert wird ;D ;D ;D
BTW: Ohne Jürgen's verlinkte Dokumentation wäre ich nicht in der Lage gewesen, die Bibliothek einzubinden >:( >:( >:(
Danke + Gruß
Peter
Hallo Peter,
Zitatwelche Einstellungen nehmt Ihr zum Kompilieren?
Board: "NodeMCU 1.0 (ESP-12E Module)" oder "WEMOS D1 R2 & mini", je nach Board.
Flash Size: "4M (3M SPIFFS), CPU Freq.: 80MHz, Upload Speed: 921600
ZitatBTW: Ohne Jürgen's verlinkte Dokumentation wäre ich nicht in der Lage gewesen, die Bibliothek einzubinden >:( >:( >:(
Das ist natürlich etwas fummelig, hatte ich in meiner Doku nur zur Hälfte aufgeschrieben, hab auch wieder etwas gesucht,
als ich die esp8266 V2.4.0 aufgespielt hab, wußte aber zum Glück noch, wo es geschrieben steht ;D
Boards einfügen:
unter "Datei" -> "Voreinstellungen" -> "Zusätzliche Boardverwalter-URL's" folgendes eintragen: "http://arduino.esp8266.com/stable/package_esp8266com_index.json"
Danach kannst Du unter "Werkzeuge" -> "Board" das passende auswählen ;)
Edit: Für Peter zum kompilieren mal die V2.0 alpha anbei, viel Erfolg ;)
Gruß Thomas
Hallo Thomas,
ich kämpfe wieder mit den Tücken des Wroom2-Boards:
Wir benutzen:
RFMxx rfm(RFM_MOSI, RFM_MISO, RFM_SCK, RFM_SS);zur Initialisierung der RFM-Lib.
Als Konstruktor in der Lib steht:
RFMxx::RFMxx(byte mosi, byte miso, byte sck, byte ss, byte irq, TPinCallback pinFunction)Dann als CodeBeispiel der Lib:
bool RFMxx::Begin(bool isPrimary) {
// No radio found until now
m_radioType = RFMxx::None;
if (m_pinCallback) {
m_pinCallback(1, m_ss, OUTPUT);
m_pinCallback(2, m_ss, HIGH);
...
}und
void RFMxx::SetPin(byte pin, bool value) {
if (m_pinCallback) {
m_pinCallback(2, pin, value);
}
else {
digitalWrite(pin, value);
}
}Wenn "m_pinCallback" nicht true ist wird der SS-Pin nicht korrekt initialisiert.
Die Funktionalität ist mir nicht ganz klar ... Grübel. (und die Pins machen im Wroom mit der RFM-Lib kein Muckser :'(,
obwohl ein Blink auf jeden einzelnen Pin geht ... ) .
Mal schauen wie die Implementierung hier eigentlich gedacht ist..
Für den ESP habe ich auch nicht wirklich gute (passende) Ersatz-RFM-Libs gefunden ....
Mich wundert nur, dass es im NodeMCU einfach "so" geht.... (Initialisierung ohne IRQ und den Callback.) ???
EDIT, Deswegen im Header:
ZitatRFMxx(byte mosi=255, byte miso=255, byte sck=255, byte ss=255, byte irq=255, TPinCallback pinFunction = NULL);
Grüße,
Jürgen
Hallo Thomas,
Zitat von: hdgucken am 11 Januar 2018, 20:39:10
Boards einfügen:
unter "Datei" -> "Voreinstellungen" -> "Zusätzliche Boardverwalter-URL's" folgendes eintragen: "http://arduino.esp8266.com/stable/package_esp8266com_index.json"
Danach kannst Du unter "Werkzeuge" -> "Board" das passende auswählen ;)
das war nicht das Problem, das hatte ich schon drin. Bei mir war das Thema die BSEC Library. Das was Bosch da gerade noch in der Dokumentation hat, reicht m.E. nicht aus, um die IDE einzurichten :o
Zitat von: hdgucken am 11 Januar 2018, 20:39:10
Board: "NodeMCU 1.0 (ESP-12E Module)" oder "WEMOS D1 R2 & mini", je nach Board.
Flash Size: "4M (3M SPIFFS), CPU Freq.: 80MHz, Upload Speed: 921600
Ich hätte das Ganze unter Generic ESP Module (so wie ich damals ESPEasy compiliert habe) compiliert. Die Unterschiede ja quasi nicht vorhanden ...
Ist der Flash mode egal? Oder muss der nachher nur zum Flasher passen?
Danke + Gruß
PeMue
Hallo Peter,
die Unterschiede sind in der Boards.txt Datei der Plattform ersichtlich.
Bei mir liegt die dort:
C:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1\boards.txt
"d1_mini.name=WeMos D1 R2 & mini" gegen "Generic ESP8266 Module" vergleichen.
Da gibt es schon Unterschiede: siehe unten ...
Hallo zusammen,
hat eigentlich jemand den Ansatz weiter verfolgt, aus den aufgezeichneten Sensordaten Rückschlüsse auf den Algorithmus zu schließen?
Im internet habe ich bisher nur einen eher schlechten(zumindest hier in Colorado funktioniert er schlecht) alternativen Algorithmus gefunden, der sich aus dem Widerstand und der Luftfeuchte nährt.
Ich bin bezüglich des FHEM-Projects vollkommen fremd, aber viele von euch scheinen sich da schon echt den Kopf über den Sensor zerbrochen haben...
viele Grüße
SimGa
Zitat von: SimGa am 11 Januar 2018, 22:43:08
hat eigentlich jemand den Ansatz weiter verfolgt, aus den aufgezeichneten Sensordaten Rückschlüsse auf den Algorithmus zu schließen?
Ich denke, dass das Grundprinzip so aussieht: Die BSEC-Software rechnet sich über einen Zeitraum von einigen Tagen eine basline, wobei die niedrigste gesehene Schadstoffkonzentration als IAQ25 betrachtet wird und bei einem sinkenden Widerstand dreht sie die IAQ hoch und umgekehrt, unabhängig vom jeweiligen Absolutwert.
Und irgendwie rechnet sie die Luftfeuchtigkeit noch mit rein.
Ich finde es aber ein Unding, einen Sensor auf den Markt zu bringen und nicht zu verraten, was er (und die erforderliche Lib) eigentlich wirklich macht.
Zumindest den Einfluss von Heizdauer und Zieltemperatur und die Bedeutung des resultierenden Widerstands sollte man erfahren, um den Sensor vernünftig verwenden zu können.
Zitat von: SimGa am 11 Januar 2018, 22:43:08
..., aber viele von euch scheinen sich da schon echt den Kopf über den Sensor zerbrochen haben...
Bisher der Kopf zerbrochen, jetzt bin ich aber kurz davor, den Sensor zu zerbrechen ... ;D ;D ;D
Zitat von: hdgucken am 11 Januar 2018, 20:39:10
Für Peter zum kompilieren mal die V2.0 alpha anbei, viel Erfolg ;)
Grrr, mit Lichtsensor geht es nicht
ZitatAS_BH1750.h nicht gefunden
aber ohne dann doch (wegen Compiler direktive). Ich dachte immer, es reicht auch, wenn man die Bibliotheken in ein Verzeichnis libraries im Projektverzeichnis legt, aber dem ist scheinbar nicht so >:( >:( >:(
Ich denke, die die Arduino IDE und ich werden keine Freunde mehr :P
Zitat von: HCS am 12 Januar 2018, 11:30:09
Bisher der Kopf zerbrochen, jetzt bin ich aber kurz davor, den Sensor zu zerbrechen ... ;D ;D ;D
Hm, dafür war der aber zu teuer ;D ;D ;D
Gruß PeMue
Zitat von: PeMue am 12 Januar 2018, 16:54:28
Grrr, mit Lichtsensor geht es nicht aber ohne dann doch (wegen Compiler direktive). Ich dachte immer, es reicht auch, wenn man die Bibliotheken in ein Verzeichnis libraries im Projektverzeichnis legt, aber dem ist scheinbar nicht so >:( >:( >:(
Ich denke, die die Arduino IDE und ich werden keine Freunde mehr :P
#if HAS_LIGHTSENSOR
#include <AS_BH1750.h>
#endifDann ist die Lib im Library-Verzeichnis gemeint. Im Selben Verzeichnis mit #include "AS_BH1750.h" liegt der Lib-Code im selben Verzeichnis..
Komischerweise findet die Arduinino-Ide den Code auch im Lib-Verzeichnis, wenn Anführungstriche verwendet werden ...
PS: Wo gibt's den Lichtsensor ?
Jürgen
Hallo Thomas,
hier gäbe es noch "Inspirationen" zum Thema OLED:
http://www.technoblogy.com/show?WNM (http://www.technoblogy.com/show?WNM)
Z.B. "schneller Display-Puffer"
... und noch einige andere Interessantheiten ;D
Grüße,
Jürgen
Neuigkeiten zum Wroom2-Board:
Die RFMxx-Lib lässt sich zwar auf Soft-SPI konfigurieren, aber die zugrunde liegende SPI.h aus
der ESP-Plattform Lib leider nicht!
Aus der
SPI.cpp:
Zitatbool SPIClass::pins(int8_t sck, int8_t miso, int8_t mosi, int8_t ss)
{
if (sck == 6 &&
miso == 7 &&
mosi == 8 &&
ss == 0) {
pinSet = SPI_PINS_HSPI_OVERLAP;
} else if (sck == 14 &&
miso == 12 &&
mosi == 13) {
pinSet = SPI_PINS_HSPI;
} else {
return false;
}
return true;
}
Nach Korrektur der Verdrahtung des RFM69 auf:
MOSI = D7 (GPIO_13)
MISO = D6 (GPIO_12)
SCK = D5 (GPIO_14)
SS = D8 (GPIO_15)
... also ESP-Standard-Belegung!
Kein Soft-SPI!
In dieser Konstellation funktioniert das Board endlich. :D
Leider bietet das Board die SPI-Pins nicht nach aussen an ... :(
@HCS, hdgucken:
Zitat2018-01-12 19:54:12 LaCrosseGateway LGW UpTime: 0Tg. 7Std. 50Min. 49Sek.
2018-01-12 19:54:12 LaCrosseGateway LGW UpTimeSeconds: 28249
2018-01-12 19:54:12 LaCrosseGateway LGW RSSI: -63
2018-01-12 19:54:14 CustomSensor bme680_cc iaq: 222
2018-01-12 19:54:14 CustomSensor bme680_cc gas: 227150
2018-01-12 19:54:14 CustomSensor bme680_cc gas-kohm: 227.2
Fehlt da noch die ID des Sensors im output?
Hallo Jürgen,
Zitat von: juergs
Die RFMxx-Lib lässt sich zwar auf Soft-SPI konfigurieren, aber die zugrunde liegende SPI.h aus
der ESP-Plattform Lib leider nicht!
Die SPI Lib wird bei Soft SPI doch gar nicht eingebunden !? Merkwürdig :o
Die Arduino IDE ist schon sehr eigenartig, Bibliotheken müssen entweder direkt im Projektordner oder
im Ordner libraries sein, stimmt.
Den Lichtsensor hab ich von Segor (www.segor.de).
Gruß Thomas
Hatte ich auch gedacht, aber hier:
byte RFMxx::ReadReg(byte addr) {
SetPin(m_ss, LOW);
SPI.transfer(addr & 0x7F);
//spi8(addr & 0x7F);
byte result = SPI.transfer(0);
//byte result = spi8(0);
SetPin(m_ss, HIGH);
return result;
}
void RFMxx::WriteReg(byte addr, byte value) {
SetPin(m_ss, LOW);
SPI.transfer(addr | 0x80);
SPI.transfer(value);
//spi8(addr | 0x80);
//spi8(value);
SetPin(m_ss, HIGH);
}
Grüße,
Jürgen
Die "SPI.transfer..." müssen gegen die "spi8..." Befehle getauscht werden, bei Soft SPI !
Hatte ich das vergessen ?
Gruß Thomas
Danke für den Hinweis. :)
Werde mal die Version wechseln...
Zitat von: SimGa am 11 Januar 2018, 22:43:08
Hallo zusammen,
hat eigentlich jemand den Ansatz weiter verfolgt, aus den aufgezeichneten Sensordaten Rückschlüsse auf den Algorithmus zu schließen?
Im internet habe ich bisher nur einen eher schlechten(zumindest hier in Colorado funktioniert er schlecht) alternativen Algorithmus gefunden, der sich aus dem Widerstand und der Luftfeuchte nähert.
Hallo SimGa,
hier noch der Versuch einer Berechnung ohne Lib:
https://github.com/pimoroni/bme680/blob/master/examples/indoor-air-quality.py (https://github.com/pimoroni/bme680/blob/master/examples/indoor-air-quality.py)
Ach ja, hatte ich schon erwähnt, daß man die ADAFRUIT-OLED-LIB nicht auf das WROOM-Board flashen sollte?
Einmal unbedacht den Universalsensor-Code geflasht, das wars dann: keine Serielle mehr zum Wiedererwecken ...
Da hilft nur noch herausoperieren des ESP-Moduls ... :'(
OLED-Modul hat etwas Hitzetechnisch gelitten, aber alles geht wieder ... :)
Diesmal ist der zweite Sensor konfiguriert, dennoch kommt dieser Fehler from LGW:
ERROR: empty name in readingsBeginUpdate ERROR: >0B< returned by the CustomSensor ParseFn is invalid, notify the module maintainerZitatInternals:
DEF 07
ID 07
NAME bme680_cc_07
NR 114
STATE Initialized
TYPE CustomSensor
corrH 0
corrT 0
READINGS:
2018-01-06 22:01:22 battery 8
2018-01-06 22:01:22 gas 153280
2018-01-06 22:01:22 gas-kohm 153.3
2018-01-06 22:01:22 humidity 53
2018-01-06 22:01:22 iaq 99
2018-01-06 22:01:22 lux 0
2018-01-06 22:01:22 pressure 997
2018-01-06 22:01:22 state T: 20.5 H: 53
2018-01-06 22:01:22 temperature 20.5
Attributes:
event-min-interval .*:1800
event-on-change-reading .*
room CustomSensor,CO2-Messung
stateFormat temperature °C, humidity %, pressure hPa
userReadings gas-kohm { sprintf( "%.1f", ReadingsVal( $NAME,"gas",0 ) / 1000 + 0.05 ) }
verbose 5
Zitat2018.01.13 12:40:12 1: ERROR: empty name in readingsBeginUpdate
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBeginUpdate called by ./FHEM/36_CustomSensor.pm (207)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,temperature,21) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (210)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,humidity,43) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (214)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,state,T: 21 H: 43) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (226)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,pressure,1011) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (228)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,iaq,41) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (232)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,lux,0) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (236)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,battery,7) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (240)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: readingsUpdate(,gas,365650) missed to call readingsBeginUpdate first.
2018.01.13 12:40:12 1: stacktrace:
2018.01.13 12:40:12 1: main::readingsBulkUpdate called by ./FHEM/36_CustomSensor.pm (244)
2018.01.13 12:40:12 1: main::CustomSensor_Parse called by fhem.pl (3684)
2018.01.13 12:40:12 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (707)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (469)
2018.01.13 12:40:12 1: main::LaCrosseGateway_Read called by fhem.pl (3488)
2018.01.13 12:40:12 1: main::CallFn called by fhem.pl (687)
2018.01.13 12:40:12 1: ERROR: >0B< returned by the CustomSensor ParseFn is invalid, notify the module maintainer
2018.01.13 12:40:13 5: LGW: dispatch OK CC 11 6 16 43 16 17 0 65 0 0 70 54 86 80
Ok, hab's herausgefunden:
Zitat2018.01.13 20:41:15 3: LGW: CustomSensor-rname: bme680_cc
2018.01.13 20:41:17 5: LGW: dispatch OK CC 11 6 6 49 16 9 0 113 0 0 70 49 152 96
2018.01.13 20:41:17 5: LGW: CustomSensor-Frame: OK CC 11 6 6 49 16 9 0 113 0 0 70 49 152 96
2018.01.13 20:41:17 3: LGW: CustomSensor-rname: 0B
Der Sensor ist als dezimal 11 deklariert (weil bei miir einige niedrige LaCrosse-Devices herumschwirren...)
in $rname wird die ID hex übergeben und nicht als String ... Ich hatte es geahnt ... :(
ZitatInternals:
CHANGED
CustomSensor_lastRcv 2018-01-13 20:55:17
DEF 0B
ID 0B
LASTInputDev LGW
LGW_MSGCNT 2
LGW_TIME 2018-01-13 20:55:17
MSGCNT 2
NAME bme680_cc_11
NR 118
STATE 20.7 °C, 49 %, 1008 hPa
TYPE CustomSensor
corrH 0
corrT 0
READINGS:
2018-01-13 20:55:17 battery 7
2018-01-13 20:55:17 gas 315880
2018-01-13 20:55:17 gas-kohm 315.9
2018-01-13 20:55:17 humidity 49
2018-01-13 20:55:17 iaq 78
2018-01-13 20:55:17 lux 0
2018-01-13 20:55:17 pressure 1008
2018-01-13 20:55:17 state T: 20.7 H: 49
2018-01-13 20:55:17 temperature 20.7
Attributes:
event-min-interval .*:1800
event-on-change-reading .*
room CO2-Messung,CustomSensor,LaCrosse
stateFormat temperature °C, humidity %, pressure hPa
userReadings gas-kohm { sprintf( "%.1f", ReadingsVal( $NAME,"gas",0 ) / 1000 + 0.05 ) }
verbose 5
Die angepasste CodeVersion habe ich hier für ESP8266_D1_WROOM_Board (https://github.com/juergs/BME680_cc_sensor_v1_5_V3_D1_WROOM_VS) hinterlegt.
Habe ein Rollback der RFM-Lib auf ein Beispiel von HCS eingebaut, um eine Funkübertragung zustande zu bekommen.
Ein FHEM-Update beinhaltet noch keine aktuelle Version der
36_LaCrossGateWay.pm und der
36_CustomSensor.pm.
Anmerkung: die Reichweite des RFM69 scheint suboptimal zu sein ...
Hallo Jürgen,
hatte wenig Zeit die Tage, sorry.
Zitat von: juergs
Ach ja, hatte ich schon erwähnt, daß man die ADAFRUIT-OLED-LIB nicht auf das WROOM-Board flashen sollte?
Einmal unbedacht den Universalsensor-Code geflasht, das wars dann: keine Serielle mehr zum Wiedererwecken ...
Da hilft nur noch herausoperieren des ESP-Moduls ... :'(
OLED-Modul hat etwas Hitzetechnisch gelitten, aber alles geht wieder ... :)
Das ist schon heftig. Das liegt bestimmt an dem "verdrehten" I2C Anschluss vom WROOM2 (D1 und D2 vertauscht).
Sollte aber mit gedrückter "Flash" Taste (GPIO 0 auf GND) beim booten in den Flash Mode gehen ?!
ZitatDer Sensor ist als dezimal 11 deklariert (weil bei miir einige niedrige LaCrosse-Devices herumschwirren...)
in $rname wird die ID hex übergeben und nicht als String ... Ich hatte es geahnt ... :(
Darüber hatte ich auch eine ganze Zeit gegrübelt, jetzt wo Du es herausgefunden hast, erklärt es die Fehlermeldungen natürlich ;)
Die RFMxx Lib hatte ich mir auch nur "ausgeborgt" und zurechtgestückelt, das mit dem TPinCallback hatte ich ebenfalls schon im Auge,
kann man getrost entfernen, hatte ich auch schon ohne getestet. War bestimmt dazu gedacht, um ohne Arduino IDE Pins umzudefinieren oder so etwas ?!
Edit: Hab die RFMxx Lib im Universalsensorprojekt V2.0 bzgl. TPinCallback und Soft-SPI geändert ;)
https://forum.fhem.de/index.php/topic,78128.msg748272.html#msg748272 (https://forum.fhem.de/index.php/topic,78128.msg748272.html#msg748272)
Gruß Thomas
Hallo Thomas,
danke für die Rückmeldung.
ZitatDas liegt bestimmt an dem "verdrehten" I2C Anschluss vom WROOM2 (D1 und D2 vertauscht).
Sollte aber mit gedrückter "Flash" Taste (GPIO 0 auf GND) beim booten in den Flash Mode gehen ?!
Denke ich auch, wollte aber nicht noch tiefer suchen ... ;)
Das Problem ist, dass die Serielle über den CP2102 Chip blockiert ist ... der ESP schwingt auf allen Ports ...
Da fällt mir auf: auf dem Wroom-Board fehlt der Aufdruck auf dem CP2xxx Chip ....
GPIO 0 auf GND explizit auf GND ziehen, werde ich beim nächsten Mal probieren ... ;D ;D ;D
Hallo Jürgen,
Zitat von: juergs
GPIO 0 auf GND explizit auf GND ziehen, werde ich beim nächsten Mal probieren ... ;D ;D ;D
Hoffentlich passiert Dir das nicht nochmal ;)
Hatte dazu mal gesehen, das der kleine Joystick mit Reset und Flash verdrahtet sein sollte,
evtl. müsstest Du nur den Stick beim einschalten in Stellung "Flash" drücken, siehe Bild:
Gruß Thomas
Hi,
es geht, wenn man Flash und Reset gleichzeitig drückt, den Flashvorgang anstößt
und erst dann Reset loslässt.
Damit konnte ich ein D1-Board reaktivieren ... da die Serielle (USB) dann bleibt ...
Grüße,
Jürgen
Zitat von: juergs
es geht, wenn man Flash und Reset gleichzeitig drückt, den Flashvorgang anstößt
und erst dann Reset loslässt.
Damit konnte ich ein D1-Board reaktivieren ... da die Serielle (USB) dann bleibt ...
Cool, dann bin ich ja gerüstet, wenn es mich mal erwischt ;D ;)
Hallo Thomas,
noch zum Thema Reichweite:
Habe einen separaten Testaufbau gemacht, weil ich den 3ten Sensor einfach nicht empfangen habe...
Obwohl er ca. 50cm neben der LGW stand und der Logikanalyser andeutet dass die Kommunikation funktioniert.
Mußte sogar die Empfindlichkeit des SDR weiter hochdrehen ...
Der höchste PA-Level scheint der Kleinste zu sein! (Ohne ins Datenblatt zu schauen ..)
Man bemerke den Unterschied zum anderen LaCrosse-Sender ...
Hi,
hab eben nochmal schnell ins Datenblatt und die RFMxx Lib geschaut, steht alles auf "max. Power".
Auszug aus dem Datenblatt: "Pout = -18 + OutputPower [dBm] , with PA0"
PA0 Output Power mit allen Bits auf 1 (5 Bits), ergibt max. Power.
Alles ok eigentlich.
Gruß Thomas
Zitat von: hdgucken am 14 Januar 2018, 20:45:51
Hi,
hab eben nochmal schnell ins Datenblatt und die RFMxx Lib geschaut, steht alles auf "max. Power".
Auszug aus dem Datenblatt: "Pout = -18 + OutputPower [dBm] , with PA0"
PA0 Output Power mit allen Bits auf 1 (5 Bits), ergibt max. Power.
Alles ok eigentlich.
Gruß Thomas
Ja ich hab's auch in der Referenzimplementierung gesehen, aber:
Quer durch die Wohnung, auf dem Balkon (3 Stahlbeton-Wände. Habe es (_10110, mach noch eine Meßreihe!) nur mal zufällig versucht einen anderen Wert zu nehmen...:
Man sieht auch: es gibt noch wesentlich Stärkere ...
Eigenartig, vielleicht ist max. Power nicht immer gut !?
Ja, ein RSSI-Wert wäre nicht schlecht ...
EDIT: Oh! hier (https://andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/). Das bestätigt mich ( kurios: PA0?!, verhält sich so wie Pa1+PA2?): https://www.andrehessling.de/wp-content/uploads/2015/02/RFM69HW_RSSIVsPowerLevel.png (https://www.andrehessling.de/wp-content/uploads/2015/02/RFM69HW_RSSIVsPowerLevel.png)
Aber: ab 30 kann ich so gerade nicht bestätigen (die 15 passt, mal schauen wie weit ich da wieder heruntergehen kann) ... ???
ZitatSet reg 0x58 to 0x2D
It increases the sensitivity by 2-3db by enabling the low noise pre-amp.
Good for more distance!
Sehr interessant !!!
Zitat von: juergs
EDIT: Oh! hier (https://andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/). Das bestätigt mich ( kurios: PA0?!, verhält sich so wie Pa1+PA2?): https://www.andrehessling.de/wp-content/uploads/2015/02/RFM69HW_RSSIVsPowerLevel.png (https://www.andrehessling.de/wp-content/uploads/2015/02/RFM69HW_RSSIVsPowerLevel.png)
Aber: ab 30 kann ich so gerade nicht bestätigen (die 15 passt, mal schauen wie weit ich da wieder heruntergehen kann) ... ???
Die RFM69HW, HCW sind leider nicht pinkompatibel, aber sonst ne echte alternative !
Gruß Thomas
Hallo zusammen,
hat jemand von Euch schon das BSEC Beispiel für AVRmega (ich meine, da müsste der Atmega644 passen?) compiliert? Für ESP8366 bekomme ich es hin, für Atmel motzt der Linker, dass die Bibliotheken inkompatibel seien :o :o :o.
Gruß PeMue
Hallo Peter,
hast Du die Dot-a-linkage probiert?
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format (https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format)
Zitatdot_a_linkage - (available from IDE 1.6.0 / arduino-builder 1.0.0-beta13) when set to true, the library will be compiled using a .a (archive) file.
First, all source files are compiled into .o files as normal. Then instead of including all .o files in the linker command directly, all .o files are saved into a .a file,
which is then included in the linker command. 1.5 format library folder structure is required.
precompiled - (feature not yet released, will be available in arduino-builder >1.3.25) set to true to allow the use of .a (archive) and .so (shared object) files.
The .a/.so file must be located at src/{build.mcu} where {build.mcu} is the architecture name of the target the file was compiled for. Ex: cortex-m3 for the Arduino DUE. The static library should be linked as an ldflag.
ldflags - (feature not yet released, will be available in arduino-builder >1.3.25) - the linker flags to be added. Ex: ldflags=-lm
Zusammen mit makefile (http://www.avrfreaks.net/forum/include-static-library-within-makefile)? oder Arduino-Makefile (https://github.com/sudar/Arduino-Makefile)
Auch hier:
ZitatWe have precompiled functions implementing all instructions sepa
rately (thus, got object file for every each instruction) and
packed it to a single *.a file (standard library of gcc is
precompiled in this way). This library does not include hardware access layer and thus is
completely device independent – it works on different microcontrollers from AVR8 family.
On the other hand, library functions expect the hardware access layer implemented outside
and specific to used microcontroller – the code in the library is not linked. There are
"unconnected" calls for functions spiMasterINIT(), spiMasterTRANSMIT() and spiMasterChipSelect(). The linker will try to link
calls from library to those functions – user has to implement them.
http://www.matejk.cz/zdroje/mcp2515-avr-can-spi.pdf (http://www.matejk.cz/zdroje/mcp2515-avr-can-spi.pdf)
ZitatOk, I think I've got it working. What I did was simply add the path to the .a file to the ##Link step by changing this line:
"{build.path}/{archive_file}" "-L{build.path}"
to this:
"{build.path}/{archive_file}" "C:\Users\Nick\Documents\Arduino\libraries\mpl\libl ibmplmpu.a" "-L{build.path}"
Bei mir ist dieser Eintrag in:
"C:\Program Files (x86)\Arduino\hardware\arduino\avr\platform.txt"und
C:\Program Files (x86)\Arduino\hardware\platform.keys.rewrite.txtzu finden...
Probiert habe ich es selbst (noch) nicht, da der ESP und der STM32 mehr als ausreichend sind .. ;)
String CalculateIAQ(float score){
String IAQ_text = "Air quality is ";
// score = (100-score)*5; // beeing calculated from gas resitance without bsec
if (score >= 301) IAQ_text += "Hazardous";
else if (score >= 201 && score <= 300 ) IAQ_text += "Very Unhealthy";
else if (score >= 176 && score <= 200 ) IAQ_text += "Unhealthy";
else if (score >= 151 && score <= 175 ) IAQ_text += "Unhealthy for Sensitive Groups";
else if (score >= 51 && score <= 150 ) IAQ_text += "Moderate";
else if (score >= 00 && score <= 50 ) IAQ_text += "Good";
return IAQ_text;
}
Hallo Jürgen,
mit Deinem letzten Zitat habe ich die Bibliothek ebenfalls eingebunden bekommen. Allerdings motzt der Linker, dass das Format nicht passt ...
Der ESP ist nicht für batteriebetriebene Sensoren, den STM kenne ich zu wenig ...
Gruß Peter
den STM kenne ich zu wenig
Das lässt sich ändern... ;)
Anbei meine
Maple-STM32-Code-Variante als Beta.
OLED und BME680 funktionieren, beim SPI zum RFM69 bin ich noch in Klärung ...
Evtl. tausche ich die SPI-LIB gegen die "RFM69-STM32-master"-Lib aus Github aus...
SPI-Bus ist aktiv. sendet aber über den RFM (noch) nicht, könnte aber auch nur die Einstellung des PA_Levels sein ...
Schaue mir das am WoE noch genauer an ... :)
Die ARM M3 precompiled BSEC-Lib ist, wie hier beschrieben, auch für den Maple einzubinden:
https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/
Die STM32 Plattform-Installation für die Arduino-IDE gibts im Internet zu hauf.
https://www.bosch-sensortec.com/bst/products/all_products/bsec (https://www.bosch-sensortec.com/bst/products/all_products/bsec)
Mein Wroom2-Board (ESP8266) läuft jetzt schon den 2ten Tag ohne Nachladen mit einem 18650
mit OLED durch!
Da wäre ich am Überlegen, das OLED einfach per Taster Software-technisch ab- und einzuschalten.
Auf dem Wroom-Board liegen die Taster leider physikalisch auf der SPI-Schnittstelle:
| Center = D5 (SCLK) |
| Up = D6 (MISO) |
| Down = D7 (MOSI) |
| Left = RES |
| Right = D3 (Flash, verfügbar) |
Habe also nur D3 frei und evtl. D0 (2te grüne LED) zur Verfügung.
In meiner ESP-Version habe ich ja WiFi abgeschalten, das spart schon erheblich.
Für den AVR könnte man aber auch damit, also ohne BSEC leben:
https://github.com/G6EJD/BME680-Example (https://github.com/G6EJD/BME680-Example)
Siehe
unten blaue zu gelber Kurve.
Hallo Leute,
Zitat von: PeMue
hat jemand von Euch schon das BSEC Beispiel für AVRmega (ich meine, da müsste der Atmega644 passen?) compiliert? Für ESP8266 bekomme ich es hin, für Atmel motzt der Linker, dass die Bibliotheken inkompatibel seien :o :o :o.
Gleiches Problem bei mir.
Daraufhin habe ich mir gleich mal zwei Blue Pills bei a...n bestellt (STM32F103C8). Hoffentlich reicht der Flash Speicher bei den Boards ???
Hab wie PeMue keine großartigen Erfahrungen damit, aber:
Zitat von: juergs
den STM kenne ich zu wenig
Das lässt sich ändern... ;)
Gruß Thomas
Diese hier waren in gefühlt 2 Tagen da: STM32F103RCBT6 (https://www.ebay.de/itm/400569863658)
Hallo zusammen,
wenn ich die BSEC Library in das Verzeichnis libraries kopiere (bzw. beim Kompilieren) kommt folgende Meldung:
e:/software/arduino185/hardware/tools/avr/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld.exe: avr:6 architecture of input file `E:\software\arduino185\portable\sketchbook\libraries\libalgobsec.a(bsec_interface.o)' is incompatible with avr:5 output
bzw.
Ungültige Bibliothek G:\software\arduino185\portable\sketchbook\libraries\BSEC in G:\software\arduino185\portable\sketchbook\libraries\BSEC gefunden
Ich vermute, da passt etwas mit der Bibliotheksstruktur nicht (oder es fehlt ein Linker Schalter).
Mir wäre persönlich ein Atmega lieber, weil
- ich dann eine Universalsensorplatine aka Dirk's Sensor machen könnte
- ggf. da auch verschiedene Protokolle (Homematic, Thomas' Universalsensor, etc.) laufen könnte und
- der ESP8266 für Batteriebetrieb nicht wirklich geeignet ist.
Damit man mir aber nicht mangelnde Lernfähigkeit vorwerfen kann ;D ;D ;D, habe ich mal meine Arduino IDE für STM32F1x befähigt. Dieser Chip ist ja auch auf meinem mapleCUx drauf :P
Gruß Peter
Edit: Der Blink Sketch lässt sich zumindest mal für den STM32F1x kompilieren ;)
ZitatDamit man mir aber nicht mangelnde Lernfähigkeit vorwerfen kann ,
Nee, so schlimm ist es jetzt auch wieder nicht. ;D
Aber da Du eigentlich mit dem STM auch schon Layout-Erfahrung gewonnen hast und dieser doch noch wesentlich mehr Möglichkeiten bietet
als ein AVR?
Aber man muss das Rad auch nicht neu erfinden ... Hatte den STM halt noch "übrig" ...
Apropos:
Ich hatte mir das Projekt von @roedert mit dem Wasserzähler angeschaut https://forum.fhem.de/index.php?action=dlattach;topic=71341.0;attach=93201 (https://forum.fhem.de/index.php?action=dlattach;topic=71341.0;attach=93201)
Er benutzt da googlecharts_line_basic (https://www.tutorialspoint.com/googlecharts/googlecharts_line_basic.htm).
Wäre für dieses Projekt ebenfalls sehr interessant...
@Peter, kann mir erst am WoE das Thema Compiler noch mal anschauen :'(
http://www.avrfreaks.net/forum/error-compiling-debug-project-only (http://www.avrfreaks.net/forum/error-compiling-debug-project-only)
ZitatFar better to post the build output - maybe just the areas where the errors actually occur if there is a lot of it.
@PeMue
ich vermute stark, dass die AVR 8 Bit Lib nicht für die Arduino, sondern für die Atmel Studio Toolchain kompiliert worden ist.
http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers) (http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers))
https://github.com/BoschSensortec/BME680_driver (https://github.com/BoschSensortec/BME680_driver)
ZitatDo you mean in the Arduino IDE? This is quite complicated as the Arduino IDE currently doesn't support precompiled libs.
This will probably be supported in on of their next releases. Once they do, we will also release a BSEC library for use in the Arduino IDE with examples.
Na ja stimmt ja so nicht ganz ....
Zur Zeit sind die Breakoutboards ausverkauft oder überteuert.
Bestünde Interesse an einem einfachen Breakoutboard für < 10 € ?
Bei Mouser kosten 10 Stück BME680: 77,10 € + Breakoutboard, habe 12 Stück bei OSHpark bestellt.
Falls sich genügend Abnehmer fänden ....
Dann die Frage an @PeMue: ist das Selbst-Bestücken überhaupt machbar?
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs am 19 Januar 2018, 17:36:55
Dann die Frage an @PeMue: ist das Selbst-Bestücken überhaupt machbar?
das geht nur mit (Hand)-Dispensen und Ofen. Bei einer größeren Menge an Leiterplatten wäre es besser, eine Schablone zu haben.
Gruß Peter
Zitat...das geht nur mit (Hand)-Dispensen und Ofen.
Ja ich weiss, die Geschichte mit dem Kaffee ... ;)
Mal schauen. Evtl wäre es besser dann bei einem anderen PCB-Lieferant anzufragen, der die Schablone mitliefert... ?
@PeMue
habe kurz in "Atmel Studio 7" das .ino-Projekt migriert und die Precompiled-Lib einfach als Library eingebunden.
Bis auf:
ZitatSeverity Code Description Project File Line
Error recipe for target 'src/libraries/Wire/src/utility/twi.o' failed bme680Mega644 c:\users\<user>\Documents\Atmel Studio\7.0\bme680Mega644\bme680Mega644\Debug\Makefile 148
und
ZitatSeverity Code Description Project File Line
Error Arduino.h: No such file or directory bme680Mega644 c:\users\<user>\Documents\Atmel Studio\7.0\bme680Mega644\bme680Mega644\src\libraries\Wire\src\utility\twi.c 28
Evtl. benötigt man auch:
http://www.visualmicro.com/page/Arduino-for-Atmel-Studio-7.aspx (http://www.visualmicro.com/page/Arduino-for-Atmel-Studio-7.aspx)
Das ist das Ergebnis:
Hallo Jürgen,
echt cool, das finde ich klasse.
Zitat von: juergs am 19 Januar 2018, 20:48:25
habe kurz in AtmelStudio das .ino-Projekt migriert und die Precompiled-Lib einfach als Library eingebunden.
Welches? Das von Dir oder das von Thomas?
Wenn Du das von Thomas genommen hast, könnte ich das ja mal auf dem Steckbrett (oder meinem uralten Pollin Board) mal in Betrieb nehmen.
Sprich ich könnte mir jetzt Gedanken über einen Batteriesensor mit folgenden Eigenschaften machen:
- 2xAA + stepup Regler
- Atmega644PAU (mit Quarz oder nur internem Quarz?)
- BME680 bzw. andere Sensoren (auch VOC?), welche?
- RFM69CW (Universalsensor) bzw. alternativ CC1101 Modul (Homematic oder was auch immer)
- vernünftiges Gehäuse
Fehlt dann noch was?
Gruß Peter
Hallo Peter,
ich habe das gerade quick&dirty gemacht.
Habe das ESP-Projekt von mir genommen (mit Thomas seinem geht das auch...)
Man muss nur die ESP-spezifischen Dinge herausnehmen ...
Für den 644P muss man noch die Feinheiten einstellen und schauen dass der Compile ohne Fehler mit den Arduino Bibliotheken durchgeht.
Das ist noch etwas F&E notwendig.... ;)
Wenn es auf den 328P geht (sprich NANO) ... :-\
Aber prinzipiell geht es mal, das ist doch schon gut!
ZitatSprich ich könnte mir jetzt Gedanken über einen Batteriesensor mit folgenden Eigenschaften machen:
- 2xAA + stepup Regler
- Atmega644PAU (mit Quarz oder nur internem Quarz?)
- BME680 bzw. andere Sensoren (auch VOC?), welche?
- RFM69CW (Universalsensor) bzw. alternativ CC1101 Modul (Homematic oder was auch immer)
- vernünftiges Gehäuse
Das hört sich super gut an. Als erstes mal ein Breadboard-Prototyp, um zu sehen wie sich die Lib auf einem 8-Bitter verhält....
Ein 3D-Gehäuse hätte ich (eigentlich) für morgen geplant ...
Zitat(auch VOC?), welche?
Mein geliefertes CSS811-Board mit dem CSS811 ist der Chip leider defekt, lässt sich aber gut auslöten ...
Muss aber erst einen Neuen besorgen.
Die andere VOC Variante wäre ja, die mit dem Sensor des CO2Monitor (https://maker-tutorials.com/guenstiges-co2-messgeraet-airco2ntrol-im-test-1-raspberry-pi-fhem-usb/)-Teils mit dem ZGm053U (http://www.zyaura.com/products/ZGm05.asp).
ZitatMethod - Dual Beam NDIR
Könnte aber etwas teurer sein ... Evtl. billiger dem CO2Monitor einfach ein FHEM-Node-Gateway zu "verpassen" ... ;)
Finde den BME680 mittlerweile mehr als ausreichend mit plausiblen Werten ... was braucht man mehr?
Ich habe bei den Sensortec-Issues auf github einen Vergleich diverser Sensoren mit dem BME680 gesehen, die Kurven waren fast alle gleichwertig ...
Finde aber die Seite nicht mehr ...
https://www.digikey.com/en/videos/m/microchip/importing-arduino-sketches-into-atmel-studio-7 (https://www.digikey.com/en/videos/m/microchip/importing-arduino-sketches-into-atmel-studio-7)
Zitat von: juergs am 19 Januar 2018, 21:06:57
Ich habe bei den Sensortec-Issues auf github einen Vergleich diverser Sensoren mit dem BME680 gesehen, die Kurven waren fast alle gleichwertig ...
War das diese Seite (Posts vom 12. November)?
https://github.com/BoschSensortec/BME680_driver/issues/6
Gruß Peter
ja, genau! Danke.
Diese Seite verhält sich komisch, geht man raus und wieder rein sind es nur 5 Issues. >:(
Ok, es sind Unterkommentare des 5. Eintrages, jetzt!
Deswegen: Es wird aber nur zögerlich geantwortet ...
Man hätte eine Ebene höher fragen sollen ...
Zitatthe code will not fit on Arduino boards based on the Atmel AVR series that have 32kB flash and 2kB of RAM
Also doch 644 oder größer ...
Ein 644P-Board und ein Atmel-ICE habe ich auch noch irgendwo rumliegen ....
AVR_GCC Standalone-Toolchain für Windows & Linux: avr-and-arm-toolchain (http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers))
ZitatAtmel AVR GNU Toolchain is also available as part of Atmel Studio. Only those users who wish to run the Atmel AVR GNU Toolchain as standalone tools from the command line need to download and install this package.
Dann sollte ein passendes Makefile reichen...
Momentan macht boards.txt noch Probleme, weil sich die Struktur mit dem Boardmanager geändert hat, aber AtmelStudio eigentlich die "alte" Variante erwartet.
Anbei Beispiel-Einträge für den ATMEGA644. Oder von: hier (http://forum.arduino.cc/index.php?topic=321805.0)
Der Arduino Boardmanager bietet mir keine ATMEGA644-Boards (http://www.instructables.com/id/ATmega-DIP40-Minimal-Board/) an. (Platforms1.wiki (https://code.google.com/archive/p/arduino/wikis/Platforms1.wiki) , Bootloader (http://menututo.com/mettre-un-bootloader-arduino-dans-un-atmega1284p/))
Arduino-IDE-1.5-3rd-party-Hardware-specification (https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification)
Info zum Maple mit BME680:
Zitat2018.01.20 18:14:52 5: LGW: CustomSensor-Frame: OK CC 7 6 7 45 9 134 0 37 0 0 80 35 144 16
2018.01.20 18:14:52 3: LGW: CustomSensor-rname: bme680_cc_07
Senden mit RFM funktioniert.
Ursache : RF_PALEVEL_OUTPUTPOWER_11111 geändert auf RF_PALEVEL_OUTPUTPOWER_01111. :)
Hallo Jürgen, Hallo Peter,
hab inzwischen auch alles mögliche inkl. Atmel Studio 7 und Mighty Core für Arduino probiert, aber nichts führt so recht zum Erfolg mit den ATMEGA 644/1284 :(
Es sollte eigentlich dieser Tage eine Arduino kompatible Lib für die AVR's von Bosch Sensortec kommen, ich schaue jetzt immer mal wieder nach dieser Version 8)
Zitat von: juergs
Info zum Maple mit BME680:
Senden mit RFM funktioniert.
Ursache : RF_PALEVEL_OUTPUTPOWER_11111 geändert auf RF_PALEVEL_OUTPUTPOWER_01111. :)
Cool, ich hab meine ARM's leider noch nicht bekommen (ab ca. dem 5.Feb. sollen sie geliefert werden) :P
Hab mal wieder den Universalsensor überarbeitet, hier ist V2.2 ! Alles ist jetzt über die Defines auswähl- bzw. einstellbar,
Soft-SPI (nicht mehr die RFMxx.h ändern), debug mode und alle Zubehör Sachen.
Dabei ist mir aufgefallen, warum bei Dir und dem WROOM2 Board die Adafruit Lib warscheinlich nicht funktioniert:
In der Adafruit_SSD1306.cpp steht nochmal "Wire.beginn()" !!! Damit geht das natürlich nicht für's WROOM2 :o
...
else
{
// I2C Init
Wire.begin();
#ifdef __SAM3X8E__
...
Anbei mal wieder die neue Version, plus ein paar Impressionen(mit und ohne debug, soft/hw SPI ...):
Gruß Thomas
Hallo Thomas,
richtig gut!
Zitathab inzwischen auch alles mögliche inkl. Atmel Studio 7 und Mighty Core für Arduino probiert, aber nichts führt so recht zum Erfolg mit den ATMEGA 644/1284
Ja so ist es mir auch ergangen ... Vorrausetzung ist es die Arduino IDE zu überreden die alte Struktur der Boards auf ATMEGA644 zu setzen, da AS7 diese alte Struktur erwartet um die Templates beim Import auf den 644 setzen zu können.
Evtl. geht das nur mit einer älteren Version, die noch mit <Arduino_Verzeichnis>/Hardware/boards.txt arbeitet. Genau
diese liest ja AS7 bei migrieren und setzen der Boardeinstellungen aus.
Vielleicht reicht es aus dort nur den 644-Eintrag nachzurüsten, ohne dass es in Arduino eine Wirkung hätte.
Der Rest erfolgt ja dann in der eigenen Toolchain von AS7. Wichtig wäre einfach nur das "richtige" Makefile für den 644 zu erhalten.
Wie gesagt, der 644 ist ja nicht mehr so der "Mainstream" bei den Boards :'(
ZitatWROOM2 Board die Adafruit Lib warscheinlich nicht funktioniert: In der Adafruit_SSD1306.cpp steht nochmal "Wire.begin()"
=> Standard I2C für das Wroom2-Board falsch herum...
Ja ist mir auch schon aufgefallen, nach dem ich die ASCII1306-Lib schon angewandt hatte.
Damit war für mich die Adafruit-Lib raus ... Kann aber wegen den Grafik-Eigenschaften noch mal
die Lib in Betracht ziehen. ;)
Verbesserungen kann ich noch weiter Implementieren:
z.B.:
* Display (An/Aus ggf. Sleep und WakeUp)
* Balken- oder Gauge-Anzeige wie hier (http://www.technoblogy.com/show?WNM), eigene Display-Routinen!
* Ersetzen des Display-Updates durch direktes Positionieren der Messwerte. (Blinken stört mit der Zeit (wg.
println -Bildaufbau)
* mehrere Display-Seiten
Beim Maple erfolgt der Displayaufbau etwas langsamer als mit dem ESP. Liegt wohl an der 400KHz-I2C-Taktrate.
Aber dieser ist für Batteriebetrieb geeignet.
Den PALevel auf 15 setzen ist wahrscheinlich für alle Varianten zu empfehlen ... :)
Ich kümmere mich jetzt mal um das Gehäuse und widme mich dann deinem UniversalSensor-Build :)
Vielleicht solltes Du auch über einen Github-Account den Code dort ablegen, das hätten den Charme, dass man dort
dann zusammen arbeiten könnte ;) und die Versionierung + Dokumentation einfacher ist ...
Grüße,
Jürgen
3D-Gehäuse für Wroom2-Board im 3D-Druck-Thread:
https://forum.fhem.de/index.php/topic,83085.0.html (https://forum.fhem.de/index.php/topic,83085.0.html)
Ideen dazu gerne wilkommen. :D
Hallo Jürgen,
Zitat von: juergs
... Vorrausetzung ist es die Arduino IDE zu überreden die alte Struktur der Boards auf ATMEGA644 zu setzen, da AS7 diese alte Struktur erwartet um die Templates beim Import auf den 644 setzen zu können.
Evtl. geht das nur mit einer älteren Version, die noch mit <Arduino_Verzeichnis>/Hardware/boards.txt arbeitet...
Wie gesagt, der 644 ist ja nicht mehr so der "Mainstream" bei den Boards :'(
Das ist noch ein guter Tip, probier ich mal ... 8)
Und stimmt, sind nicht mehr so ganz up to date, aber vielleicht für den Zweck noch ganz gut :)
Zitat
Verbesserungen kann ich noch weiter Implementieren:
Sehr gerne ;)
Zitat
Vielleicht solltes Du auch über einen Github-Account den Code dort ablegen, das hätten den Charme, dass man dort
dann zusammen arbeiten könnte ;) und die Versionierung + Dokumentation einfacher ist ...
GitHub Account hab ich auch seit kurzem, allerdings unter einem anderen Namen, vielleicht etwas blöd ?!
Aber hatte ich auch schon drüber nachgedacht :D
Zitat
Den PALevel auf 15 setzen ist wahrscheinlich für alle Varianten zu empfehlen ... :)
Werde ich auch mal testen, Reichweite ist durch nichts zu ersetzen, außer durch noch mehr Reichweite ;D
Zitat
Ich kümmere mich jetzt mal um das Gehäuse und widme mich dann deinem UniversalSensor-Build :)
Da hab ich natürlich auch Interesse, muss mir noch Gedanken dazu machen ...
Gruß Thomas
ZitatGitHub Account hab ich auch seit kurzem, allerdings unter einem anderen Namen, vielleicht etwas blöd
Na dann gibt's vielleicht ein
github.com/hdgucken? ;) ;) ;D ;D
Hat auch den Vorteil, dass man den Überblick über seine eigenen Projekte behält.
Besonders, wenn man den Rechner oder Betriessystem wechselt (... und der Backup-Fall!) ;)
Apropos:
Maple-Version: https://github.com/juergs/Maple_BME_CC_Sensor (https://github.com/juergs/Maple_BME_CC_Sensor)
Hab einfach mal den Namen hdgucken zum bestehenden account hinzugefügt, ist insgesamt besser,
dann muss ich nicht 2 accounts betreuen :) Muss nur noch das Projekt hochladen ;)
Edit: es ist vollbracht: https://github.com/amigatommy/BME680-UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor)
Gruß Thomas
alias hdgucken / amigatommy (on github) ;)
Hallo Jürgen,
Zitat von: juergs am 21 Januar 2018, 12:22:37
Apropos:
Maple-Version: https://github.com/juergs/Maple_BME_CC_Sensor (https://github.com/juergs/Maple_BME_CC_Sensor)
von welcher Bibliothek kommt den
HardWire.h?
C:\temp\BME680_sensor_maple\BME680_sensor_maple.ino:133:22: fatal error: HardWire.h: No such file or directory
#include <HardWire.h>
compilation terminated.
exit status 1
Ich versuche gerade die arduino IDE für den STM32F103x einzurichten, Blink Sketch geht, Deiner leider noch nicht :(
Danke + Gruß
Peter
https://github.com/leaflabs/libmaple/blob/master/libraries/Wire/HardWire.h (https://github.com/leaflabs/libmaple/blob/master/libraries/Wire/HardWire.h)
Zitat/*
* Library created by crenn to use the new WireBase system and allow Arduino
* users easy interaction with the I2C Hardware in a familiar method.
*/
;)
https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/ (https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/)
hier eine gute Anleitung zum einbinden der libalgobsec.a und das tweaken der STM32 SPI Lib 8)
Zitat von: hdgucken am 23 Januar 2018, 15:09:47
https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/ (https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/)
hier eine gute Anleitung zum einbinden der libalgobsec.a und das tweaken der STM32 SPI Lib 8)
Soweit muss ich erst einmal kommen ;D
Gruß PeMue
Zitatthen you want to know how to wire up the pins of a BME680 breakout board with the Arduino MEGA. As a first step,
I would try to get the BME680 examples running which you can find at https://github.com/BoschSensortec/BME680_driver.
Das wäre der erste Part ohne BSEC ...
Zitat von: juergs am 23 Januar 2018, 14:18:20
https://github.com/leaflabs/libmaple/blob/master/libraries/Wire/HardWire.h (https://github.com/leaflabs/libmaple/blob/master/libraries/Wire/HardWire.h) ;)
Hm, diese Bibliothek findet sich selber nicht, Fehlermeldungen:
In file included from C:\temp\BME680_sensor_maple\BME680_sensor_maple.ino:133:0:
E:\software\arduino185\portable\sketchbook\hardware\Arduino_STM32\STM32F1\libraries\Wire/HardWire.h:42:27: fatal error: Wire/WireBase.h: No such file or directory
#include <Wire/WireBase.h>
^
compilation terminated.Inhalt der Bibliothek:
28.07.2016 21:23 2.303 HardWire.cpp
28.07.2016 21:23 2.314 HardWire.h
28.07.2016 21:23 644 rules.mk
28.07.2016 21:23 4.895 Wire.cpp
28.07.2016 21:23 3.785 Wire.h
28.07.2016 21:23 4.050 WireBase.cpp
28.07.2016 21:23 4.343 WireBase.hHeader von
HardWire.h:
#include <Wire/WireBase.h>
#include <wirish/wirish.h>
#include <libmaple/i2c.h>
das Unterverzeichnis
Wire gibt's nicht :o :o :o
Gruß PeMue
Hallo Peter,
....schaue mal nach...
ZitatUsing library Wire in folder: C:\Users\<js>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire (legacy)
Das sit bei mir ein Ordner im Projekt-Ordner, den man in Preferences einstellt.
Dieser wird wohl automatisch bei der Toolchain-Installation im Boardmanager angelegt ...
Datenträger in Laufwerk C: ist SYSTEM
Volumeseriennummer: 7096-15F4
Verzeichnis von C:\Users\js\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries
23.01.2018 18:19 <DIR> .
23.01.2018 18:19 <DIR> ..
13.06.2017 01:39 <DIR> Adafruit_GFX_AS
13.06.2017 01:39 <DIR> Adafruit_ILI9341
13.06.2017 01:39 <DIR> Adafruit_ILI9341_STM
13.06.2017 01:39 <DIR> Adafruit_SSD1306
13.06.2017 01:39 <DIR> A_STM32_Examples
13.06.2017 01:39 <DIR> EEPROM
13.06.2017 01:39 <DIR> Ethernet_STM
13.06.2017 01:39 <DIR> FreeRTOS
13.06.2017 01:39 <DIR> FreeRTOS821
13.06.2017 01:39 <DIR> Lcd7920_STM
13.06.2017 01:39 <DIR> LiquidCrystal
13.06.2017 01:39 <DIR> MapleCoOS
13.06.2017 01:39 <DIR> MapleCoOS116
13.06.2017 01:39 <DIR> OLED_I2C
13.06.2017 01:39 <DIR> OneWireSTM
13.06.2017 01:39 <DIR> RTClock
13.06.2017 01:39 <DIR> Serasidis_EtherCard_STM
13.06.2017 01:39 <DIR> Serasidis_VS1003B_STM
13.06.2017 01:39 <DIR> Serasidis_XPT2046_touch
13.06.2017 01:39 <DIR> Servo
13.06.2017 01:39 <DIR> SPI
13.06.2017 01:39 <DIR> STM32ADC
13.06.2017 01:39 <DIR> Touch-Screen-Library_STM
13.06.2017 01:39 <DIR> Wire
23.01.2018 18:19 13.785 Wire.zip
13.06.2017 01:39 <DIR> WS2812B
1 Datei(en), 13.785 Bytes
27 Verzeichnis(se), 146.876.633.088 Bytes frei
So sieht das bei mir aus, weiss aber leider nicht mehr genau, ob ich das manuell da reingelegt habe.
Sehr wahrscheinlich schon :( ??? ::) Asche auf mein Haupt!
Die
SPI-Lib aus diesem Verzeichnis (STM32-Standard-Library-Suchpfad) habe ich auch noch dazu gepackt.
(und eine
OLED_I2C liegt auch noch dort ..)
Wo das bei Dir liegt, kannst du am Compile-Output sehen, wenn Du in Preferences "Show verbose output during *compile and *upload"
beide Checkboxen angeklickt hast.
Grüße,
Jürgen
PS:
Der Status ist aber wirklich "preliminary"... Mann kann auch die I2C-Speed noch auf FAST einstellen.
Dann ist der Display-Update schneller....
Bin soweit, jetzt fehlen mir nur noch meine STM32 Boards, die sind noch unterwegs ... :)
Hab den Universalsensor V2.2 auf STM32 umgebaut, hoffe, daß alles funktionieren wird:
Der Sketch verwendet 74492 Bytes (56%) des Programmspeicherplatzes. Das Maximum sind 131072 Bytes.
Globale Variablen verwenden 5920 Bytes (28%) des dynamischen Speichers, 14560 Bytes für lokale Variablen verbleiben. Das Maximum sind 20480 Bytes.
Hallo Jürgen,
es reicht nur die Wire Bibliothek, die habe ich in Wire_leaflab umbenannt, da schon eine Wire Bibliothek vorhanden war. Dann hat die Arduino IDE anstandslos durchkompiliert (obwohl ich die BSEC Bibliothek noch nicht eingebunden habe ???), aber es kamen immerhin rote Warnmeldungen. Das ist also anders als beim ESP8266 oder beim AVR, der Linker linkt, auch wenn die Bibliothek nicht da ist und erstellt einen Sketch :o. Nach dem Einbinden der BSEC Bibliothek (mit Deinem Sketch aus github):
Sketch uses 72700 bytes (65%) of program storage space. Maximum is 110592 bytes.
Global variables use 5752 bytes (33%) of dynamic memory, leaving 11656 bytes for local variables. Maximum is 17408 bytes.
Jetzt muss ich mich nur noch darum kümmern, welcher der richtige Bootloader für den mapleMini ist. :D
Gruß PeMue
Hallo Peter,
freut mich, dass es geklappt hat. (Die ASCII_SD1306-OLED-Lib gibt eine Warnmeldung aus bezüglich Fast-I2C-Mode (400KHz) aus und kann vernachlässigt werden)
Zitatder Linker linkt, auch wenn die Bibliothek nicht da ist
Nein, der Compiler meckert eigentlich, weil er die Einsprungspunkte in die BSEC-Funktionen nicht findet ...
Das MapleMini-Board kommt ja schon mit dem Leaflabs Bootloader, bzw. mit dem Hardware-DFU-Bootloader.
Auf einen
fabrikneuen STM-Chip brauchst Du nur die manuelle Boot-Prozedur seriell (!) einmal einleiten:
Brücke zwischen Ground und BOOT1 und den Blink-Sketch über Arduino flashen (Flash-Button gedrückt halten und Reset kurz toggeln)
Danach sollte dann die Arduino-IDE über USB als DFU-Bootloader erkennen und beim Flashen vom Blink Sketch seinen Bootloader mit auf den Prozessor brennen.
Von da ab braucht man nicht mehr manuell die Button-Prozedur durchführen, sondern die Arduino-IDE schaltet automatisch in den Flashmodus.
Wie gesagt, das gilt nicht für das Maple-Board, nur für einen eigenen neuen Chip. Ansonsten kennen wir das schon aus dem MapleCUL-Thread. ;)
Diesen Bootloader könntest Du dann auch mit dem "
Flash Loader Demonstrator" auf den Chip bringen (ist aber mit der Arduino-IDE nicht erforderlich).
Wäre noch die Frage offen, wo liegt der Arduino-STM-Bootloader zum manuellen Flashen ?
Hoffe, ich habe das noch richtig in Erinnerung. ::)
Ansonsten, hier:
http://www.rogerclark.net/stm32f103-and-maple-maple-mini-with-arduino-1-5-x-ide/ (http://www.rogerclark.net/stm32f103-and-maple-maple-mini-with-arduino-1-5-x-ide/)
http://www.rogerclark.net/arduino-stm32-usb-serial-and-dfu/ (http://www.rogerclark.net/arduino-stm32-usb-serial-and-dfu/)
Bootloader binary: maple_mini_boot20.bin
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries)
http://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/ (http://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/)
Maple + Adafruit SSD1306-OLED- Lib mit Hardware I2C_1:
(defaults, mit 0x3C-Adresse und 128x64-Auflösung)
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306_STM32.h>
#define OLED_RESET 4
Adafruit_SSD1306 display(OLED_RESET);im STM-Hardware-Ordner (aus preferences.txt: <lib-Path>\hardware)
ZitatC:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Adafruit_SSD1306
folgende Änderungen für I2c_1 :
//#include <HWIRE.h>
#include <HardWire.h>
HardWire HWIRE(1,I2C_FAST_MODE); // I2c1
//HardWire HWIRE(2,I2C_FAST_MODE); // I2c2
#include "Adafruit_GFX.h"
#include "Adafruit_SSD1306_STM32.h"
/*
Things to know:
This adaption uses hardware I2C (hardwire.h), Port: I2c2. SDA=0, SCL=1 on maple mini
To change it to Port I2C1:
//HardWire HWIRE(1,I2C_FAST_MODE); // I2c1
HardWire HWIRE(2,I2C_FAST_MODE); // I2c2
*/
Der compiler beklagte sich, dass er swap nicht kennt, deshalb:
#define swap(x, y) do { typeof(x) SWAP = x; x = y; y = SWAP; } while (0)in der Datei:
C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Adafruit_SSD1306\Adafruit_SSD1306_STM32.cppgeändert bzw. hinzugefügt.
Damit funktioniert auch der I2C-FastMode mit 400KHz.
Grüße,
Jürgen
Hallo Thomas,
Zitat von: hdgucken am 21 Januar 2018, 00:19:56
Hab mal wieder den Universalsensor überarbeitet, hier ist V2.2 ! Alles ist jetzt über die Defines auswähl- bzw. einstellbar,
habe mittlerweile mein nanoLGW mit der v2.2 aktualisiert:
BME680 wireless sensor V2.2
Protocol: UniversalSensor
BSEC version: 1.4.5.1
ESP Core Version: 2_4_0
ESP SDK Version: 2.1.0(deb1901)
NODE-ID : 0x6F
aktivierte Komponenten:
RFM69 - 433/868/915MHz Sender
BH1750 - Lichtsensor
OLED - 128x64 OLED Display mit SH1106 Chipsatz
Messung der Versorgungsspannung aktiv
OLED not found
Hardware-SPI fuer RFM69 aktiviert
NSS an GPIO-Pin 15
RFM69 init ...
Init LaCrosse done
Set frequency to 868.300 MHz
Set datarate to 17241 bps
done
BME680 init ... done
BH1750 init ... not present
Ready, start measuring ...
[7597.00] P: 1006.8| T: 30.55| rH: 30.33| IAQ: 25.00 (0)| Gas: 19316.00| UBat: 3.7V
transmission time: 32 ms
data:
205 111 5 25 30 255 255 255 255 255 255 255 255 0 39 83 0 0 25 0 75 116 255 255 255 22 36 255 255 255 127 182
CD 6F 5 19 1E FF FF FF FF FF FF FF FF 0 27 53 0 0 19 0 4B 74 FF FF FF 16 24 FF FF FF 7F B6
32 bytes sent.
[19598.00] P: 1006.7| T: 30.84| rH: 28.65| IAQ: 25.00 (0)| Gas: 18798.00| UBat: 3.7VFHEM empfängt dieselben Werte:
2018-01-28 19:19:37 LaCrosse LaCrosse_6F gas1: 25
2018-01-28 19:19:37 LaCrosse LaCrosse_6F gas2: 18798Verbesserungsvorschlag: Im Debug Mode auch die Höhe mit ausgeben, da sieht man dann, welche Höhe der Sensor eingestellt hat (und ich habe prompt die mit 0 m geflasht :o).
Gruß PeMue
Edit 1:Und den Sprung im Druck kann man sehr gut sehen: ursprünglich Berlin, dann 0 m und jetzt die Höhe, die für meinen Wohnort passt ;D Deckt sich jetzt auch mit den anderen Drucksensoren.
Edit 2:Und hier noch die mapleMini Hardware zu Einpflegen in den Code, noch ungetestet, aber geflasht:
Hardware setup: BME680 RFM69CW
NodeMCU +------+ +-------+
+--\/--+ +3.3V | 0x76 | +3,3V | | GND
VCC 3,3V | | GND <-> SDA | or | --> MOSI | NSS| RFM_NSS <--
int.LED (D0) GPIO 16 | | GPIO 1 (D10) --> SCL | 0x77 | <-- MISO | |
<-- SCL (D1) GPIO 5 | | GPIO 3 (D9) GND | | --> SCK | |
RESET RST | | GPIO 15 (D8) RFM_NSS --> +------+ +-------+
<-> SDA (D2) GPIO 4 | | GPIO 13 (D7) MOSI --> BH1750 SH1106 OLED
(D3) GPIO 0 | | GPIO 12 (D6) MISO <-- +------+ +-------+
(D4) GPIO 2 | | GPIO 14 (D5) SCK --> +3.3V | 0x23 | +3.3V | 0x3C |
+------+ GND | or | GND | or |
--> SCL | 0x5C | --> SCL | 0x3D |
<-> SDA | | <-> SDA | |
+------+ +-------+
mapleMini
+--\/--+
<-- VCC 3.3V | | VCC 3.3V
<-- GND | | GND
BOOT0 | | VBAT
<-> SDA PB_7 | | PC_13
<-- SCL D10/PB_6 | | PC_14
PB_5 | | PC_15
PB_4 | | RESET
PB_3 | | PA_0
PA_15 | | PA_1
PA_14 | | PA_2
PA_13 | | PA_3
PA_12 | | PA_4/A2 NSS
PA_11 | | PA_5/D13 SCK
PA_10 | | PA_6/D12 MISO
PA_9 | | PA_7/D11 MOSI
PA_8 | | PB_0
PB_15 | | PB_2
PB_14 | | PB_10
PB_13 | | PB_11
PB_12 | | + 5V
+------+
PB_1 LED1
Hallo PeMue,
Zitat von: PeMue
habe mittlerweile mein nanoLGW mit der v2.2 aktualisiert:
[19598.00] P: 1006.7| T: 30.84| rH: 28.65| IAQ: 25.00 (0)| Gas: 18798.00| UBat: 3.7V[/code]
FHEM empfängt dieselben Werte:
2018-01-28 19:19:37 LaCrosse LaCrosse_6F gas1: 25
2018-01-28 19:19:37 LaCrosse LaCrosse_6F gas2: 18798
Das ist merkwürdig, habe heute mein 2. LGM auf die Platine gebracht und mit BME680 bestückt. Habe bei beiden LGM's jetzt auch so niedrige Gas Werte
(13 -15 kOhm, obwohl der eine Sensor vorher am Universalsensor "normale" Werte geliefert hat (zwischen 300 und 500 kOhm). Evtl. Timing Problem ?
Die Kurven sind aber im Vergleich zum Universalsensor ziemlich identisch.
Zitat
Edit 1:
Und den Sprung im Druck kann man sehr gut sehen: ursprünglich Berlin, dann 0 m und jetzt die Höhe, die für meinen Wohnort passt ;D Deckt sich jetzt auch mit den anderen Drucksensoren.
Ok, die Höhenkorrektur werde ich erstmal als Debug-Ausgabe mit einbauen ;)
ZitatUnd hier noch die mapleMini Hardware zu Einpflegen in den Code, noch ungetestet, aber geflasht:
Danke, hab sogar schon getestet, stimmt soweit, man kann die Pins direkt als "PA4" oder "PB6" im Quellcode verwenden, wird korrekt verarbeitet ;)
V2.2 läuft jetzt komplett auf der STM32 Hardware (BluePill hab ich), es gibt nur ein Problem bei mir, der RFM69 arbeitet soweit normal, es kommt aber nichts an den LGM's an :o
Heute sind über den Tag dann doch ganz sporadisch ca. 5 Werte angekommen, da weiß ich noch nicht so recht weiter. Hab schon einen zweiten RFM und mit weniger Sendeleistung,
wie Jürgen schon geschrieben hatte, probiert, keine Veränderung. Hab dann mit dem SPI Takt gespielt, der geht problemlos mit relativ sauberen Signalen bis ca. 2.5MHz, bin jetzt
bei etwa 285kHz, Soft-SPI macht ca. 400kHz, aber geht auch nicht besser oder schlechter. Na mal schauen ... :-[
Dann ist mir noch etwas sehr interessantes aufgefallen, hab mein altes SSD1306 Display vom Steckbrett-LGM einfach mal so an den Universalsensor gehangen, ohne
auf SSD1306 in der Adafruit Lib zurück zu stellen, es läuft :D
Das bedeutet, SH1106 und SSD1306 funktionieren ohne Änderung !
Gruß Thomas
Zur Info:
https://davidegironi.blogspot.de/2017/05/mq-gas-sensor-correlation-function.html (https://davidegironi.blogspot.de/2017/05/mq-gas-sensor-correlation-function.html)
Hallo Jürgen,
nochmal zur Adafruit Lib: das Problem, daß diese mit dem STM32 nicht funktioniert, liegt an dem zweiten Aufruf von Wire.begin() in der Adafruit Lib selbst.
Den hab ich dort für STM32 deaktiviert, damit läuft es ! Gleiches gilt für die BH1750.cpp ;)
Edit: In der RFMxx.cpp ist vor "SPI.begin()" folgendes für den SPI Clock eingestellt:
SPI.setClockDivider(SPI_BAUD_PCLK_DIV_128);
bedeutet: 72MHz / 128 = 562.5kHz
so läuft es seit heute Morgen :D
Gruß Thomas
Hallo Thomas,
danke für den Hinweis!
Ok, in der
setup()-Methode, nicht RFMxx.cpp:
#if(HAS_RFM_MODULE)
/* --- RFM69CW init --- */
SPI.begin();
rfm.Begin();
...
Mit welcher SPI-Speed läuft es dann eigentlich unter den Default-Einstellungen?
Möglicherweise zu schnell für einige, aber nicht alle RFMs?
Zitat... liegt an dem zweiten Aufruf von Wire.begin()
Bei mir geht es ja (eigentlich) aber gut zu wissen, woran es scheitern könnte.
War in der letzten Zeit mit dem Gehäuse zu stark beschäftigt.
Habe gerade noch mal eine LGW-Gateway mit der FW 1.31 aufgebaut, mein ältester Sensor mit alten Einstellungen wird
aus 1m Entfernung nicht empfanden, dort habe ich noch nicht den PA-Level gesetzt ...
Die anderen beiden aber sofort....
Bei einem Update auf FHEM kommt nicht die CustomSensor-Version, ist der UniveralSensor gesetzt?
Dann muss ich das noch aktualisieren.
Die Adafruit-Lib funktioniert bei mir auch auf dem Maple mit den vorher geschilderten (https://forum.fhem.de/index.php/topic,78619.msg757061.html#msg757061) Einstellungen ;)
Die ASCIISD1306-Lib aktualisiert das Display noch zu langsam, dort muss ich auch noch auf FAST :) umstellen ...
Aber sonst alles ok!
Dann fehlt nur noch ein Gehäuse für WemosD1mini und die STMs.
Langsam gehen mir die BME's aus ... Vielleicht werde ich doch mal eine Bestückung probieren ... (7€ bei 10er Abnahme + 0.80 Cent für die Platine)
Nachschub (http://www.watterott.com/de/BME680-Breakout) ist momentan rar, ähm ausverkauft ... :-X :'(
Dann klappt es ja schon richtig Klasse mit den STMs, Respekt! :D
Dann wäre das nächste Ziel: Batterie-Betrieb ?
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs
Ok, in der setup()-Methode, nicht RFMxx.cpp:
#if(HAS_RFM_MODULE)
/* --- RFM69CW init --- */
SPI.begin();
rfm.Begin();
...
In der Setup-Methode nicht "SPI.begin();", in der RFMxx.cpp, siehe V2.2 !
Zitat
Mit welcher SPI-Speed läuft es dann eigentlich unter den Default-Einstellungen?
Möglicherweise zu schnell für einige, aber nicht alle RFMs?
Bei mir geht es ja (eigentlich) aber gut zu wissen, woran es scheitern könnte.
Ich meine, es war Standard SPI_CLOCK_DIV16, also 4.5MHz.
Sollte der RFM69 ja auch locker können, laut Datenblatt bis 10MHz !
Zitat
Habe gerade noch mal eine LGW-Gateway mit der FW 1.31 aufgebaut, mein ältester Sensor mit alten Einstellungen wird
aus 1m Entfernung nicht empfanden, dort habe ich noch nicht den PA-Level gesetzt ...
Die anderen beiden aber sofort....
Das ist noch interessant, hab noch keine Versuche mit der Reichweite gemacht, wird spannend :-[
Zitat
Bei einem Update auf FHEM kommt nicht die CustomSensor-Version, ist der UniveralSensor gesetzt?
Dann muss ich das noch aktualisieren.
Stimmt, in den Updates ist nur Universalsensor implementiert, weil Du Dir das CustomSensor Modul sparst, bei dieser Variante ;)
Zitat
Langsam gehen mir die BME's aus ... Vielleicht werde ich doch mal eine Bestückung probieren ... (7€ bei 10er Abnahme + 0.80 Cent für die Platine)
Nachschub (http://www.watterott.com/de/BME680-Breakout) ist momentan rar, ähm ausverkauft ... :-X :'(
Meine drei Stück sind jetzt auch verbaut, mal schauen, wann es wieder welche gibt 8)
Zitat
Dann klappt es ja schon richtig Klasse mit den STMs, Respekt! :D
Ja, so langsam geht es voran :D
Zitat
Dann wäre das nächste Ziel: Batterie-Betrieb ?
Wäre natürlich genial, wie sieht es denn mit der Akkulaufzeit auf dem WEMOS Board aus, mußtest Du schon mal nachladen ?
Gruß Thomas
Kaum beschwert man sich über fehlenden Nachschub ... gibt es wieder :)
Alternatives STM-Sensor Board:
http://flabbergast.github.io/bat-board/ (http://flabbergast.github.io/bat-board/)
Ich habe mir bei den Chinesen dieses Board http://www.watterott.com/de/STM32F103C8T6-Minimum-System-Board bestellt, aber für 5 € in Deutschland auch ziemlich preiswert.
Gruß PeMue
Zitat von: PeMue
Ich habe mir bei den Chinesen dieses Board http://www.watterott.com/de/STM32F103C8T6-Minimum-System-Board bestellt, aber für 5 € in Deutschland auch ziemlich preiswert.
Das habe ich auch, ist das "BluePill". Zwei sind noch unterwegs ... ;)
Bin noch am arbeiten, wegen der Parameter Eingaben. Ist doch etwas aufwändiger als gedacht ... :o
Gruß Thomas
Hallo Thomas,
hier gibt es ein Menü, das meiner Meinung nach, sehr einfach zum seriellen Parametrieren benutzt werden kann:
https://playground.arduino.cc/Code/Menu (https://playground.arduino.cc/Code/Menu)
Menu#Download (https://playground.arduino.cc/Code/Menu#Download)
void loop()
{
if (Serial.available())
{
byte read = Serial.read();
switch (read)
{
case 'w': menu.moveUp(); break;
case 's': menu.moveDown(); break;
case 'd': menu.moveRight(); break;
case 'a': menu.moveLeft(); break;
case 'e': menu.use(); break;
}
}
}
Hallo Jürgen,
Zitat von: juergs
hier gibt es ein Menü, das meiner Meinung nach, sehr einfach zum seriellen Parametrieren benutzt werden kann ...
So ungefähr dachte ich auch, hab mal was zusammengebaut, ist noch nicht der endgültige Stand, aber geht erstmal ;)
Die erste Abfrage (Settings löschen) kommt bei jedem Start und hat einen 5 sek. Timeout, heißt, wenn man nichts eingibt, geht es nach 5 sek.
mit "N" weiter. Ist nur für den Fall, daß man später mal etwas ändern will.
Die Abfragen zu den Settings kommen normalerweise nur beim ersten Start, wenn im EEPROM alles "0xFF" ist.
Aber auch, wenn nur einer der Werte einem gelöschten EEPROM entspricht, dann wird nur der oder die noch nicht geänderten Werte abgefragt.
Diese Version (3.0) ist nur für STM32 ! Überlege noch, ob man das dann zusammenführt mit dem ESP8266 oder
beide Versionen für sich laufen sollten ?
Gruß Thomas
Anbei ein paar Bilder:
So, bin mal wieder ein ganzes Stück weiter gekommen. Version 3.0 ist online !
Ab sofort werden der ESP8266 UND der STM32F103Cx unterstützt.
Getestet habe ich mit einer NodeMCU V1.0 (ESP8266) und dem BluePill (STM32F103C8T6).
Zusätzlich werden jetzt die Settings (NodeID, Höhe über NN und Temperatur Offset) im EEPROM gespeichert.
Was noch nicht geht: VCC Messung beim STM32, steht im Moment konstant auf 3,3V , kommt aber demnächst.
Verfügbar ab sofort hier: https://github.com/amigatommy/BME680-UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor) :)
Gruß Thomas
Anbei 2 Bilder, einmal Start mit dem BluePill, dann noch der Start mit der NodeMCU ...
Zitat von: hdgucken am 18 Februar 2018, 01:19:14
Version 3.0 ist online !
Cool, vielen Dank dafür!
ZitatThe Lightsensor (BH1750) is also optional, it can but not must be connected.
Zitat... the RFM69CW must also not be connected, in this case, no wireless transmission is possible. The data where transmitted by the serial port only (115200 Baud).
Ui, man darf keinen Lichtsensor bzw. Display anschließen 8) 8) 8), ich glaube, das war so nicht gemeint.
Ich würde das so formulieren:
The Lightsensor (BH1750) is also optional, it can be but does not need to be connected.
... the RFM69CW is also optional, in this case, no wireless transmission is possible. In this case the values are transmitted only by serial port (115200 Baud).Ich muss mal heute Nachmittag schauen, wie ich die IDE umbauen muss, um die BSEC Bibliothek einzubinden. Vermutlich geht das ohne irgendwelche Umbauten.
Im übrigen habe ich gesehen, dass die Widerstandswerte wieder im 200-300 kOhm Bereich sind, welcher Bereich ist denn nun richtig?
Gruß PeMue
Hallo Peter,
Zitat von: PeMue
Ui, man darf keinen Lichtsensor bzw. Display anschließen 8) 8) 8), ich glaube, das war so nicht gemeint.
Oh je, ich sollte manchmal doch eher ins Bett gehen, was man nachts so für einen Mist zusammen schreibt ;D
Vielen Dank für den Hinweis jedenfalls, habe das gleich mal verbessert, ich hoffe, so ist es jetzt richtig zu verstehen ;)
Zitat
Ich muss mal heute Nachmittag schauen, wie ich die IDE umbauen muss, um die BSEC Bibliothek einzubinden. Vermutlich geht das ohne irgendwelche Umbauten.
Ich hab das in der Doku geschrieben, wie es bei mir funktioniert hat, ist eigentlich nicht weiter schlimm.
Zitat
Im übrigen habe ich gesehen, dass die Widerstandswerte wieder im 200-300 kOhm Bereich sind, welcher Bereich ist denn nun richtig?
Ich würde sagen, 200-300kOhm Bereich ist richtig, hab auch immer noch Probleme mit dem BME680 an meinem zweiten LGM. Hab an diesem ein
Nextion Display angeschlossen, jetzt ist das Phänomen, daß der Gas Wert nach einiger Zeit komplett einfriert (bei ca. 808kOhm!) und generell auch nur im zweistelligen KiloOhm Bereich
misst, die Kurve passt allerdings im Vergleich zum UniversalSensor.
So sieht es im Moment bei mir aus (Bilder) ...
Gruß Thomas
Hallo Thomas,
die Software läuft auf meinem nanoLGW, siehe
BME680 wireless sensor V3.0
Compiled: Sun Feb 18 14:21:12 2018
Protocol: UniversalSensor
BSEC version: 1.4.5.1
ESP Core Version: 2_4_0
ESP SDK Version: 2.1.0(deb1901)
OLED init ... not found
Node-ID is: 255 (0xFF)
Node-ID set to: 111 (0x6F)
Save permanently (Y/N)?
OK.
Altitude is: 65560.5m
new value (0.0-8848.9):
Altitude set to: 240.0m
Save permanently (Y/N)?
OK.
Temperature offset: -1.1 degrees celsius
new value (+-10.0):
Temperature offset set to: 0.0 degrees celsius
Save permanently (Y/N)?
OK.
Save settings ...
Node-ID : 111 (0x6F)
Altitude : 240.0m
Temperature offset: 0.0 degrees celsius
RFM69 init ... done
BME680 init ... done
BH1750 init ... not present
Ready, start measuring ...
[142299.00] P: 1026.6| T: 37.61| rH: 15.03| IAQ: 25.00 (0)| Gas: 33767.00| UBat: 3.7V
[445308.00] P: 1026.3| T: 33.34| rH: 18.32| IAQ: 20.21 (1)| Gas: 44664.00| UBat: 3.7V
[448308.00] P: 1026.4| T: 33.30| rH: 18.33| IAQ: 17.01 (1)| Gas: 44902.00| UBat: 3.7V
[451308.00] P: 1026.3| T: 33.28| rH: 18.34| IAQ: 16.64 (1)| Gas: 44950.00| UBat: 3.7V
[454308.00] P: 1026.3| T: 33.28| rH: 18.33| IAQ: 20.48 (1)| Gas: 44807.00| UBat: 3.7V
[457308.00] P: 1026.3| T: 33.24| rH: 18.36| IAQ: 20.50 (1)| Gas: 44902.00| UBat: 3.7V
Ein paar Anmerkungen von meiner Seite:
- Die RFM69xx Library fehlt in github.
- Meine Widerstandswerte sind und bleiben im 30-40 kOhm Bereich, auch mit der v2.2.
- Die Einstellungen müssen ohne CR/LF gemacht werden, sonst kapiert es die Software nicht.
- Beim maple Mini ist mir nicht klar, wie man so rechtzeitig auf die serielle Schnittstelle zugreift, dass man was ändern kann. Das liegt aber ggf. daran, dass ich noch keinen BME680 dran habe, da schaltet die interne LED auf hell ;D
Ich lass' den mal weiterrennen.
Gruß Peter
Edit:
Der Widerstand geht hoch in den 100k Bereich :o
2018-02-18_16:49:12 LaCrosse_6F gas1: 29
2018-02-18_16:49:12 LaCrosse_6F gas2: 117735
2018-02-18_16:54:12 LaCrosse_6F gas1: 24
2018-02-18_16:54:12 LaCrosse_6F gas2: 120606
2018-02-18_16:59:12 LaCrosse_6F gas1: 27
2018-02-18_16:59:12 LaCrosse_6F gas2: 121128
Hallo Peter,
Zitat von: PeMue
Ein paar Anmerkungen von meiner Seite:
- Die RFM69xx Library fehlt in github.
Die heißt nur RFMxx und ist mit im Sketch Ordner 8)
Zitat
Meine Widerstandswerte sind und bleiben im 30-40 kOhm Bereich, auch mit der v2.2.
Das ist schon merkwürdig, das hab ich bei mir noch nicht beobachtet.
Vielleicht pendelt sich das noch ein in den nächsten Tagen ...
Zitat
Die Einstellungen müssen ohne CR/LF gemacht werden, sonst kapiert es die Software nicht.
Beim maple Mini ist mir nicht klar, wie man so rechtzeitig auf die serielle Schnittstelle zugreift, dass man was ändern kann. Das liegt aber ggf. daran, dass ich noch keinen BME680 dran habe, da schaltet die interne LED auf hell ;D
Ich lass' den mal weiterrennen.
Das mit CR/LF ist natürlich ein kleines Problem, der eine hat's der andere nicht ;D Je nach verwendeter Terminalsoftware und deren Einstellungen.
Mit der Arduino IDE und Putty klappt das bei mir sehr gut. Wüßte da jetzt keine allgemeingültige Lösung.
Man hat 5 Sekunden Zeit, das Terminal zu öffnen, ist vielleicht etwas knapp, aber wenn ich da noch länger warte, denkt man ja, der Sensor funktioniert nicht, weil erstmal nichts passiert :o
Wäre aber kein Problem, einfach die Wartezeit nach belieben hochsetzen. Man könnte auch warten, bis sich die serielle Schnittstelle verbunden hat, aber dann hat man
wieder ein Problem: wenn man kein serielles Kabel anschließt, startet die Software nicht, ein Teufelskreis :(
Aber fürs erste ist es doch schon mal nicht schlecht, denke ich :)
Gruß Thomas
Ein neues Firmwarerelease:
BSEC_1.4.6.0_Generic_Release_20180323 (https://www.bosch-sensortec.com/bst/products/all_products/bsec)
soeben runtergeladen, schaue ich mir an ... Danke für den Hinweis !
Frohe Ostern an Alle !
Gruß Thomas
Hallo Jürgen, hallo Thomas,
ihr seid mir einfach zu schnell :o
Könntet Ihr bitte hier (https://forum.fhem.de/index.php/topic,51329.msg788819.html#msg788819) mal schauen, ob der BH1750 korrekt verdrahtet ist? Dann wäre das nämlich ein potentieller Kandidat für einen Universalsensor.
Euch allen noch schöne Ostern.
Gruß Peter
Hallo Peter,
Ich habe den Lichtsensor noch nicht eingesetzt, aber
Das hier (http://www.esp8266learning.com/bh1750fvi-ambient-light-sensor-example.php) scheint okay zu sein .
Schöne Restostern 8)
Jürgen
genau dieses Modul verwende ich auch ! Die verlinkte Schaltung funktioniert also 100% ;)
Gruß Thomas
Edit: die einfache Beschaltung (1kOhm, 1uF) sollte aber auch reichen, da kommt es dann nur auf eine schnell ansteigende (2,4V in max. 100us) Versorgungsspannung an.
Müßte man mal testen ...
Hallo Gemeinde,
den BME680 gibt es mittlerweile beim freundlich Ali ( http://s.click.aliexpress.com/e/qNfqByz ) auf einem Board.
Frage: Kann man den mit einem Wemos D1 mit einem Sleep-Modus beschalten, oder braucht der eine "Warm-Up-Phase". Also wie beispielsweise wie beim Feinstaubsensor einem MQ-7, bei dem ein paar Sekunden vor der Messung der Sensor erst mal erwärmt werden muss.
Ich habe vor, den Sensor mit einem Wemos D1 mit einer 18650 zu betreiben.
LG
/robin
Hallo Robin,
der Sensor braucht eine längere "Einbrennphase" von ca. 3-4 Tagen und während der Laufzeit einen kontinuierlichen Abfragezyklus .... (Aufheizung des Glühkörpers + BSEC-Algorithmus)
Von einem Betrieb mit DeepSleep halte ich persönlich nicht viel, heißt aber nicht, dass es unmöglich wäre. Der 18650 wäre eine gute Wahl ...
Müßte mal jemand ausprobieren (;-)
Glaube HCS hat diesen Modus auch schon verworfen ...
Das Board ist nicht schlecht, aber ähnlicher Preis wie bei Watte...
Grüße,
Jürgen
... nicht ganz das Topic, aber vielleicht von Interesse:
bsec_bme680_linux (https://github.com/alexh-name/bsec_bme680_linux)
Did anybody try compiling the basic.ino sketch from BSEC archive? I already tried the one from BSEC 1.4.6.0 but it doesn't compile (I'm using an STM32F103C8T6 board).
Would somebody kindly upload somewhere BSEC 1.4.5.1 zip file?
Thanks!
Hello kylix,
did you notice that you have to include the bsec-lib into your linker settings to compile successfully the original sketch?
The how-to I mentioned earlier in this thread.
Jürgen
Greetings from Big Apple 😎
Yes. In fact, the BME680 Universal Sensor sketch v3.0 works. I just need to compile the default basic.ino sketch. And this doesn't work. I'd like to try with version 1.4.5.1 .... who knows, maybe that compiles, but I don't have the full .zip archive.
From Bosch's website you can only download the latest version ... 1.4.6.0
Perhaps it will help meanwhile if you post the error outputs of your compile?
I have no error when compiling, so I suppose the library gets correctly linked. Though, in the Serial Monitor Window I see: BSEC library version 0.0.0.0; BME680 error code: -2
Hello kylix,
you must modify the original "bus_write" and "bus_read" function to get it work with the STM32F103C8T6 too:
bus_write:
from:
return (int8_t)Wire.endTransmission();
to:
#ifdef __STM32F1__
Wire.endTransmission();
return 0;
#else
return (int8_t)Wire.endTransmission();
#endif
bus_read:
from:
return comResult;
to:
#ifdef __STM32F1__
return 0;
#else
return comResult;
#endif
greetings Thomas
Hi Thomas,
the basic.ino sketch doesn't seem to use those 2 functions (I'll have to check bsec.h and bsec.cpp):
#include "bsec.h"
// Helper functions declarations
void checkIaqSensorStatus(void);
void errLeds(void);
// Create an object of the class Bsec
Bsec iaqSensor;
String output;
// Entry point for the example
void setup(void)
{
Serial.begin(115200);
iaqSensor.begin(BME680_I2C_ADDR_PRIMARY, Wire);
output = "\nBSEC library version " + String(iaqSensor.version.major) + "." + String(iaqSensor.version.minor) + "." + String(iaqSensor.version.major_bugfix) + "." + String(iaqSensor.version.minor_bugfix);
Serial.println(output);
checkIaqSensorStatus();
bsec_virtual_sensor_t sensorList[7] = {
BSEC_OUTPUT_RAW_TEMPERATURE,
BSEC_OUTPUT_RAW_PRESSURE,
BSEC_OUTPUT_RAW_HUMIDITY,
BSEC_OUTPUT_RAW_GAS,
BSEC_OUTPUT_IAQ_ESTIMATE,
BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_TEMPERATURE,
BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_HUMIDITY,
};
iaqSensor.updateSubscription(sensorList, 7, BSEC_SAMPLE_RATE_LP);
checkIaqSensorStatus();
// Print the header
output = "Timestamp [ms], raw temperature [°C], pressure [hPa], raw relative humidity [%], gas [Ohm], IAQ, IAQ accuracy, temperature [°C], relative humidity [%]";
Serial.println(output);
}
// Function that is looped forever
void loop(void)
{
if (iaqSensor.run()) { // If new data is available
output = String(millis());
output += ", " + String(iaqSensor.rawTemperature);
output += ", " + String(iaqSensor.pressure);
output += ", " + String(iaqSensor.rawHumidity);
output += ", " + String(iaqSensor.gasResistance);
output += ", " + String(iaqSensor.iaqEstimate);
output += ", " + String(iaqSensor.iaqAccuracy);
output += ", " + String(iaqSensor.temperature);
output += ", " + String(iaqSensor.humidity);
Serial.println(output);
} else {
checkIaqSensorStatus();
}
}
// Helper function definitions
void checkIaqSensorStatus(void)
{
if (iaqSensor.status != BSEC_OK) {
if (iaqSensor.status < BSEC_OK) {
output = "BSEC error code : " + String(iaqSensor.status);
Serial.println(output);
for (;;)
errLeds(); /* Halt in case of failure */
} else {
output = "BSEC warning code : " + String(iaqSensor.status);
Serial.println(output);
}
}
if (iaqSensor.bme680Status != BME680_OK) {
if (iaqSensor.bme680Status < BME680_OK) {
output = "BME680 error code : " + String(iaqSensor.bme680Status);
Serial.println(output);
for (;;)
errLeds(); /* Halt in case of failure */
} else {
output = "BME680 warning code : " + String(iaqSensor.bme680Status);
Serial.println(output);
}
}
}
void errLeds(void)
{
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, HIGH);
delay(100);
digitalWrite(LED_BUILTIN, LOW);
delay(100);
}
I think I found them in bsec.cpp, but they are different:
/**
@brief Callback function for reading registers over I2C
*/
int8_t Bsec::i2cRead(uint8_t devId, uint8_t regAddr, uint8_t *regData, uint16_t length)
{
uint16_t i;
int8_t rslt = 0;
if(Bsec::i2c_obj) {
Bsec::i2c_obj->beginTransmission(devId);
Bsec::i2c_obj->write(regAddr);
rslt = Bsec::i2c_obj->endTransmission();
Bsec::i2c_obj->requestFrom((int) devId, (int) length);
for (i = 0; (i < length) && Bsec::i2c_obj->available(); i++) {
regData[i] = Bsec::i2c_obj->read();
}
} else {
rslt = -1;
}
return rslt;
}
/**
* @brief Callback function for writing registers over I2C
*/
int8_t Bsec::i2cWrite(uint8_t devId, uint8_t regAddr, uint8_t *regData, uint16_t length)
{
uint16_t i;
int8_t rslt = 0;
if(Bsec::i2c_obj) {
Bsec::i2c_obj->beginTransmission(devId);
Bsec::i2c_obj->write(regAddr);
for (i = 0; i < length; i++) {
Bsec::i2c_obj->write(regData[i]);
}
rslt = Bsec::i2c_obj->endTransmission();
} else {
rslt = -1;
}
return rslt;
}
Ok, i meant "bsec_iot_example" in the folder "example" :)
Thats different.
greetings Thomas ;)
Hallo zusammen,
habe zufällig hier https://blog.jokielowie.com/en/2017/12/niedlugo-pomiar-jakosci-powietrza-bosch-bme680-oraz-ccs811-iaq-tvoc/ etwas interessantes über BME680 bzw. CCS811 gefunden.
Gruß PeMue
Hallo Peter,
die ePaper-Display-Idee finde ich gut.
Nach ca. 1 Jahr verabschiedet sich mein kleines OLED-Display
bei Dauerbetrieb langsam ...
Grüße,
Jürgen
Zitat von: juergs am 03 Oktober 2018, 11:13:48
... die ePaper-Display-Idee finde ich gut.
so etwas? Dann sollten wir aber einen neuen Thread dafür öffnen.
Gruß PeMue
Zitat von: PeMue am 03 Oktober 2018, 16:49:14
so etwas? Dann sollten wir aber einen neuen Thread dafür öffnen.
Gruß PeMue
Ja, muss aber erst noch bestellen ... ;)
Das OLED-Display ist wirklich so schlecht im Dauerbetrieb geworden ... :(
Wo gibt es den sketch mit dem OLED Display und der IAD - Anzeige?
Hallo fh168,
hier (https://github.com/juergs/BME680_cc_sensor_v1_5_V3_D1_WROOM_VS) und hdguckens aktuellerer Universal-Sensor-Sketch (https://github.com/amigatommy/BME680-UniversalSensor)
Jeweils mit spezifischer LGW-Version (bin leider noch auf "LaCrosseGateway V1.30") + fhem-Modul-Änderungen zu betreiben!
Vom Bosch müsste es auch schon wieder neue Versionen der BSEC (https://github.com/BoschSensortec/BSEC-Arduino-library)-Library geben ....
Würde aber eher noch den Sketch von hdgucken hier in diesem Thread nehmen,
da ich noch nicht auf die neue Version der LaCrosseGateway umgestellt habe.
Sobald PeMue mit dem Braten der LGW-Platine nachgezogen hat, baue ich meine Sketche ebenfalls um (Sorry..)
Die IAQ-Quer ist nur der gleitende Mittelwert des IAQ-Wertes, der steht etwas ruhiger ...
Grüße,
Jürgen
Hier zur Info noch eine andere Variante der Messung mit CO2-Sensor MH-Z14:
https://www.stall.biz/project/professioneller-co2-sensor-am-wohnzimmersensor-wiffi-wz (https://www.stall.biz/project/professioneller-co2-sensor-am-wohnzimmersensor-wiffi-wz)
http://www.doctormonk.com/2018/03/review-and-test-of-mh-z14a-ndir-co2.html (http://www.doctormonk.com/2018/03/review-and-test-of-mh-z14a-ndir-co2.html)
Die teure NDIR-Sensor-Variante (> 100€):
http://www.epluse.net/de/produkte/co2-messung/co2-sensor/ee894/ (http://www.epluse.net/de/produkte/co2-messung/co2-sensor/ee894/)
MH-Z19
http://www.guillier.org/blog/tag/air-quality.html (http://www.guillier.org/blog/tag/air-quality.html)
sieht sehr interessant aus :D
... und der Preis von 19$ scheint im Bereich des BME680 zu liegen ... ;)
BME680 für raspberry-i2c:
https://github.com/twartzek/bme680-raspberry (https://github.com/twartzek/bme680-raspberry)
http://www.ludwich.de/ludwich/Sensoren-TFLG.html (http://www.ludwich.de/ludwich/Sensoren-TFLG.html)
Zitat von: juergs am 04 Oktober 2018, 20:47:59
Sobald PeMue mit dem Braten der LGW-Platine nachgezogen hat, baue ich meine Sketche ebenfalls um (sorry ...)
hat er (https://forum.fhem.de/index.php?action=dlattach;topic=51329.0;attach=106682;image) ;) und die BME680 werden erkannt bzw. liefern Werte.
Gruß Peter
Hallo Peter,
die Sensor-Platine hat sich nach der Bestückung etwas zickig angestellt.
Habe aber auch eine etwas "eigenwilligen" Aufbau gewählt:
Da die FTDI232 noch nicht da waren, habe ich mich mit einem Serial-Adapter beholfen.
Dann war zu klären wie das mit dem RTS-Signal zu handeln ist, wenn der Adapter dieses nicht nach außen geführt hat...
Den Flash-Vorgang habe ich dann versucht, mit 2 Tastern zu "simulieren", was aber auf Anhieb nicht funktionierte.
Dann habe ich mich auf die Fehlersuche begeben:
Beim Antippen des CH-PD-Pins mit der Oszi-Spitze leuchtete die Reset-LED kurz auf.
Dann habe ich den CH_PD-Eingang kurzerhand mit 3V3Volt verbunden -> Programmieren geht!
Um die Frage zu beantworten wie das mit der ID und mehreren Sensoren geht (seriell, mit 115.200 KBaud, 8N1):
(COM6) Compiled: Fri Dec 07 17:57:22 2018
(COM6) Protocol: UniversalSensor
(COM6) BSEC version: 1.4.5.1<LF>ESP Core Version: 2_4_0_RC1
(COM6) ESP SDK Version: 2.0.0(656edbf)
(COM6)
(COM6) Do you want to delete settings in EEPROM (Y/N)?
(COM6) Not deleted.
(COM6)
(COM6) Node-ID is: 255 (0xFF)
(COM6) New value (1-254):
(COM6) sl<NUL>lœž|<NUL>Œ#<STX>ân<EOT><EOT><FF>Œ<EOT>$ì<FF>#|ƒ<STX>ä<ESC>"r²Ü>Œ<EOT>bŒòonŸ$nnœâì<FF>b<FS>pì#$ <ETX>{lpûnà<DLE><STX><FF><EOT>,<FF>l<EOT>ŒÜ<EOT><EOT><FF>b<EOT>oã|<STX>dì<EOT><EOT>p<FF>,,ûnNî<STX>lŒŽd`<STX><ESC><DC2>on<FF>$`<STX><SI><STX>o{Û'o<FF><FF>b<EOT>Ü<SI>l<SO>{›'o<FF><EOT>b<FF>Ü<SO>lÜãâ<FF>Ü<FS>ŽŒŒœpr$ü,oÜ<STX><Error: RX FRAMING ERROR><Error: RX FRAMING ERROR><Error: RX FRAMING ERROR><ESC>{,²Üî<STX><FF><DC3/XOFF>b<ESC>"olœ|Œûn|p<FF>$ž|<ESC><STX><EOT>nàŽ,<ETX>ä<ESC>ã'ƒ<ETX><EOT><ESC>b<DC2>Ûo`{l<Error: RX FRAMING ERROR>
(COM6) BME680 wireless sensor V3.0
(COM6) Compiled: Fri Dec 07 17:57:22 2018
(COM6) Protocol: UniversalSensor
(COM6) BSEC version: 1.4.5.1<LF>ESP Core Version: 2_4_0_RC1
(COM6) ESP SDK Version: 2.0.0(656edbf)
(COM6)
(COM6) Do you want to delete settings in EEPROM (Y/N)?
(COM6) Y
(COM6) Settings deleted.
(COM6)
(COM6) Node-ID is: 255 (0xFF)
(COM6) New value (1-254):
(COM6) 112
(COM6) Node-ID set to: 112 (0x70)
(COM6) Save permanently (Y/N)?
(COM6) OK.
(COM6) RFM69 init ... done
(COM6) BME680 init ... done
(COM6) BH1750 init ... done
(COM6) Ready, start measuring ...
(COM6)
(COM6) [63321.00] P: 994.3| T: 38.24| rH: 18.11| IAQ: 25.00 (0)| Gas: 1184.00| Light: 15.42lx
(COM6) [66321.00] P: 994.2| T: 38.28| rH: 18.00| IAQ: 25.00 (0)| Gas: 1443.00| Light: 15.42lx
(COM6) [69321.00] P: 994.3| T: 38.32| rH: 17.88| IAQ: 25.00 (0)| Gas: 2019.00| Light: 15.42lx
(COM6) [72321.00] P: 994.3| T: 38.33| rH: 17.83| IAQ: 25.00 (0)| Gas: 2560.00| Light: 15.42lx
(COM6) [75321.00] P: 994.3| T: 38.35| rH: 17.77| IAQ: 25.00 (0)| Gas: 3147.00| Light: 15.42lx
(COM6) [78321.00] P: 994.3| T: 38.33| rH: 17.77| IAQ: 25.00 (0)| Gas: 3593.00| Light: 15.42lx
Versuche, das auf der Sensor-HW/Platine noch herauszufinden woran das liegt/lag ...
...und ob die LGW damit zurecht kommt. ;-)
Grüße,
Jürgen
Hallo Jürgen,
so wie es aussieht funktioniert der BH1750 dann auch. Klasse!
Gruß Peter
Zitat von: PeMue am 09 Dezember 2018, 18:36:20
Hallo Jürgen,
so wie es aussieht funktioniert der BH1750 dann auch. Klasse!
Gruß Peter
... und reagiert auch auf Licht 8):
(COM6) [9318468.00] P: 997.7| T: 36.86| rH: 18.86| IAQ: 176.24 (1)| Gas: 119326.00| Light: 4.53lx
(COM6) [9321468.00] P: 997.7| T: 36.86| rH: 18.86| IAQ: 176.13 (1)| Gas: 119412.00| Light: 4.53lx
(COM6) [9324468.00] P: 997.8| T: 36.85| rH: 18.86| IAQ: 182.48 (1)| Gas: 118898.00| Light: 4.53lx
(COM6) [9327468.00] P: 997.7| T: 36.88| rH: 18.83| IAQ: 172.83 (1)| Gas: 119758.00| Light: 4.30lx
(COM6) [9330468.00] P: 997.7| T: 36.85| rH: 18.87| IAQ: 169.13 (1)| Gas: 120280.00| Light: 4.30lx
(COM6) [9333468.00] P: 997.8| T: 36.77| rH: 18.92| IAQ: 186.66 (1)| Gas: 119069.00| Light: 17.92lx
(COM6) [9336468.00] P: 997.7| T: 36.83| rH: 18.89| IAQ: 175.83 (1)| Gas: 119585.00| Light: 18.33lx
(COM6) [9339468.00] P: 997.7| T: 36.85| rH: 18.89| IAQ: 176.95 (1)| Gas: 119240.00| Light: 19.17lx
(COM6) [9342468.00] P: 997.7| T: 36.88| rH: 18.85| IAQ: 178.00 (1)| Gas: 119069.00| Light: 19.58lx
Zitat von: juergs am 09 Dezember 2018, 19:29:31
... und reagiert auch auf Licht 8):
Jupp, zwischen Straßenlampe und Wohnzimmer (https://de.wikipedia.org/wiki/Beleuchtungsst%C3%A4rke), Du solltest mal Deine Beleuchtung überprüfen 8) 8) 8).
Gruß Peter
;D ;D
lol, war noch am Reagieren ...
Apropos Licht....
... sehr gute (Positionier-) Arbeit! :D
Mittlerweile hat sich einiges in der CO2-Szene getan:
Robin hat hier seine Variante mit MQTT-Anbindung präsentiert:
https://blog.moneybag.de/fhem-air-qualitysensor-bme-680-temperatur-luftfeuchte-luftdruck-ueber-mqtt-getestet/
Neue Hardware mit günstigeren Preisen:
Typ1 mit STM32 (https://de.aliexpress.com/item/GY-MCU680V1-BME680-Temperatur-und-Feuchtigkeit-Luftdruck-Indoor-Air-Qualit-t-IAQ-MCU680-Sensor-Modul/32905797241.html?spm=a2g0x.search0104.3.9.4adc589dyMo1W4&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=fbb6ba02-2374-4ee6-a223-cba6035fcf7b&algo_expid=fbb6ba02-2374-4ee6-a223-cba6035fcf7b-1)
Typ2 nur Sensor (https://de.aliexpress.com/item/BME680-Digitale-Temperatur-Feuchtigkeit-Temperatur-Druck-Hohe-H-he-Sensor-Modul-Digitale-4-in-1-Gas/32867056032.html?spm=a2g0x.search0104.3.23.4adc589dyMo1W4&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=fbb6ba02-2374-4ee6-a223-cba6035fcf7b&algo_expid=fbb6ba02-2374-4ee6-a223-cba6035fcf7b-3)
Typ1 verwendet diesen Controller:
https://www.st.com/en/microcontrollers/stm32f051k8.html (https://www.st.com/en/microcontrollers/stm32f051k8.html)
Hallo Zusammen,
ich versuche hier den Sketch bei mir zum Laufen zu überreden, leider ziemlich erfolglos.
Die fertigkompilierte bin kann ich aufspielen und der Sensor läuft auch, nur bekomme ich ihn nicht in FHEM eingebunden.
Es sind wohl auch die Daten am LacrosseGateway angekommen, nur konnte FHEM nichts damit anfangen:
2018.12.22 18:02:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 52 0 0 0 21 35 112 , help me!
2018.12.22 18:03:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 72 0 0 0 21 6 144 , help me!
2018.12.22 18:04:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 41 0 0 0 21 40 96 , help me!
2018.12.22 18:05:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 39 0 0 0 21 41 96 , help me!
2018.12.22 18:06:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 48 0 0 0 21 37 112 , help me!
2018.12.22 18:07:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 55 0 0 0 21 21 112 , help me!
2018.12.22 18:08:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 48 0 0 0 21 40 96 , help me!
2018.12.22 18:09:21 3: myLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 50 0 0 0 21 37 112 , help me!
Den CustomSensor habe ich auch angelegt:
Internals:
DEF 06
ID 06
NAME BME680_CS_06
NR 1328
STATE Initialized
TYPE CustomSensor
corrH 0
corrT 0
Attributes:
Kompiliere ich den Sketch selbst, startet der Sensor, fragt einiges an Daten ab und meldet anschließend "BME680 init ... Error while initializing BSEC library !"
Wo habe ich den Fehler im Sketch und wie bekomme ich den Sensor im FHEM zum laufen?
BME680 wireless sensor V3.0
Compiled: Sun Dec 23 01:47:57 2018
Protocol: UniversalSensor
BSEC version: 1.4.7.1
ESP Core Version: 2_4_1
ESP SDK Version: 2.2.1(cfd48f3)
OLED init ... not found
Do you want to delete settings in EEPROM (Y/N)?
Not deleted.
Settings from EEPROM:
Node-ID : 222 (0xDE)
Altitude : 66.0m
Temperature offset: 0.0 degrees celsius
RFM69 init ... done
BME680 init ... Error while initializing BSEC library !
Hallo Alex,
Zitat von: Nighthawk am 22 Dezember 2018, 18:58:45
Die fertigkompilierte bin kann ich aufspielen und der Sensor läuft auch, nur bekomme ich ihn nicht in FHEM eingebunden. Es sind wohl auch die Daten am LacrosseGateway angekommen, nur konnte FHEM nichts damit anfangen:
schau mal hier (https://forum.fhem.de/index.php/topic,43672.msg870076/topicseen.html#msg870076), das sollte Dein Problem lösen.
Zitat von: Nighthawk am 22 Dezember 2018, 18:58:45
Den CustomSensor habe ich auch angelegt:
Das sollte FHEM per autocreate erledigen. Bitte vorher löschen.
Zitat von: Nighthawk am 22 Dezember 2018, 18:58:45
Kompiliere ich den Sketch selbst, startet der Sensor, fragt einiges an Daten ab und meldet anschließend "BME680 init ... Error while initializing BSEC library !"
Welche BSEC library hast Du eingebunden? Wie hast Du das gemacht? Ich hab's mal Anfang des Jahres gemacht, muss mal schauen, was ich damals aufgeschrieben habe. Aus diesem Grund bevorzuge ich die fertigen Binaries.
Gruß Peter
Hallo Peter,
danke, probiere ich gleich mal aus.
Die BSEC Library habe ich nahc dieser Anleitung eingebunden:
https://github.com/BoschSensortec/BSEC-Arduino-library (https://github.com/BoschSensortec/BSEC-Arduino-library)
das hat mir beim Kompilieren Fehler geschmissen.
Danach habe ich es eingebunden wie hier beschrieben:
https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/ (https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/)
Darauf kamen keine Fehler mehr und der Sketch wurde kompiliert und auf das Wemos D1 übertragen, nur leider funktioniert es so nicht.
Gruß
Alex
Hallo Alex,
Zitat von: Nighthawk am 22 Dezember 2018, 19:30:39
Danach habe ich es eingebunden wie hier beschrieben:
https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/ (https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/)
Darauf kamen keine Fehler mehr und der Sketch wurde kompiliert und auf das Wemos D1 übertragen, nur leider funktioniert es so nicht.
das funktioniert nur für die v1.4.5.1 von letztem Jahr. In der neueren v1.4.7.1 gibt es eine Anleitung dazu (habe ich noch nicht ausprobiert), man muss den Linker aktualisieren. hdgucken hat meine ich noch mit der v1.4.5.1 compiliert.
Gruß Peter
Leider hat es mit dem "ignore_battery" nicht funktioniert, es wird kein Device angelegt.
Die v1.4.5.1 habe ich leider auch nicht gefunden.
ZitatmyLaCrosseGateway: Unknown code OK CC 6 6 25 43 16 4 0 39 0 0 0 21 41 96 , help me!
Es gibt 2 Varianten der BME680-Sensor-Firmware. Die etwas ältere Variante "CustomSensor", die einige Code-Änderungen in FHEM bedarf und eine neuere von hdgucken die über das "UniversalSensor"-Protokoll läuft.
Die CustomSensor-Variante liefert obiges Fehlerbild, wenn keinen Code-Anpassungen in FHEM gemacht wurden.
Offensichtlich hast Du da irgendwie beide Varianten vermischt.
Ich benutze jetzt diese Version aus dem GIT-Repo von Thomas (hdgucken):UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor) zusammen mit der Version: LaCrosseGateway V1.32 (noch in zwei verschiedenen fhem-Instanzen).
Damit sollte obiges Problem behoben sein.
Um ein Device davon in FHEM anzulegen habe ich die Zeit für das Pairing (https://forum.fhem.de/index.php/topic,43672.msg870076.html#msg870076) auf 300 Sek erhöht um zumindest im Sendeinterval zu liegen.
Ich habe dazu auch die neueste "LaCrosseITPlusReader"-Firmware für die LaCrosseGateway V1.32 aus fhem 5.9 verwendet.
UniversalSensor:a.) der interne BME680 der LGW (LaCrosseGateway V1.32, liefert nicht IAQ, sondern nur GAS1):
ZitatInternals:
DEF 76
IODev LGW
LASTInputDev LGW
LGW_MSGCNT 2417
LGW_TIME 2018-12-22 22:57:21
LaCrosse_lastRcv 2018-12-22 22:57:21
MSGCNT 2417
NAME LaCrosse_76
NR 99
STATE T: 29.2 H: 30
TYPE LaCrosse
addr 76
battery_new 0
bufferedH 30
bufferedT 29.2
corr1 0
corr2 0
previousH 30
previousT 29.2
sensorType 4=LaCrosseGateway
READINGS:
2018-12-22 22:57:21 battery ok
2018-12-22 22:57:21 error 0
2018-12-22 22:57:21 gas1 37666
2018-12-22 22:57:21 gas2 0
2018-12-22 22:57:21 humidity 30
2018-12-22 22:57:21 pressure 1031
2018-12-22 22:57:21 state T: 29.2 H: 30
2018-12-22 22:57:21 temperature 29.2
Attributes:
IODev LGW
room LaCrosse
Der externe (Universal-)Sensor:
ZitatInternals:
DEF 70
IODev LGW
NAME LaCrosse_70
NR 103
STATE T: 34.5 H: 19
TYPE LaCrosse
addr 70
corr1 0
corr2 0
READINGS:
2018-12-10 20:59:49 battery ok
2018-12-10 20:59:49 error 0
2018-12-10 20:59:49 gas1 25
2018-12-10 20:59:49 gas2 89585
2018-12-10 20:59:49 humidity 19
2018-12-10 20:59:49 lux 4
2018-12-10 20:59:49 pressure 1010.3
2018-12-10 20:59:49 state T: 34.5 H: 19
2018-12-10 20:59:49 temperature 34.5
2018-12-10 20:59:49 version 3
2018-12-10 20:59:49 voltage 24.6
Attributes:
IODev LGW
room LaCrosse
CustomSensor (extern, deprecated, bei mir noch mit LaCrosseGateway V1.30):ZitatInternals:
CustomSensor_lastRcv 2018-12-22 22:54:00
DEF 06
ID 06
LASTInputDev LGW
LGW_MSGCNT 45
LGW_TIME 2018-12-22 22:54:00
MSGCNT 31
NAME bme680_cc
NR 101
STATE 19.1 °C, 57 %, 1010 hPa
TYPE CustomSensor
corrH 0
corrT 0
READINGS:
2018-12-22 22:54:00 battery 8
2018-12-22 22:54:00 gas 809010
2018-12-22 22:54:00 gas-kohm 809.1
2018-12-22 22:54:00 humidity 57
2018-12-22 22:54:00 iaq 226
2018-12-22 22:54:00 lux 0
2018-12-22 22:54:00 pressure 1010
2018-12-22 22:54:00 state T: 19.1 H: 57
2018-12-22 22:54:00 temperature 19.1
Attributes:
event-min-interval .*:1800
event-on-change-reading .*
icon cul_wlan
room CO2-Messung,CustomSensor,LaCrosse
stateFormat temperature °C, humidity %, pressure hPa
userReadings gas-kohm { sprintf( "%.1f", ReadingsVal( $NAME,"gas",0 ) / 1000 + 0.05 ) }
verbose 3
liefert bei mir in der LaCrosseGateway V1.32-FHEM-Instanz auch diesen Output:
Zitat2018.12.22 23:28:00 3: LGW: Unknown code OK CC 6 5 147 58 16 17 2 67 0 0 80 117 128 32 , help me!
Benutze auber auch noch nicht für meine Sketche die neuste BSEC-Variante, bin aber mit den Ergebnissen sehr zufrieden,
nachts steigen die CO2-Werte relativ hoch an und gehen tagsüber nach Lüften wieder auf bessere Werte zurück.
BME680 wireless sensor V3.0
Compiled: Fri Dec 07 17:57:22 2018
Protocol: UniversalSensor
BSEC version: 1.4.5.1
ESP Core Version: 2_4_0_RC1
ESP SDK Version: 2.0.0(656edbf)
Do you want to delete settings in EEPROM (Y/N)?
Not deleted.
Settings from EEPROM:
Node-ID : 201 (0xC9)
Altitude : 180.0m
Temperature offset: 0.0 degrees celsius
Grüße,
Jürgen
Änderungen in hdguckens für den nanoLGW-code mit bme680:
... IDE hat bei mir trotz "false" gemosert:
#define HAS_RFM69 true //is auto detected, if not found, sensor works without RFM69, data only on serial port
#define HAS_OLED false //is auto detected, if not found, sensor works without OLED (SH1106 or SSD1306)
#define HAS_LIGHTSENSOR false //is auto detected, if not found, sensor works without BH1750
#define VCC_MEASURE false //if not needed, you can disable it here
#define SOFT_SPI false //if you need SOFT-SPI, set true
#define DEBUG false //activate debug mode
void dim_display (byte brightness)
{
#if HAS_OLED
display.ssd1306_command(SSD1306_SETCONTRAST);
display.ssd1306_command(brightness);
#endif
}
Einbindung hier: https://forum.fhem.de/index.php/topic,78619.msg706765.html#msg706765 (https://forum.fhem.de/index.php/topic,78619.msg706765.html#msg706765)
Zitatwhere the board support package for our board is installed. On Windows, this could be for example in <USER -
_HOME>\AppData\Local\Arduino15\packages\esp8266\hardware or in <ARDUINO_ROOT>\hardware. Once we
found the location, we need to perform the following steps. Please keep in mind that the target paths might differ
slightly depending on the ESP8266 package version you are using.
1. We need to copy the file binaries\staticlib\ESP8266\libalgobsec.a from the BSEC package into the
hardware\esp8266\2.3.0\tools\sdk\lib folder.
2. The linker file found at hardware\esp8266\2.3.0\tools\sdk\ld\eagle.app.v6.common.ld needs to be modifed
by inserting the line
*.cpp.o(.literal*, .text*)
*libc.a:(.literal .text .literal.* .text.*)
*libm.a:(.literal .text .literal.* .text.*)
*libalgobsec.a:(.literal .text .literal.* .text.*)
*libgcc.a:_umoddi3.o(.literal .text)
*libgcc.a:_udivdi3.o(.literal .text)
libalgobsec.a:(.literal .text .literal. .text.) after the line libm.a -
3. Finally, we need to change the linker argument, telling the linker to include BSEC. This is achieved by adding the
argument -lalgobsec to the line compiler.c.elf.libs=-lm -lgcc ... found in
hardware\esp8266\2.3. -0\platform.txt.
Beim Compilieren muss dann der Linker das Flag: -lalgobsec anzeigen:
Linking everything together...
"C:\Users\juergs\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-gcc"
-g -Os -nostdlib -Wl,--no-check-sections -u call_user_start -u _printf_float -u _scanf_float -Wl,
-static "-LC:\Users\juergs\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1/tools/sdk/lib"
"-LC:\Users\juergs\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1/tools/sdk/ld"
"-LC:\Users\juergs\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1/tools/sdk/libc/xtensa-lx106-elf/lib"
"-Teagle.flash.4m.ld" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read
-o "C:\Users\juergs\AppData\Local\Temp\arduino_build_548430/BME680_UniversalSensor.ino.elf" -Wl,
--start-group "C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\bme680.c.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\bsec_integration.c.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\BME680_UniversalSensor.ino.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\HandleEeprom.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\RFMxx.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\SensorBase.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\sketch\UniversalSensor.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\libraries\Wire\Wire.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\libraries\EEPROM\EEPROM.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430\libraries\SPI\SPI.cpp.o"
"C:\Users\juergs\AppData\Local\Temp\arduino_build_548430/arduino.ar"
-lhal -lphy -lpp -lnet80211 -llwip_gcc -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lmesh -lwpa2 -lstdc++ -lm -lc -lgcc
-lalgobsec
-Wl,--end-group "-LC:\Users\juergs\AppData\Local\Temp\arduino_build_548430"
Erfahrungen zur nanoLGW-Platine V1.5 mit BME680+BH1750:
https://forum.fhem.de/index.php/topic,51329.msg876501.html#msg876501 (https://forum.fhem.de/index.php/topic,51329.msg876501.html#msg876501)
Aus meinen Tests mit pemue's
nanoLGW-Platine hier die etwas geänderte UniversalSensor- Code (Dank @hdgucken!):
BME680_LaCrosse_UniversalSensor (https://github.com/juergs/BME680_LaCrosse_UniversalSensor)
Mit BME680 + Lichtsensor bh1750, ohne OLED.
Die LED an GPIO16 wird nicht angesteuert, sondern die des ESP-Moduls. Der WiFi-Teil des ESPs ist abgeschalten.
[5698320.00] P: 1044.5| T: 25.83| rH: 28.66| IAQ: 43.88 (1)| Gas: 106717.00| Light: 286.25lxOffiziell:
1020,5 hPa (1037 bezogen auf NN)Im Gegensatz zu den Readings des CustomSensors (plausibler):
battery 8
2018-12-25 18:37:37 gas 0
2018-12-25 18:37:37 gas-kohm 0.1
2018-12-25 18:37:37 humidity 47
2018-12-25 18:36:37 iaq 102
2018-12-25 18:37:37 lux 0
2018-12-25 18:37:37 pressure 1023
2018-12-25 18:36:37 state T: 19.9 H: 47
2018-12-25 18:37:37 temperature 19.9
/edit: Der Sensor braucht einige Tage (Bosch:4) Dauerbetrieb!
Parametrierung: SensorID, Temperatur-Offset und Meereshöhe mittels Arduino integriertem Serial Monitor (Shift+CTRL M).
Der unten angefügte Code bezieht sich auf die nanoLGW-Platine V1.5 von hier (https://forum.fhem.de/index.php/topic,51329.msg875976.html#msg875976),
lässt sich aber auch 1:1 auf einen Wemos D1 mini oder mit einem ESP8266-F-Modul betreiben ...
Schaltplan nanoLGW V1.5 (https://forum.fhem.de/index.php?action=dlattach;topic=51329.0;attach=99273)
ZitatBSEC 1.4.7.1 (v1.4.7.1 | Sept. 18th, 2018)
• New outputs added (see bsec_datatypes.h)
• Simulate data sets from multiple sensors using 1 BSEC instance, e.g. on a cloud server (see chapter 2.8 in the SW integration guide)
• Added Arduino library to log BME680 data without the need of BSEC (bme680_data)
• Enable an ODR of 1/3 s for Temperature, Pressure, Humidity while IAQ is in ULP (example: basic_config_state_ULP_LP)
BSEC 1.4.6.0
• New ULP+ feature for additional measurements on demand,
• Improved behavior on dynamic changes in LP mode,
• BSEC lite version with reduced memory requirements included,
• size of state string defined, size of config string reduced,
• Option to (temporarily) disable baseline tracker for special applications,
• Documentation & code improvements.
BSEC 1.4.5.1
• Improved humidity compensation,
• Improved accuracy status,
• Additional config strings included,
• Fixed accuracy / IAQ value after initialization,
• Code optimization.
Musste also für die letzte Version (https://www.bosch-sensortec.com/bst/products/all_products/bsec) nur die
libalgobsec.a ersetzen. :D
RF der nanoLGW-RFM-Settings.
@Nighthawk
Zitat von: Nighthawk am 22 Dezember 2018, 20:23:48
Leider hat es mit dem "ignore_battery" nicht funktioniert, es wird kein Device angelegt.
Die v1.4.5.1 habe ich leider auch nicht gefunden.
Du musst die Dateien aus meinem Git Repository: https://github.com/amigatommy/BME680-UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor) verwenden, das ist der Stand mit V1.5.4.1.
Ich habe einige Änderungen in den originalen Dateien gemacht !
Zum Beispiel die "bsec_integration.c" -> um die Erkennung der I2C Adresse des BME680 zu automatisieren.
Auch die BH1750 und die Adafruit Libs sind leicht modifiziert, was ebenfalls die automatische Erkennung der I2C-Adresse
und bei der Adafruit Lib zusätzlich die Unterstützung für SH1106 Displays betrifft.
Habe die neue BSEC Soft V1.4.7.1 schon eingebunden, inkl. einiger Änderungen von Jürgen ;).
Compilieren geht schon, muß nur noch auf der Hardware getestet werden, will ich heute noch machen und dann auf Git Hub hochladen, sage hier bescheid, wenn es soweit ist ;o)
Es gibt neue Readings in dieser Version, sieht man dann auf der seriellen :D
Das sind: static_iaq , co2_equivalent und breath_voc_equivalent.
Hänge hier noch eine Doku zur Integration der BSEC Soft und der geänderten Dateien an, Stand V1.5.4.1:
P.S.: In der Doku hat sich ein kleiner Fehler eingeschlichen: Der BH1750 Lib Ordner muss "AS_BH1750" und nicht "AS_BH1750-master" !!!
Hallo Zusammen,
dank Peter habe ich es mit der bsec 1.4.5 zum Laufen bekommen, vielen Dank für die Unterstützung!
Hallo Thomas,
bei der Luftfeuchte scheinen die Werte noch nicht ganz zu stimmen (im Vergleich zu einem echten LaCrosseSensor).
Sowohl bei der nanoLGW-Platine, also auch in der LGW Firmware?
Die Werte sind viel zu niedrig.
LaCrosse_25 ist ein richtiger LaCrosse-Sensor: LaCrosse_25 T: 20.7 H: 41
bme680_cc CustomSensor mit geändertem fhem-Code an LGW V1.30: bme680_cc 21.5 °C, 40 %, 1017 hPa
LaCrosse_76 ist der BME 680 der LaCrosseGateway V1.32 LaCrosse_76 T: 29 H: 23
LaCrosse_10 UniversalSensor_1 (nanoLGW) LaCrosse_10 T: 25.1 H: 27
LaCrosse_0C UniversalSensor_2 (nanoLGW) LaCrosse_0C T: 28.7 H: 24
Grüße,
Jürgen
Hallo Jürgen,
bei mir sind die Feuchtewerte auch nicht 100% stimmig, habe mir aber darüber noch keine weiteren Gedanken gemacht :o
So in etwa passt es aber:
Universalsensor mit STM32 - 46% (mit BSEC V1.4.7.1 8))
LaCrosseGateway Nr.1 - 40%
LaCrosseGateway Nr.2 - 41%
Gruß Thomas
P.S. Die neue V3.1 des Universalsensors ist online: https://github.com/amigatommy/BME680-UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor) ;)
Hallo Thomas,
ich habe hier x Temperatur + Luftfeuchte-Sensoren im Einsatz.
In einem beheizten Raum scheinen mir die 40% sehr plausibel,
aber 25% scheint mir eher sehr daneben zu liegen ...
Ich vergleiche mal den CC-Sensor mit dem Universalsensor-Code um evtl. Unterschiede zu finden.
ZitatDie neue V3.1 des Universalsensors ist online
Schön, dann kann ich die schon mal in Augenschein nehmen.
Der neuere ULP-Modus scheint ja auch für Batterie-betriebene Geräte gedacht zu sein.
Durch den ESP8266 kann man das aber nicht unbedingt nachverfolgen.
Der CO2 Wert verlangt ja eigentlich auch nach einer Anzeige (Nextion/ePaper).
Ich habe mir neuere Sensor-Breakouts bestellt, die einen STM32 auf dem Board beinhalten.
Da bin ich mal gespannt. :D
Grüße,
Jürgen
Zum Luftfeuchte-Problem:
https://github.com/BoschSensortec/BME680_driver/issues/51 (https://github.com/BoschSensortec/BME680_driver/issues/51)
/*!
* @brief This internal API is used to calculate the humidity value.
*/
static uint32_t calc_humidity(uint16_t hum_adc, const struct bme680_dev *dev)
{
int32_t var1;
int32_t var2;
int32_t var3;
int32_t var4;
int32_t var5;
int32_t var6;
int32_t temp_scaled;
int32_t calc_hum;
temp_scaled = (((int32_t) dev->calib.t_fine * 5) + 128) >> 8;
var1 = (int32_t) (hum_adc - ((int32_t) ((int32_t) dev->calib.par_h1 * 16)))
- (((temp_scaled * (int32_t) dev->calib.par_h3) / ((int32_t) 100)) >> 1);
var2 = ((int32_t) dev->calib.par_h2
* (((temp_scaled * (int32_t) dev->calib.par_h4) / ((int32_t) 100))
+ (((temp_scaled * ((temp_scaled * (int32_t) dev->calib.par_h5) / ((int32_t) 100))) >> 6)
/ ((int32_t) 100)) + (int32_t) (1 << 14))) >> 10;
var3 = var1 * var2;
var4 = (int32_t) dev->calib.par_h6 << 7;
var4 = ((var4) + ((temp_scaled * (int32_t) dev->calib.par_h7) / ((int32_t) 100))) >> 4;
var5 = ((var3 >> 14) * (var3 >> 14)) >> 10;
var6 = (var4 * var5) >> 1;
calc_hum = (((var3 + var6) >> 10) * ((int32_t) 1000)) >> 12;
if (calc_hum > 100000) /* Cap at 100%rH */
calc_hum = 100000;
else if (calc_hum < 0)
calc_hum = 0;
return (uint32_t) calc_hum;
}OK, eine Herausforderung zum Reengineering ... :( :o
Vermute, dass die Erfassung mit dem BME280 vergleichbar ist.
Also erst noch etwas forschen...
PS: Die BME680 mit STM32F051k8-Sensoren (https://de.aliexpress.com/item/GY-MCU680V1-BME680-Temperatur-und-Feuchtigkeit-Luftdruck-Indoor-Air-Qualit-t-IAQ-MCU680-Sensor-Modul/32905797241.html?spm=a2g0x.search0104.3.2.21a861c1tzC5SF&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=9c0468c9-27a7-4cb6-bd36-295dcd541f54&algo_expid=9c0468c9-27a7-4cb6-bd36-295dcd541f54-0) sind heute gekommen ... :D
ZitatThis module has two ways to read data, namely serial port (TTL level) or chip itself IIC communication mode.
The product has high precision and high stability. It is possible to directly output utility data and omit the algorithm.
The baud rate of the serial port is 9600bps and 115200bps. There are two modes of continuous output and interrogation output, which can adapt to different working environments.
Connect to all microcontrollers and computers
When soldering the PS solder joint, the module is in the chip's own IIC mode, at which point the MCU does not participate in the operation and does not consume current. Can be used as a simple BME680 module.
Zitat von: juergs
... In einem beheizten Raum scheinen mir die 40% sehr plausibel,
aber 25% scheint mir eher sehr daneben zu liegen ...
Da gebe ich dir recht ...
Zitat
... Ich vergleiche mal den CC-Sensor mit dem Universalsensor-Code um evtl. Unterschiede zu finden.
Humidity wird nicht weiter umgerechnet, kommt direkt aus der Bosch lib als "float humidity".
Die Berechnung des humidity Wertes in der Bosch Lib ist schon spannend ... ;D
Ein kleines Display wäre auch schön, mal schauen 8)
Gruß
Thomas
Hallo Jürgen,
coole Teile, ist aber eine andere ARM Architektur als der Maple-mini oder Bluepill (STM32F051),
muss man schauen, ob es mit der Arduino IDE machbar ist.
Was mir gerade noch einfällt, Du hattest mal geschrieben, das Dein OLED Display mit der Zeit sehr schlecht geworden ist.
Hab mal ein Bild von meinem angehängt, läuft jetzt seit November 2017 (mit Dimmung, wenn dunkel). Kein einbrennen zu erkennen :)
Hab heute noch eine feinere Abstufung beim Display dimmen in der V3.1 eingefügt.
Gruß Thomas
Zitatmuss man schauen, ob es mit der Arduino IDE machbar ist
Ja sehe ich auch so, falls es nicht direkt gehen sollte kann man den ByPass per Lötbrücke aktivieren.
Für das Modul konnte ich bisher keine Beschreibung ausmachen.
Es kann laut Angaben 9600 und 115K Baud.
Im Moment bekomme ich nur über 9600 Baud zyklisch Ausgaben des Moduls zu sehen.
Das Datenformat ist aber unklar und nicht Ascii. Habe dazu der Vertreiber kontaktiert, vieleicht
ist er in der Lage die Doku dazu nachzuliefern ... :o :( >:(
Na ja, dann doch ByPass und ESP ;D ... oder umprogrammieren (http://www.farrellf.com/projects/hardware/2014-06-14_Complete_STM32F0_Development_Environment/).
Vielleicht trenne ich auch nach der ersten Stiftleiste die Platine ab, dann ist
der BME ggf. auch noch 1 Euro billiger als bei Re***lt ... ;D
Zum OLED-Display, macht es Sinn es Nachts herunterzudimmen (lichtempf. Widerstand),
hatte es auf 100% Helligkeit eingstellt und es so gelassen. Habe noch einige Exemplare über,
so das der Nachschub gesichert ist. ;-)
Vieleicht reicht es mir noch, mein ePaper-Display zu aktivieren bzw. erst mal einzuarbeiten ...
Dann wäre das Einbrenn-Problem auch vom Tisch ;)
By the way: in der LGW gibt es ja die Display-Optionen um Messwerte in einem Loop Seitenweise anzuzeigen.
Dort funktioniert der Display-Refresh ohne Flackern. Evt. wäre das auch noch eine Idee hier mit umzusetzen. ;)
Jürgen
/edit: Angehängt der ES8266-Sketch QY_
MCUBME680_Interface_V2.ino für die Plotterausgabe der Arduino-IDE.
Ein erster Erfolg, es sei denn man kann chinesisch ???
https://github.com/op0xA5/GYMCU680/blob/master/main.go
.. bietet wenigstens einige Hinweise auf das Protokoll-Format des GY-MCU680V1.
Oder in Thailand:
https://www.mcucity.com/product/2315/4-in-1-bme680-i2c-stm32-uart-temperature-humidity-pressure-and-gas-sensor (https://www.mcucity.com/product/2315/4-in-1-bme680-i2c-stm32-uart-temperature-humidity-pressure-and-gas-sensor)
//GY_MCU680 air quality sensor ARDUINO
#include SoftwareSerial mySerial(4, 5);
uint16_t temp1=0;
int16_t temp2=0;
unsigned char Re_buf[30],counter=0;
unsigned char sign=0;
int led = 13;
void setup()
{
Serial.begin(9600);
mySerial.begin(9600);
mySerial.listen();
delay(4000);
mySerial.write(0XA5);
mySerial.write(0X55);
mySerial.write(0X3F);
mySerial.write(0X39);
delay(100);
mySerial.write(0XA5);
mySerial.write(0X56);
mySerial.write(0X02);
mySerial.write(0XFD);
delay(100);
}
void loop(){
float Temperature ,Humidity;
unsigned char i=0,sum=0;
uint32_t Gas;
uint32_t Pressure;
uint16_t IAQ;
int16_t Altitude;
uint8_t IAQ_accuracy;
while (mySerial.available()) {
Re_buf[counter]=(unsigned char)mySerial.read();
if(counter==0&&Re_buf[0]!=0x5A) return;
if(counter==1&&Re_buf[1]!=0x5A)
{
counter=0;
return;
};
counter++;
if(counter==20)
{
counter=0;
sign=1;
}
}
if(sign)
{
sign=0;
if(Re_buf[0]==0x5A&&Re_buf[1]==0x5A )
{
for(i=0;i<19;i++)
sum+=Re_buf[i];
if(sum==Re_buf[i] )
{
temp2=(Re_buf[4]<<8|Re_buf[5]);
Temperature=(float)temp2/100;
temp1=(Re_buf[6]<<8|Re_buf[7]);
Humidity=(float)temp1/100;
Pressure=((uint32_t)Re_buf[8]<<16)|((uint16_t)Re_buf[9]<<8)|Re_buf[10];
IAQ_accuracy= (Re_buf[11]&0xf0)>>4;
IAQ=((Re_buf[11]&0x0F)<<8)|Re_buf[12];
Gas=((uint32_t)Re_buf[13]<<24)|((uint32_t)Re_buf[14]<<16)|((uint16_t)Re_buf[15]<<8)|Re_buf[16];
Altitude=(Re_buf[17]<<8)|Re_buf[18];
Serial.print("Temperature:");
Serial.print(Temperature);
Serial.print(" ,Humidity:");
Serial.print(Humidity);
Serial.print(" ,Pressure:");
Serial.print(Pressure);
Serial.print(" ,IAQ:");
Serial.print(IAQ);
Serial.print(" ,Gas:");
Serial.print(Gas );
Serial.print(" ,Altitude:");
Serial.print(Altitude);
Serial.print(" ,IAQ_accuracy:");
Serial.println(IAQ_accuracy);
}
delay(1000);
}
}
}*
Der Output passt auch noch nicht so ganz (lässt sich mit dem GO-Programm evtl. korrigieren):
Temperature:22.50 ,Humidity:39.96 ,Pressure:101894 ,IAQ:25 ,Gas:38277 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.50 ,Humidity:39.95 ,Pressure:101894 ,IAQ:25 ,Gas:38992 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.51 ,Humidity:39.93 ,Pressure:101894 ,IAQ:25 ,Gas:39734 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.47 ,Humidity:39.99 ,Pressure:101896 ,IAQ:25 ,Gas:40426 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.46 ,Humidity:39.99 ,Pressure:101896 ,IAQ:25 ,Gas:41062 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.44 ,Humidity:39.99 ,Pressure:101896 ,IAQ:25 ,Gas:41761 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.45 ,Humidity:39.97 ,Pressure:101898 ,IAQ:25 ,Gas:42140 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.43 ,Humidity:39.98 ,Pressure:101898 ,IAQ:25 ,Gas:42875 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.42 ,Humidity:39.95 ,Pressure:101898 ,IAQ:25 ,Gas:43546 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.43 ,Humidity:39.92 ,Pressure:101898 ,IAQ:25 ,Gas:44005 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.43 ,Humidity:39.93 ,Pressure:101898 ,IAQ:25 ,Gas:44473 ,Altitude:-47 ,IAQ_accuracy:0
Temperature:22.44 ,Humidity:39.92 ,Pressure:101896 ,IAQ:25 ,Gas:45244 ,Altitude:-47 ,IAQ_accuracy:0
Es gibt wohl auch eine Windows-Anwendung dazu. Aber nur für den chinesisch Sprachbegabten. ;):-\
Was wohl der Parametrier-Teil mit "A5 56 01 FC" bewirkt?
Temperature:21.50 ,Humidity:42.33 ,Pressure:1017 ,IAQ:244 ,Gas:84681 ,Altitude:-36 ,IAQ_accuracy:3
Sieht doch schon ganz verwertbar aus. :D
Nachts ist der IAQ-Wert in der Tat so hoch!
Alternative für die IAQ-Berechnung aus dem Resistance-Wert:
https://github.com/pimoroni/bme680-python/blob/master/examples/indoor-air-quality.py (https://github.com/pimoroni/bme680-python/blob/master/examples/indoor-air-quality.py)
https://learn.pimoroni.com/tutorial/sandyj/getting-started-with-bme680-breakout (https://learn.pimoroni.com/tutorial/sandyj/getting-started-with-bme680-breakout)
Der Lieferant hat schnell reagiert, leider in chinesisch ... Translator sei Dank!
Die Einstell-Möglichkeiten des GY-MCUBME680-Moduls mit serieller Ausgabe, übersetzt:
Byte3 des Telegramms ist noch etwas unklar "formuliert". 0x0F sendet das volle Datenpaket mit 20 Bytes.
float Temperature ,Humidity;
uint32_t Gas;
uint32_t Pressure;
uint16_t IAQ;
int16_t Altitude=0;
uint8_t IAQ_accuracy;
uint16_t temp1=0;
int16_t temp2=0;
Zitat von: hdgucken am 29 Dezember 2018, 00:37:11
P.S. Die neue V3.1 des Universalsensors ist online: https://github.com/amigatommy/BME680-UniversalSensor (https://github.com/amigatommy/BME680-UniversalSensor) ;)
Würdest du bitte die binäre Firmware-Datei für STM32F103Cx zur Verfügung stellen?
Vielen Dank im Voraus!
Hallo Locutus,
ist noch ein bisschen Nacharbeit erforderlich:
D:\Work_FHEM\Projects\_BME680\BME680-UniversalSensor-3.1-BSEC V1.4.7.1\BME680_UniversalSensor\BME680_UniversalSensor.ino: In function 'void setup()':
BME680_UniversalSensor:702: error: 'class TwoWire' has no member named 'setClock'
Wire.setClock(400000);
Spezielle Konfiguration(en)?
Die Konfiguration ist mit allen Optionen auf true.
Debug= false.
Laut Thomas soll es Auto-Detect-fähig sein.
Generic STMF103C-series - Variante
C8 (20K Ram/ 64KFlash) . Es gibt auch noch die
CB-Variante mit 128K Flash.
Falls Du eine andere Variante benötigst, Bescheid sagen ;)
Zitat#define HAS_RFM69 true //is auto detected, if not found, sensor works without RFM69, data only on serial port
#define HAS_OLED true //is auto detected, if not found, sensor works without OLED (SH1106 or SSD1306)
#define HAS_LIGHTSENSOR true //is auto detected, if not found, sensor works without BH1750
#define VCC_MEASURE true //if not needed, you can disable it here
#define SOFT_SPI false //if you need SOFT-SPI, set true
#define DEBUG false //activate debug mode
Zitat#elif defined(__STM32F1__)
#define RFM_SS PA4 // SS pin -> RFM69 (NSS) //for both Soft- and HW-SPI
#define RFM_SCK PA5 // SCK pin -> RFM69 (SCK) //only used by soft spi
#define RFM_MISO PA6 //MISO pin <- RFM69 (MOSI) //only used by soft spi
#define RFM_MOSI PA7 //MOSI pin -> RFM69 (MISO) //only used by soft spi
Aber Achtung: Thomas hat die Variante
CB vorgegeben:
ZitatIn der Arduino IDE als Board "Generic STM32F103C series" wählen und als Variante "STM32F103CB (20k RAM, 128k Flash)" !
Sonst reicht der Speicher nicht ;o)
Die Boards haben in den allermeisten Fällen 128K Flash Speicher, obwohl die C8 Boards offiziell nur 64k Flash haben sollten.
Grüße,
Jürgen
Die Debug-enbled Variante macht etwas mehr Ärger:
Zitat
c:\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple\libmaple\usb\stm32f1\usb_cdcacm.c:65:2: warning: #warning USB CDC ACM relies on LeafLabs board-specific configuration. You may have problems on non-LeafLabs boards. [-Wcpp]
#warning USB CDC ACM relies on LeafLabs board-specific configuration.\
und es hagelt
Zitat.. /bsec_integration.c:193: warning: undefined reference to `bsec_init'
/bsec_integration.c:203: warning: undefined reference to `bsec_set_configuration'
etc ...
Äh, ja is klar: habe die neue BSEC-LIB für ARM noch nicht angepasst ! :-\ :-[
Muss ich noch nachholen...
Die precompiled Lib ist etwas versteckt, es gibt noch eine ARM_CC-Variante + und Bosch hat es immer noch nicht geschafft die ARM-Konfiguration in den Guide mit aufzunehmen:
Zitat
BSEC_1.4.7.1_Generic_Release_20180907\BSEC_1.4.7.1_Generic_Release_20180907\algo\bin\Normal_version\gcc\Cortex_M3\libalgobsec.a
An dieser Stelle noch mal die Hinweis-Infos von Thomas:
https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=111504 (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=111504)
und generell:
https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/ (https://wolfgangklenk.wordpress.com/2017/11/05/indoor-air-quality-iaq-measurement-with-bosch-bme680-and-stm32f103c8t6/)
Zitat von: locutus
Würdest du bitte die binäre Firmware-Datei für STM32F103Cx zur Verfügung stellen?
Vielen Dank im Voraus!
klar, im Anhang einmal mit debug und einmal normal ohne debug Ausgabe.
Die angeschlossenen Komponenten werden automatisch erkannt und eingebunden.
Ohne RFM69 nur Ausgabe über USB seriell, BME680 ist Mindestvoraussetzung ;o)
Beim ersten Start innerhalb von 5 Sekunden das serielle Terminal öffnen,
dann kann man den Sensor konfigurieren (115200Baud,8N1).
Viel Erfolg und guten Rutsch !
@juergs:
Du mußt das Board STM32F103CB(20k Ram, 128k Flash) einstellen, sonst bricht der Compiler ab mit "zu wenig Speicher" !
ansonsten bei mir nur etliche Warnungen (nichts schlimmes), aber keine Fehler.
Arduino 1.8.7, BSEC 1.4.7.1
Viel Erfolg und guten Rutsch !
Gruß Thomas
P.S.: die angehängten Dateien sind für BluePill und baugleiche Boards mit onBoard LED an PC13 !
Ich hatte die BSEC-LIB nur in der Maple-Variante hinterlegt:
ZitatC:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\maple_mini\ld
Aber es gibt ja mehr:
ZitatVerzeichnis von C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants
13.06.2017 01:39 <DIR> .
13.06.2017 01:39 <DIR> ..
13.06.2017 01:39 <DIR> generic_gd32f103c
13.06.2017 01:39 <DIR> generic_stm32f103c
13.06.2017 01:39 <DIR> generic_stm32f103r
13.06.2017 01:39 <DIR> generic_stm32f103r8
13.06.2017 01:39 <DIR> generic_stm32f103t
13.06.2017 01:39 <DIR> generic_stm32f103v
13.06.2017 01:39 <DIR> generic_stm32f103z
13.06.2017 01:39 <DIR> hytiny_stm32f103t
13.06.2017 01:39 <DIR> maple
13.06.2017 01:39 <DIR> maple_mini
13.06.2017 01:39 <DIR> maple_ret6
13.06.2017 01:39 <DIR> microduino
13.06.2017 01:39 <DIR> nucleo_f103rb
13.06.2017 01:39 <DIR> STM32VLD
Ok, dort in den ld-Verzeichnissen überall die neue
libalgosec.a hinterlegen und die
common.inc ändern.
Dann probiere ich es wieder ... morgen.
Allen einen guten Rutsch ins neue Jahr ;) :)
Grüße,
Jürgen
Hallo Thomas,
super, warst schneller...
Danke für die Mithilfe ;) :)
Grüße + und ebenfalls einen guten Rutsch!
Jürgen
Hallo Jürgen,
kein Problem ;o)
Das Protokoll von dem China Sensor ist ja gar nicht mal so schlecht, läßt sich was draus machen,
könnte man dann ohne bsec Gefummel verwenden 8)
Errechnet er sich die Höhe aus dem Luftdruck eigentlich selbst ? Sieht für mich jedenfalls so aus.
Bis denn ...
Hallo Thomas,
Zitatkönnte man dann ohne bsec Gefummel verwenden
ja, rel. wenig Aufwand und mit einem Nano und RFM69 oder CC1101 sogar recht einfach.
Der BME680 lässt sicht einfach abtrennen und lässt sich dann über BSEC betreiben.
Ein Batteriebetrieb mit 5 mA ist wohl eher für einen begrenzten Zeitraum möglich.
Es sei denn, man verwirklicht den ULP (Ultra Low Power) Modus mit der BSEC-Lite Variante.
Zitat
Configuration Supply voltage of BM -
E680
Maximum time between
bsec_sensor_control()
calls
Time considered for background calibration:
generic_33v_300s_28d 3.3V 300s 28 days
generic_33v_300s_4d 3.3V 300s 4 days
generic_33v_3s_28d 3.3V 3s 28 days
generic_33v_3s_4d 3.3V 3s 4 days
generic_18v_300s_28d 1.8V 300s 28 days
generic_18v_300s_4d 1.8V 300s 4 days
generic_18v_3s_28d 1.8V 3s 28 days
generic_18v_3s_4d 1.8V 3s 4 days
The default configuration (after calling bsec_init), to which BSEC will be configured, is "generic_18v_300s_4d".
ZitatYou will notice that we now get IAQ, temperature and humidity data once every 3 seconds. This is because the
example code is pre-configured to use what is called low-power (LP) mode.
For certain applications, we may want to reduce the power consumption (and data rate) and use ultra-low-power
mode. Since it only takes around 0.08 mA current on average, this mode is ideal for long-term battery powered
operation. But let's see if we can change the code to lower the data rate.
Ich schaue mir mal das Octopus-Demo genauer an .. Wie vermutet läuft der Sketch nicht out-of-the-box und brauch jede Menge
Puzzle-Arbeit.
Grüße,
Jürgen
Hallo Jürgen,
für ULP-Mode mußt Du nur im Setup statt " ret = bsec_iot_init(BSEC_SAMPLE_RATE_LP, ... " -> " ret = bsec_iot_init(BSEC_SAMPLE_RATE_ULP, ... " angeben,
schon läuft der Sensor im ULP-Mode, hab ich schon mal getestet ;)
Gruß Thomas
Zitat von: hdgucken am 31 Dezember 2018, 18:47:54
Die angeschlossenen Komponenten werden automatisch erkannt und eingebunden.
Ohne RFM69 nur Ausgabe über USB seriell, BME680 ist Mindestvoraussetzung ;o)
Beim ersten Start innerhalb von 5 Sekunden das serielle Terminal öffnen,
dann kann man den Sensor konfigurieren (115200Baud,8N1).
Ich stehe auf dem Schlauch! Maple Mini (ohne RFM69) mit
sudo dfu-util -d 1eaf:0003 -a 2 -D Universalsensor_stm32f103c_normal.bin –Rgeflasht, OLED zeigt ***SETUP*** an, USB ist aber inaktiv und nun die Frage: wie die Konfiguration durchführen? Serieller Adapter am RX1 und TX1 führt auch nicht zum Erfolg.
Hallo locutus,
Zitat von: locutus
Ich stehe auf dem Schlauch! Maple Mini (ohne RFM69) mit
sudo dfu-util -d 1eaf:0003 -a 2 -D Universalsensor_stm32f103c_normal.bin –R
geflasht, OLED zeigt ***SETUP*** an, USB ist aber inaktiv und nun die Frage: wie die Konfiguration durchführen? Serieller Adapter am RX1 und TX1 führt auch nicht zum Erfolg.
Für den maple mini muß anders compiliert werden, anbei die maple mini Versionen ;)
Die Version STM32F103C ist für z.B. BluePill Boards, mit onBoard LED an Pin PC13.
Gruß Thomas
ZitatBluePill F103C8 (Basic support, no USB)
MapleMini F103CB (Basic support, no USB)
Nucleo F103RB
einstieg_mikrocontroller_stm32f103 (http://joe-c.de/pages/posts/einstieg_mikrocontroller_stm32f103_101.php)
Für den STM32F031 (https://www.st.com/en/evaluation-tools/stm32f0discovery.html)
hier die Arduino-Integrations-Möglichkeit: https://github.com/stm32duino/wiki/wiki/Add-a-new-variant-(board) (https://github.com/stm32duino/wiki/wiki/Add-a-new-variant-(board))
Deshalb hatte ich ja auch nach der Konfiguration gefragt!
Ohne RFM war jetzt noch direkt getestet ;)
Habe nur den MapleMini als Testsystem. Mein Compile bleibt wirklich bei "**** Setup ****" stehen,
obwohl ich den RFM69 angeschlossen habe. Die Serielle gibt nichts aus.
Muss noch mal mit meiner Maple-Version vergleichen.
STOP! Kommando zurück!Wird "Setup" angezeigt möchte er die serielle Konfiguration anwerfen (6 Sekunden Wartezeit) :
... und tut dies auch.
In einem Terminal-Progamm läuft der Eprom-Teil rel. schnell durch.
Besser zu empfehlen die Arduino-IDE, deren serieller Monitor reagiert auf die EEprom-Konfiguration mit Handshake besser.
Das hier ist mit RFM:
Zitat
BME680 wireless sensor V3.1
Compiled: Wed Jan 02 07:42:22 2019
Protocol: UniversalSensor
BSEC Version: 1.4.7.1
OLED init ... found on 0x3C
Do you want to delete settings in EEPROM (Y/N)?
Settings deleted.
Node-ID is: 255 (0xFF)
New value (1-254):
Node-ID set to: 12 (0x0C)
Save permanently (Y/N)?
new value (1-254):
Node-ID set to: 14 (0x0E)
Save permanently (Y/N)?
OK.
Altitude is: 65560.5m
new value (0.0-8848.9):
Altitude set to: 0.0m
Save permanently (Y/N)?
OK.
Temperature offset: -1.1 degrees celsius
new value (+-10.0):
Temperature offset set to: 0.0 degrees celsius
Save permanently (Y/N)?
new value (+-10.0):
Temperature offset set to: 0.0 degrees celsius
Save permanently (Y/N)?
OK.
Save settings ...
Node-ID : 14 (0x0E)
Altitude : 0.0m
Temperature offset: 0.0 degrees celsius
RFM69 init ... done
BME680 init ... done
BH1750 init ... not present
Ready, start measuring ...
[58092.00] P: 1018.5| T: 18.61| rH: 44.80| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 34134.00| UBat: 3.3V
[61092.00] P: 1018.5| T: 18.62| rH: 44.86| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 30935.00| UBat: 3.3V
[64092.00] P: 1018.5| T: 18.66| rH: 44.82| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 34931.00| UBat: 3.3V
[67092.00] P: 1018.5| T: 18.69| rH: 44.74| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 39582.00| UBat: 3.3V
Grüße,
Jürgen
Ohne RFM69 geht es ebenfalls, als reiner Standalone-Sensor:
(Allerdings unter Win10 geflasht!)
Zitatmaple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1671
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
error resetting after download: usb_reset: could not reset device, win error: Das System kann die angegebene Datei nicht finden.
Done!
Resetting USB to switch back to runtime mode
BME680 wireless sensor V3.1
Compiled: Wed Jan 02 07:42:22 2019
Protocol: UniversalSensor
BSEC Version: 1.4.7.1
OLED init ... found on 0x3C
Do you want to delete settings in EEPROM (Y/N)?
Settings deleted.
Node-ID is: 255 (0xFF)
New value (1-254):
Node-ID set to: 14 (0x0E)
Save permanently (Y/N)?
OK.
Altitude is: 65560.5m
new value (0.0-8848.9):
Altitude set to: 180.0m
Save permanently (Y/N)?
OK.
Temperature offset: -1.1 degrees celsius
new value (+-10.0):
Temperature offset set to: 0.0 degrees celsius
Save permanently (Y/N)?
OK.
Save settings ...
Node-ID : 14 (0x0E)
Altitude : 180.0m
Temperature offset: 0.0 degrees celsius
RFM69 not found, no wireless transmission !
BME680 init ... done
BH1750 init ... not present
Ready, start measuring ...
[47292.00] P: 1040.6| T: 19.82| rH: 45.39| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 133786.00| UBat: 3.3V
[50292.00] P: 1040.6| T: 19.80| rH: 45.39| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 140756.00| UBat: 3.3V
[53292.00] P: 1040.6| T: 19.84| rH: 45.22| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 149554.00| UBat: 3.3V
[56292.00] P: 1040.6| T: 19.88| rH: 45.05| IAQ: 25.00 (0)| Static IAQ: 25.00| CO2e: 0.00| bVOC: 0.00
| Gas: 156104.00| UBat: 3.3V
Kleiner Schönheitsfehler: in der Daueranzeige fehlt der IAQ-Wert ;) :(
... der nach einer gewissen Initialisierungszeit mit
"Luftgüte: berechne.." dann doch angezeigt wird. :) :D
Der Sensor geht ja nach einem Reset/Einschalten von einem anfänglichen IAQ-Wert 25, kurze Zeit auf 0, um dann richtige Werte auszugeben.
Hallo Jürgen,
hast Dir ja was vorgenommen, mit dem STM32F05 ;)
Werde das auch mal in Angriff nehmen, nur leider wenig Zeit.
Wenn "*** SETUP ***" im Display steht, dann läuft das Setup im seriellen Terminal, war als Hinweis gedacht :)
Die 6 Sekunden Wartezeit hab ich gleich am Anfang, also nach dem Einschalten des Sensors drin, damit man Zeit hat, das serielle Terminal zu öffnen.
Vielleicht sollte ich die LED in der Zeit blinken lassen, damit man sieht, das sich was tut ?
Bei "*** SETUP ***" könnte man ja noch "see serial terminal..." drunter schreiben, ist dann vielleicht eindeutiger ?
Gruß Thomas
Hallo Thomas,
... alles gut. Funktioniert ja alles so wie es soll. :D :)
Die Use-Cases ohne RFM etc. waren ja speziell von mir ja gar nicht vorgesehen und damit auch nicht getestet.
Umso besser, dass es auch so funktioniert.
Das mit dem STM32F05x war nur so eine Idee. Der Prozessor (und auch die Boards dazu) ist ja noch billiger als der F103.
Ob das aber Sinn macht, sei dahingestellt ... ;)
Ich wollte nur die Möglichkeit in Betracht ziehen da noch andere STM32-Familienmitglieder in Arduino mit einbinden zu können.
Die könnte z.B. auch ein STM8-Typ sein (kein BSEC), da gibt es schon eine Lösung, die den ATtiny8x ersetzen könnte.
Momentan versuche ich auch mit ein paar herumliegenden ST7735-LCD-TFT-Displays eine ansprechende Standalone (https://create.arduino.cc/projecthub/edr1924/gorgy-meteo-clock-1bfc49)-Lösung
hinzubekommen. Das bietet etwas mehr Möglichkeiten wie das OLED-Display.
Also vor der Stufe zum Nextion- und ePaper-Display, die ich auch noch hier liegen habe.
Leider ist der Faktor Zeit, wie immer etwas begrenzt ;)
Nachdem ich derzeit mit länger mit dem ESP aktiv war, ist der Refresh mit den STMs aber auch für mich hilfreich. :-[ ;D
Falls Locutus etwas mit dem BME680 planen sollte: Wichtig darauf zu achten, eine thermische Isolation
zu den Wärme-erzeugenden Komponenten hinzubekommen. Auf der NanoLGW und der Gateway-Platine werden die Temperaturwerte
doch sehr verfälscht (bei mir 6..8°C zu hoch) und die Auswirkungen auf den BSEC-Algorithmus wird nicht von der Hand zu weisen sein.
Genauso die Anordnung im oder am Gehäuse wäre auch noch ein Aspekt, den es zu berücksichtigen gilt.
Ich sehe eine Lösung mit einer Stiftleiste z.B. im 1mm-Raster hier sinnvoll, um den Sensor dann passend abgetrennt platzieren zu können.
Bei mir verhält sich das Maple-Board so, dass direkt nach dem Einstecken in die USB-Buchse, der Bootloader in einem Zeitfenster aktiv ist
und DFU-UTIL findet das Board. Danach ist die Serielle Schnittstelle aktiv.
Unter Windows ist dieses Tool (https://helmpcb.com/software/serial-port-monitor) sehr hilfreich,
da es den Aufbau der Seriellen in der Taskleiste anzeigt. Vor allem, wenn man viele Serielle im Einsatz hat... ;D ;D
Vielleicht gibt es auch unter Linux etwas Vergleichbares ?
Ich habe mir noch ein paar weitere Sensoren bestellt, um dann eine 3-dimensionale Auflösung hinzubekommen und herauszufinden
wie sich das CO2 im Raum bzw. dann auch in der Wohnung verteilt... Also ein Sensor am Boden plus einen in 1m + 2m Höhe.
Ich würde gerne dem Phänomen auf die Schliche kommen, warum die Werte nachts so hoch ansteigen ...
Grüße,
Jürgen
PS: Locutus: /var/log/messages ?
Bei mir sind die IAQ Werte Nachts auch so hoch, wäre mal interessant, das mit den unterschiedlichen Höhen zu erfassen.
Siehe Anhang ...
Vielleicht könnte man eine abgespeckte Version des Universalsensors direkt für das kleine STM32F05 Board entwickeln,
da es ja nur 64K Flash hat.
Mein BluePill verhält sich mit dem Bootloader genau so, erst DFU-Mode und nach ein paar Sekunden schaltet es auf USB seriell um.
Gruß Thomas
Hallo Thomas,
vieleicht ist das hier auch was für Dich:
https://randomnerdtutorials.com/serialdebug-library-arduino-ide/ (https://randomnerdtutorials.com/serialdebug-library-arduino-ide/)
https://www.youtube.com/watch?v=ba_eu06mkng (https://www.youtube.com/watch?v=ba_eu06mkng)
Der Verlauf 2er Sensoren und der entsprechende GAS-Output.
Sehr plausible Werte. Ein Verdacht habe ich schon, woher der hohe Anteil in der Nacht kommen könnte. ;)
Siehe vorher| nachher.
Leider sind die grafischen Auswerte-Möglichkeiten in FHEM etwas beschränkt, aber ausreichend.
Hallo Zusammen,
irgendwie kam ich auf die Idee, meine "herumliegenden" SaintSmart-TFT-LCD-Displays mit dem BME680-Sensor zu kombinieren.
Da hatte ich noch nicht geahnt, wie das zu einem "Adafruit"-Marathon ausarten würde.
Leichtfertiger Weise dachte ich, dass es mit dem MapleMini sehr einfach einzubinden wäre.
Einfach die Adafruit-Libs einbinden und fertig! =>
falsch gedacht!
Hier möchte ich jetzt meine Erfahrungen dazu teilen, da man sich in dieser Konstellation tagelang damit beschäftigen könnte.
Die Idee dazu kam von diesen Webseiten: https://www.instructables.com/id/Arduino-sketch-for-a-retro-analogue-meter-graphic-/ (https://www.instructables.com/id/Arduino-sketch-for-a-retro-analogue-meter-graphic-/)
ZitatUNO and 2.2" ILI9341 based 320 x 240 pixel TFT
und dieser Seite Oscillograf (https://translate.google.com/translate?sl=auto&tl=de&u=http%3A%2F%2Fwww.ad-res.ru%2Fcontrollers%2Foscillograf.php) und https://www.instructables.com/id/Arduino-BMP180-temperature-and-pressure-sensor-rea/ (https://www.instructables.com/id/Arduino-BMP180-temperature-and-pressure-sensor-rea/)
Um es kurz zu machen: So einfach zu realisieren ist das in der Tat nicht.
Gründe:Im Netz gibt es gefühlt tausend verschiedene Varianten + Versionen der Adafuit-Libs, alle mit spezifischen Änderungen für bestimmte
Prozessortypen, ohne dass die "Feinheiten" dokumentiert sind.
Ich hatte mir die TFT-Displays "ST7735 128x160" für 5$ von Hersteller Sainsmart erstanden.
Also
Vorgehensweise: Libraries von Adafruit herunterladen und versuchen für den ESP (http://www.lcdwiki.com/%E3%80%90Application%E3%80%911.6inch_SPI_Module_MSP1601_with_D1_mini) oder STM32 (https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://hubstub.ru/stm32/&xid=17259,15700022,15700124,15700186,15700190,15700201,15700237,15700242,15700248&usg=ALkJrhgdnsmRG_eVCDDZKFXpuDeuqkXT-Q)
zum Laufen zu bekommen.
Ergebnis: die Libraries sind nicht mal nach dem Download mit den Sample zu ohne Fehler zu kompilieren....
Entweder fehlen weitere Header-Dateien oder die Versionen passen nicht zusammen... :(
Die Libs hatte ich in
<Arduino-Verz>/libraries gelegt. FALSCH (Denkfehler!):
Sie müssen für den Maple in dem
".../Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries" liegen.
Dort liegen schon die Versionen, die ich irgenwann mal dort installiert hatte:
Zitat02.12.2018 23:01 <DIR> Adafruit_GFX_AS
02.12.2018 23:01 <DIR> Adafruit_ILI9341
02.12.2018 23:01 <DIR> Adafruit_ILI9341_STM
Die Original-Version der Lib ließ sich nicht kompilieren. Wilde CPP-Fehler.
Auch die Neueste von hier nicht: https://github.com/rogerclarkmelbourne/Arduino_STM32 (https://github.com/rogerclarkmelbourne/Arduino_STM32)
Ach ja, es sind nicht native ST7735-Versionen, sondern ILI9341-Libs. Die Soft-SPI-Lösung war noch Fehler-behafteter.
Ich fand nur diese:
"Adafruit_ILI9341_STM". Alle Maple-Beispiele nutzten diese
unauffindbare "Adafruit_ILI9341_STM_AS" (https://www.instructables.com/id/Arduino-TFT-display-and-font-library/) ...
Letztendlich ging die Hardware-Variante mit SPI_1 des Maples.
Nach Ausprobieren von gefühlt tausend Varianten + Versionen und intensiver Suche im Netz habe ich endlich,
nach ca. anderthalb Tagen mit dieser Variante (http://stm32duino.com/viewtopic.php?f=13&t=127&sid=f2ce806d5e257c944f232b08df2dbf5c&start=10) der STM32F1/libraries (https://github.com/victorpv/Arduino_STM32) den Durchbruch erzielt. (...naja fast!) .
(Grafik- und SPI-Libs im STM32-Libs-Ordner (!) durch diese Versionen ersetzt.)
Ok, die Lib geht von einem Display (https://www.ebay.com/itm/2-2-inch-TFT-LCD-Display-Module-ILI9341-SPI-240x320-for-Arduino-51-AVR-STM32-ARM/302946539659?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D2%26asc%3D20140602152332%26meid%3Df99e3c2e0c604efaa86afb71f2545b9a%26pid%3D100011%26rk%3D1%26rkt%3D5%26sd%3D360699426541%26itm%3D302946539659&_trksid=p2047675.c100011.m1850) der Größe 240x320 aus und meines (https://www.sainsmart.com/products/1-8-tft-spi-lcd-screen-with-microsd-socket#idTab2) hat 128x160 (https://www.tweaking4all.com/hardware/arduino/sainsmart-arduino-color-display/), ist etwas kleiner!
Und die Grafik-Koordinaten (https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://learn.adafruit.com/adafruit-gfx-graphics-library/coordinate-system-and-units&xid=17259,15700022,15700124,15700186,15700190,15700201,15700237,15700242,15700248&usg=ALkJrhhQh9JfP9i4ZyoN6dZxsIAqeAhe_w) (pdf (https://cdn-learn.adafruit.com/downloads/pdf/adafruit-gfx-graphics-library.pdf?timestamp=1546571038)) sind gespiegelt und müssen skaliert werden, aber das kriegt man noch hin ... ;)
... und natürlich die Anbindung mit dem BME680...
Fazit: ein nicht ganz unerhebliches Unterfangen, für den STM32 etwas Passendes (https://www.instructables.com/id/Select-Color-Display-for-ESP32/) hinzubekommen!
Jetzt ist auch noch die Lib für den ESP8266 hinzugekommen.
Der Code für den Maple wurde angepasst.
Das Spiegeln der Koordinaten ist noch etwas aufwändiger als gedacht
und das Display löschen will (noch) nicht so richtig vollständig ...
STM32-F1 | https://github.com/victorpv/Arduino_STM32 (https://github.com/victorpv/Arduino_STM32) |
| ESP8266(Wemos) | https://github.com/Bodmer/TFT_eSPI (https://github.com/Bodmer/TFT_eSPI) |
|
Hier lassen sich die Display-Typen über "user_setup"-Header-Dateien einstellen.
Die Anpassung der Koordinaten geht über ein Skalierungsfaktor (#define M_SIZE 0.667) und nicht über Lib-Settings.
Die Farbe des Schutzfolien-Tabs ist äußerst relevant:
// #define ST7735_INITB
// #define ST7735_GREENTAB
// #define ST7735_GREENTAB2
// #define ST7735_GREENTAB3
// #define ST7735_GREENTAB128 // For 128 x 128 display
// #define ST7735_GREENTAB160x80 // For 160 x 80 display (BGR, inverted, 26 offset)
// #define ST7735_REDTAB
// #define ST7735_BLACKTAB
// #define ST7735_REDTAB160x80 // For 160 x 80 display (24 offset) |
Ich habe die Black-Tab-Variante (hatte noch ein Exemplar mit Original-Folie...)
Zur Lösung gäbe es zwei Varianten:
1. die Einfache: auf ein 240x128 - Display ausweichen, dann passen die Libs ohne Änderungen.
2. die Aufwändige: für 128x160 die Lib erforschen und ändern, oder die Koordinaten immer in der Anwendung spiegeln ...
Oder doch nochmal Suchen? Fündig geworden: Flip-Problem bei
setRotation!
LÖSUNG für ST7735 und ILI9341 für beide Libraries:An verschieden Stellen wir das MADCTL-Register beschrieben. Irgendwie haben die Entwickler der LIB nicht
nicht alle Varianten berücksichtigt
Adafruit_ILI9341_STM.cpp (Maple/STM32):
void Adafruit_ILI9341_STM::setRotation(uint8_t m)
{
// --- juergs, Varianten neu hinzugefügt!
rotation = m % 6; // can't be higher than 3, now 5
switch (rotation) {
case 0:
m = (MADCTL_MX | MADCTL_BGR );
_width = ILI9341_TFTWIDTH;
_height = ILI9341_TFTHEIGHT;
break;
case 1:
m = (MADCTL_MV | MADCTL_BGR);
_width = ILI9341_TFTHEIGHT;
_height = ILI9341_TFTWIDTH;
break;
case 2:
m = (MADCTL_MY | MADCTL_BGR );
_width = ILI9341_TFTWIDTH;
_height = ILI9341_TFTHEIGHT;
break;
case 3:
m = (MADCTL_MX | MADCTL_MY | MADCTL_MV | MADCTL_BGR);
_width = ILI9341_TFTHEIGHT;
_height = ILI9341_TFTWIDTH;
break;
case 4:
m = 0xC8;
_width = ILI9341_TFTHEIGHT;
_height = ILI9341_TFTWIDTH;
break;
case 5:
// --- juergs, diese Variante neu hinzugefügt!
// --- hier wird das Bit5 des Registers auf "1" = "Reversed" gesetzt, gab es vorher nicht!
//--- Bit7 wird auf "1" gesetzt, BottomToTop und BGR Farben eingestellt
// Doku mau ... :o
m = ( MADCTL_MV | MADCTL_MY| MADCTL_BGR ); // 0xa8
_width = ILI9341_TFTHEIGHT;
_height = ILI9341_TFTWIDTH;
break;
}
In der Library
TFT_eISP:
Zitat#define ILI9341_DRIVER
#define ST7735_BLACKTAB
In
user_setup.h ist zu setzen, damit das Display in den passenden Modus schaltet.
Man muss nur wissen, welcher Fall in welchem Header zu wählen ist.
Bei den x-konfigurations-Möglichkeiten und vielen redundanten Defines ... Easy, oder?! :( ::)
Für den ESP findet sich der relevante Code in der Header-Datei:
ILI9341_Rotation.h case 7:
#ifdef M5STACK
writedata(TFT_MAD_MX | TFT_MAD_BGR);
#else
writedata(TFT_MAD_MY | TFT_MAD_MV | TFT_MAD_BGR);
#endif
_width = _init_height;
_height = _init_width;
break; Schwere Geburt, für so ein kleines Display.... ;)
Offensichtlich gibt es verschieden TFT-Controller-Varianten, die einmal auf "Normal" und einmal auf "Reversed" zu setzen sind,
daß sie sich mit den Zusatz-Grafik-Libs betreiben lassen.
Größe und Orientierung passt jetzt...
Dann muss nur noch der Maple Code bereinigt werden, bzw auf die ursprüngliche Version ohne Faktor zurückgegangen werden...
Damit die Skalen-Schrift + Anzeige auch wieder erscheinen ...
Dann kann ich mich an die Umsetzung der BME680-Sensorwerte machen.
Datenblatt: Datenblatt ILI9341.pdf (http://www.buydisplay.com/download/ic/ILI9341.pdf) (nur?) Seite 95.
sainsmart-arduino-color-display/ (https://www.tweaking4all.com/hardware/arduino/sainsmart-arduino-color-display/)
Bin gerade beim Implementieren und der seriellen BME680-Boards auf dem MapleMini.
Beim näheren Hinsehen ergeben sich nun auch einige Fallstricke bei der STM32 angepassten Library.
- Es fehlt noch eine kleinere Schriftart.
- Generell scheint die STM-Lib weit weniger Features zu enthalten, wie die des ESP8266.
- Das Zeigerinstrument wird von einem gößeren Anzeigeformat herunterskaliert.
- Das endet sehr mühselig in der Bestimmung der absoluten Koordinaten....
- Es wird wohl besser sein, das virtuelle Instrument objektorientierter anzupacken, was aber auch etwas mehr Aufwand bedeutet.
IAQ-Werte > 250 habe ich bisher selten gesehen .... deshalb macht es wohl kein Sinn, den Bereich auf IAQmax=500 skalieren,
sondern eine passende "adaptive" Dynamik einzubauen ...
So langsam wird es was....
Dennoch, hier die Todo-Liste:
- Tag-/Nacht-Display
- RFM69CW (LaCrossegateway) und/oder CC1101 (CUL)
- mehrere Seiten-Darstellungen
- Encoder oder Tasten zur Bedienung
- ansprechendes 3D-Druck-Gehäuse
- asynchrone Erfassung der seriellen BME680-Daten über Interrupt-Erfassung
- asynchrones Display-Update
- Timing aufteilen
Hilfreich dazu ist ein Sketch-Programm zu Ausprobieren der Grafik: sketchit (http://www.sketchit.org/) (C#-Interpreter (https://www.codeproject.com/Articles/1254950/%2FArticles%2F1254950%2FSketchIt-A-Small-NET-Based-Development-Environment))
Sorry an die *nixer, CSharp liegt mir "etwas" mehr ... ;) :)
Beispiel zum selbst Live-Ausprobieren:using System.Drawing;
float M_SIZE = 0.068F;
float _sx = 0.0F;
float _sy = 0.0F;
int _x0=0, _x1=0;
int _y0=0, _y1=0;
int tl = 15;
int _sxInt = 0;
int _syInt = 0;
int _idx = 0;
SetSize(160,128);
DrawBackground(GetColor(200,255,255));
DrawRectangle(5,3,Width-10, Height/2+10);
SketchIt.Api.Color slatBlue = GetColor(255,255,255);
Pen skyBluePen = new Pen(Brushes.DeepSkyBlue);
// indexe laufen von 0..20
for (int i=-50; i<51; i+=5)
{
_sx = Cos((i - 90) * 0.0174532925F);
_sy = Sin((i - 90) * 0.0174532925F);
PrintLine("idx, i, sx, sy =\t", _idx, i, _sx, _sy);
_idx++;
_sxInt = Convert.ToInt32(_sx * M_SIZE * 100 + tl);
_syInt = Convert.ToInt32(_sy * M_SIZE * 100 + tl);
_x0 = _sxInt + Convert.ToInt32(M_SIZE * 120);
_y0 = _syInt + Convert.ToInt32(M_SIZE * 150);
_x1 = Convert.ToInt32(_sx) + M_SIZE * 120;
_y1 = Convert.ToInt32(_sy) + M_SIZE * 150;
if (i<50) DrawLine(_x0,_y0,_x1,_y1);
PrintLine("idx, i, _sxInt, _syInt =\t", _idx, i, _sxInt, _syInt);
PrintLine("idx, i, x0, y0 =\t", _idx, i, _x0, _y0);
PrintLine("idx, i, x1, y1 =\t", _idx, i, _x1, _y1);
}Erste Code-Arbeitsversion für den Maple: https://github.com/juergs/BME680_TFT_Monitor/blob/master/BME680_Maple_TFT_Monitor.ino (https://github.com/juergs/BME680_TFT_Monitor/blob/master/BME680_Maple_TFT_Monitor.ino)
Für Vorschläge und Pull-Requests gerne immer willkommen... ;) :)
Für den ESP ist zusätzlich zum TFT noch folgendes geplant (JavaScript + Chart.js): esp8266-data-logging-with-real-time-graphs (https://circuits4you.com/2019/01/11/esp8266-data-logging-with-real-time-graphs/?relatedposts_hit=1&relatedposts_origin=1530&relatedposts_position=1)
Lauffähiges Beispiel habe ich beigefügt.
Hallo Jürgen,
Deine breakouts für den BME680 waren von hier (https://oshpark.com/shared_projects/LXuNziGd), oder? Ich überlege, ob ich eines für den Lacrosse GateWay mache, der dann seitlich auf der Platine (mit 90 ° Stiftleisten) festgelötet wird und aus dem Gehäuse rausschaut.
Gruß Peter
Hallo Peter,
ja, die von OSH.
Allerdings betrachtet man das Preis/Leistungsverhältnis is das komplette QY-MCU680V1-Board, seriell ja ebenfalls für das LGW geeignet.
Da wäre ja noch eine oder mehere Serial-Bridges onboard. Der BME kostet bei Rei****t 9,90€ + Versand.
Die QY-MCU680V1-Board von Ali kosten 8,80/Stück, kein Porto. Bei Rutronik 8,90€ + MWst + Porto.
Solche Ali-Preise sind nur in Tausender Stückzahlen wertschöpfend (oder Fakes?).
Die Platinen hatte ich noch herumliegen, aus der Zeit wo ich noch mit dem Gedanken spielte, die Dinger selbst SMD-verlöten zu können.
Na ja, ab bekomme ich sie schon mal. ;)
Leider wirklich schade um Deine Mühe, die Dinger auf die Platine zu bekommen. Trotzdem vielen Dank dafür.
Würde trotzdem empfehlen, das Breakoutboard von der Platine entfernt am Gehäuse zu montieren.
Sensor-oberfläche ins Freie ...
PS: um die thermische Einstreuung in der nanoLGW zu verhindern würde ich den Sensor ebenfalls außen anbringen wollen
und im 3D-Gehäuse für genügend Durchluft bzw. sorgen ...
Ich würde ein Halterung dafür vorsehen. Bei dem Meter-Projekt ist der BH1750 auch sinnvoll,
da Tag-/Nacht-Erkennung und Regelung der Displayhelligkeit Sinn macht.
Da sie ja den ESP beinhalten ist ein Netzteil unabdingbar und die Anschlußmöglichkeiten dazu auch ...
D.h. die Gehäuse (LGW+nanoLGW) sollten standfest und das Netzteilkabel mit Hohlstecker abkönnen.
Wenn die Gehäuse fertig konzipiert + gedruckt sind, lasse ich Dir gerne ein paar davon zukommen. ;)
Dauert leider noch etwas ...
Grüße,
Jürgen
Zitatob ich eines für den Lacrosse GateWay mache, der dann seitlich auf der Platine (mit 90 ° Stiftleisten) festgelötet wird und aus dem Gehäuse rausschaut.
Ist wohl auch Gehäuse-abhängig. Prinzipiell aber die wohl bessere Variante. :)
Mit STM32F103+BSEC und I2C-Bypass? ;D ;) :D
Zitat von: juergs am 14 Januar 2019, 19:51:57
Mit STM32F103+BSEC und I2C-Bypass? ;D ;) :D
Nur, wenn Du dafür die Software schreibst ;D ;D ;D
Gruß Peter
Zitat von: PeMue am 14 Januar 2019, 21:00:53
Nur, wenn Du dafür die Software schreibst ;D ;D ;D
Gruß Peter
... könnte man darüber nachdenken ... ;) :) :D
Wobei ich gerade die Erfahrung mit der seriellen Variante mache, daß während des Entwickelns und Uploadens,
die Erfassung einfach weiterläuft und der Sensor muss nicht neu initialisiert werden. Hat was ...
Man bekommt gleich gültige Werte :)
So, Berechnungs-Fehler in der unteren Hälfte beseitigt und die Werte schon mal gelabeld.
Werte zum Darstellen bereitgestellt. Muss nur noch deren Positionierung "iterativ" anpassen ;)
Durch Anhauchen reagiert die Anzeige wie zu erwarten war... sehr sensibel. :) ;) :D
Die Farbgebung der Skala ist erst mal etwas empirisch verteilt ...
Wobei ich gestern auch schon IAQ-Werte von über 160 gesehen habe, die in etwa realistisch
einzuschätzen waren und zur Stoßlüftung angemahnt haben ... ;D
Die Grafiken sind schon mal vorbereitet, benötige aber noch die Einbindung einer kleineren Schrift.
ZitatProgram BME680_Maple_TFT_Monitor size: 70.344 bytes (used 64% of a 110.592 byte maximum) (2,88 secs)
Hier mal ein Mitschnitt:IAQ_m ist schon der skalierte Wert für den Anzeige-Bereich von -50..+50 ° in 0..100%.
EMA_S ist der leicht geglättete IAQ-Wert und IAQ der momentan gemessene Wert.
[2691.28] - EMA_S, IAQ, IAQ_m: 43 43 8
[2694.52] - EMA_S, IAQ, IAQ_m: 42 42 8
[2697.75] - EMA_S, IAQ, IAQ_m: 44 46 8
[2700.98] - EMA_S, IAQ, IAQ_m: 42 42 8
[2704.21] - EMA_S, IAQ, IAQ_m: 41 41 8
[2707.44] - EMA_S, IAQ, IAQ_m: 43 45 8
[2710.67] - EMA_S, IAQ, IAQ_m: 41 40 8
[2713.91] - EMA_S, IAQ, IAQ_m: 44 47 8
[2717.14] - EMA_S, IAQ, IAQ_m: 44 44 8
[2720.37] - EMA_S, IAQ, IAQ_m: 41 39 8
[2723.60] - EMA_S, IAQ, IAQ_m: 43 45 8
[2726.83] - EMA_S, IAQ, IAQ_m: 44 46 8
[2730.06] - EMA_S, IAQ, IAQ_m: 42 42 8
[2733.29] - EMA_S, IAQ, IAQ_m: 45 48 9
[2736.53] - EMA_S, IAQ, IAQ_m: 46 47 9
[2739.76] - EMA_S, IAQ, IAQ_m: 46 46 9
[2742.99] - EMA_S, IAQ, IAQ_m: 48 50 9
[2746.22] - EMA_S, IAQ, IAQ_m: 48 48 9
[2749.45] - EMA_S, IAQ, IAQ_m: 50 52 10
[2752.68] - EMA_S, IAQ, IAQ_m: 49 49 9
[2755.91] - EMA_S, IAQ, IAQ_m: 46 44 9
[2759.15] - EMA_S, IAQ, IAQ_m: 43 41 8
[2762.38] - EMA_S, IAQ, IAQ_m: 42 42 8
[2765.61] - EMA_S, IAQ, IAQ_m: 46 49 9
[2768.84] - EMA_S, IAQ, IAQ_m: 44 43 8
[2772.07] - EMA_S, IAQ, IAQ_m: 43 43 8
[2775.30] - EMA_S, IAQ, IAQ_m: 41 41 8
[2778.53] - EMA_S, IAQ, IAQ_m: 41 41 8
[2781.76] - EMA_S, IAQ, IAQ_m: 41 42 8
[2785.00] - EMA_S, IAQ, IAQ_m: 42 43 8
[2788.23] - EMA_S, IAQ, IAQ_m: 43 45 8
[2791.46] - EMA_S, IAQ, IAQ_m: 46 48 9
[2794.69] - EMA_S, IAQ, IAQ_m: 46 46 9
[2797.92] - EMA_S, IAQ, IAQ_m: 48 50 9
[2801.15] - EMA_S, IAQ, IAQ_m: 49 51 9
[2804.39] - EMA_S, IAQ, IAQ_m: 45 43 9
[2807.62] - EMA_S, IAQ, IAQ_m: 45 45 9
LowerPane zeigt schon mal Werte, muss aber noch feingetunt werden.
/edit: IAQ_m interessiert nicht, HUMIDITY dafür nachgezogen... ;)
Hallo Jürgen,
Zitat von: juergs am 13 Januar 2019, 21:43:15
ja, die von OSH.
ich habe mir diese
breakouts mal angeschaut und habe den Verdacht, dass die Vias teilweise im Nirwana verschwinden. Und vierlagig ist diese Leiterplatte auf jeden Fall auch nicht. Daher mein Vorschlag: wenn sich mein Verdacht bestätigen sollte, mache ich ein Breakout mit BME680 und BH1750, das mittes 1,27 mm Pinleisten sowohl auf den LGW als auch auf den nanoLGW angelötet werden kann. Einverstanden?
Einziger Nachteil:
Zitat von: juergs am 13 Januar 2019, 21:43:15
Dauert leider noch etwas ...
Gruß Peter
Zitat von: PeMue am 16 Januar 2019, 21:13:50
Hallo Jürgen,
ich habe mir diese breakouts mal angeschaut und habe den Verdacht, dass die Vias teilweise im Nirwana verschwinden. Und vierlagig ist diese Leiterplatte auf jeden Fall auch nicht. Daher mein Vorschlag: wenn sich mein Verdacht bestätigen sollte, mache ich ein Breakout mit BME680 und BH1750, das mittes 1,27 mm Pinleisten sowohl auf den LGW als auch auf den nanoLGW angelötet werden kann. Einverstanden?
Gruß Peter
Hallo Peter,
ja klar, das hört sich super gut an. :)
Zitat von: juergs am 16 Januar 2019, 21:29:14
ja klar, das hört sich super gut an. :)
so etwa?
Gruß Peter
Hallo Peter,
im Prinzip ja, weil abgesetzt, aber wenn man sich vorstellt dass man das Board
an ein (3D-Druck-)Gehäuse montieren muss, wären zwei M2,5 Bohrungen (diagonal?) zusätzlich noch sehr praktisch :D ;) ;D
Zwar nicht so riesig, wie unten im BME-280-Beispiel (warum auch immer der BME280 0%rH liefert), aber ähnlich.
Ich stelle mir eine Vertiefung im Deckel vor ... von der Rückseite würde das Board mit zwei Senkkopf-Schrauben befestigt...
Oder ich müsste mir ein Schiebe-/Klemm-Mechanismus einfallen lassen ...
Wenn man sich schon was wünschen darf... ;D
/edit: ... der BME280 0%rH liefert => Der Unterschied zwischen BME - und BMP280 !
Grüße,
Jürgen
Hallo zusammen,
ich würde jetzt mal mit einem solchen breakout board ins Rennen gehen (siehe BME680_BH1750_breakout_v1.0_top.png (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=114241;image)).
Leider ohne Schraubenlöcher, aber m.E. braucht es das auch nicht, da die Platine so klein ist (9x7,5 mm), dass sie keine Schrauben braucht.
Anbindung ist über einen 1.27 mm Pinheader, der am nanoLGW per SMD gelötet wird, so dass das breakout board oben aus dem Gehäuse schauen kann (die Höhe kann über das Einlöten justiert werden).
Beim LGW habe ich das ganze in Durchsteck relalisiert, so dass das breakout board auf der Seite aus dem Gehäuse rausschauen kann.
Irgendwelche Verbesserungsvorschläge? Wenn nicht, schaue ich, dass ich Platinen bestelle.
Gruß Peter
Hallo Peter,
super! Nehme auf alle Fälle einen Posten ab ... :D
Bei den OSH-Breakouts habe ich mich mit einem BME680 und einem in einem Schraubstock eingespannten Bügeleisen
versucht. Was soll ich sagen, bin mit dem Ergebnis zufrieden und es funktioniert sogar!
Die Sensor-Größe ist wirklich grenzwertig .... Ebenso die 0403 4K7-R's (hatte nur 0604 da..)
Ist die kostengünstigste Variante ;D
Danke + Grüße!
Jürgen
Hallo,
habe jetzt mal die Breakouts, LGW v1.4 und nanoLGW v1.6 bestellt, mal sehen, ob die noch vor dem chinesischen Neujahr gefertigt werden.
Zitat von: juergs am 28 Januar 2019, 18:15:04
Bei den OSH-Breakouts habe ich mich mit einem BME680 und einem in einem Schraubstock eingespannten Bügeleisen
versucht. Was soll ich sagen, bin mit dem Ergebnis zufrieden und es funktioniert sogar!
da hätte ich gerne mal ein Bild gesehen ;)
Gruß Peter
So, ich habe mal versucht nach einem ESP8266-SDK-Upgrade, die BOSCH-BSEC-Lib mit der
Zitathardware\esp8266\2.5.0-beta2\tools\sdk\lib
zu konfigurieren:
Die Anleitung galt ja für die V2.4.0:############################################
# Einbinden der BSEC Software für ESP8266: #
# Stand: 09.01.2018 #
# ESP8266 Paket V2.4.0 #
# BSEC V1.4.5.1 #
############################################
https://github.com/BoschSensortec/BSEC-Arduino-library
1. Die Lib "[b]libalgobsec.a[/b]" muss nach "[b]\Users\[Benutzername]\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0\tools\sdk\lib\[/b]" kopiert werden !
Das ist die "precompiled Lib" von Bosch Sensortec.
2. Die Linker Datei "hardware\esp8266\2.4.0\tools\sdk\ld\eagle.app.v6.common.ld" muß angepasst werden:
nach der Zeile "*libm.a:(.literal .text .literal.* .text.*)" , die Zeile "*libalgobsec.a:(.literal .text .literal.* .text.*)" einfügen.
3. Als letztes muss noch ein Parameter in der Datei [b][i]"hardware\esp8266\2.4.0\platform.txt"[/i][/b] hinzugefügt werden:
am Ende der Zeile "compiler.c.elf.libs= ... -lm -lgcc" folgendes anfügen " -lalgobsec" .
Änderungen:
1.) Die "
libalgobsec.a" muss nach "
\Users\[Benutzername]\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2\tools\sdk\lib\" kopiert werden !
Das ist die "precompiled Lib" von Bosch Sensortec.
2.) in die Linker Datei
eagle.app.v6.common.ld.h im Verzeichnis
Zitat"hardware\esp8266\2.5.0-beta2\tools\sdk\ld\
... nach der Zeile
"*libm.a:(.literal .text .literal.* .text.*)" die Zeile
"*libalgobsec.a:(.literal .text .literal.* .text.*)"einfügen.
3. Als letztes muss noch ein Parameter in der Datei "
hardware\esp8266\2.5.0-beta2\platform.txt" hinzugefügt werden:
am Ende der Zeile "compiler.c.elf.libs= ... -lm -lgcc" folgendes anfügen " -lalgobsec" .
Dann sollte bei einem Compile + Linkerlauf, ähnlich diesem Beispiel-Output folgende Info stehen:
Zitat"C:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9/bin/xtensa-lx106-elf-gcc" -Wl,-Map
"-Wl,C:\Users\<user>\AppData\Local\Temp\arduino_build_984070/bsec_iot_example.ino.map" -g -Wall -Os -nostdlib -Wl,--no-check-sections -u app_entry -u _printf_float -u _scanf_float -Wl,-static
"-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/lib" "-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/ld"
"-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/libc/xtensa-lx106-elf/lib"
"-Teagle.flash.4m.ld" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read -o "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070/bsec_iot_example.ino.elf"
-Wl,--start-group "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bme680.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bme680_calculations.c.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bsec_integration.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\RFMxx.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\SensorBase.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bsec_iot_example.ino.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Wire\Wire.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\SPI\SPI.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\glcdfont.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\Adafruit_GFX.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\AS_BH1750\AS_BH1750.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\AS_BH1750\AS_BH1750A.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\core\core.a" -lhal -lphy -lpp -lnet80211 -llwip2-536-feat -lwpa -lcrypto -lmain -lwps -lbearssl -laxtls -lespnow -lsmartconfig -lairkiss
-lwpa2 -lstdc++ -lm -lc -lgcc -lalgobsec -Wl,--end-group
"-LC:\Users\<user>\AppData\Local\Temp\arduino_build_984070"
Hallo Peter,
sorry, brauchte den BME680 für ein weiteres Breakout!
Aber dafür die Bilder... ;)
Das IR-Thermometer wollte nicht so recht...
Vielleicht doch besser mit NiCr-Ni-Thermoelement und SolidState-Relais-Steuerung.
Nicht so die Profi-Thermokurve, aber es geht.
Vorher mit Flussmitteldispenser und Lötzinn benetzt, dann nach einem, oder zwei Kaffe (!!!) ::)
den BME positioniert.... ;D ;) :)
Hoffe, dass der BME nicht an Hitze-Schlag stirbt....
Zitat... und nicht gerade zur Nachahmung empfohlen!!!
Falls es jemand noch nicht wissen sollte, die Dinger werden so richtig heiß!
Verbrennungsgefahr!
Apropos, gibt es etwas Neues zu Deinen neuen Breakouts?
Grüße,
Jürgen
Zitat von: juergs am 17 Februar 2019, 11:35:44
Apropos, gibt es etwas Neues zu Deinen neuen Breakouts?
still in production, ich habe aber gerade auf der Elecrow Webseite freundich nach dem Status gefragt. Was lernen wir: entweder deutlich vorher bestellen oder danach, zwischendrin ist suboptimal. Wenn ich sehe, dass Papa Romeo schon 200 Platinen bei JLCPCB liegen hat :o.
Gruß Peter
Ui, danke! :-X ;D ;)
Jürgen
... und geht!
[797602.00] P: 1031.3| T: 23.78| rH: 30.40| IAQ: 27.71 (1)| Static IAQ: 26.18| CO2e: 0.00| bVOC: 0.00| Gas: 8552.00| UBat: 3.3V
Neuer Status: shipped :)
Gruß Peter
Aktueller Status für die Neugierigen:
Zitat2019-02-25 09:00 Frankfurt Main, Germany, Flight landed
Zitat2019-02-26 16:00 Destination Clearance Facility, EU, Cleared by customs
Zitat2019-02-28 04:13 FRANKFURT/M, Germany, Arrived at facility
Zitat2019-03-01 14:07 xxx, Germany, Successfully delivered
Gruß Peter
Hi zusammen,
Letzte Woche kam mein Lieferung BME680 von AliExpress.
Ich habe sie mit einem ESP8266 (WEMOS D1 mini) und ESPEasy über das neue MQTT Modul von Rudolf in Fhem eingebunden.
Läuft super.
Das BME680 Modul ist nicht im normalen Repository von ESPEasy. Es liegt im Playground und muss vor dem kompilieren in das ESPEasy Quellverzeichnis kopiert werden.
Das Display ist ein OLED SSD1306.
Im Anhang ist noch ein Bild von einem Versuchsaufbau mit MHZ-19 (CO2), BH1750 und BME280. Das Gehäuse ist aber noch nicht optimal.
Anbei der Link zum Projekt https://www.thingiverse.com/thing:3385002
Hallo tobias.gj,
das espeasy-Modul liefert Dir über die Adafruit-Lib nur :
UserVar[event->BaseVarIndex + 3] = bme.gas_resistance / 1000.0;
Den Widerstandswert, der nicht dem VOC-Wert entspricht, geschweige denn PPM.
Hier führt nur der Weg über die statische BSEC-Lib, die einige Anforderungen
an die Laufzeitumgebung stellt. Ob das über die ESPEasy-Umgebung laufen würde ?
Evtl. die Anpassung von Jörg: https://forum.fhem.de/index.php/topic,96241.0.html (https://forum.fhem.de/index.php/topic,96241.0.html)
könnte Dir da weiterhelfen (ohne BSEC).
Viel Spaß mit dem Modul und neue Erkenntnisse über CO2 ;)
Grüße,
Jürgen
Das ist richtig, bin gerade dabei ein alternatives Modul reinzufummeln um das Problem zu lösen und auch die IAQ Werte zu bekommen.
Hallo zusammen,
die Platinen sind da, mal sehen, ob ich die kleinen Dinger bestückt bekomme ::) ::) ::).
Nur zur Info: Die Pfostenstecker sind im RM1,27 mm.
Gruß Peter
Hallo Jürgen,
Zitat von: juergs am 29 Dezember 2018, 11:55:03
PS: Die BME680 mit STM32F051k8-Sensoren (https://de.aliexpress.com/item/GY-MCU680V1-BME680-Temperatur-und-Feuchtigkeit-Luftdruck-Indoor-Air-Qualit-t-IAQ-MCU680-Sensor-Modul/32905797241.html?spm=a2g0x.search0104.3.2.21a861c1tzC5SF&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=9c0468c9-27a7-4cb6-bd36-295dcd541f54&algo_expid=9c0468c9-27a7-4cb6-bd36-295dcd541f54-0) sind heute gekommen ... :D
hast Du irgendwo einen Schaltplan für diese Teile gefunden? Meiner ist gestern gekommen ...
Danke + Gruß
Peter
Hallo Peter,
Schaltplan ... nicht direkt, aber die SW dazu.
Ein Reengineering sollte aber nicht so schwer sein.
Ist ja nur RX/TX und ggf. I2C als Bypass direkt zum BME680.
Mal schauen was ich machen kann... 8)
Aktuelle Firmware für das Modul "GY-MCU680V1 BME680" zum Maple ist hier: BME680_Maple_TFT_Monitor (https://github.com/juergs/BME680_TFT_Monitor)
STM32F051K8 (https://www.st.com/content/ccc/resource/technical/document/user_manual/30/ae/6e/54/d3/b6/46/17/DM00050135.pdf/files/DM00050135.pdf/jcr:content/translations/en.DM00050135.pdf) S.39
Details (https://forum.fhem.de/index.php/topic,78619.msg878330.html#msg878330) und hier (https://de.aliexpress.com/item/GY-MCU680V1-BME680-Temperatur-und-Feuchtigkeit-Luftdruck-Indoor-Air-Qualit-t-IAQ-MCU680-Sensor-Modul/32907106319.html)
Wäre auch für die ESP-Wetterstation (https://forum.fhem.de/index.php/topic,52403.0.html) brauchbar... ;) :)
Oder alternativ in der Cloud: https://thinger.io/ (https://thinger.io/) (Anm.: frei, sehr einfach und funktioniert!) Übersicht (http://docs.thinger.io/)
Nur für 30 Tage: Azure Iot-Hub (https://docs.microsoft.com/de-de/azure/iot-hub/iot-hub-arduino-huzzah-esp8266-get-started) habe ich mit dem ESP8266 leider noch nicht erfolgreich zum Laufen gebracht ...
BME680 (https://german.alibaba.com/product-detail/hot-selling-original-new-stock-bme680-ic-chips-60777091878.html?spm=a2700.8699010.29.92.1b002968OBhAZP) für 1,60$ das Stück ???
Schaltplan (auf die Schnelle) ohne Gewähr ...
Hallo Jürgen,
ich wollte jetzt nicht, dass Du anfängst, einen Schaltplan zu zeichnen ;). Hat die Software die Bosch BSEC integriert, oder ist ein x-beliebiger IAQ Algorithmus umgesetzt?
Zitat von: juergs am 21 März 2019, 18:08:57
BME680 (https://german.alibaba.com/product-detail/hot-selling-original-new-stock-bme680-ic-chips-60777091878.html?spm=a2700.8699010.29.92.1b002968OBhAZP) für 1,60$ das Stück ???
Da würde ich eher dieses Angebot (https://de.aliexpress.com/item/100-neue-original-BME280-BME280-BME680-BME-680-IC-SENSOR-DRUCK-FEUCHTIGKEIT-TEMP/32968997530.html?spm=a2g0s.8937460.0.0.816c2e0ebhJALt) bestellen. 10 Stück für 69 € ist günstig und m.E. relativ sicher.
Gruß Peter
Hallo Peter, Schaltplan hat mich auch interessiert 8)
Ich vermute, die SW hat BSEC integriert und zeigt eigentlich sehr plausible Werte an.
Ich habe den Output in meiner FW noch geringfügig geglättet.
Für den Maple habe ich diese Module bekommen:
Air602-WiFi-Module (https://www.seeedstudio.com/Air602-WiFi-Module-p-3139.html) um den Maple mit Wifi-Fähigkeiten auszustatten ...
Zumindest wie man eCO2 und VOCeq aus BSEC bekommen, hat Bosch endlich mal erklärt:
https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BME680-BSEC-eCO2/m-p/5919
Habe das erstaunlicherweise noch niemanden testen gesehen...
Danke für die zusätzliche Informationsquelle.
Z.B. auch diese Info ist interessant:
The IAQ accuracy is actually reflecting the current state of the background calibration process, such as:
IAQ Accuracy=0 could either mean:
BSEC was just started, and the sensor is stabilizing (this lasts normally 5min in LP mode or 20min in ULP mode),
there was a timing violation (i.e. BSEC was called too early or too late), which should be indicated by a warning/error flag by BSEC,
IAQ Accuracy=1 means the background history of BSEC is uncertain. This typically means the gas sensor data was too stable for BSEC to clearly define its references,
IAQ Accuracy=2 means BSEC found a new calibration data and is currently calibrating,
IAQ Accuracy=3 means BSEC calibrated successfully.
Ich vermute, Du beziehst Dich mit Deinem Hinweis auf diese Frage?
https://forum.fhem.de/index.php/topic,97161.msg922102.html#msg922102 (https://forum.fhem.de/index.php/topic,97161.msg922102.html#msg922102)
und
BME680 without VOC and CO2 data (https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BME680-without-VOC-and-CO2-data/m-p/6319?advanced=false&collapse_discussion=true&filter=location&location=forum-board:bst_community-mems-forum&q=BME680&search_type=thread)
Habe eine eigene Arduino Library erstellt, die es ermöglicht aus dem BME680-Sensor, ohne die Einbindung der statischen BSEC-Libraries auch den Anteil der tVocs in PPM zu ermitteln bzw. auszugeben.
Da momentan verfügbare Libraries nur den Widerstand des Heizelements des Sensors ausgeben, welcher ohne zusätzlichen Berechungsaufwand leider keine interpretierbare Lösung darstellt.
Anbei die erste Version: getestet mit Wemos D1 mini und BME680 Sensor an Adresse 0x77. Nach ca. 30s werden erste tVoc-Werte geliefert.
Abhängigkeiten:
Als Grundlage wird die aktuelle Adafruit_BME680-Library benötigt: * https://adafruit.github.io/Adafruit_BME680/html/index.html (https://adafruit.github.io/Adafruit_BME680/html/index.html)
Welche wiederum die Installation der Adafruit Unified Sensor library benutzt: * https://github.com/adafruit/Adafruit_Sensor (https://github.com/adafruit/Adafruit_Sensor)
|-- <JS_BME680 Library> 1.0.0
| |-- <Wire> 1.0
| |-- <Adafruit BME680 Library> 1.0.7
| | |-- <Wire> 1.0
| | |-- <SPI> 1.0
| | |-- <Adafruit Unified Sensor> 1.0.3
| |-- <SPI> 1.0
Credits und Dank für die Basis + Grundlagenarbeit an Jörg @ github (https://github.com/herrmannj/) oder https://forum.fhem.de/index.php/topic,96241.0.html (https://forum.fhem.de/index.php/topic,96241.0.html)!
Arduino-Monitor-Ausgabe bei 115KB mit dem beigefügten Sample-Sketch:
*** Started!
Enabled: I2C for Wemos D1 mini SDA:D2 / SCL:D1
Scanning I2C...
I2C device found at address 0x77 !
done
I2C: ok BME680 sensor found! :-)
[10.37] Temperature = 27.32 *C Pressure = 999.40 hPa Humidity = 51.94 % Gas = 0.00 KOhms Approx. Altitude = 115.79 m
[20.37] Temperature = 27.41 *C Pressure = 999.38 hPa Humidity = 51.92 % Gas = 87.76 KOhms Approx. Altitude = 115.79 m
[30.37] Temperature = 27.53 *C Pressure = 999.40 hPa Humidity = 51.85 % Gas = 95.60 KOhms Approx. Altitude = 116.12 m
[40.37] Temperature = 27.59 *C Pressure = 999.40 hPa Humidity = 51.88 % Gas = 100.18 KOhms Approx. Altitude = 115.95 m
[50.37] Temperature = 27.63 *C Pressure = 999.40 hPa Humidity = 51.94 % Gas = 102.70 KOhms Approx. Altitude = 115.79 m
[60.37] Temperature = 27.64 *C Pressure = 999.40 hPa Humidity = 51.99 % Gas = 104.36 KOhms Approx. Altitude = 115.95 m
[70.37] Temperature = 27.65 *C Pressure = 999.38 hPa Humidity = 51.99 % Gas = 105.15 KOhms Approx. Altitude = 115.95 m
[80.38] Temperature = 27.66 *C Pressure = 999.38 hPa Humidity = 52.02 % Gas = 106.08 KOhms Approx. Altitude = 115.95 m
[90.38] Temperature = 27.66 *C Pressure = 999.38 hPa Humidity = 52.02 % Gas = 106.21 KOhms Approx. Altitude = 115.95 m
[100.38] Temperature = 27.66 *C Pressure = 999.40 hPa Humidity = 51.98 % Gas = 107.30 KOhms Approx. Altitude = 116.12 m
[110.38] Temperature = 27.66 *C Pressure = 999.38 hPa Humidity = 51.93 % Gas = 108.13 KOhms Approx. Altitude = 116.12 m
[120.38] Temperature = 27.67 *C Pressure = 999.36 hPa Humidity = 51.83 % Gas = 108.48 KOhms Approx. Altitude = 116.29 m
[130.38] Temperature = 27.68 *C Pressure = 999.36 hPa Humidity = 51.78 % Gas = 108.41 KOhms Approx. Altitude = 116.12 m
[140.38] Temperature = 27.68 *C Pressure = 999.36 hPa Humidity = 51.83 % Gas = 108.84 KOhms Approx. Altitude = 116.12 m
[150.38] Temperature = 27.68 *C Pressure = 999.38 hPa Humidity = 51.89 % Gas = 108.62 KOhms Approx. Altitude = 116.29 m
[160.38] Temperature = 27.69 *C Pressure = 999.36 hPa Humidity = 51.86 % Gas = 108.70 KOhms Approx. Altitude = 116.46 m
[170.38] Temperature = 27.69 *C Pressure = 999.34 hPa Humidity = 51.84 % Gas = 109.48 KOhms Approx. Altitude = 116.46 m
[180.39] Temperature = 27.70 *C Pressure = 999.36 hPa Humidity = 51.83 % Gas = 109.26 KOhms Approx. Altitude = 116.12 m
[190.39] Temperature = 27.69 *C Pressure = 999.36 hPa Humidity = 51.85 % Gas = 109.41 KOhms Approx. Altitude = 116.29 m
[200.39] Temperature = 27.69 *C Pressure = 999.36 hPa Humidity = 51.83 % Gas = 109.33 KOhms Approx. Altitude = 116.29 m
[210.39] Temperature = 27.68 *C Pressure = 999.36 hPa Humidity = 51.83 % Gas = 109.48 KOhms Approx. Altitude = 116.29 m
[220.39] Temperature = 27.68 *C Pressure = 999.32 hPa Humidity = 51.84 % Gas = 110.05 KOhms Approx. Altitude = 116.46 m
[230.39] Temperature = 27.68 *C Pressure = 999.32 hPa Humidity = 51.82 % Gas = 110.34 KOhms Approx. Altitude = 116.29 m
[240.39] Temperature = 27.68 *C Pressure = 999.32 hPa Humidity = 51.80 % Gas = 111.00 KOhms Approx. Altitude = 116.29 m
[250.39] Temperature = 27.68 *C Pressure = 999.32 hPa Humidity = 51.78 % Gas = 110.93 KOhms Approx. Altitude = 116.12 m
[260.39] Temperature = 27.68 *C Pressure = 999.34 hPa Humidity = 51.81 % Gas = 110.93 KOhms Approx. Altitude = 116.29 m
[270.39] Temperature = 27.68 *C Pressure = 999.32 hPa Humidity = 51.80 % Gas = 110.63 KOhms Approx. Altitude = 116.46 m
[280.40] Temperature = 27.68 *C Pressure = 999.34 hPa Humidity = 51.75 % Gas = 111.52 KOhms Approx. Altitude = 116.46 m
[290.40] Temperature = 27.68 *C Pressure = 999.34 hPa Humidity = 51.80 % Gas = 110.78 KOhms Approx. Altitude = 116.46 m
[300.40] Temperature = 27.69 *C Pressure = 999.34 hPa Humidity = 51.77 % Gas = 111.37 KOhms Approx. Altitude = 116.63 m
[300.77] Taupunkt: 17.00 tVOC: 125
BME680-Reading done.
[310.40] Temperature = 27.69 *C Pressure = 999.32 hPa Humidity = 51.78 % Gas = 111.37 KOhms Approx. Altitude = 116.46 m
[310.77] Taupunkt: 17.01 tVOC: 125
BME680-Reading done.
[320.40] Temperature = 27.70 *C Pressure = 999.30 hPa Humidity = 51.76 % Gas = 111.96 KOhms Approx. Altitude = 116.63 m
[320.77] Taupunkt: 17.00 tVOC: 125
BME680-Reading done.
[330.40] Temperature = 27.70 *C Pressure = 999.30 hPa Humidity = 51.78 % Gas = 111.07 KOhms Approx. Altitude = 116.46 m
[330.77] Taupunkt: 17.00 tVOC: 125
BME680-Reading done.
[340.40] Temperature = 27.70 *C Pressure = 999.34 hPa Humidity = 51.77 % Gas = 111.82 KOhms Approx. Altitude = 116.46 m
[340.77] Taupunkt: 17.00 tVOC: 125
BME680-Reading done.
[350.40] Temperature = 27.70 *C Pressure = 999.34 hPa Humidity = 51.79 % Gas = 111.44 KOhms Approx. Altitude = 116.46 m
[350.78] Taupunkt: 17.02 tVOC: 126
BME680-Reading done.
Sketch uses 288476 bytes (27%) of program storage space. Maximum is 1044464 bytes.
Global variables use 28076 bytes (34%) of dynamic memory, leaving 53844 bytes for local variables. Maximum is 81920 bytes.
Verbesserungsvorschäge gerne erwünscht, da diese Version "noch in Arbeit" ist und einige Dinge noch verifiziert werden müssen ... ;)
Aktualisierte Versionen pflege ich in Github ein: BME680-Arduino-Library-with_TVOC- (https://github.com/juergs/BME680-Arduino-Library-with_TVOC-)
Jürgen
BSEC-Konfiguration mit platformio:
https://www.heise.de/ct/artikel/Mikrocontroller-bequem-programmieren-mit-PlatformIO-4403209.html (https://www.heise.de/ct/artikel/Mikrocontroller-bequem-programmieren-mit-PlatformIO-4403209.html)
Here is how I got to get the BME680 running using Bosch BSEC Arduino Library on Platformio IDE.
1. Create a project for the board that you are going to use.
2. Copy the https://github.com/BoschSensortec/BSEC-Arduino-library/
3. Copy the files from BSEC-Arduino-library/src to your src folder on Platformio IDE.
4. Copy the files from BSEC-Arduino-library/examples/basic_config_state/ also to the src folder (bsec_serialized_configurations_iaq.cpp and bsec_serialized_configurations_iaq.h)
5. Copy the source code from the https://github.com/BoschSensortec/BSEC-Arduino-library/blob/master/examples/basic_config_state/basic_config_state.ino to your main.cpp
6. Download the latest library at https://www.bosch-sensortec.com/en/bst/products/all_products/bsec
7. Copy the libalgobsec.a file for the ESP8266 to the folder lib on your platformio project.
8. Add this line at the end of your platformio.ini
build_flags = -L/Users/USER/Documents/PlatformIO/Projects/BSEC_BME680/lib/ -lalgobsec
Hopefully, it will build. I know it sounds complicated but is less than changing your Arduino IDE to use precompiled libraries.
Für nodeMCU wollte platformio die libalgobsec.a außer im /lib-Verzeichnis auch noch in diesem Verzeichnis haben:
C:\Users\js\AppData\Roaming\SPB_Data\.platformio\packages\framework-arduinoespressif8266@1.20401.3-puya\tools\sdk\libc\xtensa-lx106-elf\lib
bzw. habe in platform.ini die buildflags dann so angepasst:
build_flags = -L/C:/Users/js/Documents/PlatformIO/Projects/190901-123302-nodemcuv2/lib/ -lalgobsec
Hallo Jürgen,
Du bist ja mächtig aktiv. Hast Du denn schon Informationen darüber, ob es sich lohnt, einen batteriebetriebenen Sensor mit dem BME680 zu machen? Dann würde ich entweder auf Dirk's Universalsensor (innen) einen Atmega644 (oder größer) draufpacken oder einen STM32F103 (parallel zum Arduino pro mini 3,3 V) draufpacken. Mein Favorit wäre ganz klar der Atmega, aber mit dem neuen Bootloader sollten Laien auch ganz gut mit dem STM Prozessor klarkommen können.
Gruß Peter
Hallo Peter,
ja das Thema hat mich mal wieder gepackt ;)
Mit der Library wäre es schon denkbar sogar mit den ATtinys einen Sensor zu bewerkstelligen.
Allerdings müsste man den Stromverbrauch analysieren und den Zwang kontinierlich den Sensor
in bestimmten Zeitintervallen abzufragen wären ja kontraproduktiv zum Batterie-Betrieb.
Will aber nicht sagen, dass es aus meiner Sicht nicht gehen würde. :D
Also müsste man da noch etwas Aufwand Richtung Batterie-Betrieb treiben...
Die Lib habe ich bis jetzt nur mit dem ESP8266 getestet. Evtl. sind noch einige spezifische Eigenschaften nur auf ESP ausgerichtet (z.B. Wire etc.).
Vermute aber, dass es mit einem ATMEL/Atmega oder STM32 ebenfalls gehen und nach Anpassungen auch lauffähig wäre.
Die Idee eines Batteriebetriebenen Devices sagt mir ebenfalls zu ;)
Meine Intension war es ja die Lib mit in ESPEasy mit einzubindenn, bin aber gerade mit dem Thema
platformIO doch etwas abgeschweift...
ZitatHast Du denn schon Informationen darüber, ob es sich lohnt, einen batteriebetriebenen Sensor mit dem BME680 zu machen?
Nein nocht nicht bewusst, da ja mit ESP unterwegs war. :(
Mit platformio + BSEC kommt halt immer was Neues dazu:
Zitat
Processing nodemcuv2 (platform: espressif8266; board: nodemcuv2; framework: arduino)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/nodemcuv2.html
PLATFORM: Espressif 8266 1.7.3 #7507605 > NodeMCU 1.0 (ESP-12E Module)
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES: toolchain-xtensa 1.40802.0 (4.8.2), tool-esptool 1.413.0 (4.13), framework-arduinoespressif8266 1.20401.3-puya (2.4.1)
Converting BSEC_Octopus_BME680.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Looking for Adafruit NeoPixel, library in registry
Found: https://platformio.org/lib/show/28/Adafruit NeoPixel
LibraryManager: Installing id=28
Adafruit NeoPixel @ 1.2.4 is already installed
Looking for Adafruit SSD1306, library in registry
Found: https://platformio.org/lib/show/135/Adafruit SSD1306
LibraryManager: Installing id=135
Adafruit SSD1306 @ 1.3.0 is already installed
Found 33 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Adafruit GFX Library> 1.5.6
| |-- <SPI> 1.0
|-- <EEPROM> 1.0
|-- <Adafruit NeoPixel> 1.2.4
|-- <Wire> 1.0
|-- <Adafruit SSD1306> 1.3.0
| |-- <Adafruit GFX Library> 1.5.6
| | |-- <SPI> 1.0
| |-- <SPI> 1.0
| |-- <Wire> 1.0
|-- <SPI> 1.0
Compiling .pio\build\nodemcuv2\src\BSEC_Octopus_BME680.ino.cpp.o
Linking .pio\build\nodemcuv2\firmware.elf
c:/users/js/appdata/roaming/spb_data/.platformio/packages/toolchain-xtensa@1.40802.0/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\firmware.elf section `.text' will not fit in region `iram1_0_seg'
.pio\build\nodemcuv2\src\BSEC_Octopus_BME680.ino.cpp.o:(.text.setup+0x38): undefined reference to `bsec_config_iaq'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\nodemcuv2\firmware.elf] Error 1
================================================================================================================================ [FAILED] Took 2.74 seconds ================================================================================================================================
i
2cRead und i2cWrite referece not found (sind Klassenmethoden des iaqSensor):
iaqSensor.i2cRead, iaqSensor.i2cWriteDaran bin ich noch am Knabbern...
firmware.elf section `.text' will not fit in region `iram1_0_seg'undefined reference to `bsec_config_iaq'Das kommt davon, wenn man Versionen durcheinander würfelt.
https://github.com/t-pi/Octopus_BSEC/blob/master/BSEC_AQI.ino (https://github.com/t-pi/Octopus_BSEC/blob/master/BSEC_AQI.ino)
https://github.com/t-pi/Octopus_BSEC (https://github.com/t-pi/Octopus_BSEC)
Mit den
Arduino-Einstellungen ...
Auch mit Arduino mit konfiguriertem BSEC:
BSEC_Octopus_BME680.ino:296: undefined reference to `bsec_config_iaq'Ah + Ohhh:
Zitatthe bsec_config_iaq is an encrypted string that cannot be modified by the end user. We validate the entire use-case in the lab and in the field for certain configurations, then release the appropriate configuration strings. If you have different requirements you can contact Bosch Sensortec technical support right here on this forum.
Die Jungs machen es einem nicht gerade einfach ... :(
Auskommentiert und auf die Konfiguration verzichtet:
//iaqSensor.setConfig((uint8_t *)bsec_config_iaq);Sketch uses 329225 bytes (31%) of program storage space. Maximum is 1044464 bytes.
Global variables use 33804 bytes (41%) of dynamic memory, leaving 48116 bytes for local variables. Maximum is 81920 bytes.
Mal zum Testen in ESPEasy, habe die nächst größere PlugIn-ID nach 119 gewählt.
Oh... Werde das morgen gern mal testen .... bin gespannt .
Zitat von: juergs am 01 September 2019, 23:18:08
Mal zum Testen in ESPEasy, habe die nächst größere PlugIn-ID nach 119 gewählt.
bekomme noch den Fehler in der _P120 ws iss_BME680 angeht.. obwohl ich #471 beachtet hatte...
exit status 1
js_BME680.h: No such file or directory
Zitatjs_BME680.h: No such file or directory
Dann hast Du die Lib nicht richtig installiert?
Je nach dem Tool, mit dem Du ESPEasy compilierst ...
In platformio ist es etwas schwieriger:
Im cmd-Fenster
"pio.exe lib install <kompletter Pfad zur Lib>" eingeben, um sie lokal ins Projekt einzubinden ...
Geht in der Arduino-IDE das Testprogrämmchen?
Beitrag #472 war gemeint . Sorry .
Der mit der ZIP.
Diese habe ich runtergeladen und in Arduino ide über Bibliotheken verwalten ... zip hinzugefügt ....
Hatte bisher immer so funktioniert ....
Werde aber noch mal genauer nachschauen ob's auch noch anders geht .
also ich habe eben nochmal aus der lib das JS_BME680 gelöscht.
habe dann die Zip nochmal runter geladen. und über Bibliothek zip hinzufügen die Datei gewählt. leider kein erfolg.... mach ich noch was falsch? andere Vorgehensweise?
Bei mir liegt die Lib dort (Arduino): C:\Users\js\Documents\Arduino\libraries\js_BME680
Einfach das zip entpacken und die cpp und .h datei mit dem ExamplesVerzeichnis dor hin kopieren .
Arduino neu starten dann bei Examples /Beispiele "js_BME680" suchen und das Testprogramm aufrufen und Compilieren ...
So schaut's bei mir aus .... komisch ....
Mit Test Programm aufrufen meinst du dann das esp easy mit dem integrierten p120 bme ino ?!
Nein! Einfach eine neue Arduino-IDE aufmachen.
Da ich eine Englische Version habe:
Über Datei -> Beispiele "JS_BME680" suchen dann werden zwei Verzeichnisse angezeigt:
Dann "js_bme680_sample" aussuchen und mal compilieren -> wenn OK ist die LIB richtig installiert.
Es hat sich ein kleiner Fehler eingeschlichen:
/*******************************************************************************
* Copyright 2017
* Written by Rossen Tchobanski (rosko@rosko.net)
* BSD license, all text above must be included in any redistribution
*
* Release notes:
Adafruit_BME680 Library v1.0.5 required (https://github.com/adafruit/Adafruit_BME680/tree/1.0.5)
*****************************************************************************/
Letzte Zeile war am Anfang auch ein /*, das führte dazu, dass platformio das Ganze möglicherweise ignoriert hat und die Arduino-IDE nur Fehler wirft ...
Anmerkung: war im Plugin 119 BME680 I2C Temp/Hum/Barometric/Pressure/Gas Resistence Sensor, also im Playground original so drin ...
Compiliere ich mit _P119_BME680.ino (Adafruit BME680) oder mit _P120_BME680.ino (js_BME680) geht der Compile jeweils ohne Fehler durch, allerdings erzeugt das Binary mit _P120_BME680.ino nur Exceptions
und das _P119_BME680.ino funktioniert.
Auch mit einem platformio-Lauf mit -v Option nichts Ersichtliches oder Aufschlussreiches .....
Ein Vergleich mit beiden Souce-Files lieferte auch nichts Bedeutendes...
Hier das Tesprogramm mit der Lib ist auch I.O. :
> Executing task in folder 190902-215322-arduino-blink: C:\Users\js\AppData\Roaming\SPB_Data\.platformio\penv\Scripts\platformio.exe device monitor <
--- Miniterm on COM6 115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[80.38] Temperature = 25.11 *C Pressure = 1011.34 hPa Humidity = 35.85 % Gas = 22.66 KOhms Approx. Altitude = 16.08 m
[90.38] Temperature = 25.14 *C Pressure = 1011.34 hPa Humidity = 36.28 % Gas = 25.28 KOhms Approx. Altitude = 16.08 m
[100.38] Temperature = 25.17 *C Pressure = 1011.30 hPa Humidity = 35.75 % Gas = 27.94 KOhms Approx. Altitude = 15.75 m
[110.38] Temperature = 25.17 *C Pressure = 1011.36 hPa Humidity = 35.64 % Gas = 30.44 KOhms Approx. Altitude = 15.91 m
Vielleicht weiß jemand Rat?
jupp, auch mit der Arduino IDE findet er Deine Library nicht. _P119_BME680.ino kompiliert (muss ich noch testen), aber _P120_BME680.ino kompiliert nicht (js_BME680.h not found). Die Beispielprogramme gehen aber beide zu kompilieren. Sehr strange ...
Gruß Peter
Hallo Peter, danke fürs Probieren
hier ist ein Fingerzeig:
https://www.letscontrolit.com/wiki/index.php/Tutorial_Arduino_Firmware_Upload (https://www.letscontrolit.com/wiki/index.php/Tutorial_Arduino_Firmware_Upload)
und hier:
https://waschto.eu/espeasy-eigene-oder-zusaetzliche-plugins-einbinden/ (https://waschto.eu/espeasy-eigene-oder-zusaetzliche-plugins-einbinden/)
https://www.bastelgarage.ch/index.php?route=extension/d_blog_module/post&post_id=15 (https://www.bastelgarage.ch/index.php?route=extension/d_blog_module/post&post_id=15)
https://diyprojects.io/esp-easy-develop-plugins/#.WUFqgZDyuUm (https://diyprojects.io/esp-easy-develop-plugins/#.WUFqgZDyuUm)
Selecting the plugin sets
In version ESPEasy v2 or higher its possible to select different plugin sets. Since we're using Arduino IDE instead of Platformio, its neccesary to select them in ESPEasy.ino.
In the top of the .ino file you find the defines you can uncomment to enable a plugin set:
//build all the normal stable plugins
//#define PLUGIN_BUILD_NORMAL
//build all plugins that are in test stadium
//#define PLUGIN_BUILD_TESTING
//build all plugins that still are being developed and are broken or incomplete
//#define PLUGIN_BUILD_DEV
Habe bei mir die Zeile #include JS_BME680 einfach gelöscht und die Lib durch die IDE setzen lassen ..
dann gings ... strange (:-((
Stellt sich natürlich die Frage: warum geht das Plugin _P119... ohne Änderung?
Bei espeasy gibt es eine Datei, wo die plugins mit Nummer bzw Bezeichnung eingetragen werden müssen, glaube ich.
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
hallo Sascha,
dann müsste ein Umbenennen der Datei auf _119P.... funktionieren.
Da ich noch Deubgausgaben in der Lib habe könnte das noch Probleme geben.
Wichtig wäre erst mal ein funtionierender Compile auf dem Esp.
//#define USES_P117 // Neopixels
//#define USES_P117 // Nextion
#define USES_P118 // CCS811
#define USES_P119 // BME680
#define USES_P120 // Thermocouple
#define USES_P121 // Candle
#define USES_P122 // NeoPixel (MERGED?)
#define USES_P123 // NeoPixel_Clock (MERGED?)
#define USES_P124 // NeoPixelBusFX
...
in define_plugin_sets.h
Aha, deshalb!
Ok, ein Schritt weiter.
Es reicht natürlich nicht, nur das File umzubenennen, sondern die 120_ids mussten auch wieder zurück auf 119.
Mit der produtiv-platformio-Konfiguration stehe ich noch auf Kriegsfuß, aber wenigstens ein Compile
der abgespeckten platformio.ini-Version war erfolgreich (sonst dauert die Erstellung aller Varianten doch etwas länger...):
Environment Status Duration
----------------- -------- ------------
custom_ESP8266_4M FAILED 00:00:10.711
normal_ESP8266_4M SUCCESS 00:00:27.040
d1_mini FAILED 00:00:00.849
Nach einem Clean:
Environment Status Duration
----------------- -------- ------------
custom_ESP8266_4M SUCCESS 00:00:24.235
normal_ESP8266_4M SUCCESS 00:00:26.106
d1_mini FAILED 00:00:00.854
Es kommen zwar noch Exceptions, aber die Lib wird angesprochen ...
Dann kommt es noch zum Konflikt, möglicherweise mit der seriellen Debugausgabe.
oid JS_BME680Class::do_begin()
{
DEBUG_BEGIN; //Serial.begin(115200);
delay(3000); // wait debug console to settle
DEBUG_PRINT("");
DEBUG_PRINT(F("*** Started!"));
Aber immerhin wird die Lib gestartet, dann kann ich morgen weitermachen und darauf aufbauen ... ;D :)
Anbei die auf 119 umfunktionierte 120er...
Ok, manchmal muss man wirklich einen oder zwei Schritte zurück gehen oder ein paar Nächte d'rüber schlafen ... ::)
... und dann den langen Text nochmal neu eingeben, wenn der FHEM-Upload schief geht ...
- neues ESPEasy-Zip entpackt
- Adafruit_BME680_Library +Adafruit_Unified_Sensor + js_BME680 - Libraries in das \lib-Verzeichnis zu den anderen ESPEasy-Libs kopiert
- neue Version von Arduino portable benutzt
- \src kopiert in \ESPEasy-Verzeichnis
- _P119_BME680.ino ins \ESPEasy-Verzeichnis kopiert
- in Arduino mit "add file: _P119_BME680.ino" hinzugefügt
- #include <js_BME680.h> als ersten in ESPEasy.ino eingefügt, sonst beschwert sich die IDE ...
- Den default Arduino libraries-Ordner in C:\Users\js\Documents\Arduino\ umgebogen: von C:\Users\js\Documents\Arduino\libraries nach D:\Temp\ESPEasy-mega.org\lib
- dafür habe ich ein Symlink erstellt ind nachdem ich den Orginal-Arduino-Lib-Ordner umbenannt habe...
- Symlink als Admin erstellen: C:\Users\js\Documents\Arduino>mklink /D libraries D:\Temp\ESPEasy-mega.org\lib
- Arduino-Compile läuft mit Warnungen durch: erste Debug-Ausgabe nach Upload SPIFFS fehlt -> von "none" auf 1M konfiguriert.
- Zwei mal den ESP resetten.
ZitatHauptproblem: Im Laufe der Zeit sammeln sich so einige Libs im \libraries-Ordner von Arduino an.
Das gibt bei Arduino nur Ärger mit gleichen Lib-Header-Namen, wie in meinem Fall ...
Eine bestehende Konfiguration von einer vorigen ESPEasy-Installation wurde einfach übernommen ....auch gut ...
Ggf. muss ich die Lib noch prüfen und ggf. Timings noch klären, aber fürs erste gehts es schon mal ... der TVOC-Wert wird noch nicht übergeben, liefert "nan" im Moment.
Mal schauen woran das liegt ... Also etwas Kleinarbeit ist von Nöten ... immerhin mal ein Anfang! ;) :D
[/list]
.. und die erzeugte ESP8266-Binary (0x76 I2C-Adresse!)
Hallo Jürgen,
Zitat von: juergs am 04 September 2019, 21:02:37
- in Arduino mit "add file: _P119_BME680.ino" hinzugefügt
und ich dachte, die IDE nimmt automatisch alle Dateien mit der Endung .cpp/.h und .ino automatisch mit rein?
Auf jeden Fall: Gratulation zum (Teil-)Erfolg!
Gruß Peter
Hallo Peter,
vielen Dank , war wirklich ein hartes Stück Arbeit!
Muß noch mit mehr Debugausgaben schauen wie sich das PlugIn bezüglich Daten verhält ...
Aber bin erst mal froh, ein gelungenen Compile fabriziert zu haben.
Hauptproblem: Im Laufe der Zeit sammeln sich so einige Libs im \libraries-Ordner von Arduino an.
Das gibt bei Arduino nur Ärger mit gleichen Lib-Header-Namen, wie in meinem Fall ...
Aber mit der gezeigten Methode kann man sich die Libs ja passend zurechtbiegen ... ;)
Grüße,
Jürgen
Nur Tracing eingebaut und ein paar kleine Änderungen:
INIT : Booting version: (custom) (ESP82xx Core 2_5_0, NONOS SDK 3.0.0-dev(c0f7b44), LWIP: 2.1.2)
13054 : INIT : Free RAM:35616
13055 : INIT : Warm boot #2 Last Task: Background Task - Restart Reason: External System
13061 : FS : Mounting...
13088 : FS : Mount successful, used 75802 bytes of 957314
13101 : CRC : No program memory checksum found. Check output of crc2.py
13145 : CRC : SecuritySettings CRC ...OK
js_bme680.cpp:435: void JS_BME680Class::do_begin()
js_bme680.cpp:488: void JS_BME680Class::do_begin()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:231: bme680VocValid = 0
js_bme680.cpp:235: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:268: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:283: void JS_BME680Class::getBme680Readings()
js_bme680.cpp:295: tVoc = 228.04
js_bme680.cpp:306: str_tVoc = 228
js_bme680.cpp:331: str_ratio = 1.0859
:D
Benutze das Ocotpus-Board mit BME280 auf Adresse 0x77 (!), deshalb der BME680 mit pemue's Sensor-Platine (ohne Pullups, vielleicht auf Board ...).
Die Trace-Lib von: https://github.com/bblanchon/ArduinoTrace (https://github.com/bblanchon/ArduinoTrace)
Lasse das mal länger laufen und schaue mal auf die "Langzeitstabilität", bzw. der neue Sensor braucht auch 4 Tage um sich einzubrennen... ;)
Da könnte ich mir in Verbindung mit Neopixel auch etwas vorstellen ... ;)
Die lauffähige ESPEasy-Version mit BME680 und TVoc-Ausgabe !
Wenige Debug-Ausgaben sind aktiv.
ESP12E-----------BME680 @ 0x76 (SDO = GND)
GND------------>GND
3.3V------------>3.3V
D2------------>SDA
D1------------>SCL
Falls jemand mit testen möchte ... und die Implementierung in FHEM schildern möchte (MQTT ?)... ;)
Infos zu ESPEasy: https://waschto.eu/easyesp/ (https://waschto.eu/easyesp/) . HowTo ESPEasy Konfiguration und Live-Demo.
Hallo Jürgen,
da könnte man doch mal folgende Kombinationen testen:
- nanoLGW mit BME680
- mapleMini mit BME680 und Thommy's Sketch
- WeMosD1 mini mit BME680 und Deinem Sketch
- wenn ich MQTT eingerichtet bekomme, dann noch locutus' TVOC Sensor von AMS (CCS811)
Muss mal schauen, was ich davon hinbekomme.
Gruß Peter
Hallo Peter,
gerne, die nanoLGW ohne den RFM69 wäre mir auch in den Sinn gekommen ;-)
Wenn's klappt wäre das super. Mit der Lib würde das aber auch auf dem 328er gehen, ggf. mit CC1101 etc. (Dirks Universal-Sensor...)
Der Maple mit dem Air602-WiFi-Sender ... oho!
Thommy's Sketch? Ist mir entgangen ...
Die jetzige Binary ist als Target: "Wemos D1 und D2 mini" compiliert... allerdings nur Adresse: 0x76.
Das Umschalten auf 0x77 müsste in ESPEasy auch klappen, wenn ich es eingebaut bekomme ...
Wenn ich am WoE mehr Zeit habe, liefere ich die Sourcen dazu ...
Allerdings muss ich noch Erfahrungen über das Timing-Verhalten des ESPEasy-Subsystems wie z.B. in Verbindung mit anderen Sensoren
sammeln.... und das interne Logging tiefer ergründen: z.B. für die Logausgabe im Browser.
Geht:
4923376: EVENT: Bme680#Temperature=23.23
4923403: EVENT: Bme680#Humidity=40.09
4923429: EVENT: Bme680#Pressure=1009.12
4923454: EVENT: Bme680#TVoc=201.09
4933763: EVENT: Bme680#Temperature=23.23
4933825: EVENT: Bme680#Humidity=40.09
4933856: EVENT: Bme680#Pressure=1009.12
4933881: EVENT: Bme680#TVoc=205.70
4934767: WD : Uptime 82 ConnectFailures 0 FreeMem 23776 WiFiStatus 3
4943373: EVENT: Bme680#Temperature=23.23
4943399: EVENT: Bme680#Humidity=40.09
4943424: EVENT: Bme680#Pressure=1009.12
4943451: EVENT: Bme680#TVoc=205.70
Grüße,
Jürgen
.. und die Rules (https://espeasy.readthedocs.io/en/latest/Rules/Rules.html) passend für Neopixel und TVoc ansteuern ...
Meine eigene Interpretation zum Testen .. ;)
//--- red
on Bme680#TVoc>=400 do
TaskValueSet 3,1,0
TaskValueSet 3,2,0
TaskValueSet 3,3,1
if [Bme680#TVoc] < 500
neopixel, 1,255,0,0
endif
endon
//--- orange
on Bme680#TVoc>=300 do
TaskValueSet 3,1,0
TaskValueSet 3,2,0
TaskValueSet 3,3,1
if [Bme680#TVoc] < 400
neopixel, 1,255,102,204
endif
endon
//--- yellow
on Bme680#TVoc>=200 do
TaskValueSet 3,1,0
TaskValueSet 3,2,1
TaskValueSet 3,3,0
if [Bme680#TVoc] < 300
neopixel, 1,255,96,0
endif
endon
//--- green
on Bme680#TVoc>=100 do
TaskValueSet 3,1,1
if [Bme680#TVoc] < 200
neopixel, 1,0,255,50
endif
endon
//--- no TVOC activity
on Bme680#TVoc=0 do
TaskValueSet 3,1,0
neopixel, 1,255,255,255
endonAuffallend die hohe Abweichung des BME280-Sensors, der auf der Octopusplatine sitzt.
Der BME680-Wert ist wahrscheinlicher ... :)
ZitatLuftdruck
1005,7 hPa (1023 bezogen auf NN)
Luftfeuchtigkeit
54,9 %
Hi,
es gibt verschiedene Breakout Boards mit dem BME680. Macht das einen Unterschied?
Hier für 20€ aus Deutschland: https://shop.pimoroni.de/products/bme680-breakout
Für 12€ aus China: https://www.ebay.de/itm/CJMCU-680-BME680-Atmospheric-Pressure-Sensor-Temperature-Humidity-BMP280-SI7021/401739634718?hash=item5d898c581e
Die China-Variante hat noch zusätzlich einen SDO und CS Pin, die pirimoni Variante nicht.
Hallo Tobias,
Zitat von: Tobias am 07 September 2019, 08:33:25
es gibt verschiedene Breakout Boards mit dem BME680. Macht das einen Unterschied?
nein, es muss nur der Adress Pin mit rausgeführt sein.
Ich habe mal eines bei Waterott gekauft, das war relativ preiswert und schnell da.
Zitat von: Tobias am 07 September 2019, 08:33:25
Die China-Variante hat noch zusätzlich einen SDO und CS Pin, die pirimoni Variante nicht.
Der Baustein kann SPI und I2C, hier wird nur I2C verwendet, daher werden die extra Pins in unserer Anwendung nicht verwendet.
Gruß Peter
Hallo Tobias,
den BME680 alleine bekommt man für ca. 9,45 € + Porto , dh. Breakboards < 20€ wären eigentlich preislich vertretbar.
Lohnt sich dafür fast nicht ein Board selbst zu machen und zu bestücken ...
Reich-elt bietet auch ein Breakoutboard für den BME680 an ...
Zum Sensor selbst: Habe meiner Lib noch einen Kalman-Filter (https://github.com/TKJElectronics/KalmanFilter) auf den tVoc-Rohwert spendiert.
Blau = tVOC (Rohwert)
Rot = tVoc (Kalman gefiltert)
Grün = Temperatur
Orange = Luftfeuchte
In EspEasy sind leider nur 4 Sensorwerte möglich, so dass ich noch eine Möglichkeit in den Device-Konfigurationsdialog einbauen muss,
um den gefilterten Wert, statt dem tVoc-Rohwert anzuzeigen, bzw. zwischen beiden zu wählen.
Damit müssten auch noch zusätzlich I2C-Adress-Auswahl + T-Offset + H-Offset - Parametrierung hinzukommen.
Gerade fast Off-Topic: Basic setup for BME680 and NodeMCU (ESP12E) + platformIO (https://www.popsblog.me/post/19) ;)
Die bisher günstigste Methode zum Einsatz des BME680: => gy-mcu680v1 (https://www.hackster.io/xxlukas84/bme680-gy-mcu680v1-indoor-air-quality-meter-901d02) (seriellle Anbindung, scheinbar mit BSEC). Dafür gibt es aber noch kein ESPEasy-Image/Plugin (aber eine Idee (https://forum.fhem.de/index.php/topic,78619.msg881365.html#msg881365), Idee2 (https://github.com/adrianalin/bme680_nodemcu_socketio) dafür...)
Muss aber erst mal die Parametriermöglichkeiten in einem ESPEasy-Plugin verstehen und anwenden ...
Geschafft, die BME680-ESPEasy-Konfiguration des Devices steht!
Hier die erste Version mit Allem ;)
Der Debug-Output sieht sehr gut aus:
723 : BME680 : init
726 : BME680 : PLUGIN_READ initialized.
728 : BME680 : PLUGIN_READ-Settings: I2C: 118 Elevation: 180 Filter: 1 Toffs: 1 Hoffs: 1 Plot: 0 Debug: 1
*** JS_BME680Class started!
JS_BME680.resitance beeing zero! First Reading?
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 277
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 267
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 257
. . .
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 67
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 57
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 47
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 37
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 27
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 17
JS_BME680.bme680VocValid not ready! Wait about 300 sec (5 min) to warm up ... 7
--------------------------------------
Timestamp: 302.62
tVoc: 128.88
tVocEst: 64.44
Approx (tV): 128.88
Approx (tV2): 12.89
Ratio: 1.00
Ratio_log: 0.00
ABC_base: 8355825
Abs_Hum: 10.89
Resistance (raw): 109263
Resistance (filt.): 109263.00
Temp: 23.64
Hum: 10.89
Press: 1004.77
Dewpoint: 12.95
Alt: 25820.40
T-Offs: 1.00
H-Offs: 0.00
--------------------------------------
Bis auf die Berechnung der Höhe (die in ESPEasy nicht angezeigt wird ....) ;)
Durch setzen des Filters wird der gefilterte/geglättete TVOC-Wert ausgegeben.
Das macht bei der Empfindlichkeit des Sensors auf Luftzug auch Sinn ....
Änderungen an Konfigurationen werden nach TOOLS -> Reboot übernommen.
Anleitung + Code: https://github.com/juergs/ESPEasy_BME680_TVOC (https://github.com/juergs/ESPEasy_BME680_TVOC)
Mit Arduino compiliert (siehe auch Hinweise dazu auf github)!
Bei Fragen, fragen .... Verwendung ohne Gewähr :D ;D
Anmerkung:
Die Aufwärmzeit ist auf 5 Minuten konfiguriert, in dieser Zeit kommt der Wert TVOC = 0.
Danach erst sollten TVOC Werte angezeigt werden! Also etwas Geduld beim Anwerfen ...
Grüße + viel Spaß beim Testen.
Jürgen
BME680 vs. Dallas 18B20 (12Bit) (https://www.letscontrolit.com/wiki/index.php/Dallas_DS18b20)
Falls die Dezimale eine Rolle spielen sollten ... ;D ;)
Der BME war noch in der 5-Minuten Aufwärmphase ... deshalb kein TVOC-Wert.
... und ein paar super Kurven ( nein, nicht 90-60-90) ;D
IAQ (mit BSEC, nanoLGW) vs. TVOC (SLINK)...
Fehlt noch die MQTT-Bridge zu ESPEasy ...
Zitat von: juergs am 08 September 2019, 17:07:01
Anleitung + Code: https://github.com/juergs/ESPEasy_BME680_TVOC (https://github.com/juergs/ESPEasy_BME680_TVOC)
Mit Arduino compiliert (siehe auch Hinweise dazu auf github)!
Bei Fragen, fragen .... Verwendung ohne Gewähr :D ;D
...
Grüße + viel Spaß beim Testen.
Jürgen
Hi,
vielen Dank für die tolle Arbeit, kommt gerade recht für meine China Lieferung des dfrobot bme680 boards:)
Leider blinkt mein D1 mini (azdelivery) nach dem flashen nur alle 6 Sekunden. Ich vermute mal, dass mein esp8266 nicht mit dem sketch klarkommt (leider habe ich keine Auflistung für das interpretieren blinkender LEDs gefunden). Daher habe ich mich auch (erstmals) an ein kompilieren gemäß Deiner github Anleitung getraut, leider mit dem selben Ergebnis. Mit welchen boards hast Du denn bisher positive Rückmeldung gehabt/bekommen?
Als Warnung, ich bin raspi veteran, aber noch esp Neuling...
Hi twenta,
diese Version arbeitet im Moment nur mit einer Sensoradresse von 0x76 zusammen. Das Blinken bedeutet, dass Dein D1 einen Reset auslöst und neu startet.
Das Verhalten werde ich noch Ändern.
Der Sketch sollte mit nodeMCU und Wemos D1&D2 mini ESP8266 funktionieren.
Dieser Breakout liegt z.B. auf 0x77 (!) : https://learn.adafruit.com/adafruit-bme680-humidity-temperature-barometic-pressure-voc-gas/arduino-wiring-test (https://learn.adafruit.com/adafruit-bme680-humidity-temperature-barometic-pressure-voc-gas/arduino-wiring-test)
Also sicherstellen, dass der Adress-Pin auf Gnd liegt.
Du kannst das prüfen, wenn Du erst mal ein BME680-Standard Sketch (z.B. Adafruit/dfrobot) zum Testen benutzt, ob Deine Anordnung funktioniert und überhaupt Werte liefert.
Beobachte auch den Output im Seriellen Monitor.
In Arduino SPIFF = "1M" konfiguriert?
Etwas "neue" Theorie für den BME + ESP32: https://github.com/G6EJD/BME680-Example (https://github.com/G6EJD/BME680-Example)
--------------------------------------------------------------
Sensor Readings:
Temperature = 25.98°C
Pressure = 1014.88 hPa
Humidity = 48.6%
Gas = 361708.56 ohms
Qualitative Air Quality Index comprised of 21% Humidity and 75% Gas
IAQ Score = 20, air quality is Good
--------------------------------------------------------------
Sensor Readings:
Temperature = 26.45°C
Pressure = 1014.88 hPa
Humidity = 48.0%
Gas = 363268.66 ohms
Qualitative Air Quality Index comprised of 21% Humidity and 75% Gas
IAQ Score = 20, air quality is Good
--------------------------------------------------------------
Zitat von: juergs am 12 September 2019, 11:27:14
diese Version arbeitet im Moment nur mit einer Sensoradresse von 0x76 zusammen. Das Blinken bedeutet, dass Dein D1 einen Reset auslöst und neu startet.
Also sicherstellen, dass der Adress-Pin auf Gnd liegt.
D
u kannst das prüfen, wenn Du erst mal ein BME680-Standard Sketch (z.B. Adafruit/dfrobot) zum Testen benutzt, ob Deine Anordnung funktioniert und überhaupt Werte liefert.
Beobachte auch den Output im Seriellen Monitor.
Hallo Jürgen,
danke mit diesen Hinweisen habe ich es hinbekommen. Außerdem war mir nicht bewusst, dass die von mir genutzte "post flash action" (WIFI, WIFI passwort) folgenlos waren und der d1 mini im AP modus gestartet ist. Ich beobachte nun mal, was er so an Daten liefert :)
Habe einige Verbesserungen eingebaut:
Jetzt sollte auch die Adresse 0x77 für den BME einsetzbar sein.
Dafür habe ich die Initialiserung des BME an eine passendere Stelle gelegt.
Das hat den Vorteil, dass ein nicht angeschlossener BME680 in ESPEasy keine Exceptions mehr erzeugt
und sich ESPEasy aufrufen läßt, um über den Device-Konfiguratins-Dialog mittels Adress-Auswahl, Device-ENABLE-Checkbox gesetzt und SUBMIT-Button gedrückt, konfigurieren lässt.
Erst dann läuft erst die Initialisierung des BMEs los.
Die Zykluszeit habe ich von 10 auf 12s hochgesetzt, da dies Bosch in https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BME680-AN014.pdf (https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BME680-AN014.pdf)
auf Seite 10 vorschlägt. Messwerte werden im 12s Rythmus vom BME gelesen, aber erst nach der konfigurierten Zyklus-Zeit (default=60s) an die ESPEasy-Oberfläche geliefert.
Alle anderen Änderungen wie z.B. Plot + Debugausgabe werden erst nach einem Reset wirksam ...
* Github Repository (https://github.com/juergs/ESPEasy_BME680_TVOC) ist aktualisiert. :D
Vergleich der TVOC und IAQ-Berechnung von G6EJD (https://github.com/G6EJD/BME680-Example) mit IAQ-Bewertungen von 20 (gut) .. 500 (schlecht)
Offenes Fenster -> geschlossen ...
TVOC vs. IAQ
Verbesserte ESPEasy-Rules mit WS2812B an D5 (GPIO14):
Zitat//--- red
on bme680#TVoc>=400 do
if [bme680#TVoc] < 500
neopixel, 1,255,0,0
endif
endon
//--- orange
on bme680#TVoc>=300 do
if [bme680#TVoc] < 400
neopixel, 1,255,153,0
endif
endon
//--- yellow
on bme680#TVoc>=200 do
if [bme680#TVoc] < 300
neopixel, 1,255,255,0
endif
endon
//--- green
on bme680#TVoc>=100 do
if [bme680#TVoc] < 200
neopixel, 1,0,255,0
endif
endon
//--- no TVOC activity (blue)
on bme680#TVoc=0 do
neopixel, 1,0,0,255
endon
Hat jemand ein Hinweis/Konfiguration für ESPEasy-BMEx80 über mosquitto /MQTT2_SERVER oder FHEM_HTTP an FHEM?
Zur Not, geht auch Jörgs SLINK-Protokoll (zusätzliche FHEM-Module für UDP-Broadcast-Empfang (https://github.com/herrmannj/AirQuality/tree/master/FHEM)) (!) von ESP-Easy über UDP an FHEM!
;D :D
Hier die ESPEasy-Version, um SLINK-UDP-Wahlmöglichkeit ergänzt.
Ohne MQTT oder FHEM_HTTP-Protokoll ...
Achtung: zusätzliche Module (siehe Antwort #517) für FHEM-Datenempfang erforderlich!
ohne es getestet zu haben, über CONTROLLER kann man doch eigentlich einen Mosquitto Client definieren..?? Oder hast du es explizit nicht eingebunden?
Hallo Tobias,
ja habe die Controller-Typ-Definitionen gesehen und auch ausprobiert. (Man sieht es in #518 in der Definition des BME680-Devices ...)
Auf dem Pi habe ich mosquito auf 1883 und MQTT2_FHEM_Server auf 1884 definiert.
Dorthin kann ich auch Messages "manuell" schicken ...
Mir geht es eigentlich um die Konfiguration der Controller ... und des MQTT2_Devices in FHEM und die Übermittlung der vier Messdaten ...
Wenn Du ein Beispiel-Tipp hast?
Grüße,
Jürgen
MQTT-Infos zu MQTT2_FHEM_Server + Device hier: https://wiki.fhem.de/wiki/Sonoff#MQTT_und_TASMOTA (https://wiki.fhem.de/wiki/Sonoff#MQTT_und_TASMOTA)
und Attribut "autocreate = 1"
https://www.letscontrolit.com/wiki/index.php?title=ESP_Easy_web_interface#Controllers_page_.28version_2.0.2B.29 (https://www.letscontrolit.com/wiki/index.php?title=ESP_Easy_web_interface#Controllers_page_.28version_2.0.2B.29)
Hallo Jürgen,
ich bin mir nicht sicher, ob ich Dein Problem verstehe, da zumindest in ESPEasy die Konfig doch recht einfach ist:
Hier eine Beschreibung, wie ich es mosquitto als mqtt2 client in fhem angelegt habe...
Unter Controller Deine IP des mqtt servers (vorzugsweise mosquito) eingeben (siehe mqtt1.png)
Dann unter Devices->Data aquisition->Send to Controller die checkbox der Nummer des gerade erstellten mqtt servers auswählen.
Unter fhem wird es dann ziemlich fummelig ich habe es mit viel trial&error hinbekommen (mqtt2_client, https://fhem.de/commandref.html#MQTT2_CLIENT):
Ich habe ein Device mqtt2_client mit dem Namen mqttBorker angelegt
define <name> MQTT2_CLIENT <host>:<port>
und als attribs autocreate simple und subscription # gewählt (siehe mqtt2.png)
Nun fehlt noch das mqtt2_device (https://fhem.de/commandref.html#MQTT2_DEVICE):
Ich bin mir nicht mehr sicher, ob nun das mqtt2_device automatisch angelegt wurde (siehe mqtt3.png).
Hier hilft es dass attrTemplate A_00_MQTT2_CLIENT_general_bridge (oder 0_00_General_Info, bin mir nicht mehr ganz sicher... einfach ausprobieren) auszuwählen.
Ich hoffe das hilft...
Grüße
Zitat von: juergs am 15 September 2019, 17:08:17
Hat jemand ein Hinweis/Konfiguration für ESPEasy-BMEx80 über mosquitto /MQTT2_SERVER oder FHEM_HTTP an FHEM?
Hallo Jürgen,
hätte da was:
UniversalSensor V3.3 kann jetzt MQTT auf ESP8266 (WiFi) und natürlich werden jetzt auch CO2 und VOC über die BSEC Lib angezeigt 8)
Hab nur das Webinterface zum konfigurieren nicht ganz fertig, sonst läuft alles !
Wäre was zum testen auf dem NanoLGW ohne RFM69 ;)
Der Sensor sendet per WLAN die MQTT Daten an meinen RaspberryPi auf dem Mosquitto (und Fhem) als MQTT-Broker läuft.
Fhem holt sich die Daten dann von Mosquitto. Fertig ;)
Super easy und vor allem sehr einfach erweiterbar !
anbei mal ein paar Impressionen ...
Übrigends, Respekt und Hut ab für Deine Arbeit an ESP Easy !!!
Gruß Thomas
Hier hab ich mal eine BME280 Konfiguration von mir.
D1 mini mit ESP Easy sendet via MQTT an Mosquitto, fhem holt die Daten von Mosquitto.
siehe Bildchen ...
Gruß Thomas
hier noch die fhem Konfig:
define BME280_mqtt_sensor MQTT_DEVICE
attr BME280_mqtt_sensor IODev MQTT_Broker
attr BME280_mqtt_sensor alias BME280-Sensor
attr BME280_mqtt_sensor autoSubscribeReadings Controller_/BME280/+ <- Diese Zeile sucht und trägt alle Topics automatisch ein, die unter Controller_/BME280/ gefunden werden !
attr BME280_mqtt_sensor group Sensoren
attr BME280_mqtt_sensor room MQTT,Sensoren
attr BME280_mqtt_sensor stateFormat temperature °C, humidity %, pressure mBar
Diese Zeilen werden automatisch von autosubscribeReadings generiert ;o) :
attr BME280_mqtt_sensor subscribeReading_humidity Controller_Tor_Einfahrt/BME280/humidity
attr BME280_mqtt_sensor subscribeReading_pressure Controller_Tor_Einfahrt/BME280/pressure
attr BME280_mqtt_sensor subscribeReading_temperature Controller_Tor_Einfahrt/BME280/temperature
Hallo Thomas,
C-O-O-L !
:) :D
Danke Allen für die MQTT-Infos!
Die Infos dazu sind sehr vielfältig und müssen erst mal auf Brauchbarkeit und Anwendbarkeit auf den BME beurteilt werden.
Die Fhem-Seite hatte mir als MQTT-Neuling bisher noch gefehlt und die Konfiguration "LWL" und der passende Controller-Typ etc.
Insbesondere wg. Authentifizierung beim Broker und "Connection Lost"-Meldungen etc ...
... und "autoSubscribeReadings" ;)
Grüße,
Jürgen
Der Connect gegen mosquito geht mit Authentifizierung durch:
Zitat88257606: EVENT: Clock#Time=Tue,23:15
88258701: BME680-Read: performed measurement!
88258705: BME680-Read: get filtered value.
88258717:
88258724: EVENT: bme680#Temperature=24.34
88258814: EVENT: bme680#Humidity=56.33
88258871: EVENT: bme680#Pressure=1005.73
88258971: EVENT: bme680#TVOC=902.45
88258983: ACT : neopixel, 1,255,0,128
88261974: WD : Uptime 1471 ConnectFailures 0 FreeMem 22560 WiFiStatus 3
88274501: MQTT : Intentional reconnect
88274545: MQTT : Connected to broker with client ID: ESP_Easy_2
88274551: Subscribed to: ESP_Easy/#
88274553: EVENT: MQTT#Connected
88275950: BME680-Read: performed measurement!
88275954: BME680-Read: get filtered value.
88275967:
88275972: EVENT: bme680#Temperature=24.34
88276066: EVENT: bme680#Humidity=56.33
88276125: EVENT: bme680#Pressure=1005.73
88276182: EVENT: bme680#TVOC=904.41
88276194: ACT : neopixel, 1,255,0,128
88291974: WD : Uptime 1472 ConnectFailures 0 FreeMem 22480 WiFiStatus 3
Client mosqsub/22105-raspberry received PUBLISH (d0, q0, r0, m0, 'ESP_Easy/bme680/TVOC', ... (5 bytes))
949.1
Client mosqsub/22105-raspberry sending PINGREQ
Client mosqsub/22105-raspberry received PINGRESP
Client mosqsub/22105-raspberry received PUBLISH (d0, q0, r0, m0, 'ESP_Easy/bme680/Temperature', ... (4 bytes))
24.3
Client mosqsub/22105-raspberry received PUBLISH (d0, q0, r0, m0, 'ESP_Easy/bme680/Humidity', ... (4 bytes))
56.3
Client mosqsub/22105-raspberry received PUBLISH (d0, q0, r0, m0, 'ESP_Easy/bme680/Pressure', ... (6 bytes))
1005.7
Client mosqsub/22105-raspberry received PUBLISH (d0, q0, r0, m0, 'ESP_Easy/bme680/TVOC', ... (5 bytes))
950.5
Das Senden auf den mosquitto-Server klappt schon mal. :D (.. aber nicht auf den MQTT2_FHEM_Server)
Mit einem recht hohen TVOC Wert ... :(
Aber: mir dämmert! -> Habe schon seit langem kein FHEM-Update mehr gemacht! Es fehlt mit das MQTT-Broker-Device und die Attribute!
Muss also erst mal alles sichern ... dann updaten....
Ggf. geht es morgen hier weiter: https://wiki.fhem.de/wiki/MQTT#FHEM-externer_Broker (https://wiki.fhem.de/wiki/MQTT#FHEM-externer_Broker)
Grüße,
Jürgen
Bevor ich meine größere Abhandlung über meine MQTT-Erfahrungen vorstelle, ;D
hier mal ein Zwischen-Report für drei -SLINK-Instanzen (2*ESPEasy und 1*nanoLGW)
und einem Universal-Sensor, unten mit BSEC.
Anmerkung: im gleichen Raum im 2m Umkreis ...
Kalman-Filter gegen gleitenden Mittelwert.
Hier meine erste
funktionierende MQTT-Konfiguration mittels mosquitto-Broker:
define myBroker MQTT2_CLIENT 192.168.xxx.yyy:1883
setuuid myBroker 5d827ab6-f33f-72b0-8081-59810acb03c6817e
attr myBroker autocreate simple
attr myBroker disable 0
attr myBroker mqttVersion 3.1
attr myBroker room MQTT
attr myBroker subscriptions ESP_Easy/BME680/#
attr myBroker username pi
attr myBroker verbose 4
define mqtt2_client MQTT2_CLIENT 127.0.0.1:1883
setuuid mqtt2_client 5d83c812-f33f-yyyy-4092-e3f9605052xxxxxx
attr mqtt2_client autocreate 1
attr mqtt2_client rawEvents ESP_Easy/BME680/:.*
attr mqtt2_client room test
attr mqtt2_client subscriptions #
attr mqtt2_client username pi
define MQTT2_mqtt2_client MQTT2_DEVICE mqtt2_client
setuuid MQTT2_mqtt2_client 5d83c849-f33f-72b0-155e-d8648a4fbbcc7191
attr MQTT2_mqtt2_client IODev mqtt2_client
attr MQTT2_mqtt2_client readingList mqtt2_client:fhem/out/LWT:.* LWT\
mqtt2_client:Test/Temp:.* Temp\
mqtt2_client:Connect:.* Connect\
mqtt2_client:ESP_Easy:.* ESP_Easy\
mqtt2_client:ESP_Easy/bme680/Temperature:.* Temperature\
mqtt2_client:ESP_Easy/bme680/Humidity:.* Humidity\
mqtt2_client:ESP_Easy/bme680/Pressure:.* Pressure\
mqtt2_client:ESP_Easy/bme680/TVOC:.* TVOC
attr MQTT2_mqtt2_client room MQTT2_DEVICE
define FileLog_MQTT2_mqtt2_client FileLog ./log/MQTT2_mqtt2_client-%Y.log MQTT2_mqtt2_client
setuuid FileLog_MQTT2_mqtt2_client 5d83c8cf-f33f-xxxx-932b-yyyyy
attr FileLog_MQTT2_mqtt2_client logtype text
attr FileLog_MQTT2_mqtt2_client room MQTT2_DEVICE
define SVG_FileLog_MQTT2_mqtt2_client_1 SVG FileLog_MQTT2_mqtt2_client:SVG_FileLog_MQTT2_mqtt2_client_1:CURRENT
setuuid SVG_FileLog_MQTT2_mqtt2_client_1 5d83c8cf-f33f-xxxx-932b-yyyyy
attr SVG_FileLog_MQTT2_mqtt2_client_1 room CO2-Messung,IAQ,MQTT2_DEVICE Wichtig war, bei geforderter Authentifizierung Username zu definieren und das Passwort mit
set password <pwd> einzugeben.
Ausschlaggebend war der Wiki-Eintrag "Defintion für Motion-Sensor" (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele) und dieser: EBUS-MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2)
ZitatTemp/Hum. Sensor
tbd ... :(
Motion Sensor
Als MQTT-Server wird hier mosquitto verwendet, als IO-Device wird daher ein MQTT2_CLIENT-Gerät definiert:
defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883
attr mqtt2_client autocreate 1
attr mqtt2_client rawEvents zighttps://forum.fhem.de/Themes/fhem-curve-green/images/bbc/url.gifbee2mqtt/GB_Bewegungsmelder:.*
attr mqtt2_client room test
attr mqtt2_client subscriptions #
Angepasst: Eingegeben username, pwd und topic angepasst, dann legte FHEM den Rest (MQTT2_CLIENT) automatisch an und ich den SVG...
Username/pwd weil ich den Mosquitto server so bei der installation konfiguriert hatte...
Auch automatisch eingelesen, die Topics:
attr MQTT2_mqtt2_client readingList mqtt2_client:fhem/out/LWT:.* LWT\
mqtt2_client:Test/Temp:.* Temp\
mqtt2_client:Connect:.* Connect\
mqtt2_client:ESP_Easy:.* ESP_Easy\
mqtt2_client:ESP_Easy/bme680/Temperature:.* Temperature\
mqtt2_client:ESP_Easy/bme680/Humidity:.* Humidity\
mqtt2_client:ESP_Easy/bme680/Pressure:.* Pressure\
mqtt2_client:ESP_Easy/bme680/TVOC:.* TVOCwegen
attr mqtt2_client subscriptions # als root-level.
Aber vorher ein paar Negativ-Beispiele:Zitat2019.09.18 20:40:16 3: Opening mqtt device 127.0.0.1:1883
2019.09.18 20:40:16 1: mqtt: Can't connect to 127.0.0.1:1883: Connection refused
2019.09.18 20:40:23 3: Opening mqtt device 127.0.0.1:1883
2019.09.18 20:40:23 1: mqtt: Can't connect to 127.0.0.1:1883: Connection refused
2019.09.18 20:43:02 3: Opening myBroker device 127.0.0.1:1883
2019.09.18 20:43:02 1: myBroker: Can't connect to 127.0.0.1:1883: Operation now in progress
2019.09.18 20:43:02 1: myBroker: Can't connect to 127.0.0.1:1883: 127.0.0.1: Verbindungsaufbau abgelehnt (111)
~~~~
1568831217: Socket error on client <unknown>, disconnecting.
1568831217: New connection from 127.0.0.1 on port 1883.
1568831217: Socket error on client <unknown>, disconnecting.
1568831218: New connection from 127.0.0.1 on port 1883.
1568831218: Socket error on client <unknown>, disconnecting.
1568831218: New connection from 127.0.0.1 on port 1883.
1568831218: Socket error on client <unknown>, disconnecting.
1568831235: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1568831528: Error in poll: Interrupted system call.
1568831528: mosquitto version 1.4.10 terminating
1568832260: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting
1568832260: Config loaded from /etc/mosquitto/mosquitto.conf.
1568832260: Opening ipv4 listen socket on port 1883.
1568832260: Opening ipv6 listen socket on port 1883.
1568832261: New connection from 127.0.0.1 on port 1883.
1568832261: Socket error on client <unknown>, disconnecting.
1568832287: New connection from 192.168.178.41 on port 1883.
1568832287: Client ESP_Easy_2 disconnected.
1568832287: New client connected from 192.168.178.41 as ESP_Easy_2 (c0, k10, u'pi').
Ich glaube, da muss jeder MQTT-Neuling mal durch (;-)
Aber von "so einfach ..." möchte ich nicht sprechen. ;)
Danke für die Infos Thomas + Twenta!
Allerdings kam bei mir die dritte Methode erfolgreich nach dem FHEM-Update zum Zuge ...
Möglicherweise sind gewisse Einträge noch falsch ... aber so geht es bei mir ;)
Ggf. hätte es den Broker-Eintrag ebenfalls nicht gebraucht .... (?)
Es sind definitiv ein paar Fragen offen geblieben ...
Siehe auch: https://wiki.fhem.de/wiki/MQTT2_CLIENT (https://wiki.fhem.de/wiki/MQTT2_CLIENT).
Hatte auch mit dem template "MQTT2_CLIENT_general_bridge" experimentiert, aber kein Resultat erkannt ....
Weitere Möglichkeit der Visualisierung: https://waschto.eu/fhem-und-grafana-tool-zum-visualisieren-von-messdaten/ (https://waschto.eu/fhem-und-grafana-tool-zum-visualisieren-von-messdaten/)
Installation erfolgreich. Momentan klemmt es noch an der Übergabe der Daten an InfluxDB über das
93_InfluxDBLog (https://forum.fhem.de/index.php/topic,71551.0.html)-Modul.
MQTT-Auth:
http://www.steves-internet-guide.com/mqtt-username-password-example/ (http://www.steves-internet-guide.com/mqtt-username-password-example/)
Für die Anwendung für Grafana mit Influxdb kam ich mit dem Modul "93_InfluxDBLog" einfach nicht weiter.
Meine erster Weg/Versuch MQTT-Subscriptions in die InfluxDB zu schreiben war mit einem Python-Skript auf dem PI.
Neueste Versionen installieren:
# Signaturschlüssel installieren
wget -O - https://repos.influxdata.com/influxdb.key | sudo apt-key add -
# Paketquelle hinzufügen
echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
# InfluxDB installieren
sudo apt-get update && sudo apt-get install influxdb
sudo systemctl daemon-reload
sudo systemctl enable influxdb.service
sudo systemctl start influxdb.service
#grafana-Installation
echo "deb https://repos.influxdata.com/debian stretch stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
wget https://dl.grafana.com/oss/release/grafana_6.3.5_armhf.deb
sudo dpkg -i grafana_6.3.5_armhf.deb
Dann die Python-Client-Libs noch installieren:
pip install influxdbclient
pip install paho-mqtt
http://www.steves-internet-guide.com/into-mqtt-python-client/ (http://www.steves-internet-guide.com/into-mqtt-python-client/)
https://raspberry-valley.azurewebsites.net/Mosquitto/ (https://raspberry-valley.azurewebsites.net/Mosquitto/)
Mittels influx-Konsole Datenbank und Usder einrichten:
pi@raspberrypi:~ $ influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.8
> create user <USER> with PASSWORD '>PWD>' with all privileges
> create DATABASE fhem_bme680
> exit
habe voher eine Database "fhem_bme680" plus user mit allen Rechten und ein "measurement=TVOC" angelegt .
Einen UTC-Timestamp zu generieren war leider nicht erfolgreich (der code wird nicht mehr ausgeführt).
> select value from TVOC
name: TVOC
time value
---- -----
1569145672897418771 826.2
1569145732900389041 827.4
1569145792884462336 828.6
1569145852896870973 829.4
1569145912894694935 829.9
1569145972889216570 830.2
1569146032897894131 830.3
1569146092894298758 830.2
1569146152921232003 829.2
1569146212899806950 827.8
1569146272900568857 826.3
1569146332898218697 824.3
1569146392903728293 822.5
Also hat der Connect auf MQTT und auf die Subscriptions geklappt.
Nach einiger Tüftelei bekam auch der InfluxDB-client seine Connection auf die Datenbank hin.
Das Skript kann nun auf weitere Readings ausgebaut werden, wenn ich mich mehr eingearbeitet habe.
Sorry, ist wilde Tüftelei, weil Grafana + InfluxDB-Noob ... ::)
https://docs.influxdata.com/influxdb/v0.10/introduction/getting_started/ (https://docs.influxdata.com/influxdb/v0.10/introduction/getting_started/)
Grafana läuft endlich mit InfluxDB-Datenquelle!
ESP_Easy -> MQTT-Client (Controller) -> Publish -> Mosquitto-Broker -> Subscribe -> Python-Skipt -> InfluxDB -> Grafana
Hier gibt es wertvolle Infos und ein (noch ;)) besseres Python-Skript dazu:
http://nilhcem.com/iot/home-monitoring-with-mqtt-influxdb-grafana (http://nilhcem.com/iot/home-monitoring-with-mqtt-influxdb-grafana)
und hier
https://github.com/Nilhcem/home-monitoring-grafana/blob/master/02-bridge/main.py (https://github.com/Nilhcem/home-monitoring-grafana/blob/master/02-bridge/main.py)
Auch mit docker:
influxdb-and-grafana-for-sensor-time-series/ (https://thingsmatic.com/2017/03/02/influxdb-and-grafana-for-sensor-time-series/)
playing-with-docker-mqtt-grafana-influxdb-python-and-arduino/ (https://gonzalo123.com/2018/06/04/playing-with-docker-mqtt-grafana-influxdb-python-and-arduino/)
download-dashboard-json-or-copy-the-content-of-this-file-to-clipboard (https://developers.bigclown.com/integrations/grafana-for-visualization#step-3-download-dashboard-json-or-copy-the-content-of-this-file-to-clipboard)
autostart-eines-python-programm-auf-dem-raspberry-pi/ (https://webnist.de/autostart-eines-python-programm-auf-dem-raspberry-pi/)
howto/run-a-program-on-your-raspberry-pi-at-startup/ (https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/)
https://ayeks.de/post/2018-05-29-bme680-influxdb-grafana/ (https://ayeks.de/post/2018-05-29-bme680-influxdb-grafana/)
https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/ (https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/)
Habe leider noch keinen Weg gefunden, das erweiterte Skript auf dem Pi3(Stretch) ans Laufen zu bekommen:
https://raw.githubusercontent.com/Nilhcem/home-monitoring-grafana/master/02-bridge/main.py (https://raw.githubusercontent.com/Nilhcem/home-monitoring-grafana/master/02-bridge/main.py)
(Läuft unter Windows... mit 3.7.3 64bit)
mit
MQTT_TOPIC = 'ESP_Easy/bme680/+' # [bme280|mijia]/[temperature|humidity|battery|status]
MQTT_REGEX = 'ESP_Easy/([^/]+)/([^/]+)' #group1 and 2 needed: location=bme680 and measurement=TVOC|Temperature|Pressure|Humidity
Connected with result code 0
ESP_Easy/bme680/Pressure b'996.4'
ESP_Easy/bme680/TVOC b'491.0'
ESP_Easy/bme680/Temperature b'24.4'
ESP_Easy/bme680/Humidity b'52.8'
Allerdings hat der Raspi Python-Versions-Probleme:
pi@raspberrypi:~ $ python3 mqtt_influx_bridge.py
File "mqtt_influx_bridge.py", line 32
location: str
^
SyntaxError: invalid syntax
pi@raspberrypi:~ $ python3 mqtt_influx_bridge.py
File "mqtt_influx_bridge.py", line 32
location: str
^
SyntaxError: invalid syntax
pi@raspberrypi:~ $ python3 --version
Python 3.5.3
pi@raspberrypi:~ $ which python3
/usr/bin/python3
https://stackoverflow.com/questions/42002596/python-3-5-typed-namedtuple-syntax-produces-syntaxerror (https://stackoverflow.com/questions/42002596/python-3-5-typed-namedtuple-syntax-produces-syntaxerror)
https://raspberrypi.stackexchange.com/questions/10237/upgrade-from-python-2-7-to-3-3-x (https://raspberrypi.stackexchange.com/questions/10237/upgrade-from-python-2-7-to-3-3-x)
https://gist.github.com/SeppPenner/6a5a30ebc8f79936fa136c524417761d (https://gist.github.com/SeppPenner/6a5a30ebc8f79936fa136c524417761d)
Hallo,
habe bei mir seit ca. 2 Wochen einen Testaufbau mit verschiedenen BME680 und CCS811 Sensoren laufen. Alle Sensoren befinden sich im gleichen Raum auf einen Tisch nebeneinander, haben somit die gleichen Bedingungen.
Sensor1:
Sonoff iAQ locutus CO2 Indoor Sensor mit CCS811
Software: Tasmota 6.6.0 CCS811 Lib Adafruit Version 1.0.0.14
Sensor2:
Sonoff iAQ2 Wemos D1 mit CCS811 und BME280
Software: Tasmota 6.6.0 CCS811 Lib. Adafruit Version 1.0.0.14
Sensor3:
ESPEasy CCS811 iAQ / BME680 iAQ
Software: Build 20103 Mega ESPEasy Core 2_5_2
CCS811 Lib. SparkFun CCS811 Version 1.0.0
BME680 Lib. JS_BME680 von Juergs
Sensor4:
LaCrosse UniversalSensor V3.1f
Software: UniversalSensor V 3.1f
BME680 Lib. Bosch BSEC Version 1.4.7.2
Alle Daten werden in einer Influx DB gespeichert, die Anbindung der Datenbank an FHEM erfolgt mit den Modul InfluxDBLog .
Als Anlage habe ich eine 24h Auswertung mit Grafana angehängt.
Man sieht, die Kurvenverläufe gleichen sich, aber die absoluten Werte unterscheiden sich stark.
Gruß
trebron106
Hallo trebron106,
wenn Du uns freundlicherweise noch die Konfiguration / List des/der InfluxDBLog-Devices mitlieferst? ;) ;) ;)
Grüße,
Jürgen
Hallo juergs,
hier ein List der InfluxDBLog meiner Testumgebung
Datenbankname fhem
Datenbankuser fhem
Datenbankpasswort fhem
Internals:
DEF 192.168.106.160 8086 fhem fhem fhem .*:([Tt]emp|[Hh]umidity|dewpoint|taupunkt|pressure|gas1|gas2|Luftfeuchte|TVOC|eCO2|CCS811_|BMP180_|BME280_|BME680_).*
FH
FUUID 5d8cc25a-f33f-4013-25f0-eaea939f05c22094
INFLUXDB fhem
INFLUXPORT 8086
INFLUXPW fhem
INFLUXSRV 192.168.106.160
INFLUXUSER fhem
NAME InfluxDB
NR 1379
NTFY_ORDER 50-InfluxDB
REGEXP .*:([Tt]emp|[Hh]umidity|dewpoint|taupunkt|pressure|gas1|gas2|Luftfeuchte|TVOC|eCO2|CCS811_|BMP180_|BME280_|BME680_).*
STATE active
TYPE InfluxDBLog
READINGS:
2019-09-27 13:24:34 filecount 0
Attributes:
room 9.9 Test
Gruß
trebron106
Hallo trebron106,
danke für das List des Moduls, werde es gerne ausprobieren.
Bei den Vergleichswerten fällt mir (1) + (2) auf. Auch die Sonos IAQ 2 - Kurve zur der von ESPEasy_BME680.
Sowie der Peak bei Sonos IAQ(1) gegen den ESPEasy_BME680-Peak....
Was mich wundert ist der Nicht-Gleichlauf des Universalsensors (mit BSEC) zum EspEasy-BME680.
Das habe ich bei mir nicht so, bei mir korrelieren die Sensoren da etwas besser.
Evtl. wäre die Kurven (als Vergleich) von Luftfeuchte und Temperatur ein Hinweis, was da evtl. vor sich ging.
Bei liegen auch einige Sensoren im "engen" Bereich in einem Zimmer herum. Allerdings bei geöffnetem Fenster verteilt sich
das Ganze doch sehr unterschiedlich.
Den CS811 habe ich noch nicht im Einsatz. Interessant zu sehen, dass die Werte einigermaßen korrelieren....
Ansonsten teile ich Deine Meinung, dass Absolutwerte schon unteschiedlich sein können.
Wenn ich meine anderen Sensoren eingebunden habe, lässt sich da Langzeit-technisch von meiner Seite mehr sagen.
Mein RegEx:
.*:([Tt]emperature|[Tt]emp|[Hh]umidity|rH|dewpoint|taupunkt|[Pp]ressure|gas1|gas2|Luftfeuchte|TVOC|tvoc|eCO2|BME680).*liefert mir nun die richtigen fhem-Readings (z.B. auch mqtt2_client), diese werden in InfluxdB geschrieben.
define influxlog InfluxDBLog localhost 8086 fhem_test <usr> <pwd> .*:([Tt]emperature|[Tt]emp|[Hh]umidity|rH|dewpoint|taupunkt|[Pp]ressure|gas1|gas2|Luftfeuchte|TVOC|tvoc|eCO2|BME680).*
setuuid influxlog 5d8e5336-f33f-72b0-fb72-c4bc41d123276ea1
attr influxlog room MQTT2_DEVICE
attr influxlog verbose 3Nach jetzigem Kenntnisstand und den Infos hier:
https://forum.fhem.de/index.php/topic,71551.0.html (https://forum.fhem.de/index.php/topic,71551.0.html)
https://www.dev-eth0.de/2016/12/07/grafana_fhem_influxdb/ (https://www.dev-eth0.de/2016/12/07/grafana_fhem_influxdb/)
Ist noch etwas Optimierungspotential in Grafana da, aber die Grunddaten werden nun von
allen RegEx-gefilterten fhem-readings (!) in die Datenbank via
93_InfluxDBLog-Modul geschrieben.
Der Knackpunkt ist die richtige (Perl-)RegEx-Syntax zu erstellen .... und in Influx die Einträge der
measurements zu identifizieren und dann ist die Konfiguration in Grafana ebenfalls einfach ;)
Dann kann man sich den Feinheiten der Grafana-Abfragen und Visualisierungen widmen ...
Schön dabei ist, dass man bereits existierende Konfigurationen importieren kann ... https://grafana.com/grafana/dashboards (https://grafana.com/grafana/dashboards) und ein Dashboard-Beispiel (http://gasplanet.no-ip.org:3000/d/eMc20Z9ik/ttn-rottal-inn) ;)
Hier zeigt es sich auch für die MQTT-Messungen,
wiedererkennbare Benennungen, nach Device unterscheidbar, zu verwenden ist von Vorteil ... ;)
Zitatdevice-category/device-id/payload-context/payload-differentiator
Zitat>> show measurements
name: measurements
name
----
BME680_DBG_BASE_C
BME680_DBG_FILTERED
BME680_DBG_R
BME680_DBG_RATIO
BME680_aH
BME680_dewpoint
BME680_pressure
BME680_rH
BME680_temperature
BME680_tvoc
Humidity
TVOC
Temperature
humidity
pressure
temperature
>>explain select * from BME680_tvoc
QUERY PLAN
----------
EXPRESSION: <nil>
AUXILIARY FIELDS: site_name::tag, value::float
NUMBER OF SHARDS: 1
NUMBER OF SERIES: 3
CACHED VALUES: 422
NUMBER OF FILES: 0
NUMBER OF BLOCKS: 0
SIZE OF BLOCKS: 0
... und ich hatte mich gerade mit python angefreundet ... ;) ;D
Zitat von: juergs am 13 September 2019, 22:13:14
Habe einige Verbesserungen eingebaut:
Jetzt sollte auch die Adresse 0x77 für den BME einsetzbar sein.
Dafür habe ich die Initialiserung des BME an eine passendere Stelle gelegt.
Das hat den Vorteil, dass ein nicht angeschlossener BME680 in ESPEasy keine Exceptions mehr erzeugt
und sich ESPEasy aufrufen läßt, um über den Device-Konfiguratins-Dialog mittels Adress-Auswahl, Device-ENABLE-Checkbox gesetzt und SUBMIT-Button gedrückt, konfigurieren lässt.
Erst dann läuft erst die Initialisierung des BMEs los.
Die Zykluszeit habe ich von 10 auf 12s hochgesetzt, da dies Bosch in https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BME680-AN014.pdf (https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BME680-AN014.pdf)
auf Seite 10 vorschlägt. Messwerte werden im 12s Rythmus vom BME gelesen, aber erst nach der konfigurierten Zyklus-Zeit (default=60s) an die ESPEasy-Oberfläche geliefert.
Alle anderen Änderungen wie z.B. Plot + Debugausgabe werden erst nach einem Reset wirksam ...
* Github Repository (https://github.com/juergs/ESPEasy_BME680_TVOC) ist aktualisiert. :D
Hallo juergs,
ich habe die .bin, aus dem o.g. Beitrag von Dir, auf einen D1 geflasht, es werden die Messwerte korrekt ausgelesen (auf der seriellen Schnittstelle zu sehen), jedoch wird sobald der der TVOC-Wert erfasst wird, also nach 5 Minuten, die anderen Werte nicht mehr an FHEM aktualisiert. Angebunden ist es über den FHEM HTTP Controller. Zur Veranschaulichung füge ich einen Plot und die Ausgabe der seriellen Schnittstelle an. Da kann man sehen, dass die Werte gemessen werden, also Änderungen zu sehene sind, die Änderungen werden aber nicht übertragen. Auch bei anderen WIMOS D1 und einem Node MCU stelle ich das gleiche verhalten fest. Kannst Du mir vielleicht helfen.
Vielen Dank im Voraus, Ulrich
Hallo Ulrich,
Du hast eine Konfiguration gewählt, die ich so nicht getestet/ausprobiert habe.
Zum Probieren benötige ich von Dir beide Konfigurationen (Screenshot?) von der ESPEasy-Konfiguration und der
Konfiguration des FHEM-Devices. Zum Nachvollziehen auch ein Log-Auszug des FHEM-Logs zum Abbruchzeitpunkt.
Allerdings ist die einfachere Variante die Verwendung der UDP-SLINK Übertragung:
Du holst Dir von
hier (https://github.com/herrmannj/AirQuality/tree/master/FHEM) die FHEM-Module und kopierst sie in den FHEM-Ordner.
Falls Raspi, noch die Berechtigungen für den fhem-User und die dialout-Gruppe auf die neuen pm-Module setzen:
Beispielhaft:
8,0K -rw-r--r-- 1 fhem dialout 6,2K Okt 3 14:56 10_SLinkIAQC.pm
8,0K -rw-r--r-- 1 fhem dialout 4,4K Okt 3 14:56 10_SLinkIAQ.pm
8,0K -rw-r--r-- 1 fhem dialout 5,3K Jan 1 1970 10_SLinkS0.pm
8,0K -rw-r--r-- 1 fhem dialout 4,3K Jan 1 1970 10_SLinkTH.pm
Dann in Fhem neu starten und ein
Zitat
define slink slink
Device über die Eingabezeile definieren.
Falls Autocreate aktiv ist bekommst du dann eine neues SLink-Device angelegt, sofern in ESPEasy "
UDP slink transmission enable:" die Checkbox gesetzt ist.
Zitat
Internals:
DEF 45482A
FUUID 5d965caf-f33f-1cca-f8a3-7df3451b792ae5dc
ID 45482A
LASTInputDev slink
MSGCNT 92444
NAME SLinkIAQC_45482A
NOTIFYDEV global
NR 145
NTFY_ORDER 50-SLinkIAQC_45482A
SENSOR 192.168.178.55
STATE ???
TYPE SLinkIAQC
slink_MSGCNT 92444
slink_RAWMSG T:IAQC;FW:1.0;ID:45482A;IP:192.168.178.55;R:-43;F:THPV;T:20.42;H:64.14;AH:11.36;D:13.42;P:1000.4;V:761;R:480564;DB:64035000;DF:483601.375;DR:1.6758;
slink_REMOTE 192.168.178.55
slink_RSSI -43
slink_TIME 2019-10-17 18:21:47
READINGS:
2019-10-17 18:21:47 BME680_DBG_BASE_C 64035000
2019-10-17 18:21:47 BME680_DBG_FILTERED 483601.375
2019-10-17 18:21:47 BME680_DBG_R 480564
2019-10-17 18:21:47 BME680_DBG_RATIO 1.6758
2019-10-17 18:21:47 BME680_aH 11.36
2019-10-17 18:21:47 BME680_dewpoint 13.42
2019-10-17 18:21:47 BME680_pressure 1000.4
2019-10-17 18:21:47 BME680_rH 64.14
2019-10-17 18:21:47 BME680_temperature 20.42
2019-10-17 18:21:47 BME680_tvoc 761
Attributes:
room SLinkIAQC
Hierbei habe ich bisher noch keine Übertragungsprobleme feststellen können.
Die beiden anderen Übertragungsarten laufen über ein MQTT2-Device und ein MQTT-Controller in ESPEasy
oder an FHEM vorbei, über ein Mosquitto-MQTT-Server und ein Python3-Skript (als Dienst implementiert) welches die Daten in eine InfluxDB schaufelt.
Deren Daten können dann über Grafana ausgewertet werden.
Nachdem meine SD-Karte im RASPI nach 1,5 Jahren ins stolpern gekommen ist, habe ich
gleich Raspian "Buster" neu installiert. Mit dem Vorteil, dass nun Python3 verfügbar ist.
Bei der Auswertung mit Grafana ist mir leider noch ein Fehler beim Erfassen ins Auge gefallen: Die Luftdruckdaten wurden nicht aktualisiert.
Anbei die korrigierte ESPEasy-BME680-Version. :-[ :-\
Nur Sketch-Upload mit Esptool (https://github.com/arendst/Sonoff-Tasmota/wiki/Esptool) oder Arduino-Version:
esptool.exe -vv -cd nodemcu -cb 921600 -cp COM7 -ca 0x00000 -cf <Pfad zu>/ESPEasy.ino.bin FHEM-HTTP mit ESPEasy: https://forum.fhem.de/index.php/topic,55728.0.html (https://forum.fhem.de/index.php/topic,55728.0.html) ?
Nutzt den jemand diesen Sensor und könnte mir vorab mal 1-2 Maße nennen ?
Abstand Löcher , Durchmesser ggf und Mitte Loch nach unten ?!
(https://uploads.tapatalk-cdn.com/20191019/b705b4222a9ca1018423b4cf361d3d10.jpg)
Er ist bestellt . Dauert aber leider noch etwas bis er da ist .
Vielen Dank
Hallo McArthur,
die Maße kannst Du auch selbst herausfinden:
Einfach JPG ausdrucken, ggf auch 2 .. 3 mal vergrößert.
Da Du weißt, dass der Sensor (https://www.14core.com/wiring-the-bosch-bme680-gas-detection-temp-humid-pressure-with-i2c-spi/) BME680 (http://img.staticbg.com/images/oaupload/banggood/images/63/ED/c7f8dd49-f3a5-44ef-b7ec-f66060714d10.JPG) 3x3 mm Kantenlänge hat, kannst Du Dir den Skalierungsfaktor selbst berechnen ...
... und auf alle anderen Maße hinreichend genau anwenden ... ;D :)
Jürgen
Hallo,
ich benutze die 20191017_ESPEasy.ino.bin nur leider wird bei mir die Höhenkorrektur ignoriert...
Du meinst die Höhenkorrektur des Luftdrucks?
https://github.com/juergs/BME680-Arduino-Library-with_TVOC-/blob/master/js_BME680/js_bme680.cpp (https://github.com/juergs/BME680-Arduino-Library-with_TVOC-/blob/master/js_BME680/js_bme680.cpp)
Ja genau. Dort kann ich 0m oder 1000m eingeben, ohne das sich was am Luftdruck ändert.
Hat das evtl. mit der I2C Adresse zu tun? Ich habe 0x77.
ok, schaue mal nach. 😁
Hat nur was mit der Umrechnung bzw. EspEasy-Variablenübergabe zu tun.
Die I2C-Adresse ich nur für Go-No-Go verantwortlich. Werden Werte geliefert ist die richtige Adresse einegstelle.
Darüber hinaus spielt die I2C-Adresse dann keine weitere Rolle mehr.
Wobei Luftdruck-Absolut-Werte eigentlich nur einen kosmetischen Wert haben.
Wichtiger ist wohl eher die Tendenz .... ;)
By the way: https://community.grafana.com/t/date-in-local-format/17617 (https://community.grafana.com/t/date-in-local-format/17617)
... habe die Luftdruck-Höhen-Korrektor als ESPEasy-Eingabe-Möglichkeit vorgesehen, aber leider nicht weiter SW-technisch verwendet.
Sie ist also ohne Funktion .... stattdessen wird die Adafruit-Sealevel-Anpassung verwendet, also Luftdruck in Bezug auf Meereshöhe.
Falls wirklich erfoderlich, bitte die Umrechnung angeben, dann kann ich sie einbinden ... :D
Jürgen
Um dem AMS-CSS811-Sensor auch mal unter die Lupe zu nehmen, habe ich den Sensor über das SLINK-Protokoll in FHEM
mit Kalman-Filterung eingebunden und auf das SLINK-BME680-Protokoll gemapped.
Noch ohne Temperatur-Kompensation via BME280 oder NTC.
Konfiguration der IP, wie über den WiFiManager üblich.
Code und weitere Infos: https://github.com/juergs/CSS811_Slink/blob/master/README.md (https://github.com/juergs/CSS811_Slink/blob/master/README.md)
Die Umrechung ist in der _P119_BME680.ino enthalten:
//**************************************************************************/
// MSL pressure formula
//**************************************************************************/
float Plugin_119_pressureElevation(float atmospheric, int altitude) {
return atmospheric / pow(1.0 - (altitude/44330.0), 5.255);
}
Zum Vergleich mit den anderen Sensoren finde ich die Umrechung schon interessant. ;)
Danke. Mehr dazu: Conversion to sea-level pressure (https://keisan.casio.com/exec/system/1224575267)
Sollte man aber nochmal genauer nachüberprüfen ...
BME680_CS_06 - Press: 976 hPa
SLinkIAQC_45482A - Temp: 21.55 Hum: 60.47 [%rH] Press: 975.6 hPaZitatWetterstationen geben ihren Luftdruck immer auf Höhe 0 reduziert an,
damit man diese vergleichen kann.
Das Problem ist einfach nur dass der Sensor nicht weiß wo, auf welcher Höhe über NN, er wirklich ist. Den einzigen Bezugswert den er hat ist:
Code:
#define SEALEVELPRESSURE_HPA (1013.25)
Das ist ein genormter Bezugswert der aber im wahren Leben quasi nie zutrifft.
Deshalb geht er davon aus dass derzeit auf Meeresniveau diese 1013.25mbar herrschen, was aber nicht zutrifft, und errechnet daraus die Höhe an deinem Standort. Die kann dann natürlich auch nicht stimmen.
Man kann den BME680 also nicht dazu nutzen die Absolute Höhe an seinem Standort zu messen. Wenn man ihm aber die Absolute Höhe am Standort und den tatsächlichen Luftdruck am Standort mitteilt könnte man mit seiner Hilfe eine relative Höhenänderung des Sensors berechnen.
Aber auch der Angezeigte Luftdruck, diese 991,xx hPa. stimmen für denen Standort nicht mit den Daten der Wetterstationen in deiner Nähe überein.
Mit der Formel:
Code:
lokalerLuftdruck = (P/pow(1-(A/44330.0),5.255));
kannst du aber den gemessenen Luftdruck auf den Luftdruck für deine Höhe über NN umrechnen.
Dabei musst du für "P" den vom BME gemessenen Luftdruck einsetzen und für "A" deine reale Höhe in Meter über NN.
Das Ergebnis sollte dann nahe bei den Werten liegen welche Wetterstationen in deiner Nähe messen.
Quelle: BME680 und lokaler Luftdruck (https://www.arduinoforum.de/arduino-Thread-Gewinnspiel-BME680)
Erster Versuch:
Example lines for input:
mit 2158 : EVENT: bme680#Pressure=982.20 und 210 Metern
Ergebnis:
2019-11-04_20:16:09 SLinkIAQC_20040E BME680_pressure: 1007.0
Mit diesem Code der greift, wenn die Höhen-Angabe (Altitude) > 0 ist :
if (use_pressure_altitude)
{
double press = JS_BME680.getPress();
int alt = PCONFIG(1) ;
double lokalerLuftdruck = (press/pow(1-(alt/44330.0),5.255));
dtostrf(lokalerLuftdruck, 3, 1, str_pressure);
}
else
{
dtostrf(JS_BME680.getPress(), 3, 1, str_pressure);
}Resultat: 982.20 hPa => 1007.0 hPa
<980 sehr tief, stürmisch |
980-1000 tief, regnerisch |
1000-1020 normal, wechselhaft |
1020-1040 hoch, sonnig |
>1040 sehr hoch, sehr trocken |
T:IAQC;FW:1.0;ID:20040E;IP:192.168.178.49;R:-38;F:THPV;T:22.23;H:47.64;AH:0.00;D:0.00;P:1006.7;V:125;R:1073741170;DB:1073741152;DF:0;DR:1;Muss das aber erst noch mal verifizieren ... also erst mal ohne Gewähr! ;)
Lokaler Luftdruckwert im Moment nur über SLINK!
Danke für die Mühe, nur leider nutze ich slink nicht. :'(
Ich klinke mich hier mal ein, weil ich selbst mit zwei Sensoren CCS811 kämpfe, siehe hier: https://forum.fhem.de/index.php/topic,103754.msg1009471.html#msg1009471
Insofern würde mich interessieren, ob es irgendwo auf den vorangehenden 36 Seiten eine alternative Tasmota-Version gibt - da liegt nämlich irgendetwas im Argen.
Den Unterschied der absoluten Messwerte habe ich allerdings schon in den SmartHome Hacks ausführlich erklärt - die physikalische Funktionsweise der Sensoren führt zu relativ hohen Fertigungstoleranzen, sie müssen eigentlich geeicht werden. Ohne eine solche Eichung sind sie nur für relative Messungen zu gebrauchen.
Edit: Da ich die beiden CCS811 nebeneinander betreibe und sie immer schön fast gleiche Absolutwerte liefern, ist auf den ersten Blick die Fertigungstoleranz der CCS811 relativ gering.
LG
pah
https://forum.fhem.de/index.php/topic,103027.0.html
https://www.mikrocontroller.net/topic/445610
https://www.jaredwolff.com/finding-the-best-tvoc-sensor-ccs811-vs-bme680-vs-sgp30/
...
Zitat
Den Unterschied der absoluten Messwerte habe ich allerdings schon in den SmartHome Hacks ausführlich erklärt - die physikalische Funktionsweise der Sensoren führt zu relativ hohen Fertigungstoleranzen, sie müssen eigentlich geeicht werden. Ohne eine solche Eichung sind sie nur für relative Messungen zu gebrauchen.
Ich habe mich so ausführlich mit tVOC Sensoren beschäftigt das ich anfangen kann bezahlte Vorträge darüber zu halten. Kurzfassung: die Fertigungstoleranzen sind ein kleiner Teil des Problems. Dazu kommen
- Alterung
- Veränderungen durch reversible Sättigungseffekte (Memory Effekt)
vor allem aber die Querempfindlichkeit zum Wassergehalt der Luft.
Um die Widerstandswerte richtig zu interpretieren muss der variable Anteil des Wassers rechnerisch mit extremer Genauigkeit kompensiert werden. Jetzt such mal im CCS811 die Möglichkeit wie der das exakt machen soll :) (mal abgesehen von dessen buggy fw, zb baseline correction)
Der AMS IAQ-C ist besser (bedeutet er springt seltener, aber er springt).
Juergs hat eine BME680 Tasmota Version brauchbar ist.
Hallo Zusammen,
ich habe zusamme mit Jörg schon seit einger Zeit einige BME680 im Dauerbetrieb parallel laufen.
Lasse ich mehrere BMEs zur gleichen Zeit starten zeigen diese in etwa auch den gleichen Verlauf an.
Jörg hat schon die entscheidenden Links angegeben, aus denen man die entsprechenden Schlüsse ziehen kann.
Ich habe allerdings nicht für Tasmota, sondern für ESPEasy eine Umsetzung für Jörgs Erfassungs-Algorithmus umgesetzt.
Siehe hier auf GitHub (https://github.com/juergs/ESPEasy_BME680_TVOC) oder hier im Thread.
Jörgs Algorithmus kommt ohne das BSEC-Gedöns aus, da sowohl die Tasmota-, als auch die ESPEasy-Umgebung wohl die erforderliche Zykluszeit
nicht zu zulässt.
Die Erfassung über ESPEasy + SLINk und MQTT auf FHEM und Grafan läuft bei mir sehr zuverlässig.
Leider hat Dainel Waschto (https://waschto.eu/fhem-und-grafana-tool-zum-visualisieren-von-messdaten/)seine Webseite mit den HowTos "fhem-und-grafana-tool-zum-visualisieren-von-messdaten" dafür überraschend dicht gemacht.
/edit: https://www.jaredwolff.com/how-to-make-an-amazing-looking-iot-dashboard-in-no-time/ (https://www.jaredwolff.com/how-to-make-an-amazing-looking-iot-dashboard-in-no-time/)
Falls Interesse besteht, kann ich mir gerne mal das Tasmota-Sensor-Template auf eine Portiermöglichkeit prüfen.
Grüße,
Jürgen
Wenn Du Interesse hast, ich habe den algo für den BME nochmal angefasst verbessert.
Hallo Jörg,
wie könnte ich da "NEIN" sagen ... ;D :)
Hier mal wieder mal eine Gegenüberstellung CSS811/BME680.
Der CSS811 und der BME680 laufen unter ESPEasy MQTT/SLINK.
Interessant das SensorVerhalten nach dem Schliessen den hereingestellten Fensters.
Der SW-Filter den ich auf den BME680 aufgeschalten reagiert in der Art einens Tiefpasses mit verzögerten Flanken und geringerem Ausschwingen.
Dieses Verhalten ist aber von mir so gewünscht. ;) ;)
Die Ausreißer, die Pah meldet, passieren so bei mir nicht.
Allerdings habe ich bei mir auch keine externe Temperaturkompensation mit NTC auf den CCS811 geschalten.
war 10:10 einmal lüften ?
Zitatwar 10:10 einmal lüften ?
Tja, leider der umgekehrte Fall, allerdings reagiert der Sensor sehr sensibel
und das Schwingen des Fensters könnte das über den Luftzug mit "frischer" Luft schon erklären.
Allerdings steht da der CCS811 dagegen, der ca. 20 cm entfernt und 10 cm tiefer liegt.
Allerdings ist das Verhalten mit Heizungs-Luft (Fenstersims) etc. auch etwas Störgrößen behaftet.
Aber, wie Jörg schon sagte, über das Verhalten der Sensoren kann man sich so seine Gedanken machen ... :o
/edit: der CSS811 (Breakout-Board, nicht von Locutus) läuft im Gegensatz zum BME680 ohne weiteren Tiefpassfilter bis auf die letzten 10% erstaunlich koherent!
Um das genauer beurteilen zu wollen müsste ich den Filter allerdings beim BME680 ausschalten.
Das zweite Bild zeigt die Werte über die LGW und PeMues BME680-Sensor "geringer" gefiltert.
Hm,
Zitatbezahlte Vorträge darüber zu halten
Ich darf Dir versichern, das ist ein schwieriger Markt...
ZitatAlterung
Das heißt nur, dass die Eichung in regelmäßigen Abständen wiederholt werden müsste.
Ich habe selbst mehrere Metalloxidsensoren in der Werkstatt herumliegen und hatte vor, mehrere Sensoren unterschiedlichen Typs zu kombinieren. Wegen der unterschiedlichen Empfindlichkeiten auf CO2, NOx und weitere Gase lässt sich bei einer gescheiten Betrachtung der Kennlinien tatsächlich herausfieseln, welches Gas in welcher Konzentration vorhanden ist.
Ich habe aber aktuell das Problem, dass ich wegen verschiedener beruflicher Anforderungen kaum die Zeit habe, mich mit solchen Details zu befassen - deshalb wollte ich es mir einfach machen und habe mir eben die beiden Dinger von locutus kommen lassen. Tja, denkste mit einfach.
LG
pah
Hallo pah,
meine CSS811-Firmware-Version:
https://github.com/juergs/CSS811_Slink/blob/master/README.md
für den Esp8266.
Erforderlich: zusätzliche FHEM-Module für UDP-Empfang:
https://forum.fhem.de/index.php/topic,78619.msg974768.html#msg974768
einfach in den fhem-Ordner kopieren und ggf. Berechtigungen entsprechend setzen.
Die Definition des SLINK-Devices:
define slink SLink
Der Rest sollte FHEM dann per autocreate regeln.
Danke, werde ich bei Gelegenheit ausprobieren. Sehe ich das richtig, dass ich diese Firmware nicht wieder Over The Air loswerden kann, so wie das bei Tasmota der Fall ist?
LG
pah
Wenn Du mit "... diese Firmware ..." meine Version meinst:
Nein, ist nicht OTA fähig. Also gesamten Speicher per Flasher löschen, dann FW flashen.
Noch einige Infos:
Tasmota hat wohl doch die statische BSEC-Lib für den BME680 integriert:
https://github.com/arendst/Tasmota/tree/development/lib/BME680_driver-bme680_v3.5.9
https://github.com/arendst/Tasmota/tree/development/lib
Flash CCS811-Chip:
https://github.com/maarten-pennings/CCS811/tree/master/examples/ccs811flash
ZitatSince most Chinese boards come with firmware 1.1.0, and ams has released firmware 2.0.0 (around april 2018), I have written this example: it flashes 2.0.0 into a CCS811.
Locutus-Infos zum CCS811:
https://forum.fhem.de/index.php/topic,103754.msg975523.html#msg975523
https://forum.fhem.de/index.php/topic,28905.360.html
Hallo Jürgen,
bei meinem letzten Versuch BME680 mit Tasmota zu betreiben habe ich nur die Wiederstanswerte gesehen, daher bin ich mir ziemlich sicher dass die lib leider nicht in Tasmota enthalten ist.
Gruß
Alex
Hallo Alex,
die Funktionpointer sind die der statischen BSEC-Lib.
Sieht man auch Anhand der Versionierung.
Aber ohne tiefere Kenntnisse um die Installation der Lib wird das schwierig zu kompilieren sein....
Die Infos dazu stehen aber hier im Thread. :D
Grüße,
Jürgen
Hmmm. Ich denke, ich werde im kommenden Sommersemester mal einen Studenten an die Korrektur der Tasmota-Software setzen.
LG
pah
Hallo zusammen,
ich habe mal wieder probiert die BSEC Software einzubinden und mir ist folgendes aufgefallen:
- auf der Bosch Seite (https://www.bosch-sensortec.com/media/boschsensortec/downloads/bsec/bsec_1-4-7-4_generic_release.zip) bekommt man die v1.4.74 und
- im Library Manager bekommt man die v1.5.1474 von github (https://github.com/BoschSensortec/BSEC-Arduino-library) angeboten
Ich habe jetzt mal für ESP8266 die Anweisungen aus dem PDF der v1.4.74 (BSEC_1.4.7.4_Generic_Release\integration_guide\BST-BME680-Integration-Guide-AN008-47.pdf) befolgt und auch die binaries aus dieser Version reinkopiert.
Damit habe ich den Universalsensor Sketch für ESP8266 kompiliert -> funktioniert.
Generell ist das Ganze ein bisschen umständlich gemacht :o :o :o.
Schaut mal hier https://homematic-forum.de/forum/viewtopic.php?f=76&t=49422&p=560287#p559575
Da hat sich jemand umfangreich mit dem Sensor und dessen Kalibrierung beschäftigt. Vielleicht hilft das ja.
Ich habe jetzt auch ein paar von den Dingern und will sie direkt per I2C an meinen eh schon vorhandenen Raspberry-Roomnodes betreiben. Das läuft soweit, ich hänge gerade - natürlich - an der IAQ-Berechnung. Die BSEC-Library will ich nicht - u.A. möchte ich einen eigenen IAQ-Algorithmus, den ich auch nachvollziehen und genauer steuern kann, z.B. indem ich dem Sensor rückmelde, wenn das Fenster offen/geschlossen ist).
Offenbar niemand (außer Bosch in Library) hat sich bislang wohl mal genauer um die Kompensation der Widerstandswerte des VOC-Sensors gekümmert. Daher sehen auch die selbsterrechneten IAQ-Werte aus den ganzen Drittanbieter-Librarys (z.B. die Python-Library von Pimoroni) teilweise irgendwie schrottig aus.
Ich hab daher mal einen unprofessionellen Versuchsaufbau gemacht. Ergebnis: Der Ohm-Wert schießt mit abnehmender Luftfeuchte deutlich in die Höhe. Das deckt sich mit dem, wie sich solche Sensoren eben verhalten. Ist aber doof, wenn man nur den VOC-Anteil messen will und die Luftfeuchte ja eh separat hat. Die Temperatur hat (in einer anderen Messreihe ermittelt) offenbar kaum einen Einfluss (möglicherweise wegen einer guten Temperaturregelung der Sensorheizung).
Anbei ein Screenshot von meiner Messreihe Luftfeuchte (X-Achse) vs. Widerstand (Y-Achse) und meine erste simple Kompensationsformel inkl. Ergebnis. Falls jemand ein paar Beutel Silicagel o.Ä. und eine Plastiktüte zur Hand hat, würde ich mich freuen wenn ihr die Formel mal mit euren Sensoren testet (vor allem niedrige Luftfeuchtigkeitswerte sind spannend, die konnte ich noch nicht untersuchen)
Sensorparameter: 320 Grad - 150ms Heizzeit - 1Hz Abtastrate --> für andere Parameter wird man eine andere Formel brauchen
ZitatOffenbar niemand (außer Bosch in Library) hat sich bislang wohl mal genauer um die Kompensation der Widerstandswerte des VOC-Sensors gekümmert.
Sag das nicht ;) Könntest hier im forum fündig werden.
ZitatDaher sehen auch die selbsterrechneten IAQ-Werte aus den ganzen Drittanbieter-Librarys (z.B. die Python-Library von Pimoroni) teilweise irgendwie schrottig aus.
yepp, sind idR unbrauchbar.
Achtung, Du korrigierst mit der relativen Feuchte. Das funktioniert weil T in Deinem Aufbau ausreichend konstant ist. Ausschlaggebend ist jedoch die absolute Feuchte. Der Zusammenhang R und aH ist umgekehrt exponentiell.
Zwei weitere Faktoren sind Alterung und Sättigung. Stell mal Aceton daneben, entferne dann die Quelle und Lüfte bei (möglichst gleichbleibender T und aH). Der bleibt in der Sättigung (R steigt aber bleibt weit vom Ausgangswert entfernt). Erst wenn aH runter geht "erholt" der sich.
Bei 1Hz Abtastrate steigt die Abweichung des Temperatur Sensor (on-Chip). Empfehlung > 10S wenn Du T auch auswertest.
vg
Joerg
Tatsächlich, hab ich nun gefunden - wie konnte ich nur an euch zweifeln ;)
Mit absHum zu rechnen macht natürlich total Sinn in Anbetracht des beheizten Sensors. Deine Formel ...
Zitat
float ratio = (float)base / (r * aF * 7.0F);
float tV = (1250 * log(ratio)) + 125;
... ist mir allerdings noch ein bisschen unklar. Wozu hast du den Faktor 7 da drin? M.E. wäre 1/7 sinnvoll, dann rechnet man zumindest ca. den ursprünglichen Widerstandswert (bei typischen 7g/m^3). Bei der Berechnung der tVOC kürzt er sich ja raus (da in base schon enthalten).
Zitat
Stell mal Aceton daneben, entferne dann die Quelle und Lüfte bei (möglichst gleichbleibender T und aH). Der bleibt in der Sättigung (R steigt aber bleibt weit vom Ausgangswert entfernt). Erst wenn aH runter geht "erholt" der sich.
OK das kriegt man vermutlich nicht rausgerechnet.
Zitat
Bei 1Hz Abtastrate steigt die Abweichung des Temperatur Sensor (on-Chip). Empfehlung > 10S wenn Du T auch auswertest.
Hier messe ich beim startup den Temperatur-Offset. rH rechne ich entsprechend um.
Ja das Mal 7 ... Durch 7 war sinnfrei ;)
Ich hab mittlerweile einen verfeinerten Algorithmus der bisher alle Hürden genommen hat. Ich schaue Mal dass ich den in GitHub bringe
Also die Korrektur mit *absHum/7 übertrifft schonmal meine Erwartungen - das ist in dem oberen Diagramm die Kurve in Orange, gelb ist der rohe Widerstand.
Man sieht super wie der korrigierte Widerstand beim Lüften (Sensor direkt hinter dem offenen Fenster) fast konstant bleibt und nur ein bissel zittert (ist noch nicht sonderlich gefiltert). Ab um 11 schwappt schwallweise Küchenmief rüber ^^
Eigentlich reicht mir das so schon vollkommen um weiterzumachen mit dem IAQ-Score ^^ Die Baseline-Korrektur mache ich jetzt einfach über FHEM (Fenster nach mindestens 10 min geschlossen (oder CO2 < 500, wo Sensor vorhanden) --> Baseline Reset auf aktuellen Wert; mit kontinuierlicher Vergrößerung, falls mal dann doch noch mal ein größerer R-Wert kommt während das Fenster zu ist)
Hallo peterk_de,
... wilkommen im Club... ;) :)
Ich denke auch, daß die Baseline-Korrektur eigentlich noch die betstehende Schwachstelle im Meßverfahren ist.
Eigentlich müsste der Sensor immer wieder in "sauberer" Luft kalibriert werden.
Bei Positionierung an einem offenen Fenster erübrigt sich das (im Sommer) bei gelegentlichen ESP-Resets ... :D ;)
Nachdem sich seit Herauskommen des BME680-Sensors um die 2016, haben hier viele Leute in diesem Thread sehr viel Zeit, Arbeit und Mühe
investiert um das Projekt immer wieder weiter nach vorne gebracht haben. Dann fände ich es toll, wenn Du Deine
Ergebnisse konkreter hier zur Verfügung stellen würdest, um uns alle einen Schritt weiter nach vorne bringen.
Verstehe mich bitte nicht falsch, musste das einfach mal loswerden ... ;)
Grüße,
Jürgen
Hey Juergs, selbstverständlich mache ich das. Ich bin aber noch nicht weiter als diejenigen, die das Ding schon länger haben, insofern kann ich noch nicht allzuviel beitragen.
Es läuft bei mir darauf hinaus, dass ich den BME die weitestgehend rohen Werte an FHEM liefern lassen werde (also das, was ihr alle schon habt) und dann einen Score durch FHEM berechne. Wenn das bei mir zufriedenstellend funktioniert, poste ich es natürlich. Hat den Vorteil, dass es dann völlig egal ist, wie man das Ding technisch angebunden hat. Und man bei Updates am Algorithmus, wenn man mehrere davon hat, nicht diverse ESPs neu flashen muss.
Hallo,
Darf ich mal so unverschämt reingrätschen und fragen ob Herrmannj schon die verfeinerte Version hochgeladen hat?
Danke :)
Ne, hat er noch nicht ... Macht er aber noch
Hallo Jörg,
Du wirst wohl Deine Gründe haben, schade dass es bisher nicht geklappt hat.
Güße,
Jürgen
PS: plane zwei Erweiterungen des BME680:
- Mit RISC-V-Sipeed-Longan-Nano (https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html)
- Plus Air602, in Micrpython ... als WLAN-Kommunikations-Prozessor
Zitat von: juergs am 15 April 2020, 14:19:44
Hallo Jörg,
Du wirst wohl Deine Gründe haben, schade dass es bisher nicht geklappt hat.
Güße,
Jürgen
PS: plane zwei Erweiterungen des BME680:
- Mit RISC-V-Sipeed-Longan-Nano (https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html)
- Mit Air602, in Micrpython ... ]
ganz unspektakulär. Muss nochmal aufgeräumt werden. Keine Zeit bisher. kommt asap
Hi,
beim "Aufräumen" kann ich auch gerne helfen ;-)
Das erinnert mich daran, dass ich euch meinen Algorithmus auch noch "schulde".
Der ist mittlerweile sehr gut abgehangen und funktioniert bei mir prima. Ich nutze dazu die rohen Widerstandswerte des BME680 und betreibe eine sehr simple "Sensorfusion" mit einem CO2-Sensor.
So sehen die Userreadings von meinem BME680-Device aus:
correctedKOhm {
my $absH = dewpoint_absFeuchte(ReadingsVal("$name","temperature",0), ReadingsVal("$name","humidity",0));
my $kOhm = ReadingsVal("$name","kOhm",0);
return int(($absH * $kOhm / 7)+0.5);
},voc {
my $absH = dewpoint_absFeuchte(ReadingsVal("$name","temperature",0), ReadingsVal("$name","humidity",0));
my $kOhm = ReadingsVal("$name","kOhm",0);
my $correctedKOhm = ($absH * $kOhm) / 7;
my $baseCorrectedKOhm = ReadingsVal("$name","baseCorrectedKOhm",370);
my $startup = ReadingsVal("$name","startup","");
my $diff = max(0,$baseCorrectedKOhm-$correctedKOhm);
my $tVOCfak = 2200/$baseCorrectedKOhm;
if ($startup eq "done") {
return int(400+($diff*$tVOCfak));
} else {
return 0;
}
},quality { (ReadingsVal("$name","voc",450)<700?"sehr gut":(ReadingsVal("$name","voc",450)<1000?"gut":(ReadingsVal("$name","voc",450)<1500?"mittel":"schlecht"))) }
In den Readings kOhm, temperature und humidity des Devices müssen dazu die "nackten" Werte des BME680 drinstehen, wie auch immer ihr die in FHEM hineinbekommt. Startup wird bei mir done wenn der Sensor nach dem Einschalten warmgelaufen ist (nach 5 Minuten).
Die Baseline wird dann über ein ausgesprochen simples DOIF gesetzt:
([kue.balkontuer:"geschlossen"] and [kue.co2:co2] < 500)
(setreading kue.iaq baseCorrectedKOhm [kue.iaq:correctedKOhm])
Mit anderen Worten, neue Baseline immer dann, wenn wirklich vollständig gelüftet wurde (machen wir immer über die dortige Balkontür). Geht auch ohne CO2-Sensor - dann könnte man z.B. auf "Fenster war 30 Minuten offen" triggern.
Ergebnis ist dann ein Reading voc, das wirklich ziemlich gut mit dem CO2-Wert korreliert, aber eben auch durch Kochdünste mal nach oben ausreißt. Siehe z.B. Grafik am 13.4. gegen 21 Uhr
Hallp peterk_de,
interessante Herangehensweise.
Mit Jörgs Methode sieht es aber auch sehr plausibel aus.
Hier meine Anbindung üner ESPEasy und MQTT, die durchaus als wirklich sehr stabil und aussagekräftig zu betrachten ist.
Bei mir ist aber noch ein Glättungsalgorithmus zwischengeschalten, der die Ausreißer unterbindet und Steigungsänderungen etwas verzögert ...
Aber in der Tat, Baseline beim Lüften ... Aus- und -Wiedereinschalten. ;-)
Zitat von: juergs am 15 April 2020, 14:24:33
Hi,
beim "Aufräumen" kann ich auch gerne helfen ;-)
Wenn Du das mal nicht bereust ;) - allerdings kann ich aus bestätigen dass das in der Vergangenheit sehr gut funktioniert hat.
Hier ist das git: https://github.com/herrmannj/airq-mqtt
Ziele waren/sind: Umbau auf mqtt, die config vernünftig im Sensor speichern und TVOC noch besser.
Mein "Problem" ist eigentlich dass ich jetzt 4 Monate andere Sachen gemacht habe und ich weiß nicht mehr genau wo ich "damals" stehen geblieben bin. ::) Fertig ist es nicht, soviel ist sicher. Ich erinnere mich dunkel das ich in der Adafruit BME was machen wollte, da hatte ich die richtige Stelle für den Temperatur Offset gefunden.
Zum TVOC: der Algorithmus war ja schon gut, Pferdefuß war die ABC, insbesondere in extrem Situationen (wie draußen bitter kalt / Luft trocken, etc)
Die Baseline hier arbeitet daher anders: da ist ein Lowpass vorgeschaltet.
Wenn "saubere Luft" erkannt wird (vie Res * AbsHum) wird nicht mehr blind und sofort die Baseline neu gesetzt. Statt dessen wird die Baseline (über den Filter) vergleichsweise langsam angepasst. Die Filterkonstanten und das Ausleseintervall zusammen machen so etwa 10-15min aus in denen die Baseline schrittweise immer weiter angehoben wird. Dadurch gleichen sich die Latenzen der Sensoren (Hum ist extrem) gegen den Filter aus. Das bedeutet jetzt nicht das man 15min lüften muss weil die Luft ja erstmal ok ist und der Filter läuft weiter.
Baseline (und in der Folge TVOC) "nutzen" sich im Verlauf von etwa 2 Tagen "ab" (Filter). Damit wird sicher gestellt dass im Normalfall alle ein bis 2 Tage eine Baseline Korrektur durchgeführt wird. Das bedeutet dass der Raum halte alle 1-2 Tage auch saubere Luft "sehen" muss. Das passiert aber eigentlich ganz automatisch: Büro bin ich tagsüber, Nachts wird von der Lüftung "durchgelüftet". Schlafzimmer andersrum , usw. Auch die Familie ist ja nie immer und überall gleichzeitig.
Die Werte de da jetzt aus dem Sensor rauspurzeln passen daher durchgängig zu dem was man Erwartet (sind logisch) und es gibt auch keine extremen Ausreißer mehr. Die "alte" Version hatte ja noch die Macke das eine verfälschte ABC teilweise dann 2-3 Wochen lang TVOC Werte von 600ppm angezeigt hat - selbst bei geöffnetem Fenster. Das ist alles weg- ist sogar auf etwas konservativ getuned. Aber so dass eben Essen kochen (oder Ausdünstungen wie auch immer) sicher erkannt werden.
Schau mal, vielleicht kannst Du ja erkennen wo ich stehen geblieben bin. Der Sensor läuft hier auf dem Schreibtisch seid jetzt 4 - 5 Monaten, viel fehlte da mMn nicht - mqtt aber zb fehlt, Config ist auch erst 80% (meine ich)
Hallo Jörg,
das hört sich genau nach dem Passenden an. :D
Meine Erfahrungswerte sind mit der "alten" Version eigentlich schon sehr gut und nachvollziehbar.
Aber das Bessere ist des Guten Feind ;-)
Sobald ich am Thema dran bin arbeite ich mich auch wieder ein, da es mir da genauso geht wie Dir.
Danke + Grüße
Jürgen
Und nochmal eine ganz naive Frage... welchen Grund gibt es eigentlich nicht die Bosch bse Library zu nutzen? Weil sie proprietär ist oder gibt es weitere Gründe?
Ich teste diese gerade mit nem wemos und bin mit dem IAQ recht zufrieden...
Zitat von: twenta am 08 Mai 2020, 15:03:50
Und nochmal eine ganz naive Frage... welchen Grund gibt es eigentlich nicht die Bosch bse Library zu nutzen? Weil sie proprietär ist oder gibt es weitere Gründe?
Ich teste diese gerade mit nem wemos und bin mit dem IAQ recht zufrieden...
Riesen Aufwand zu installieren, ändert sich gefühlt jeden Monat ... dann wieder von vorne ...
Also nicht gerade Anwender-freundlich.
Habe beide Varianten mehrfach am Laufen ... mit Jörgs Version mehr als zufrieden, da sie zuverlässig läuft!
Sobald ich etwas Luft habe, kümmere ich mich um die neue Version.
Grüße,
Jürgen
Hallo zusammen.
Ich hatte mir hier aus dem Forum mal die .bin zum Testen gezogen. War irgendwann im Frühjahr. Lief jetzt auch Monate lag sauber durch.
Seit Letzter Woche zeigt der Sensor auf einmal viel niedrigere werte an. Ich lag immer Zwischen 600-1300. Den einen Tag hatten wir etwas gefeiert deswegen war der Wert dann mal wieder erhört. Auf einmal Brach der Wert ein und jetzt bin ich immer so bei 150-650.
Defekt vom Sensor oder worauf tippt ihr?
https://www.directupload.net/file/d/5971/692nuneb_png.htm (https://www.directupload.net/file/d/5971/692nuneb_png.htm)
Hi,
vermute Baseline-Drift, dann ein Reset/Neustart mit neuer Baseline.
Jürgen
Zitat von: juergs am 14 Oktober 2020, 20:08:43
Hi,
vermute Baseline-Drift, dann ein Reset/Neustart mit neuer Baseline.
Jürgen
kann sein aber so ein Abfall hab ich noch nie beobachtet und bis heute sind die Werte niedriger als sonst. Wobei langsam gehen die wieder hoch. Es ist immer schwer sowas ohne Referenzwert zu beurteilen.
Es empfiehlt sich wegen der Baseline den Sensor zuerst an "frischer" Luft in Betrieb zu nehmen um die Baseline zu setzen.
Je nach Stabilität des 8266 oder Netzteil kann es aber vorkommen, das ein Reset die Baseline auf ein beliebiges VOC-Level setzt.
Das sich das dann additiv auswirkt .... wandert die Anzeige über einen längeren Zeitraum möglicherweise nach oben....
Na ja, als Referenz, ohne auf andere Sensoren auszuweichen, kann ich das BME680-Serial-Breakout-Board: GY-BME680MCUV1 (https://github.com/juergs/BME680_TFT_Monitor) empfehlen.
Es beinhaltet wohl die Bosch-BSEC-Shared-Lib und ist (noch) relativ günstig erhältlich.
Als Vergleich leistet es schon seit langer Zeit sehr gute Dienste.
Grüße,
Jürgen
Hier noch ein interessantes Projekt: https://www.umwelt-campus.de/forschung/projekte/iot-werkstatt/ideen-zur-corona-krise (https://www.umwelt-campus.de/forschung/projekte/iot-werkstatt/ideen-zur-corona-krise)
Mit Tipps: Frischluft zur Bestimmung der Baseline.
Vorab schonmal vielen Dank für die sehr erhellende Diskussion in diesem Thread und natürlich für die BME680 Bibliotheksanpassungen!
Ich habe einige ESPs seit Jahren im Einsatz und bin sehr positiv überrascht von der Funktionsvielfalt von ESPEasy.
Habe die aktuelle Dev-Version (mega-Branch) aus dem GIT und dazu die Bibliotheken von @juergs über PlatformIo für einen ESP-01 kompiliert.
(Neben BME680 habe ich noch den BH1750 angeschlossen).
Parallel dazu habe ich mir die letzten Quellen von @herrmannj angeschaut - da sieht die Berechnung inzwischen sogar etwas einfacher aus. Bin dabei, den Algorithmus in die js_BME680 Bibliothek einzubauen. Allerdings wundere ich mich, dass die Baseline bisher nicht im Flash zwischengespeichert wird. Ihr habt bestimmt einen triftigen Grund dafür!? :)
Alex
ZitatAllerdings wundere ich mich, dass die Baseline bisher nicht im Flash zwischengespeichert wird.
Na ja, da müsste man wohl Versuche starten, ob man durch eine gespeicherte Baseline ein "Genauigkeitsvorteil" einkauft.
Solche Sachen wie z.B. Drift und Sensor-Alterung spielen da wohl noch eine Rolle.
Das lässt sich wohl nur durch weitere Versuchsreihen beantworten. Vielleicht kann
@herrmannj etwas mehr dazu beitragen?
Oder es reicht einfach aus, bei geöffnetem Fenster die "Baseline" zu nutzen. (Manuell, nach Einschalten und ggf. nach einem Reset des ESPs?)
Wobei meine ESPEasy-Variante eigentlich klaglos mit MQTT und Grafana erfreulich konstant durchläuft und die angezeigten Werte durchaus plausibel sind
Allerdings: Verbesserungen sind jederzeit willkommen ... :)
Grüße
Jürgen
PS: Es gibt ja mittlerweile viele interessante Aktivitäten zum BME680 + SCD30, wie Jörg auch schon erwähnte.
Auch hier z.B. https://forum.fhem.de/index.php/topic,108782.msg1029949.html#msg1029949 (https://forum.fhem.de/index.php/topic,108782.msg1029949.html#msg1029949)
oder hier: https://www.umwelt-campus.de/forschung/projekte/iot-werkstatt/ideen-zur-corona-krise-1 (https://www.umwelt-campus.de/forschung/projekte/iot-werkstatt/ideen-zur-corona-krise-1)
Ich bin von diesen Adsorptionssensoren in Bezug auf CO2 erst einmal komplett abgekommen, sondern verwende inzwischen MH-Z14 und MH-Z19B. Sehr viel besser .
Die Adsorptionssensoren werde ich demnächst parallel dazu betreiben, und den Wert aus den IR-Sensoren zur Kalibrierung der Adsorptionssensoren verwenden.
LG
pah
Dann wäre sowas: Multifunktionaler-Luftqualität-Messgerät-Kohlendioxid-Gasanalysator (https://www.amazon.de/Multifunktionaler-Luftqualit%C3%A4t-Messger%C3%A4te-Kohlendioxid-Gasanalysator/dp/B08LL7JBSH/ref=psdc_6589163031_t4_B08M68B6LD)
mit TVOC + CO2 möglich :-)
Der MH-Z19B (ABC abschalten!) macht einen exzellenten Job.
Damit die "Baseline" eines BME680 zu setzen wird nicht funktionieren. Erstens ist die Korrelation TVOC und CO2 nicht zwingend. Wenn sie es wäre, dann bräuchte man den BME680 auch gar nicht. Zweitens ist die "Baseline" beim BME ein viel komplexeres Konstrukt verglichen mit (zB) dem MH-Z19B. MOX Sensoren sind 10^x mal empfindlicher für HO2 im Vergleich zum Zielgas. IR /MH-Z19B dagegen überhaupt nicht. Dazu kommen Memory Effekte beim MOX. Daher ist es auch nicht zielführend die MOX "Baseline" im Flash zu speichern.
vg
Joerg
Du missverstehst mich - von einer Korrelation habe ich kein Wort geschrieben, und natürlich kann ich nicht die Baseline eines Sensors mit der eines anderen eichen. Allerdings habe ich mit dem MZ-Z19B einen CO2-Datenwert, der mir klar sagt, wann der Adsorptionssensor aus dem Ruder läuft und geheizt werden muss.
Setzt man darüber hinaus verschiedene Adsorptionssensoren ein, die unterschiedliche Empfindlichkeiten für andere Gase aufweisen, kann man durch eine entsprechende Ausgleichsrechnung sogar einzelne Komponenten des Gemisches bestimmen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 13 Dezember 2020, 05:20:42
Du missverstehst mich - von einer Korrelation habe ich kein Wort geschrieben, und natürlich kann ich nicht die Baseline eines Sensors mit der eines anderen eichen. Allerdings habe ich mit dem MZ-Z19B einen CO2-Datenwert, der mir klar sagt, wann der Adsorptionssensor aus dem Ruder läuft und geheizt werden muss.
Setzt man darüber hinaus verschiedene Adsorptionssensoren ein, die unterschiedliche Empfindlichkeiten für andere Gase aufweisen, kann man durch eine entsprechende Ausgleichsrechnung sogar einzelne Komponenten des Gemisches bestimmen.
LG
pah
Eine simple Version einer solchen Baseline-Korrektur mittels CO2-Sensor setze ich schon eine Weile ein (siehe weiter oben): wenn die Luft sauber ist (CO2 << 500), dann ist der aktuelle Wiederstandswert des MOx-Sensors die neue Baseline. Funktioniert schon ganz gut, natürlich nur unter der Annahme, dass es draußen nicht müffelt.
Gerade im Winter hätte ich aber gerne noch eine bessere Temperaturstabilität der Bosch-Sensoren. Leider geben sie aber die Temperatur des Heizelementes nicht aus, so dass eine Kompensation knifflig wird ...
Stell einige Minuten nach dem "kalibrieren" eine Schüssel mit kochendem Wasser in die Nähe des Sensors und warte kurz ab. ;)
Oh Orakel, Ihr sprecht in Rätseln.
LG
pah
Der "Versuchsaufbau" war für peterk_de und mit einem Rätsel hat das wenig zu tun. Die Schüssel mit kochendem Wasser sorgt für eine höhere absolute Feuchte in der Luft. In deren Folge wird der MOX fälschlicherweise einen massiven TVOC Anstieg ausgeben.
Der "Versuchsaufbau" mit kochenden Wasser illustriert auf extreme Art ein reales Problem. Beim Lüften, speziell in der dunklen Jahreszeit, sinkt die absolute Feuchte im Raum (typischerweise). In den Räumen hast Du jedoch einen kontinuierlichen Feuchtigkeitseintrag (Atmen, kochen, usw). Weil der Feuchte Anteil den TVOC massiv überlagert sind absolute Werte so verfälscht, dass Steuerungen die darauf basieren keine sicher reproduzierbaren Ergebnisse liefern oder ausreichend deterministisch sind.
Um das von Jörg gesagte vom SCD30 (NDIR) mit eCO2 vom BME680 + BSEC noch zu verdeutlichen:
https://twitter.com/hosi1709/status/1321354977214955521 (https://twitter.com/hosi1709/status/1321354977214955521)
Die neueste BSEC (https://github.com/BoschSensortec/BSEC-Arduino-library/releases) Library-Version soll ohne Linkerscript-Gefummel auskommen:
v1.6.1480
@BoschSensortec BoschSensortec released this 26 days ago
Updated to v1.4.8.0.
Updated the ESP8266's static library to not need linker script modifications.
Ich habe die Adsorptionssensoren in den SmartHome Hacks ausführlich behandelt und kann jedem gerne das physikalische Prinzip erklären. Insofern bleibe ich dabei: Verwendet man Sensoren mit unterschiedlichen Empfindlichkeitsprofilen, kann man auch einzelne Gase - ich denke an Stickoxide, Ozon, CO und CO2 - herausfieseln. Hat man nur einen Sensor, ist und bleibt das Kaffeesatzleserei und man kann durch keine noch so gute "Bibliothek" (aka Algorithmus) diese Daten erhalten.
Sieht man auch sehr deutlich an dem Peak der CO2-"Messung" aus dem Adsorptionssensor um ca. 16:20 heute - das KANN kein CO2 gewesen sein (ist ein CCS811). Der MHZ19 hängt derzeit an einem ESPDuino, das Programm kommt noch auf eine NodeMCU.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Dezember 2020, 19:23:13
... Insofern bleibe ich dabei: Verwendet man Sensoren mit unterschiedlichen Empfindlichkeitsprofilen, kann man auch einzelne Gase - ich denke an Stickoxide, Ozon, CO und CO2 - herausfieseln. ...
Ich habe nie das Gegenteil behauptet und sehe auch sonst niemanden. Klar kann man das. Mit den richtigen Kontakten und gegen Einwurf ganz vieler Münzen kann man da sogar richtig gute Sensoren kaufen die genau das machen. ;)
Unabhängig davon misst ein CCS811 natürlich kein Co2 sondern "berechnet" (btw furchtbar plump) ein eCO₂ (CO₂-Äquivalente). Was sinnfrei ist, da es eben keine zwingende Korrelation zwischen TVOC und CO₂ gibt. Und weil die TVOC Messung bauartbedingt relativ (und nicht absolut) ist, kann man damit halt nichts ernsthaftes anfangen. Btw der CCS811 gehört zu den grottigsten Vertretern seiner Zunft. Dann doch bitteschön wenigsten AMS IAQ oder BME680 ... :(
Von daher volle Zustimmung:
ZitatAutor: Prof. Dr. Peter Henning
« am: 12 Dezember 2020, 20:58:07 »
Ich bin von diesen Adsorptionssensoren in Bezug auf CO2 erst einmal komplett abgekommen, sondern verwende inzwischen MH-Z14 und MH-Z19B. Sehr viel besser .
Genauso siehts aus.
Wer evtl. einem herumliegenden CSS811-Modul trotzdem einer Verwendung zuführen möchte:
https://revspace.nl/CJMCU-811 (https://revspace.nl/CJMCU-811)
https://github.com/maarten-pennings/CCS811 (https://github.com/maarten-pennings/CCS811)
Dann noch eine interessante Abhandlung über Placing VOC Sensors for Assessing Air Quality (A CFD Study of Indoor VOC Distribution) (https://kth.diva-portal.org/smash/get/diva2:1233872/FULLTEXT01.pdf)
Hallo Zusammen,
wurde über eine Github-Issue über ein Verhalten des BME680 angesprochen:
ZitatI tried this library with my BME680 and I am 100% sure it gives wrong results in warmer rooms. The formula used to calculate tvoc is definitely not properly accounting for temperature. In a room with 28/29 °C the library gave a reading of 150-180 ppm in contrast to fresh (cold) air where it immediately went up to 240 before I closed the window.
Bottom line: Do not rely on the values produced here.
Deshalb habe ich selbst noch mal Versuche mit einer hohen Temperatur-Differenz beim setzen der Baseline mit rel. hohem Temperturunterschied.
In Grafana mit einer Saplerate von 5 Minuten und Kurvenglättung komt der Effekt kaum zum Tragen.
Allerdings in FHEM mit kleinerer Samplerate wird der Effekt sichtbar.
- Getrennter Raum und Kühlschrankaufenthalt des Sensor für ca. 10 Minuten
- Dann Arbeitszimmer bei ca. 21°C
- Setzen der Baseline außerhalb des Fenster bei ca. 2°C für ca. 10 Minuten
- Dann Reinholen des Sensors ins Arbeitszimmer
Man sieht deutlich das Überschiessen der Luftfeuchtigkeit (und TVOC-Peak) im FHEM-Plot, wohl durch Kondensationseffekte am Sensor.
Da Ganze stabilisiert sich aber bei Angleichung an die Raumumgebung.
Durch eine höhere Abttastrate geht dieser Effekt im Grafana-Plot einfach unter.
Sieht für mich nach keinem Fehler aus, sondern bestätigt eher das von herrmannj über Absorptions-Sensor-Typen gesagte. :)
Die Aussage:
ZitatBottom line: Do not rely on the values produced here.
ist mir dann doch etwas zu vorschnell und pauschal ....
Bosch Sensortec hat einen
Nachfolger, den
BME688 für den BME680 in petto:
Zitat
Environmental sensing with Artificial Intelligence.
... is the first gas sensor with #AI and lets you monitor #airquality and helps to improve your health and well-being. Train the BME688 yourself by using the new BME AI-Studio tool
ZitatAdditionally to all features of the BME680, the BME688 has a gas scanner function. In standard configuration, the presence of VSCs is being detected as indicator for e.g. bacteria growth.
And the gas scanner can be customized with respect to sensitivity, selectivity, data rate and power consumption as well.
The BME AI-Studio tool enables customers to train the BME688 gas scanner on their specific application
https://www.bosch-sensortec.com/products/environmental-sensors/gas-sensors/bme688/ (https://www.bosch-sensortec.com/products/environmental-sensors/gas-sensors/bme688/)
https://buyzero.de/products/bosch-bme688-gas-sensor-developer-kit (https://buyzero.de/products/bosch-bme688-gas-sensor-developer-kit)
https://buyzero.de/blogs/news/bme688-bme688-shuttle-board-status (https://buyzero.de/blogs/news/bme688-bme688-shuttle-board-status)
https://www.messe-ticket.de/Nuernberg/embeddedworld2021/ (https://www.messe-ticket.de/Nuernberg/embeddedworld2021/)
https://www.bosch-sensortec.com/media/boschsensortec/downloads/product_flyer/bst-bme688-fl000.pdf (https://www.bosch-sensortec.com/media/boschsensortec/downloads/product_flyer/bst-bme688-fl000.pdf)
Zitatwe will be able to ship at the end of March / beginning of April!
Ist halt alles im "preliminary"-Status noch mit Vorsicht zu geniessen .. ;)
Magst du nochmal deine aktuelle Wemos D1 / bme280 Firmware hochladen? Mit der bin hier im Thread vom November 2019 bekomme ich zwar Werte aber Tvoc bleibt auf NaN.
Du meinst BME680 mit EaspEasy? ;)
Ich vermute es ist was mit der Modulanbindung zum Wemos.
Welches Modul benutzt Du? Vielleicht fehlen die I2C-Pullup-Widerstände und müssen gesetzt werden?
Mit den Sourcen (https://github.com/juergs/ESPEasy_BME680_TVOC) könntest Du selbst ESPEasy mit der Arduino-IDE kompilieren ...
Mit den neuen Daten von hermannj (https://github.com/herrmannj/airq-mqtt)
Zitathttps://github.com/herrmannj/airq-mqtt/blob/master/IAQ_BME680.h
https://github.com/herrmannj/airq-mqtt/blob/master/IAQ_BME680.cpp
könntest Du sogar schon eine neuere Version erzeugen!
Was sagt das ESPEasy-Log? Wie ist Deine Konfiguration? Debug-Options (https://github.com/juergs/ESPEasy_BME680_TVOC/blob/master/ESP_Easy_BME680_Konfiguration.png) mal gesetzt und per SerialMonitor in Arduino abgefragt?
Läuft ein Beispiel-Sketch (https://randomnerdtutorials.com/bme680-sensor-arduino-gas-temperature-humidity-pressure/) für den BME680. Z.B. von Adafruit oder Pimoroni?
Ja natürlich den BME680. cjmcu-680 https://www.amazon.de/gp/product/B07K1CGQTJ/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1
Ich habe diese BIN-genommen: 20191104_ESPEasy.ino.bin die du hier im Thread hochgeladen hattest.
Mit dem selber kompilieren komme ich noch nicht so recht weiter.
Einen Hinweis auf Pullup-Wiederstände hatte ich da nicht gefunden - hast du da einen Link für mich ?
ich habe den Wemos so verbunden:
3v3 - VCC
gnd -gnd (muss ich das auch mit SDO verbinden? Das habe ich nicht getan)
d1 - scl
d2 - sda
Mehr habe ich an dem Wemos nicht angeschlossen.
Ich hatte hier geschaut https://github.com/juergs/ESPEasy_BME680_TVOC - das passt also.
Und wie gesagt bekomme ich auch Werte für Barometer, Temperatur und Feuchtigkeit - nur nicht für VOC
Nachdem ich ESPEasy geflasht habe und dann wieder deine bin-Datei kommt jetzt auch bei TVoc ein Wert - was auch immer nun anders ist...
Trotzdem wäre ich für ein aktuelles Compilat dankbar - ich nuze dabei im moment die SLINK-Abindung - habe aber auch MQTTauf dem Fhem am laufen.
Der BME680 wird mit I2C-Konfiguration (https://i2.wp.com/randomnerdtutorials.com/wp-content/uploads/2020/07/ESP8266-BME680-Environmental-Sensor-Wiring-Diagram-I2C-1.png?w=831&quality=100&strip=all&ssl=1) verbunden. Der SDO gehört zu SPI.
Anschluss analog zum BME280 :D
Wenn Du Daten angezeigt bekommst, sollte das so stimmen. Vielleicht ist etwas beim Flashen schiefgelaufen...
Der Sensor braucht etwas Zeit zum Starten evtl. kommt "0" oder "NaN" in der Initphase. Sollte aber nach ein paar Minuten dann Werte anzeigen ... :)
Zitat//--- allow 300 sec (5 min) to warm-up sensor for stable voc resistance (300000ms)
Liefert also erst nach 5 Minuten Werte!
BME680-Breakout (https://easyeda.com/adrirobot/BME680-Breakout)
Um die Integration des BME680-Plugin-Moduls in die aktuelle ESPEasy-Version werde ich hier (https://forum.fhem.de/index.php/topic,119678.msg1141132.html#msg1141132) weiterführen + dokumentieren.
Da die Lernkurve in den letzten 2 Jahren doch mit Visual Code und Platformio deutlich angestiegen ist und neue Grundlagen dafür erarbeitet werden müssen. ;)
Grüße,
Jürgen
PS: Aktuelles Binary: ESPEasy-mega_BME680_TVOC_20210223/releases (https://github.com/juergs/ESPEasy-mega_BME680_TVOC_20210223/releases)
PS2: Implementierung neuer Baseline-Algorithmus: Sourcen und Binary der V2 im Github-Repository (https://github.com/juergs/ESPEasy-mega_BME680_TVOC_20210223/releases/tag/release_2.0) (Vorsicht Beta !)
Ich habe mal BSEC und Jörgs Baseline-Algorithmus einer "Langzeitbeobachtung" unterzogen und konnte daraus 3 Punkte ableiten
wie sich der BSEC-Algorithmus verhält.
- Phase_1: Die Offset-Drift baut sich bei V1 kontinuierlich auf. Bis der nächste Reset wieder das Niveau auf 0 setzt. (mittlerer Offset befindet sich jetzt bei ca. 1000)
- Phase_2: Durch die Offsetdrift schlagen Minima stärker duch. BSEC begrenzt die Minima und zieht sie auf die Baseline, auch in dem der Algorithmus zu starke Ausschläge kappt.
- Phase_3: Die Offsetdrift hat sich nach einem Reset verschoben (mittlerer Offset befindet sich jetzt bei ca. 500)
Wäre für eine Baseline-Korrektur die Differenz zwischem z.B. Gleitendem Mittelwert (Ringpuffer für sinnvollen Zeitabschnitt) und dem größtem Minima-Ausschlag (prozentual gewichtet, ca. 10..20%)
ein möglicher Korrekturwert des bestehenden Algorithums von herrmanj?
Da ich ein Tiefpassfilter zwischengeschalten habe, sind Ausschläge zwar noch präsent, aber doch nicht so stark beeinflusst, wie unter BSEC. Dennoch scheint die zeitliche Verschiebung (Latenz)
ähnlich zu sein ... ;)
Im Moment scheint mir Jörgs erster Algorithmus die bessere Wahl zu sein. Wenn man noch die Baseline-Kompensation in Griff bekommt, braucht man kein BSEC mehr ;D
Die zweite Variante (mittlere Grafik) scheint mir noch nicht so gut zu funktionieren.
Grüße,
Jürgen
Im Anhang mal eine 24h Messung in meinem Schlafzimmer, inkl des Nachts eines Menschen drin schlafens, mit Fenster offen um 23:30 und dann nochmal um 10:00
Vergleich Sensair Sunrise CO2 Sensor (mit 30ppm Genauigkeit) und des V2 Filtered BME680 auf EspEasy
Den linearen CO2 Anstieg, den man im Raum hat, hat er nicht mitgekommen, aber nach Schließen des Fensters um 11:30 einen unerklärlichen, massiven Anstieg VOC gemessen, den der CO2 Sensor nicht gesehen hat (Zimmer war danach menschenleer)
Könnets Du bitte noch mal ein ähnliches Szenario ohne Filterung erzeugen.
Wenn möglich, mit Luftfeuchte.
Grüße,
Jürgen
/Edit: das Sprungantwortverhalten der V2, nach Fensteröffnen und schließen, ist auch bei mir auch nachvollziehbar.
Nochmal die
V1 mit verschiedenen Filterarten ( Kalman- + gewichteter Exponentialfilter) in die Betrachtung.
- Blau: Sensorwiderstand / 1000
- Rot: TVOC
- Grün: gew. Exponentialfilter
- Gelb: Kalmanfilter
Man sieht in Phase 1 die hohe Abweichung des Verlaufs zur reinen resistiven Kurve, während Phase 2 sauber und Phase 3 verzögert folgt.
/edit: Der Widerstand des BME680 wird größer, wenn Luft reiner. TVOC folgt gegensinnig. Scheint also eigentlich alles OK, bis auf die hohe "Verstärkung" bei schneller Differenz.
Muss den Einfluss der hohen Sprungantworten im V1-Algorithmus noch genauer herausarbeiten.
Mir fehlt im Moment der Vergleich zu einem realen CO2-Sensor.
Mein MHZ19B scheint nicht so richtig zu wollen ... :(
Zitat von: juergs am 03 April 2021, 20:24:23
Könnets Du bitte noch mal ein ähnliches Szenario ohne Filterung erzeugen.
/Edit: das Sprungantwortverhalten der V2, nach Fensteröffnen und schließen, ist auch bei mir auch nachvollziehbar.
Na klar, ich hab den Filter ausgeschaltet und werde berichten, sobald die Daten vorliegen. Bis dahin die Daten der letzten 2 Tage inkl T und %H (=2 Schlafzyklen) und Filter tVOC=true
Resistance (rt) - V1 (bl) - V2 (gn). Ohne Filterung.
V2: Baseline-Berechnung braucht > 5 Minuten.
V2: Fensteröffnen ab ca. 800 fährt in die Begrenzung der Baseline ...
An der Außenluft, sieht man das Verhalten der V2 gegen die V1.
Die V1 reagiert etwas verstärkend zu Änderungen aber folgt sicher Rsensor.
Im Moment sehe ich eher die V1 vorne. Das Offset-Problem resultiert eigentlich nur aus der Veränderung der Baseline bei einem Reset in belasteter Luft.
Die V2 reagiert etwas übernervös auf schnelle Änderungen.
Das wirft natürlich die Frage (wieder) auf, dass man die Baseline-"Kalibrierung" in "reiner" Luft speichert und nach einem Reset weiter verwendet.
Das sieht Bosch-Sensortech auch über die Parameter-Sicherung in der Adafruit-Lib so vor.
Evtl. nehme ich in mein Testcase von hier (https://forum.fhem.de/index.php/topic,116185.0.html) den MHZ19 (https://www.letscontrolit.com/forum/viewtopic.php?t=3736) + MQTT (Publish) und den SCD30 noch mit auf.
Auch dieser Thread: https://forum.fhem.de/index.php/topic,96241.msg892379.html#msg892379 (https://forum.fhem.de/index.php/topic,96241.msg892379.html#msg892379) ist zu berücksichtigen!