LaCrosseGateway und BME680

[hdgucken]

Leider sind die CRC-Fehler wieder häufiger aufgetreten, hab erstmal die "SPI-Bremse" angezogen, dabei ist mir aufgefallen, das der accuracy Wert immer bei "1" bleibt.
Scheint so, als wäre durch die Verlangsamung des SPI Taktes das BSEC Timing schon beeinträchtigt  Ein Problem jagt das Andere. Aber sonst wär's ja auch langweilig 

Gruß Thomas

[hdgucken]

Mein accuracy Wert ist jetzt wieder bei "(3)", mußte sich der Sensor doch wieder über mehrere Tage einpegeln, so ein Käse ...
Mal schauen, ob man das mit dem Speichern dieser "Lernwerte" hinbekommt, vorbereitet ist das Ganze ja schon in der BSEC Soft.
Dann funktioniert das mit den 400kHz SPI Takt für den RFM, ist ja auch nicht schlecht zu wissen. Hatte noch mit 450kHz probiert,
ging nicht, CRC-Fehler und sogar wieder viele gar nicht empfangene Pakete, was aber auch am Traffic gelegen haben könnte, also
ungünstiger Einschaltzeitpunkt, so dass zu viele Sensoren zur gleichen Zeit gesendet haben.

[HCS]

Eventuell wäre eine ganz kleine zeitliche drift sinnvoll, dass der Sensor wieder aus dem Timig des piratisierenden Senders raus kommt.

Und die Basline speichern und beim Neustart laden ist wohl auch extrem wichtig, sonst brauch er nach jedem Rest wieder Tage, bis er geistreiche Werte liefert.

Angehängt ein Chart mit Deiner Firmware oben (UniversalSensor-Edition) und unten zum Vergeich ein CO2mini, das seit einigen Wochen parallel zu den BME680-Experimenten mitläuft.
Das CO2mini hat einen echten CO2-Sensor drin, liefer also CO2 und nicht irgend ein Eqivalent. Die Werte sind (nicht nur heute) sehr realistich und spiegeln das Geschehen in der Umgebung sehr gut wieder.

Da ich aktuell den SPI-Takt nicht runtergesetzt habe, kommen viele defekte Pakete an und manchmal (wie man deutlich sieht) bestehen sie sogar die CRC-Prüfung.
Da muss ich definitiv nochmal ran, so was darf nicht durchkommen.

[HCS]

Ich habe das UniversalSensor-Protokoll auf CRC16 CCITT umgebaut. Seitem ist kein Paket mit ruinierten Daten mehr durchgekommen.

Angepasste hdgucken sources und ein neues LGW anbei.

[PeMue]

Hallo HCS;

Angepasste hdgucken sources und ein neues LGW anbei.

Deine Version heißt v1.6f, Thomas' Version hier ist schon v1.7. Welche ist denn jetzt die aktuellere bzw. welche hast Du als Basis verwendet  ?
Ich denke, ich werde noch eine Weile warten bis sich die Software etwas stabilisiert hat 

Danke + Gruß

Peter

[hdgucken]

Hallo HCS, Hallo Peter,

hab soeben meinen Universalsensor ( V1.8 ) in Betrieb genommen. Läuft einwandfrei, vielen Dank an HCS !
Habe die Software auch noch mal überarbeitet, alles etwas aufgeräumt und sämtliche Verbesserungen vom CC-Sensor mit eingebaut:

alle Extra's sind an/abwählbar(OLED,Lichtsensor und Spannungsmessung).
Spannungsmessung jetzt doch über die interne Methode, funktioniert für NodeMCU, D1 mini und baugleiche.
400kHz SPI Takt (wegen sonst aufgetretener CRC-Fehler)
Anzeige der BSEC Version beim Start

Aktueller Stand ist jetzt Universalsensor V1.8 (basiert auf Universalsensor V1.6 + HCS's Verbesserungen bzgl. CRC16 + meine Verbesserungen vom CC_Sensor V1.7) 

Ich hänge mal meinen Stand für die weitere Bearbeitung mit ran  :

[hdgucken]

noch ein paar Impressionen:

und zwei fertige Binarys V1.8:
1. NodeMCU ohne OLED und Lichtsensor, Node-ID: 0xEE, BME680 auf 0x76
2. WEMOS D1 mini ohne OLED und Lichtsensor, Node-ID: 0xEE, BME680 auf 0x76

Gruß Thomas

[hdgucken]

eine Kleinigkeit hab ich noch, um den Gas Widerstandswert im Fhem Plot in kOhm darzustellen, einfach:

Code Auswählen Erweitern

$fld[3]/1000
in der Zeile für Gas2 unter "Function" eintragen.

siehe Anhang:

Gruß Thomas

[HCS]

Da es wohl zumindes FHEM-Seitig funktioniert, könnte ich dann das 36_LaCrosse.pm und ein LGW V1.31 einchecken, oder weist Du noch ein zu lösendes Problem?

[oli82]

Da es wohl zumindes FHEM-Seitig funktioniert, könnte ich dann das 36_LaCrosse.pm und ein LGW V1.31 einchecken, oder weist Du noch ein zu lösendes Problem?

Heist das dann Gateway mit BME680 oder Gateway, welches einen BME680 über LaCrosse empfängt?

[HCS]

Heist das dann Gateway mit BME680 oder Gateway, welches einen BME680 über LaCrosse empfängt?

Aktuell bedeutet es:
- Das LGW kann das UniversalSensor-Protokoll, das der BME680/Licht-Sensor von hdgucken sendet
(oder jeder andere Selbstbau-Sensor senden könnte, um (optional) Temperatur, Feuchte, Druck, 2xGas, Lux, Regen, Wind, Windböen, Windrichtung, Spannung und Version loszuwerden)

- Das LaCrosse Device in FHEM unterstützt diese Readings

- Das LGW kann selbst einen BME680, übermittelt aber nur Temperatur, Feuchte, Druck und den Widerstand des Gas-Sensors (IAQ oder was auch immer muss man sich in FHEM selbst daraus zurechtkristallkugeln)

Also das wäre so, wenn ich es dann mal einchecken würde ...

[oli82]

Also das wäre so, wenn ich es dann mal einchecken würde ...

Danke für die Erläuterung.

Habe noch die Vorabversion der 1.31 drauf. Es hieß ja, dass es Timingprobleme gibt.
Deshalb fragte ich nochmal nach.

[hdgucken]

Hallo HCS,

Da es wohl zumindes FHEM-Seitig funktioniert, könnte ich dann das 36_LaCrosse.pm und ein LGW V1.31 einchecken, oder weist Du noch ein zu lösendes Problem?

Kannst Du so einchecken 

Hab V1.9 fertig, BME680 I2C Adresse einstellen ist vorbei, geht jetzt automatisch !!!
Hab noch auf arduino esp8266 V2.4.0 umgestellt, musste dadurch den vcc Korrekturfaktor anpassen, waren plötzlich 0.4V mehr 
Projekt anbei ...

Gruß Thomas

[PeMue]

Hallo Thomas,

Hab V1.9 fertig, BME680 I2C Adresse einstellen ist vorbei, geht jetzt automatisch !!!

ist das JeeLink_LaCrosseGateway.bin aus Deinem ZIP-Archiv die Firmware vom Universalsensor?
Oder einfach die v1.31-prel(irgendwas) von HCSs Firmware für das LaCrosse Gateway?

Danke + Gruß

Peter

[HCS]

Hier ist auf alle Fälle die aktuelle Version vom LGW und 36_LaCrosse drin, die für jegliche hdgucken-Version Voraussetzung ist.
https://forum.fhem.de/index.php?action=dlattach;topic=78128.0;attach=92996