LaCrosseGateway und BME680

[SusisStrolch]

Ich wollte die aktuelle Beta installieren, habe jedoch das Problem das OTA aus FHEM heraus nicht funktioniert.
Beim LCG mit BME280 funktioniert der OTA, beim LCG mit BME680 hingegen nicht.

Code Auswählen Erweitern


2017-12-04 15:47:25.943 Global global    Started not blocking
2017-12-04 15:47:25.948 Global global    flashing LaCrosseGateway LCG.BME680
2017-12-04 15:47:25.953 Global global    hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
2017-12-04 15:47:25.959 Global global    Mode is LaCrosseGateway OTA-update
2017-12-04 15:47:25.964 Global global    LCG.BME680 closed
2017-12-04 15:47:25.969 Global global    target: http://192.168.254.139/ota/firmware.bin
2017-12-04 15:47:26.003 Global global    Upload started, please wait a minute or two ...
2017-12-04 15:47:29.505 Global global   
2017-12-04 15:47:29.510 Global global    --- LGW reports ---------------------------------------------------------------------------
2017-12-04 15:47:29.515 Global global    Start receiving 'firmware.bin'
2017-12-04 15:47:29.520 Global global    ERROR: UPLOAD_FILE_START
2017-12-04 15:47:29.525 Global global    ERROR: UPLOAD_FILE_WRITE
2017-12-04 15:47:29.529 Global global    ERROR: UPLOAD_FILE_WRITE
2017-12-04 15:47:29.533 Global global    ERROR: UPLOAD_FILE_WRITE
...
2017-12-04 15:47:30.534 Global global    ERROR: UPLOAD_FILE_WRITE
2017-12-04 15:47:30.539 Global global    ERROR: UPLOAD_FILE_END
2017-12-04 15:47:30.543 Global global   
2017-12-04 15:47:30.547 Global global    ERROR: OTA update failed
2017-12-04 15:47:30.552 Global global    ----------------------------------------------------------------------------------------------------
2017-12-04 15:47:31.101 Global global    LCG.BME680 opened
2017-12-04 15:47:31.105 Global global    Finshed


[SusisStrolch]

Nachtrag: das gleiche Ergebnis (ERROR...) bei OTA via curl...

[HCS]

Nachtrag: das gleiche Ergebnis (ERROR...) bei OTA via curl...

Hmmm, so habe ich gestern das "BME680-LGW" mehrmals aktualisiert.

Hattest Du es ursprünglich mit "Flash Size 4M (3M SPIFFS)" geflasht?

Gerade nochmal probiert mit:

Code Auswählen Erweitern

curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@..\Release\LaCrosseGateway.ino.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin

Ergebnis:

Code Auswählen Erweitern

Starting upload
######################################################################## 100,0%
.
Response from LGW
-----------------
Start receiving 'firmware.bin'
Firmware size: 485728
Rebooting ESP8266 ...

OTA update finished
Drücken Sie eine beliebige Taste . . .

Das lief sogar durch den VPN-Tunnel ohne Probleme.

und die vier Tage Einlernphase des BME680 beginnen nun wieder neu ...

[trebron106]

Hi
bei mir hat das Flashen problemlos geklappt. Aber im Reading Debug sind jetzt sehr große Werte zB. 1239554.  Sehen um eine 10er Potenz zu gross  aus.

Gruß
Klaus

[SusisStrolch]

Hattest Du es ursprünglich mit "Flash Size 4M (3M SPIFFS)" geflasht?

Das könnte die Ursache sein... habe das Modul ursprünglich mit

Code Auswählen Erweitern

esptool.py -b 921600 -p /dev/ttyUSB0 write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 ../Development/BME680/Test680.bin
geflasht.

Kann erst Samstag wieder testen...

[juergs]

Musste heute resetten ...  blieb fest auf 391 IAQ.
Evtl. auch erst wieder die BurnIn-Phase ...
Das Signal scheint jetzt deutlich ruhiger zu sein ...
Mal beobachten ...

[juergs]

Hallo,
heute zeigt der BME680 in der neuen BSEC-Version im LGW ein etwas seltsames Verhalten....
(Vergleich zu iAQ-Core)

[HCS]

Zitat aus: https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf

BME680 is a metal oxide-based sensor that detects VOCs by adsorption (and subsequent oxidation/reduction) on its sensitive layer. Thus, BME680 reacts to most volatile compounds polluting indoor air (one exception is for instance CO2)

CO2 kann er schon mal überhaupt nicht messen 

Zitat von BoschSensortec aus: https://github.com/BoschSensortec/BME680_driver/issues/6#issuecomment-351274972

We will not disclose the exact nature of how the IAQ index can be calculated.

Was die IAQ nun bedeutet will man nicht verraten 

Die BSEC ist der Horrortrip, das LGW liefert aktuell keine vernünftigen Werte, weil es das erforderliche Timing, das die BSEC erwartet, nicht konstant hinbekommt.
PCA301 erwartet auch ein Timing und die Bridges und was da alles so bedient werden muss, darf es nicht vernachlässigen.

@PeMue: willst Du Dir anstatt dem BME680 nicht lieber einen echten CO2 Sensor (irgend einen NDIR-Sensor oder so was) raussuchen?
Einmal umschwenken (aber vorher genauer schauen, was der Sensor wirklich kann und macht) wäre ich noch dabei.
Oder wir finden eine Formel, wie wir ohne BSEC aus dem Widerstand etwas rechnen, das uns auch sagt, was wir da gemessen haben.

Und wenn es BME680 sein muss, kann man ihn ja damit anbinden: https://forum.fhem.de/index.php/topic,78619.msg726533.html#msg726533
Das was hdgucken da macht, finde ich nicht schlecht, weil es sich auf den BME8680 konzentrieren kann.
Das sollte eigentlich auch auf einer Nano-LGW-Platine laufen, weil es verwendet ESP8266, RFM69CW und BME680.
Ich spiele es mal auf ein NanoLGW drauf, und schaue, was passiert.

Meinungen?

[PeMue]

Hallo HCS,

erstmal vielen Dank für Deine Hartnäckigkeit, Dich mit dem Thema auseinanderzusetzen. Ich habe das Datenblatt nicht allzu detailliert angeschaut und mich eher auf den Werbeflyer verlassen, sorry.

Die BSEC ist der Horrortrip, das LGW liefert aktuell keine vernünftigen Werte, weil es das erforderliche Timing, das die BSEC erwartet, nicht konstant hinbekommt.
PCA301 erwartet auch ein Timing und die Bridges und was da alles so bedient werden muss, darf es nicht vernachlässigen.

Was nicht vernünftig geht, macht auch keinen Sinn. Die LGW Platinen sind deshalb nicht für die Katz, weil da drauf ja noch der BME280 ist, und der funktioniert ja mit der LGW Software.

@PeMue: willst Du Dir anstatt dem BME680 nicht lieber einen echten CO2 Sensor (irgend einen NDIR-Sensor oder so was) raussuchen?
Einmal umschwenken (aber vorher genauer schauen, was der Sensor wirklich kann und macht) wäre ich noch dabei.

Ja, da würde ich mitgehen. Allerdings würde ich da erstmal eine Recherche machen, was es da so alles gibt. Das wäre jetzt typischerweise die Zeit für ein "brainstorming" 
Einen oder zwei iAQ-cores müsste ich noch da haben, aber die sind teuer (27 €  ). Bei aliexpress habe ich den kleinen Bruder als breakout gesehen, der ist mit 18 € schon bezahlbarer ...
Die Diskussion der Hardware würde ich dann aber im Platinen Thread führen wollen.

Oder wir finden eine Formel, wie wir ohne BSEC aus dem Widerstand etwas rechnen, das uns auch sagt, was wir da gemessen haben.

Was müssten wir dann wie machen? Wir nehmen die gemessenen Werte und lassen diese durch einen Formelgeneratoralgorithmus? Mir ist nicht klar, was das regelmäßige Nachführen der BSEC Software macht. Macht sie das nur die ersten vier Tage oder konstant? Das Thema könnte zeitintensiv und am Ende ohne Ergebnis sein ...

Und wenn es BME680 sein muss, kann man ihn ja damit anbinden: https://forum.fhem.de/index.php/topic,78619.msg726533.html#msg726533
Das was hdgucken da macht, finde ich nicht schlecht, weil es sich auf den BME8680 konzentrieren kann.
Das sollte eigentlich auch auf einer Nano-LGW-Platine laufen, weil es verwendet ESP8266, RFM69CW und BME680.

Das habe ich mir noch nicht angeschaut, bei mir läuft die LGW Software im Hintergrund. Ich könnte aber parallel einen Wemos D1 mini mit der BME Software befüttern und in den selben Raum stellen.
Dann hätten wir einen Vergleich ...

Gruß Peter

[hdgucken]

Hallo HCS und Peter,

ich glaube auch, daß die BSEC Software (aufgrund des Timings) auf dem LGW nicht wirklich brauchbar eingebunden werden kann.

Oder wir finden eine Formel, wie wir ohne BSEC aus dem Widerstand etwas rechnen, das uns auch sagt, was wir da gemessen haben.

Das wäre auch meiner Meinung nach das Sinnvollste für den LGW, oder eben ein anderer Sensor, welcher einfacher zu handeln ist.

Das was hdgucken da macht, finde ich nicht schlecht, weil es sich auf den BME8680 konzentrieren kann.
Das sollte eigentlich auch auf einer Nano-LGW-Platine laufen, weil es verwendet ESP8266, RFM69CW und BME680.
Ich spiele es mal auf ein NanoLGW drauf, und schaue, was passiert.

Das sollte mit relativ wenig Aufwand machbar sein. OLED läßt sich deaktivieren, dann je nach Bedarf Lichtsensor und die Messung der Betriebsspannung auskommentieren.

Gruß Thomas

[HCS]

ich könnte noch LUX als weiteren optionalen Wert vorsehen, dann könntest Du

Code Auswählen Erweitern

OK WS ID  XXX TTT TTT HHH RRR RRR DDD DDD SSS SSS GGG GGG FFF PPP PPP GAS GAS GAS DEB DEB DEB LUX LUX LUX
schicken und alles geht.

Da war ich gerade voll neben der Spur. Das kann man über die HF-Strecke so natürlich nicht senden. 

Aber ich könnte wohl ein Protokoll für einen virtuellen Sensor implementieren, der genau diese Daten in das oben umsetzt, das dann von 36_LaCrosseGateway.pm -> 36_LaCrosse.pm weiterverarbeitet wird.
Also im Prinzip eine universelle virtuelle Wetterstation, die diese Daten verarbeiten kann:
-Temperatur
-Feuchte
-Niederschlag
-Wind
-Böen
-Windrichtung
-Luftdruck
-Gas
-LUX
-Debug

Das wäre mit kleinen Anpassungen oder Erweiterungen grob Dein CC-Protokoll
CC 06 0E 06 25 32 64 06 00 2A 00 10 21 09 78 47 70

Damit könnte jeder auf 868 irgend einen Sensor erfinden und solange er keine weiteren Daten als die oben aufgeführetn hat, diese einfach an das LGW schicken und bekommt dann ein ganz normales LaCrosse-Device angelegt, das diese Daten führt.

Ich glaube so sollte das gehen, was ich im ersten Anlauf vorhatte 

[PeMue]

Hallo HCS, hallo Thomas,

wenn ich das richtig verstanden habe, wäre die Strategie die folgende:

BME680 als LaCrosse Sensor:

• wir verwenden Thomas' Software, ggf. müsste bei der Initialisierung geprüft werden, ob ein OLED bzw. BH1750 da ist, falls nicht, werden diese softwareseitig nicht ausgelesen/bedient (fände ich besser als auskommentieren  )
• HCS müsste das FHEM Modul anpassen, damit dieser Sensor  mit dem LGW empfangen werden kann
• ich würde auf dem nanoLGW den LM75 runterwerfen und einen BH1750 integrieren

LaCrosse Gateway:

• der BME680 fliegt runter (weil das Timing mit der BSEC Software nicht vernünftig darstellbar ist)
• ich/wir suchen einen anderen Sensor, der softwareseitig besser integrierbar ist
• Layout: PeMue
• LGW Software: HCS

Habe ich das soweit richtig verstanden?

Danke + Gruß

PeMue

[HCS]

Habe ich das soweit richtig verstanden?

Ja.

wir verwenden Thomas' Software, ggf. müsste bei der Initialisierung geprüft werden, ob ein OLED bzw. BH1750 da ist, falls nicht, werden diese softwareseitig nicht ausgelesen/bedient (fände ich besser als auskommentieren  )

Zumindes für OLED kann ich die Autoerkennung liefern, das LGW kann die, für den BH1750 sollte das auch machbar sein

Code Auswählen Erweitern

HCS müsste das FHEM Modul anpassen, damit dieser Sensor  mit dem LGW empfangen werden kann
Nur erweitern für LUX, der Rest (Temp, Hum, Pressure, Gas (IAQ)) müsste Stand heute schon gehen.

Code Auswählen Erweitern

ich würde auf dem nanoLGW den LM75 runterwerfen und einen BH1750 integrieren
Jeden Sensor erst genau überlegen ...   
Aber vermutlich ja.

Ob man die Betriebsspannung unbedingt braucht wäre zu überlegen, das wird man wohl eh nicht auf Batterie laufen lassen?
Aber notfalls nehmen wir sie auch noch in das "OK WS ..." format auf.

[HCS]

ich könnte noch LUX als weiteren optionalen Wert vorsehen, dann könntest Du

Code Auswählen Erweitern

OK WS ID  XXX TTT TTT HHH RRR RRR DDD DDD SSS SSS GGG GGG FFF PPP PPP GAS GAS GAS DEB DEB DEB LUX LUX LUX
schicken und alles geht.

Da war ich gerade voll neben der Spur. Das kann man über die HF-Strecke so natürlich nicht senden. 

Aber ich könnte wohl ein Protokoll für einen virtuellen Sensor implementieren, der genau diese Daten in das oben umsetzt, das dann von 36_LaCrosseGateway.pm -> 36_LaCrosse.pm weiterverarbeitet wird.
Also im Prinzip eine universelle virtuelle Wetterstation, die diese Daten verarbeiten kann:
-Temperatur
-Feuchte
-Niederschlag
-Wind
-Böen
-Windrichtung
-Luftdruck
-Gas
-LUX
-Debug

Das wäre mit kleinen Anpassungen oder Erweiterungen grob Dein CC-Protokoll
CC 06 0E 06 25 32 64 06 00 2A 00 10 21 09 78 47 70

Damit könnte jeder auf 868 irgend einen Sensor erfinden und solange er keine weiteren Daten als die oben aufgeführetn hat, diese einfach an das LGW schicken und bekommt dann ein ganz normales LaCrosse-Device angelegt, das diese Daten führt.

Ich glaube so sollte das gehen, was ich im ersten Anlauf vorhatte 

[hdgucken]

Aber ich könnte wohl ein Protokoll für einen virtuellen Sensor implementieren, der genau diese Daten in das oben umsetzt, das dann von 36_LaCrosseGateway.pm -> 36_LaCrosse.pm weiterverarbeitet wird.
Also im Prinzip eine universelle virtuelle Wetterstation, die diese Daten verarbeiten kann:
-Temperatur
-Feuchte
-Niederschlag
-Wind
-Böen
-Windrichtung
-Luftdruck
-Gas
-LUX
-Debug

Das wäre mit kleinen Anpassungen oder Erweiterungen grob Dein CC-Protokoll
CC 06 0E 06 25 32 64 06 00 2A 00 10 21 09 78 47 70

Damit könnte jeder auf 868 irgend einen Sensor erfinden und solange er keine weiteren Daten als die oben aufgeführetn hat, diese einfach an das LGW schicken und bekommt dann ein ganz normales LaCrosse-Device angelegt, das diese Daten führt.

Ich glaube so sollte das gehen, was ich im ersten Anlauf vorhatte 

Das wäre eine super Lösung finde ich 
Batterie würde ich auch weglassen, LGW mit Batterie ist nix 

... wir verwenden Thomas' Software, ggf. müsste bei der Initialisierung geprüft werden, ob ein OLED bzw. BH1750 da ist, falls nicht, werden diese softwareseitig nicht ausgelesen/bedient (fände ich besser als auskommentieren  )

Gruß Thomas

Hast natürlich recht, auskommentieren war auch nur für einen Versuch auf dem NanoLGW gemeint, müßte man dann "ordentlich" machen, mit Erkennung usw.