Hier findet die Diskussion zur Implementierung des environmental sensor BME680 von Bosch im LaCrosseGateway statt.
Sensor siehe hier: https://www.bosch-sensortec.com/bst/products/all_products/bme680
Aktueller Stand: Experimentierstadium
Der BME680 misst: Temperatur, relative Luftfeuchte, Luftdruck und VOC (Volatile Organic Compounds)
Die FHEM-Module 36_LaCrosseGateway.pm und 36_LaCrosse.pm sind bereits vorbereitet für den neuen Wert IAQ
Angehängt ist eine Testfirmware (kein LGW) die einfach auf der seriellen Konsole die gemessenen Werte rausloggt (siehe log unten)
Einfach auf einen ESP8266 flashen an dem per I2C ein BME680 angeschlossen ist.
Die Werte unten stammen von einem NanoLGW (danke an PeMue) auf dem ein BME680 sitzt.
Format einer Zeile (z.B. 40 T:23.7 H:59 P:995.4 G:19752)
40 Sekunden seit Programmstart
23.7 °C
59% rH
995.4 hPa (nicht auf NN normalisiert)
Widerstand des gas-sensors 19752 Ohm
Je geringer der Widerstand umso schlechter die Luft.
Momentan ist noch unklar, wie man den aus dem Sensor ausgelesenen Widerstandswert in die von Bosch propagierte IAQ (Indoor Air Quality) umrechnet.
Ich habe die Messreihe kommentiert (feste scrollen), was jeweils gerade passiert ist. Man sieht deutlich, wie der Sensor reagiert.
Die Temperatur ist natürlich NanoLGW-Konstruktionsbedingt drastisch zu hoch.
@PeMue: hast ihn wohl doch nicht geplättet ;)
Im Anhang noch ein Plot von einem ersten LGW-Prototyp, der den Widerstandswert / 10 übermittelt (von einem anderen Sensor auf einem breakout, nicht dem NanoLGW, darum nicht vergleichbar mit der Messreihe unten).
Die Beschriftung IAQ stimmt nicht, es ist der ausgelesene Widerstand geteilt durch 10 (weil nur ein word dafür im Protokoll)
Um 07:00 wurden die Fenster zum Lüften aufgerissen
Um 11:00 scheinbar auch
Um 19:00 wurde bei offener Tür zu dem Raum, in dem das LGW steht, gekocht (mit Bratpfanne und so)
Kalt gestartet
--------------
Starting
BME680 found
5 T:23.0 H:60 P:995.4 G:808370
10 T:23.1 H:60 P:995.3 G:21518
15 T:23.1 H:60 P:995.4 G:20055
20 T:23.2 H:60 P:995.3 G:20055
25 T:23.3 H:60 P:995.3 G:19979
30 T:23.4 H:59 P:995.4 G:19808
35 T:23.5 H:59 P:995.4 G:19903
40 T:23.7 H:59 P:995.4 G:19752
45 T:23.8 H:58 P:995.4 G:19734
50 T:24.0 H:58 P:995.4 G:19623
55 T:24.2 H:58 P:995.4 G:19549
60 T:24.3 H:58 P:995.4 G:19423
65 T:24.5 H:57 P:995.4 G:19423
70 T:24.7 H:57 P:995.4 G:19209
75 T:24.8 H:57 P:995.4 G:19209
80 T:25.0 H:57 P:995.4 G:19244
85 T:25.1 H:57 P:995.4 G:19104
90 T:25.3 H:56 P:995.4 G:19034
95 T:25.5 H:56 P:995.4 G:18914
100 T:25.6 H:56 P:995.4 G:18812
105 T:25.8 H:56 P:995.4 G:18778
110 T:25.9 H:56 P:995.4 G:18744
115 T:26.0 H:56 P:995.4 G:18628
120 T:26.2 H:56 P:995.4 G:18628
125 T:26.3 H:55 P:995.4 G:18529
130 T:26.5 H:55 P:995.4 G:18463
135 T:26.6 H:55 P:995.4 G:18318
140 T:26.8 H:55 P:995.4 G:18286
145 T:26.9 H:55 P:995.4 G:18238
150 T:27.0 H:55 P:995.4 G:18222
155 T:27.2 H:55 P:995.4 G:18128
160 T:27.3 H:54 P:995.4 G:18050
165 T:27.4 H:54 P:995.4 G:18019
170 T:27.5 H:54 P:995.4 G:17880
175 T:27.6 H:54 P:995.4 G:17850
180 T:27.7 H:54 P:995.4 G:17819
185 T:27.8 H:54 P:995.4 G:17759
190 T:27.9 H:54 P:995.4 G:17729
195 T:28.0 H:54 P:995.4 G:17669
200 T:28.1 H:54 P:995.4 G:17639
205 T:28.2 H:53 P:995.3 G:17536
210 T:28.3 H:53 P:995.3 G:17462
215 T:28.4 H:53 P:995.4 G:17492
220 T:28.5 H:53 P:995.3 G:17419
225 T:28.6 H:53 P:995.4 G:17361
230 T:28.7 H:53 P:995.4 G:17332
235 T:28.8 H:53 P:995.3 G:17233
240 T:28.9 H:53 P:995.4 G:17289
245 T:28.9 H:53 P:995.4 G:17176
250 T:29.0 H:52 P:995.3 G:17148
255 T:29.1 H:52 P:995.3 G:17162
260 T:29.2 H:52 P:995.3 G:17092
265 T:29.3 H:52 P:995.4 G:17009
270 T:29.3 H:52 P:995.3 G:16926
275 T:29.4 H:52 P:995.4 G:16926
280 T:29.5 H:52 P:995.3 G:16912
285 T:29.5 H:52 P:995.4 G:16885
290 T:29.6 H:52 P:995.3 G:16844
295 T:29.7 H:52 P:995.3 G:16844
300 T:29.7 H:51 P:995.4 G:16750
305 T:29.8 H:51 P:995.3 G:16790
310 T:29.8 H:51 P:995.3 G:16683
315 T:29.9 H:51 P:995.4 G:16670
320 T:30.0 H:51 P:995.4 G:16723
325 T:30.0 H:51 P:995.3 G:16643
330 T:30.1 H:51 P:995.3 G:16657
335 T:30.1 H:51 P:995.3 G:16617
341 T:30.2 H:51 P:995.3 G:16525
346 T:30.2 H:51 P:995.3 G:16499
351 T:30.3 H:51 P:995.3 G:16551
356 T:30.3 H:51 P:995.3 G:16512
361 T:30.4 H:50 P:995.3 G:16434
366 T:30.4 H:50 P:995.3 G:16409
371 T:30.5 H:50 P:995.3 G:16370
376 T:30.5 H:50 P:995.3 G:16306
381 T:30.6 H:50 P:995.3 G:16306
386 T:30.6 H:50 P:995.3 G:16357
391 T:30.7 H:50 P:995.3 G:16268
396 T:30.7 H:50 P:995.3 G:16218
401 T:30.8 H:50 P:995.3 G:16218
406 T:30.8 H:50 P:995.3 G:16205
411 T:30.9 H:50 P:995.3 G:16243
416 T:30.9 H:49 P:995.3 G:16168
421 T:31.0 H:49 P:995.3 G:16143
426 T:31.0 H:49 P:995.3 G:16143
431 T:31.0 H:49 P:995.3 G:16143
436 T:31.1 H:49 P:995.3 G:16118
441 T:31.1 H:49 P:995.3 G:16118
446 T:31.1 H:49 P:995.3 G:16106
451 T:31.2 H:49 P:995.3 G:16069
456 T:31.2 H:49 P:995.3 G:16069
461 T:31.3 H:49 P:995.3 G:16020
466 T:31.3 H:49 P:995.3 G:15958
471 T:31.3 H:49 P:995.3 G:15971
476 T:31.4 H:49 P:995.3 G:15995
481 T:31.4 H:49 P:995.3 G:15971
486 T:31.4 H:48 P:995.3 G:15910
491 T:31.5 H:48 P:995.3 G:15946
496 T:31.5 H:48 P:995.3 G:15898
501 T:31.5 H:48 P:995.3 G:15922
506 T:31.5 H:48 P:995.3 G:15922
511 T:31.6 H:48 P:995.3 G:15910
516 T:31.6 H:48 P:995.3 G:15910
521 T:31.6 H:48 P:995.3 G:15874
526 T:31.7 H:48 P:995.3 G:15874
531 T:31.7 H:48 P:995.3 G:15838
536 T:31.7 H:48 P:995.3 G:15754
541 T:31.7 H:48 P:995.3 G:15754
546 T:31.7 H:48 P:995.3 G:16131
Raus ins Freie
--------------
551 T:31.8 H:43 P:995.2 G:17684
556 T:31.8 H:39 P:995.3 G:18034
561 T:31.9 H:37 P:995.2 G:17834
566 T:31.9 H:36 P:995.2 G:18191
571 T:31.9 H:35 P:995.2 G:18480
576 T:31.9 H:34 P:995.2 G:18778
581 T:31.9 H:33 P:995.2 G:19209
586 T:31.9 H:33 P:995.2 G:19297
591 T:31.8 H:32 P:995.2 G:19586
596 T:31.8 H:32 P:995.1 G:19660
601 T:31.7 H:32 P:995.1 G:19790
606 T:31.6 H:32 P:995.2 G:19940
611 T:31.5 H:33 P:995.1 G:19979
616 T:31.4 H:33 P:995.1 G:20036
621 T:31.3 H:33 P:995.1 G:20055
626 T:31.2 H:33 P:995.1 G:20036
631 T:31.1 H:33 P:995.1 G:20288
636 T:31.0 H:33 P:995.1 G:20328
641 T:30.8 H:34 P:995.1 G:20567
646 T:30.7 H:34 P:995.1 G:20507
651 T:30.5 H:34 P:995.1 G:20608
656 T:30.4 H:35 P:995.1 G:20669
661 T:30.2 H:35 P:995.1 G:20792
666 T:30.1 H:35 P:995.1 G:20730
671 T:30.0 H:36 P:995.1 G:20833
676 T:29.8 H:36 P:995.1 G:20979
681 T:29.7 H:36 P:995.1 G:20896
686 T:29.6 H:36 P:995.1 G:20938
691 T:29.5 H:37 P:995.1 G:20710
696 T:29.4 H:37 P:995.1 G:20669
701 T:29.4 H:36 P:995.1 G:20628
706 T:29.4 H:36 P:995.1 G:20427
Wieder rein
-----------
711 T:29.4 H:35 P:995.1 G:15766
716 T:29.3 H:36 P:995.1 G:18159
Mit Zigarettenrauch eingenebelt
-------------------------------
721 T:29.3 H:36 P:995.1 G:11111
726 T:29.3 H:37 P:995.1 G:14470
731 T:29.3 H:37 P:995.1 G:9556
736 T:29.3 H:38 P:995.1 G:4365
741 T:29.3 H:37 P:995.1 G:4233
746 T:29.3 H:36 P:995.1 G:4398
751 T:29.3 H:36 P:995.1 G:2497
756 T:29.4 H:37 P:995.1 G:4335
761 T:29.6 H:35 P:995.1 G:4520
766 T:29.7 H:36 P:995.1 G:4405
771 T:29.8 H:36 P:995.1 G:5463
Zitat von: HCS am 17 Oktober 2017, 21:48:38
@PeMue: hast ihn wohl doch nicht geplättet ;)
Dafür war der auch zu teuer ;D
Zitat von: PeMue am 17 Oktober 2017, 21:56:17
Dafür war der auch zu teuer ;D
Ja, eigentlich ist das PVDS auf dem Nano.
Aber die hotplate braucht fast nicht zu heizen, ein NanoLGW im Stick-Gehäuse erreicht die 200 °C Messtemperatur schon fast so ;D ;D ;D
@PeMue: wie machen wir hier denn jetzt weiter?
Testest Du mal, ob Du Werte bekommst und eine Idee hast, wie wir die Widerstandswerte interpretieren sollten?
Und ob die Widerstandswerte der realen Situation folgen?
Hallo Ihr fleißigen Entwickler ;)
Besitze jetzt auch ein BME680 Breakout Board und zwar das von BlueDot. Wirkt qualitativ sehr hochwertig.
Wäre toll, wenn der irgendwann auf dem LGW einsetzbar wäre. Habt Ihr vielleicht schon eine LGW-Firmware zum testen ?
Würde gern helfen, ist aber zeitlich leider nicht ganz einfach.
Gruß Thomas
Zitat von: hdgucken am 29 Oktober 2017, 12:31:23
Hallo Ihr fleißigen Entwickler ;)
Oh, Pluralis Majestatis :)
Zitat von: hdgucken am 29 Oktober 2017, 12:31:23
Wäre toll, wenn der irgendwann auf dem LGW einsetzbar wäre.
So generell ist er im LGW implementiert. Nur die Berechnung der IAQ fehlt. Da fehlt mir schlicht noch die Formel.
Ich könnte aber mal eine Version rausgeben, die anstatt IAQ den Widerstandswert liefert. Der entspricht ja der Schadstoffkonzentration.
Hallo HCS,
meiner zeigt schon gewisse Grundreflexe, ich scheine meinen BME680 dann auch nicht geschrottet zu haben. Mit der LGW Software wird das Radio sauber erkannt, d.h. das Ding sollte auch Sensoren empfangen können. Bilder vom Aufbau folgen im nanoLGW Thread:
20 T:38.5 H:14 P:988.2 G:2051
25 T:38.4 H:14 P:988.2 G:2298
30 T:38.4 H:14 P:988.2 G:2521
35 T:38.3 H:14 P:988.2 G:2742
40 T:38.2 H:14 P:988.2 G:3084
45 T:38.0 H:14 P:988.2 G:3331
50 T:37.9 H:14 P:988.2 G:3622
55 T:37.7 H:14 P:988.2 G:3892
60 T:37.5 H:14 P:988.2 G:4158
65 T:37.2 H:15 P:988.2 G:4478Die Temperatur steigt ziemlich schnell, aber das wissen wir ja schon.
Nebenbei: Die Baudrate sollte 57600 baud sein.
Ich hänge ihn mal eine Weile an meinen Test Raspberry Pi und logge in eine Datei mit und plotte mal.
Hallo Thomas,
Zitat von: hdgucken am 29 Oktober 2017, 12:31:23
Wäre toll, wenn der irgendwann auf dem LGW einsetzbar wäre.
hardwareseitig kann die LGW Platine den BME680 schon ;) Du musst ihn nur noch auflöten ;D
Gruß PeMue
Zitat von: PeMue am 29 Oktober 2017, 17:26:17
meiner zeigt schon gewisse Grundreflexe
Das sieht schon mal gut aus.
Bist Du bei 20 Sekunden an die frische Luft gegangen, weil die Temperatur sinkt und die Luft besser wird?
@HCS: eine Version mit R-Werten wär doch schon mal was, könnte man sich ja "profisorisch" in was schöneres umrechnen ;D
@PeMue: das wär mal ne "Löt-Herausforderung", ich glaub, ich bleib erst mal beim BreadBord :D
Ich werd mal versuchen, meinem Schätzchen was zu entlocken :)
Bis später ...
Zitat von: hdgucken am 29 Oktober 2017, 17:58:14
@HCS: eine Version mit R-Werten wär doch schon mal was, könnte man sich ja "profisorisch" in was schöneres umrechnen ;D
Ja, ich werde kommende Woche eine Beta machen, die den Widerstand liefert.
Zitat von: hdgucken am 29 Oktober 2017, 17:58:14
@PeMue: das wär mal ne "Löt-Herausforderung"
Das kann er wohl voll und ganz bestätigen ;) ;D
Zitat von: HCS am 29 Oktober 2017, 18:15:37
Ja, ich werde kommende Woche eine Beta machen, die den Widerstand liefert.
Das wäre toll, würde gern mal testen :D
Zitat von: HCS am 29 Oktober 2017, 18:15:37
Das kann er wohl voll und ganz bestätigen ;) ;D
Ich weiß, er hat schon mit Erfolg einen auf die Platine gebacken ;D
@HCS: hab eben mal Deine Testfirmware auf eine NodeMCU hochgeladen,
musste nur den SDO auf Masse legen, um die Adresse 0x76 einzustellen, läuft :D
Zitat von: hdgucken am 29 Oktober 2017, 20:25:51
Ich weiß, er hat schon mit Erfolg einen auf die Platine gebacken ;D
Nein, es waren schon zwei. Und >10 BME280 ;D ;D ;D
So und jetzt ein paar Ergebnisse:
- Im ersten Plot ist die Temperatur und die Feuchte aufgetragen.
- Im Zweiten Plot der Widerstand.
Am Anfang stand der PC (mit HTerm) kurz im Wohnzimmer und wanderte dann ins Arbeitszimmer. Bei t=8000 habe ich den nanoLGW kurz aus dem Fenster gehängt, bei t=22000 habe ich ihn zweimal kurz angeblasen, bei zwischen t=43000 und 51000 war er wieder draußen (durch das gekippte Fenster), bei t=58000 ist das Ganze wieder ins Wohnzimmer gewandert.
Wenn ich jetzt mal interpretieren soll, wäre die Luft im Arbeitzimmer "dicker" als im Wohnzimmer und draußen ganz "dick". Es sei denn, es ist umgekehrt und ein hoher Widerstand heißt "gute Luft" :o :o :o
Das Ganze ist ggf. auch mit Vorsicht zu genießen, denn der BME680 hat eine Verpolung (durch das falsche Layout) überlebt, dabei ist aber ein Spannungsregler auf dem WeMos D1 mini hinübergegangen. Die Temperatur- bzw. Feuchtewerte scheinen aber plausibel.
Gruß PeMue
Edit:
Und hier noch die Unix Befehle für den Raspberry Pi (nano LGW hängt an /dev/ttyUSB1):
sudo stty -F /dev/ttyUSB1 57600
sudo cat /dev/ttyUSB1 > /tmp/bme680.txt &
Zitat von: PeMue am 30 Oktober 2017, 11:23:39
Es sei denn, es ist umgekehrt und ein hoher Widerstand heißt "gute Luft"
Ja, niedriger Widerstand = schlechte Luft.
Irgendwie ist es mühsam, das alles in zwei Threads zu verhackstücken.
Vielleicht sollten wir die Grundlagenforschung erst mal nur dort machen: https://forum.fhem.de/index.php/topic,78619.msg706880.html#msg706880
Da gibt es auch gerade neue Erkenntnisse.
Wenn die Grundlagen durch sind, komme ich dann hier zuück für die Implementierung im LGW.
Zitat von: PeMue am 30 Oktober 2017, 10:27:12
Nein, es waren schon zwei. Und >10 BME280 ;D ;D ;D
Respekt !!! Wie machst Du das, ich hab mal ein paar SMD Platinen mit nem
Gaslötkolben (mit ca. 3mm Luftdüse) gelötet, ging ziemlich gut, könnte mir aber
vorstellen, das der BMEx80 dafür zu empfindlich ist.
Zitat von: hdgucken am 31 Oktober 2017, 00:27:04
Respekt !!! Wie machst Du das ...
Ich dispense mit einer feinen Nadel unter dem Mikroskop (vorher Kaffeeentzug!) und dann geht es in den (geregelten) Pizzaofen ;)
Gruß PeMue
Nicht schlecht, stimmt, Lötpaste auftragen mit der Spritze war schon nicht ohne, Kaffee vorher geht gar nicht ;)
Die Umbauanleitung von dem Pizzaofen hatte ich vor einiger Zeit auch mal intensiver studiert,
vielleicht sollte ich das auch mal in Angriff nehmen, SMD ist im Vormarsch :)
Gruß Thomas
@PeMue: Kommt bei der "HCS-FW" für Dich eine IAQ raus, die dem entspricht, was Du erwarten würdest?
Falls ja, dann würde ich die BSEC-Routinen mitsamt der geheimen precompiled lib mal in das LGW einbauen, dass wir ohne shell scripte usw. vernünftige charts bekommen.
Einige Punkte sind noch offen, aber die kann ich dann später ergänzen z.B.
Man müsste die Baseline, die die BSEC ermittelt hat, regelmäßig speichern (persistent im EEPROM oder so) und beim nächsten Start wieder setzen, sonst beginnen die "vier Tage" nach einem Neustart wieder von vorne
@HCS - bist Du schon dazu gekommen dieses LGW + BME680 Testimage zu bauen?
Würde mich mit Daten vom Kaminzimmer beteiligen....
Hallo HCS,
Zitat von: HCS am 14 November 2017, 12:24:40
@PeMue: Kommt bei der "HCS-FW" für Dich eine IAQ raus, die dem entspricht, was Du erwarten würdest?
Falls ja, dann würde ich die BSEC-Routinen mitsamt der geheimen precompiled lib mal in das LGW einbauen, dass wir ohne shell scripte usw. vernünftige charts bekommen.
nach Dienstreise komme ich endlich mal wieder dazu, an einem vernünftigen Rechner zu antworten.
Ich bin mir noch nicht sicher, was der IAQ Wert eigentlich so wirklich bedeutet. Ich habe auch den Eindruck, dass dieser sich in einem Raum mit keinerlei Luftaustausch verbessert, was ich physikalisch absolut nicht nachvollziehen kann. Aber ich meine, momentan kriegen wir einfach nicht mehr aus dem Sensor raus, ohne viel Entwicklungsaufwand reinzustecken. Ich hätte gedacht, das das Ganze deutlich transparenter ist :o
Wenn es für Dich ein vertretbarer Aufwand ist, dann bitte gerne. Dann kann ich mein nanoLGW (BME680) im Wohnzimmer auch mit dem LGW (BME280) bezüglich Temperatur, Druck und relativer Luftfeuchte auch mal vergleichen. Was packst Du dann in die Übertragung zusätzlich mit rein?
Gas: 343435 IAQ: 70 HT: 320 HD: 197 AC: 3? Oder die letzten drei nur per Debug?
Danke + Gruß
PeMue
Zitat von: SusisStrolch am 18 November 2017, 11:25:01
@HCS - bist Du schon dazu gekommen dieses LGW + BME680 Testimage zu bauen?
Ich arbeite noch dran. Wird wohl so Ende nächster Woche werden (alle Angaben wie immer ohne Gewähr :) )
Zitat von: PeMue am 18 November 2017, 17:56:32
Ich bin mir noch nicht sicher, was der IAQ Wert eigentlich so wirklich bedeutet.
Ich mir auch nicht. Dass Bosch nicht verrät, was sie da eigentlich zusammenrechnen ist schon seltsam.
Zitat von: PeMue am 18 November 2017, 17:56:32
Wenn es für Dich ein vertretbarer Aufwand ist, dann bitte gerne.
Naja, ist mehr als ich dachte, drum ist es auch noch nicht fertig :(
Aber ich ziehe es jetzt durch.
Ich werde die Daten so wie bei einem BME280 an FHEM schicken, es entsteht also ein LaCrosse-Device mit Temperatur, Feuchte und Luftdruck und beim BME680 dann zusätzlich einem gas-Reading. Ich habe es von IAQ zu einem allgemeineren "gas" zurückgerudert, falls wir irgendwann beschließen, nicht die Bosch IAQ zu nehmen und etwas selbst berechnen.
Das LaCrosseGateway-device hat die Readings (je nach Einstellung vom Attribut "ownSensors") auch und zusätzlich noch ein reading mit dem rohen Widerstand des Sensors. Damit kann man dann weiterhin Vergleiche anstellen und eventuell zu einer eigenen Berechnung kommen.
Hi HCS,
ich habe im Internet folgendes Beispiel für die Berechnung des IAQ gefunden ,
Zitat
Using the BME680 to measure temperature, pressure, humidity and air quality.
The sensor is used to get so-called Gas Resistance and then an Air Quality Index (IAQ) is determined from a combination
of the readings of humidity and gas content of the air.
The index comprises up to 25% for the humidity contribution and 75% for the gas contribution.
Very low or high humidity is considered to result in an uncomfortable environment,
with 40% being optimal. Therefore the humidity contribution to the IAQ is derived from a value that is 0 when RH is 0 and
rises to 25% at 40% RH, above 40% RH the value falls to 0 at 100% RH, so in summary the RH quality scores peaks at 40% RH and
falls to 0 either side of that value, with the final value scaled between 0 and 25%.
For Gas it has been assumed that normal breathable air with no pollutants (adverse gases) corresponds to the sensors
highest output of 300,000 ohms. The sensor outputs a Gas resistance value ranging from a low of 50,000 to a high of 500,000 and beyond.
A linear relationship is assumed and the output scaled accordingly between 0 and 75%.
The result of humidity and gas indexes is a qualitative and a so-called IAQ - Indoor Air Quality index value scaled
from 0-100% (where 100% is good). This is then scaled to 0-500 where a 500 value is bad and
descriptive values applied in stages from good to hazardous air quality.
There is no definitive (ISO Standard method for calculating an IAQ.
(c) d.l.bird 2017 all rights reserved and as per the MIT licence agreements listed in all my software.
float hum_weighting = 0.25; // so hum effect is 25% of the total air quality score
float gas_weighting = 0.75; // so gas effect is 75% of the total air quality score
float hum_score, gas_score;
float gas_reference = 250000;
float hum_reference = 40;
int getgasreference_count = 0;
// The MIT License (MIT) Copyright (c) 2017 by David Bird.
// Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files
// (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge,
// publish, distribute, but not to use it commercially for profit making or to sub-license and/or to sell copies of the Software or to
// permit persons to whom the Software is furnished to do so, subject to the following conditions:
// The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
// OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
// CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
// See more at http://dsbird.org.uk
//Calculate humidity contribution to IAQ index
float current_humidity = bme.readHumidity();
if (current_humidity >= 38 && current_humidity <= 42)
hum_score = 0.25*100; // Humidity +/-5% around optimum
else
{ //sub-optimal
if (current_humidity < 38)
hum_score = 0.25/hum_reference*current_humidity*100;
else
{
hum_score = ((-0.25/(100-hum_reference)*current_humidity)+0.416666)*100;
}
}
//Calculate gas contribution to IAQ index
int gas_lower_limit = 50000; // Bad air quality limit
int gas_upper_limit = 500000; // Good air quality limit
gas_score = (0.75/(gas_upper_limit-gas_lower_limit)*gas_reference -(gas_lower_limit*(0.75/(gas_upper_limit-gas_lower_limit))))*100;
//Combine results for the final IAQ index value (0-100% where 100% is good quality air)
float air_quality_score = hum_score + gas_score;
Serial.println("Air Quality = "+String(air_quality_score,1)+"% derived from 25% of Humidity reading and 75% of Gas reading - 100% is good quality air");
Serial.println("Humidity element was : "+String(hum_score/100)+" of 0.25");
Serial.println(" Gas element was : "+String(gas_score/100)+" of 0.75");
if (bme.readGas() < 120000) Serial.println("***** Poor air quality *****");
Serial.println();
if ((getgasreference_count++)%10==0) GetGasReference();
Serial.println(CalculateIAQ(air_quality_score));
Serial.println("-------------------------------------------------------");
delay(15000);
}
void GetGasReference(){
// Now run the sensor for a burn-in period, then use combination of relative humidity and gas resistance to estimate indoor air quality as a percentage.
// Serial.println("\nGetting a new gas reference value");
int readings = 10;
for (int i = 0; i <= readings; i++){ // read gas for 10 x 0.150mS = 1.5secs
gas_reference += bme.readGas();
}
gas_reference = gas_reference / readings;
Serial.println("\nGetting a new gas reference value -> "+String(gas_reference)+" <--");
}
String CalculateIAQ(float score){
String IAQ_text = "Air quality is ";
score = (100-score)*5;
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;
}
https://github.com/G6EJD/BME680-Example (https://github.com/G6EJD/BME680-Example)
Gruß
Klaus
Zitat von: trebron106 am 19 November 2017, 14:53:23For Gas it has been assumed that normal breathable air with no pollutants (adverse gases) corresponds to the sensors highest output of 300,000 ohms. The sensor outputs a Gas resistance value ranging from a low of 50,000 to a high of 500,000 and beyond.
Die Widerstandswerte kann ich nicht nachvollziehen.
Meine beiden BME680 (die nebeneinander stehen) liegen je nach Luftqualität zwischen:
BME680 #1: 3000 ... 5000 Ohm
BME680 #2: 4500 ... 8000 Ohm
mit einer von Bosch gerechneten IAQ von 250 ... 25.
Das zeigt schon mal, dass die Sensoren von ihrer Baseline sehr unterschiedlich sind.
Und es würde bedeuten, dass bei meinen Sensoren "normal breathable air with no pollutants" eher bei 10000 Ohm liegt.
Ich lasse das LGW jetzt erst mal die von Bosch gerechnete IAQ liefern, die ist das "offiziellste" was wir momentan haben.
Hallo @HCS, ich verwende dein Test-Binary vom 7.11.
Das liefert mir jedoch Gas-Werte im Bereich 10⁵ - 10⁶ zurück (läuft allerdings erst seit 2 Tagen).
Wie kommst Du denn auf die 3000-5000 Ohm?
Verwendest Du da einen Korrekturfaktor? (Ich konnte dazu in den Datenblättern nichts finden).
@trebron106: Bzgl VOC sagt das Datenblatt folgendes aus:
Zitat
As a raw signal, BME680 will output resistance values and its changes due to varying VOC concentrations (the higher the concentration of reducing VOCs, the lower the resistance and vice versa). Since this raw signal is influenced by parameters other than VOC concentration (e.g. humidity level), the raw values are transformed to an indoor air quality (IAQ) index by smart algorithms inside BSEC.
Und das steht doch (für den BME Sensor) im Widerspruch zu
Zitat
For Gas it has been assumed that normal breathable air with no pollutants (adverse gases) corresponds to the sensors highest output of 300,000 ohms. The sensor outputs a Gas resistance value ranging from a low of 50,000 to a high of 500,000 and beyond.
Oder übersehe ich da etwas?
Zitat von: SusisStrolch am 20 November 2017, 11:05:52
Hallo @HCS, ich verwende dein Test-Binary vom 7.11.
Das liefert mir jedoch Gas-Werte im Bereich 10⁵ - 10⁶ zurück (läuft allerdings erst seit 2 Tagen).
Wie kommst Du denn auf die 3000-5000 Ohm?
Verwendest Du da einen Korrekturfaktor? (Ich konnte dazu in den Datenblättern nichts finden).
Genau das Test-Binary verwendei ich auch und ich korrigiere keine Werte.
Ich liefere genau das, was die Bosch-Routinen berechnen.
Beispielzeile aus dem Log:
2017-11-08_16:29:19 TS: 151200 T: 19.9 H: 59.6 P: 1020.8 Gas: 5930 IAQ: 27 HT: 320 HD: 197 AC: 3Der absulute Widerstandswert hat meiner Beobachtung nach nicht viel zu sagen.
2017-11-07_00:05:14 TS: 5760 T: 19.9 H: 56.5 P: 1025.7 Gas: 3852 IAQ: 30 HT: 320 HD: 197 AC: 3
2017-11-20_10:56:05 TS: 98340 T: 19.3 H: 53.4 P: 1024.1 Gas: 8083 IAQ: 30 HT: 320 HD: 197 AC: 3Man sieht: am 07.11.2017 hat die Bosch-Routine bei 3852 Ohm eine IAQ von 30 berechnet und am 20.11.2017 hat sie die gleiche IAQ bei 8083 Ohm berechnet.
Und das bei kaum unterschiedlicher Temperatur und Luftfeuchtigkeit.
Ich glaube, dass es so funktioniert: der höchste Widerstandswert, der im Lauf der Zeit gesehen wurde, wird als "saubere Luft" mit ca. 400ppm eCO2 und 0 VOC betrachtet und alles drunter dann entsprechend dieser basline hingerechnet. Das ist wohl auch der Grund, warum Bosch meint, dass es mehrere Tage dauert, bis ein vernünftiges Ergebnis dargestellt wird und man die basline speichern und bei einem Sensor-Neustart wieder setzen soll, weil sonst das Spiel wieder von vorne beginnt.
Und je weniger der Sensor gelaufen ("eingebrannt") ist, um so mehr driftet er durch die Gegend.
Zitat von: SusisStrolch am 20 November 2017, 11:05:52
... im Widerspruch ...
Die Grundaussage stimmt schon, je geringer der Widerstand umso schlechter ist die Luft.
Zitat von: HCS am 19 November 2017, 08:33:46
Ich arbeite noch dran. Wird wohl so Ende nächster Woche werden (alle Angaben wie immer ohne Gewähr :) ) ...
@HCS, PeMue, SusisStrolch: Hab eben erst wieder mal in diesem Thread vorbei geschaut. Hab da auch was fertig,
schaut mal hier: https://forum.fhem.de/index.php/topic,78619.msg719003.html#msg719003 ;)
War wirklich ne Menge Arbeit, aber das Ergebnis ist doch nicht schlecht ...
Gruß Thomas
So, hier eine Beta vom LaCrosseGateway V1.31, die den BME680 unterstützt.
Die IAQ wird von den Bosch-Routinen berechnet.
Der BME680 muss die Adresse 0x76 haben und wird wie ein BME280 angeschlossen.
Es geht nur BME680 oder BME280, nicht beide gleichzeitig
Im WebIF wird der BME680 mit seinen aktuellen Werten angezeigt
36_LaCrosse.pm und 36_LaCrosseGateway.pm müssen auf dem aktuellen Stand sein
LaCrosse-Device in FHEM:
- Reading "gas" ist die vom den Bosch-Routinen berechnete IAQ
- Reading "debug" ist der vom Senosor gelieferte Widerstand
- Temperatur, Feuchte und Druck ist ganz normal, wie bei einem BME280
Anhang entfernt, es gibt eine neuere Version hier: https://forum.fhem.de/index.php/topic,78128.msg725370.html#msg725370
Zitat von: HCS am 28 November 2017, 20:58:36
So, hier eine Beta vom LaCrosseGateway V1.31, die den BME680 unterstützt.
Das bekomme ich heute nicht mehr installiert, werde es aber testen.
Danke + Gruß Peter
Uiuiuiui...
Komme auch erst morgen zum flashen.
Hmm, ob es da vielleicht auch ein Setting für die Heatplate (temp& duration) geben könnte?
Hallo HCS,
die ersten Gehversuche schauen schon mal besser aus, als die Vorversionen, die bei mir einfach nicht wollten.
Muss mich aber erst mal noch in die LGW-Thematik tiefer einarbeiten ... :'(
Bzw. noch warten, weil ich die RFMs in der HCW-Version und nicht in der CW-Version bestellt hatte, heul ...
***CLEARLOG***
LaCrosseITPlusReader.Gateway V1.31
Free heap: 17704 Flash size: 4194304 Core: 2_3_0 SDK: 1.5.3(aec24ac9)
Reset: Hardware Watchdog
Fatal exception:4 flag:1 (WDT) epc1:0x40107080 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Starting I2C with 400 kHz
Configured altitude: 0
Searching RFMs and Sensors
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
We got no connection :-(
AccessPoint: Starting ...
AccessPoint: running, SSID=LaCrosseGateway_402275
Starting frontend
Starting OTA
Starting data port 1 on 81
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.31 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 402275 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=,MacAddress=5C:CF:7F:06:23:63,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15920,Version=1.31,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.29,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15648,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.22,OLED=none
.....
MX....'%.{....*..........HnX.J*..XI+...j8...H.&(o.T...HN<.ZJ......
***CLEARLOG***
LaCrosseITPlusReader.Gateway V1.31
Free heap: 17704 Flash size: 4194304 Core: 2_3_0 SDK: 1.5.3(aec24ac9)
Reset: Hardware Watchdog
Fatal exception:4 flag:1 (WDT) epc1:0x4020f038 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Starting I2C with 400 kHz
Configured altitude: 0
Searching RFMs and Sensors
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
We got no connection :-(
AccessPoint: Starting ...
AccessPoint: running, SSID=LaCrosseGateway_402275
Starting frontend
Starting OTA
Starting data port 1 on 81
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.31 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 402275 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=,MacAddress=5C:CF:7F:06:23:63,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15920,Version=1.31,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.29,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15648,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15424,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15200,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=50,UpTimeText=0Tg. 0Std. 0Min. 50Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14976,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.21,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=60,UpTimeText=0Tg. 0Std. 1Min. 0Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16384,LD.Min=0.05,LD.Avg=0.05,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=70,UpTimeText=0Tg. 0Std. 1Min. 10Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15936,LD.Min=0.06,LD.Avg=0.06,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=80,UpTimeText=0Tg. 0Std. 1Min. 20Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15488,LD.Min=0.06,LD.Avg=0.06,LD.Max=0.22,OLED=none
OK VALUES LGW 402275 UpTimeSeconds=90,UpTimeText=0Tg. 0Std. 1Min. 30Sek. ,WIFI=,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15040,LD.Min=0.06,LD.Avg=0.06,LD.Max=0.22,OLED=none
Versuche mal den BME680 wenigstens zum Laufen zu bekommen.
Grüße,
Jürgen
Zitat von: SusisStrolch am 28 November 2017, 21:17:06
Hmm, ob es da vielleicht auch ein Setting für die Heatplate (temp& duration) geben könnte?
Definitiv nicht.
Die BSEC Routinen berechnen die Zieltemperatur und Heizdauer der hotplate und jede Abweichung davon ruiniert den Bosch-Algorithmus.
Und auch bezüglich Timing, wann die nächste Messung aufgerufen werden muss, ist die BSEC sehr pingelich und antwortet dann direkt mit einem "Timing nicht eingehalten."
Das war übigens der schwierigste Teil bei der Integration ins LGW, es hat ja sonst auch noch was zu tun ...
Zitat von: juergs am 28 November 2017, 21:22:58
die ersten Gehversuche schauen schon mal besser aus, als die Vorversionen, die bei mir einfach nicht wollten.
Muss mich aber erst mal noch in die LGW-Thematik tiefer einarbeiten ... :'(
Das lässt sich hier: https://forum.fhem.de/index.php/topic,43672.msg355938.html#msg355938
und hier machen: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#LaCrosseGateway_einrichten
Aber verbinde Dich doch einfach mal auf den AccessPoint mit dem Namen LaCrosseGateway_402275 und öffne dann im Browser die Adresse 192.168.222.1
ZitatAber verbinde Dich doch einfach mal auf den AccessPoint mit dem Namen LaCrosseGateway_402275 und öffne dann im Browser die Adresse 192.168.222.1
Danke, schon gemacht und funktioniert.
Muss erst mein Sensor auf 0x76-Adresse umstellen und die passenden I2C-Pins finden.
Funktioniert das Standalone mit dem BME, ohne RFMs, nur über Serielle Verbindung ?
Zitat von: juergs am 28 November 2017, 21:51:27
und die passenden I2C-Pins finden.
Schau mal, ob sie eventuell noch in der Verpackung liegen ;D ;D ;D
Zitat von: juergs am 28 November 2017, 21:51:27
Funktioniert das Standalone mit dem BME, ohne RFMs, nur über Serielle Verbindung ?
Ein LGW läuft auch ohne irgendwas dran, macht dann aber halt wenig Spaß.
Nur ein BME680 dran, ohne RFM69 funktioniert.
Aber der eigentliche Sinn ist es, es per WiFi mit dem LaCrosseGateway-Modul an FHEM anzubinden.
Es sendet die BME680-Daten nicht im Klartext über die serielle Schnittstelle.
ZitatSchau mal, ob sie eventuell noch in der Verpackung liegen
Ja, ja ;D
D1+D2 passt, aber die Adresse noch nicht....
ZitatNur ein BME680 dran, ohne RFM69 funktioniert.
Passt schon, RFMs sind schon bestellt ....
Ansonsten, nur noch gefühlt (nebenbei) "tausend" Thread-Seiten und das Wiki durchlesen 8)
.. und ein kleiner Fehler in der Doku....
Zitat von: juergs am 28 November 2017, 22:00:52
Ansonsten, nur noch gefühlt (nebenbei) "tausend" Thread-Seiten und das Wiki durchlesen 8)
Der erste Beitrag vom Thread reicht, den Rest musst Du nicht lesen.
Oder nur das Wiki, sollte auch reichen.
Kaum macht man es richtig, schon geht's (zumindest der BME, SDO gegen GND = 0x76) :D
Zitat
ESP8266
present :-)
Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 13656 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi
-70 dBm
Mode: Station Time to connect: 5.1 s
Radio #1
---
Radio #2
---
Radio #3
---
Radio #4
---
Radio #5
---
SHT75
---
BME680
OK
T=22.8 H=37 P=994.8 I=0 R=25684
BME280
---
BMP180
---
DHT22
---
LM75
---
SC16IS750 (0x90)
---
SC16IS750 (0x92)
---
MCP23008
---
OLED
---
DataPort #1
81
DataPort #2
---
DataPort #3
---
Serial-bridge #1
---
Serial-bridge #2
---
Soft-bridge
---
Nextion
---
Analog port
Disabled
ADC=9 U=4294967295 mV (0 ... 0 mV)
Ok, der Rest folgt morgen. :D
Zitates scheint mit dem 16.11. eine neue .ZIP von Bosch zu geben
von hier (https://www.bjoerns-techblog.de/2017/11/bme680-mit-nodemcu-an-ttn/#comments)
2017.11.29 18:16:35 3: Opening myLGW device 192.168.xxx.yyy:81
2017.11.29 18:16:35 3: myLGW device opened
2017.11.29 18:16:37 1: readingsUpdate(myLGW,debug,6115) missed to call readingsBeginUpdate first.
2017.11.29 18:16:37 1: stacktrace:
2017.11.29 18:16:37 1: main::readingsBulkUpdate called by ./FHEM/36_LaCrosse.pm (327)
2017.11.29 18:16:37 1: main::LaCrosse_Parse called by fhem.pl (3713)
2017.11.29 18:16:37 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (703)
2017.11.29 18:16:37 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (468)
2017.11.29 18:16:37 1: main::LaCrosseGateway_Read called by fhem.pl (3498)
2017.11.29 18:16:37 1: main::CallFn called by fhem.pl (700)
2017.11.29 18:16:37 1: readingsUpdate(myLGW,debug,7818) missed to call readingsBeginUpdate first.
2017.11.29 18:16:37 1: stacktrace:
2017.11.29 18:16:37 1: main::readingsBulkUpdate called by ./FHEM/36_LaCrosse.pm (327)
2017.11.29 18:16:37 1: main::LaCrosse_Parse called by fhem.pl (3713)
2017.11.29 18:16:37 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (703)
2017.11.29 18:16:37 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (468)
2017.11.29 18:16:37 1: main::LaCrosseGateway_Read called by fhem.pl (3498)
2017.11.29 18:16:37 1: main::CallFn called by fhem.pl (700)
Du bist nicht auf der aktuellen Version von 36_LaCrosseGateway.pm
Siehe eins tiefer ???
Meinte natürlich 36_LaCrosse.pm
https://svn.fhem.de/trac/changeset/15505/trunk/fhem/FHEM/36_LaCrosse.pm
Hallo HCS,
mit dem Befehl:
update https://svn.fhem.de/trac/changeset/15505/trunk/fhem/FHEM/36_LaCrosse.pmkommt :
Zitatnothing todo...
Die entsprechenden Zeilen sind in 36_LaCrosse.pm enthalten....
Ein Update hatte ich gestern gemacht.
Hallo HCS,
mein nanoLGW läuft:
BME680 OK T=38.1 H=16 P=978.5 I=46 R=280491
Es hat sich sogar die Einstellungen, die ich damals mit einer alter Firmware gemacht habe, gemerkt.
Jetzt muss ich nur noch die Plotdateien anpassen.
Danke + Gruß
PeMue
PS:
Das hat er noch in die Log-Datei geschrieben:
2017.11.29 21:20:33 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/36_LaCrosse.pm line 152.
Edit:
Die initCommands zumindest mit der Höhe anzugeben ist nicht schlecht, dann wird der Druck auch so angezeigt, wie die anderen Drucksensoren den auch messen ...
Auch hier positive Rückmeldung zum LCG mit BME680. Läuft seit gestern nachmittag bisher problemlos.
Der BME680 hängt an einem WeMos D1 Mini Pro (RobotDyn), dieser wird über ESPLink (ebenfalls D1 Mini) mitgeloggt.
Edit:
Eine Kleinigkeit hätte ich noch...
Ich habe das Setting "kvp" auf "readings" gesetzt.
In den readings fehlt mir nun der Wert für "UpTimeSeconds", es wird lediglich "UpTimeText" als "UpTime" geliefert.
defmod LCG.BME680 LaCrosseGateway 192.168.254.139:81
attr LCG.BME680 event-on-change-reading .*
attr LCG.BME680 icon it_wifi
attr LCG.BME680 kvp readings
attr LCG.BME680 mode WiFi
attr LCG.BME680 ownSensors both
attr LCG.BME680 room Wohnzimmer,LaCrosseGateway,Sensoren
attr LCG.BME680 timeout 60
attr LCG.BME680 usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
attr LCG.BME680 verbose 5
attr LCG.BME680 watchdog 300
setstate LCG.BME680 initialized
setstate LCG.BME680 2017-11-30 09:01:19 FramesPerMinute 0
setstate LCG.BME680 2017-11-30 09:01:19 FreeHeap 16616
setstate LCG.BME680 2017-11-30 09:01:19 OLED none
setstate LCG.BME680 2017-11-30 09:01:19 RSSI -62
setstate LCG.BME680 2017-11-30 09:01:19 ReceivedFrames 0
setstate LCG.BME680 2017-11-30 09:01:19 UpTime 0Tg. 15Std. 36Min. 15Sek.
setstate LCG.BME680 2017-11-30 09:01:19 debug 75363
setstate LCG.BME680 2017-11-30 09:01:19 gas 78
setstate LCG.BME680 2017-11-30 09:01:19 humidity 35
setstate LCG.BME680 2017-11-30 09:01:19 pressure 1004
setstate LCG.BME680 2017-11-30 09:01:19 state initialized
setstate LCG.BME680 2017-11-30 09:01:19 temperature 19.6
Zitat von: SusisStrolch am 30 November 2017, 08:52:40
Auch hier positive Rückmeldung zum LCG mit BME680. Läuft seit gestern nachmittag bisher problemlos.
Hast Du um 17:00 den Ofen angezündet?
Nein, hatte das LGW aus dem Arbeitszimmer (1.OG) ins Kaminzimmer runter geschleppt.
Ofen war bereits seit 13:00 an (Susi hatte ihren freien Tag).
Ansonsten liese sich ja so ein rapider Temperaturanstieg nur mit nem Kanister Sprit erreichen...
Edit: irgendwie scheinen mir Humidity und Pressure beim 680er ein wenig "zappeliger" als beim 280.
Hab' jetzt mal ein LCG mit BME280 daneben gestellt um zu vergleichen...
(Susi wirds mir hoffentlich verzeihen...)
Zitat von: SusisStrolch am 30 November 2017, 09:57:52
irgendwie scheinen mir Humidity und Pressure beim 680er ein wenig "zappeliger" als beim 280.
Ich habe eh den Eindruck, dass der Druck einen Tick zu hoch ist, den der BME680 liefert, aber ich glaube, dass die in der neuen BSEC da was gemacht haben.
Dafür erscheint mir die Temperatur realistischer als beim BME280.
Zitat von: SusisStrolch am 30 November 2017, 08:52:40
Edit:
Eine Kleinigkeit hätte ich noch...
Ich habe das Setting "kvp" auf "readings" gesetzt.
In den readings fehlt mir nun der Wert für "UpTimeSeconds", es wird lediglich "UpTimeText" als "UpTime" geliefert.
Immer diese "
Edit:", die entdecke ich nur mit viel Glück ...
Das war bisher der Plan. Brauchst Du die Sekunden wirklich?
Das reading "UpTimeSeconds" könnte ich wohl noch spendieren.
Zitat von: PeMue am 29 November 2017, 21:41:52
Edit:
Die initCommands zumindest mit der Höhe anzugeben ist nicht schlecht, dann wird der Druck auch so angezeigt, wie die anderen Drucksensoren den auch messen ...
Grmpfff, noch ein
Edit:oder alternativ (besser) auf der Setup-Page des LGW Altitude setzen, dann stimmt es auch, wenn kein LGW es gesendet hat.
Zitat von: PeMue am 29 November 2017, 21:41:52
PS:
Das hat er noch in die Log-Datei geschrieben:
2017.11.29 21:20:33 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/36_LaCrosse.pm line 152.
"
PS:" ist auch noch eine Variante, ich lese immer nur bis "Danke + Gruß" ;D ;D
Den hatte ich auch schon mal gesehen und als ich mich damit beschäftigen wollte dann nie wieder bekommen.
Statt Edit 8)
Streiche alles bis auf "Guten Morgen"...
Für den BME280 habe ich einen Event-Aggregator am laufen - deshalb sind die Kurven deutlich "smoother"...
Zitat von: HCS am 30 November 2017, 10:19:11
Das war bisher der Plan. Brauchst Du die Sekunden wirklich?
Das reading "UpTimeSeconds" könnte ich wohl noch spendieren.
So würde zumindest die Anzahl der Formate etwas reduziert. Das erleichtert eine einheitliche Darstellung.
Zitat von: SusisStrolch am 30 November 2017, 08:52:40
In den readings fehlt mir nun der Wert für "UpTimeSeconds"
Eingebaut, morgen FHEM-Update machen.
Super!
Hallo SusisStrolch,
Zitatattr LCG.BME680 kvp readings
danke, das war wohl der Knackpunkt zum Anzeigen der Werte, bzw. Erzeugen des Filelogs. :D
Timeout + Watchdog hatte ich ebenfalls noch gesetzt.
@HCS
Zitat2017.11.30 21:51:16 5: myLGW: dispatch OK WS 0 4 4 187 38 255 255 255 255 255 255 255 255 0 3 226 0 0 27 0 188 190
2017.11.30 21:51:16 1: readingsUpdate(myLGW,debug,48318) missed to call readingsBeginUpdate first.
2017.11.30 21:51:16 1: stacktrace:
2017.11.30 21:51:16 1: main::readingsBulkUpdate called by ./FHEM/36_LaCrosse.pm (327)
2017.11.30 21:51:16 1: main::LaCrosse_Parse called by fhem.pl (3713)
2017.11.30 21:51:16 1: main::Dispatch called by ./FHEM/36_LaCrosseGateway.pm (703)
2017.11.30 21:51:16 1: main::LaCrosseGateway_Parse called by ./FHEM/36_LaCrosseGateway.pm (468)
2017.11.30 21:51:16 1: main::LaCrosseGateway_Read called by fhem.pl (3498)
2017.11.30 21:51:16 1: main::CallFn called by fhem.pl (700)
ist leider immer noch da. Mal schauen nach dem morgigen Update, ob das immer noch da, bzw. in der jetztigen Ausprägung (ohne RFMs) relevant ist ....
Grüße,
Jürgen
Hallo HCS,
mir ist aufgefallenn, dass das IAQ-Signal sehr verrauscht 'rüberkommt.
Ein Möglichkeit wäre ja SusisStrolch's Lösung:
attr LCG.BME680 event-on-change-reading .*
oder ggf. eine gleitende Mittelwertbildung wie hier (https://github.com/juergs/iAQ_NANO_328_LaCrosse/blob/master/utility/movingAvg.cpp) ?
Im unten angehängten Bild wird das Rauschen durch die Skalierung etwas minimiert dargestellt.
ist aber im Vergleich zu Temp,HUM + P schon auffällig ...
Man sieht auch deutlich, wie sich eine Störung (Fensteröffnen) sich auf das System und dessen Wiedererholzeiten auswirkt.
Der iAQ-core scheint aber auch eine Art Clipping-Funktionalität mit eingebaut zu haben ...
Grüße,
Jürgen
Zitat von: juergs am 30 November 2017, 21:50:26
@HCSist leider immer noch da. Mal schauen nach dem morgigen Update, ob das immer noch da, bzw. in der jetztigen Ausprägung (ohne RFMs) relevant ist ....
Was steht in der ersten Zeile vom 36_LaCrosse.pm?
Hallo HCS,
vor update :
# $Id: 36_LaCrosse.pm 15483 2017-11-23 20:03:23Z HCS $
nach update:
# $Id: 36_LaCrosse.pm 15505 2017-11-26 10:29:53Z HCS $
Das LGW liefert alle 10 Sek. Readings. Kann das (wie) parametriert werden?
Internals:
Alive 2017-12-03 16:36:22
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.xxx.yyy:81
DeviceName 192.168.xxx.yyy:81
FD 4
NAME myLGW
NR 8
NTFY_ORDER 50-myLGW
PARTIAL
RAWMSG OK VALUES LGW 402275 UpTimeSeconds=142352,UpTimeText=1Tg. 15Std. 32Min. 32Sek. ,WIFI=adm,ReceivedFrames=0,FramesPerMinute=0,RSSI=-60,FreeHeap=15336,LD.Min=0.07,LD.Avg=0.07,LD.Max=5.46,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.31
myLGW_MSGCNT 127
myLGW_TIME 2017-12-03 16:37:02
nextOpenDelay 2
settings + BME680 {IP=192.168.xxx.yyy}]
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
4:EMT7110 ^OK\sEMT7110\s
5:Level ^OK\sLS\s
6:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-12-03 16:37:02 FramesPerMinute 0
2017-12-03 16:37:02 FreeHeap 15336
2017-12-03 16:37:02 OLED none
2017-12-03 16:37:02 RSSI -60
2017-12-03 16:37:02 ReceivedFrames 0
2017-12-03 16:37:02 UpTime 1Tg. 15Std. 32Min. 32Sek.
2017-12-03 16:37:02 UpTimeSeconds 142352
2017-12-03 16:37:02 state initialized
helper:
Attributes:
event-on-change-reading .*
icon temp_inside
kvp readings
room HARDWARE,RECEIVER
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 3
watchdog 300
Zitat von: juergs am 03 Dezember 2017, 16:24:08
Hallo HCS,
vor update :
# $Id: 36_LaCrosse.pm 15483 2017-11-23 20:03:23Z HCS $
nach update:
# $Id: 36_LaCrosse.pm 15505 2017-11-26 10:29:53Z HCS $
Und damit sollte dann der Fehler weg sein.
Hallo HCS,
vielen Dank, das passt jetzt! :)
Ich hatte meine HW-Bundle (mit Jeelink+LaCrosse) nicht erwähnt:
CUL:
32U4CUL (Initialized)
NANOCUL (opened)
mapleCul (opened)
SIGNALduino:
SIGNALESP (opened)
STACKABLE_CC:
mapleCUL433 (Defined)
EC3000:
EC3000_7C0C (on (0.2 W))
JeeLink:
myJeeLink (opened)
KeyValueProtocol:
KeyValueProtocol_LGW_402275 (Initialized)
LaCrosse:
LaCrosse_00 (T: 22.1 H: 37)
LaCrosseGateway:
myLGW (initialized)
Anbei eine neue Beta des LGW V1.31, die die neue BSEC V1.4.5.1 verwendet.
Die BSEC-Version wird nun auch auf der Hardware-Page angezeigt.
BME680 OK T=20.2 H=55 P=1028.0 I=131 R=13718 (BSEC V1.4.5.1)
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.
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
Nachtrag: das gleiche Ergebnis (ERROR...) bei OTA via curl...
Zitat von: SusisStrolch am 04 Dezember 2017, 16:04:46
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:
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.binErgebnis:
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 ...
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
ZitatHattest Du es ursprünglich mit "Flash Size 4M (3M SPIFFS)" geflasht?
Das könnte die Ursache sein... habe das Modul ursprünglich mit
esptool.py -b 921600 -p /dev/ttyUSB0 write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 ../Development/BME680/Test680.bingeflasht.
Kann erst Samstag wieder testen...
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 ...
Hallo,
heute zeigt der BME680 in der neuen BSEC-Version im LGW ein etwas seltsames Verhalten....
(Vergleich zu iAQ-Core)
Zitat aus: https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf
ZitatBME680 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
ZitatWe 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?
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.
Zitat von: HCS am 20 Dezember 2017, 17:37:20
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.
Zitat von: HCS am 20 Dezember 2017, 17:37:20
@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 € :o). 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.
Zitat von: HCS am 20 Dezember 2017, 17:37:20
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 ...
Zitat von: HCS am 20 Dezember 2017, 17:37:20
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
Hallo HCS und Peter,
ich glaube auch, daß die BSEC Software (aufgrund des Timings) auf dem LGW nicht wirklich brauchbar eingebunden werden kann.
Zitat
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.
Zitat
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
Zitat von: hdgucken am 20 Dezember 2017, 22:49:50
ich könnte noch LUX als weiteren optionalen Wert vorsehen, dann könntest Du
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 :)
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 ;D ;D ;D)
- 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
Zitat von: PeMue am 21 Dezember 2017, 13:08:37
Habe ich das soweit richtig verstanden?
Ja.
Zitatwir 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 ;D ;D ;D)
Zumindes für OLED kann ich die Autoerkennung liefern, das LGW kann die, für den BH1750 sollte das auch machbar sein
HCS müsste das FHEM Modul anpassen, damit dieser Sensor mit dem LGW empfangen werden kannNur erweitern für LUX, der Rest (Temp, Hum, Pressure, Gas (IAQ)) müsste Stand heute schon gehen.
ich würde auf dem nanoLGW den LM75 runterwerfen und einen BH1750 integrierenJeden 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.
Zitat von: hdgucken am 20 Dezember 2017, 22:49:50
ich könnte noch LUX als weiteren optionalen Wert vorsehen, dann könntest Du
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 :)
Zitat von: HCS
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 8)
Zitat von: PeMue
... 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 ;D ;D ;D)
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. ;)
Zitat von: hdgucken am 21 Dezember 2017, 18:59:20
Batterie würde ich auch weglassen, LGW mit Batterie ist nix 8)
Stattdessen würde ich (falls machbar) ein Feld für die Firmwareversion mit einbauen ...
Gruß PeMue
Zitat von: hdgucken am 21 Dezember 2017, 18:59:20
Das wäre eine super Lösung finde ich :)
Cool, schon zwei, die das so sehen :)
Hier mal ein
Grobentwurf (angelehnt an LaCrosse und WS...) wie das HF-Protokoll für den "UniversalSensor" aussehen könnte:
US ID TT TT HH RR RR DD DD SS SS GG GG FF PP PP GA GA GA LU LU LU VV xx xx xx CR
| | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | |------- CRC
| | | | | | | | | | | | | | | | | | | | | | | | | |---------- additional data
| | | | | | | | | | | | | | | | | | | | | | | | | ------------ additional data
| | | | | | | | | | | | | | | | | | | | | | | |---------------- additional data
| | | | | | | | | | | | | | | | | | | | | | |------------------- Version*10 V3.5 == 35
| | | | | | | | | | | | | | | | | | | | | |---------------------- LUX 1er
| | | | | | | | | | | | | | | | | | | | |------------------------- LUX 256er
| | | | | | | | | | | | | | | | | | | |---------------------------- LUX 65536er
| | | | | | | | | | | | | | | | | | |------------------------------- GAS 1er
| | | | | | | | | | | | | | | | | |---------------------------------- GAS 256er
| | | | | | | | | | | | | | | | |------------------------------------- GAS 65536er
| | | | | | | | | | | | | | | |---------------------------------------- Pressure*10 1er hPa
| | | | | | | | | | | | | | |------------------------------------------- Pressure*10 256er
| | | | | | | | | | | | | |---------------------------------------------- Flags see below
| | | | | | | | | | | | |------------------------------------------------- WindGust*10 1er m/s
| | | | | | | | | | | |---------------------------------------------------- WindGust*10 256er
| | | | | | | | | | |------------------------------------------------------- WindSpeed*10 1er m/s
| | | | | | | | | |---------------------------------------------------------- WindSpeed*10 256er
| | | | | | | | |------------------------------------------------------------- WindDirection*10 1er 0.0 ... 365.0 Degrees
| | | | | | | |---------------------------------------------------------------- WindDirection*10 256er
| | | | | | |------------------------------------------------------------------- Rain*10 1er mm
| | | | | |---------------------------------------------------------------------- Rain*10 256er mm
| | | | |------------------------------------------------------------------------- Humidity plain %
| | | |---------------------------------------------------------------------------- Temp*10+1000 1er °C
| | |------------------------------------------------------------------------------- Temp*10+1000 256er °C
| |---------------------------------------------------------------------------------- Sensor ID 1 ... 255
|------------------------------------------------------------------------------------- fix "US"
Missing values shall be set to 0xFF
Example: US 01 FF FF 57 FF FF ... 44(CRC) if only humidity is available
Flags: 128 64 32 16 8 4 2 1
| | |
| | |-- New battery
| |------ ERROR
|---------- Low battery
Hallo HCS,
dein Entwurf gefällt mir gut, könnte man durchaus so machen :)
Außerdem würde ich dadurch das Modul "CustomSensor" gar nicht mehr benötigen, cool ;)
Als "additional data" könntest Du noch IAQ mit rein nehmen, z.B. für meinen oder einen anderen BME680 Sensor.
Dann würde es mir an nichts fehlen ;D ;D ;D
Gruß Thomas
Zitat von: hdgucken am 22 Dezember 2017, 21:19:12
Außerdem würde ich dadurch das Modul "CustomSensor" gar nicht mehr benötigen, cool ;)
Das war der Plan.
Zitat von: hdgucken am 22 Dezember 2017, 21:19:12
Als "additional data" könntest Du noch IAQ mit rein nehmen, z.B. für meinen oder einen anderen BME680 Sensor.
Ich dachte GAS als universelles Reading für Sensoren, die so etwas liefern, das könnte CO2, IAQ, usw. sein.
Aber eventuell sollte ich GAS1 und GAS2 vorsehen, für Sensoren wie den CCS811, die zwei solche Werte liefern (eCO2 und TVOC)
Für Test-Daten wie z.B. den Widerstand des BME680 hatte ich dann "additional data" vorgesehen, wo man so was mitschicken kann.
Ich würde das gerne so universell (drum UniversalSensor) machen, wie möglich und es nicht genau auf einen BME680 ausrichten, der anders als andere Sensoren eine IAQ liefert.
Und vielleicht nehme ich doch eine Voltage mit rein, für Sensoren, die das liefern wollen. Da sollte ein Byte (voltage *10) reichen, was dann 0 ... 25,5V abdeckt?
Hallo HCS,
Zitat von: HCS
Ich dachte GAS als universelles Reading für Sensoren, die so etwas liefern, das könnte CO2, IAQ, usw. sein.
Aber eventuell sollte ich GAS1 und GAS2 vorsehen, für Sensoren wie den CCS811, die zwei solche Werte liefern (eCO2 und TVOC)
Für Test-Daten wie z.B. den Widerstand des BME680 hatte ich dann "additional data" vorgesehen, wo man so was mitschicken kann.
Ich würde das gerne so universell (drum UniversalSensor) machen, wie möglich und es nicht genau auf einen BME680 ausrichten, der anders als andere Sensoren eine IAQ liefert.
Und vielleicht nehme ich doch eine Voltage mit rein, für Sensoren, die das liefern wollen. Da sollte ein Byte (voltage *10) reichen, was dann 0 ... 25,5V abdeckt?
So gesehen, hast Du natürlich recht, wenn der Wertebereich von "GAS" so von 0 bis ungefähr 500 geht, ist das ok.
Werte bis 500000 (Ohm) müssen eigentlich nicht sein, dann sendet man das halt in kOhm, Spannung wäre auch völlig ok so :)
Gruß Thomas
Zitat von: hdgucken am 23 Dezember 2017, 22:09:05
wenn der Wertebereich von "GAS" so von 0 bis ungefähr 500 geht, ist das ok.
Werte bis 500000 (Ohm) müssen eigentlich nicht sein, dann sendet man das halt in kOhm, Spannung wäre auch völlig ok so :)
Der maximal übertragbare Wert für Gas wäre aktuell rund 16,7 Millionen.
Hallo HCS,
Zitat von: HCS
Der maximal übertragbare Wert für Gas wäre aktuell rund 16,7 Millionen.
Natürlich, wer lesen kann ... (1er, 256er, 65536er) ;D
Also alles bestens, das Universalsensor Protokoll kann kommen ;)
Gruß Thomas
Zitat von: hdgucken am 28 Dezember 2017, 01:44:48
Also alles bestens, das Universalsensor Protokoll kann kommen ;)
Ja, wird kommen, bin dran.
Zitat von: hdgucken am 28 Dezember 2017, 01:44:48
Also alles bestens, das Universalsensor Protokoll kann kommen ;)
Und hier kommt es.
Anbei ein LaCrosseGateway V1.31, das den UniversalSensor kann und ein 36_LaCrosse.pm, das ihn auch kann.
Deinen BME680_cc_sensor habe ich auf UniversalSensor umgebaut (auch anbei), meine sonstigen kleinen Änderungen daran darfst Du natürlich auch ignorieren.
Alles im Prototyp-Stadium. Kannst ja mal ein wenig mit experimentieren. Wenn wir es rund haben, checke ich es offiziell ein.
Die peaks im Chart sind Pakte, die es auf der HF-Strecke so unglücklich gekippt hat, dass CRC wieder stimmt. Evtl. sollte ich zwei CRC einbauen, die unterschiedlich rechnen, um die Übertragung besser abzusichern.
Als erstes wünsche ich allen hier ein gesundes neues Jahr !!!
Hallo HCS,
hab gerade Deinen Beitrag gesehen und musste natürlich sofort mal reinschauen ;)
Super Arbeit ! Deine Änderungen sind klasse, endlich mal ein vernünftiges Sendarray ;D
Hatte auch kurz mit dem esp internal vcc probiert, geht aber wegen des Onboard Spannungsteilers
auf den NodeMCU's nicht so gut, hab das dann verworfen.
Zitat von: HCS
Die peaks im Chart sind Pakte, die es auf der HF-Strecke so unglücklich gekippt hat, dass CRC wieder stimmt. Evtl. sollte ich zwei CRC einbauen, die unterschiedlich rechnen, um die Übertragung besser abzusichern.
Das Problem mit den peaks hatte ich auch vereinzelt, es fehlten dann Daten und der Rest hat sich dadurch verschoben, gab viele crc Fehler im Log.
Hatte daraufhin mit dem SPI Takt für den RFM etwas experimentiert und siehe da, mit 400kHz sind die Spikes und crc Fehler weg !
Standardmäßig sollte der Takt bei 1 MHz liegen (laut ESP SPI Lib), hab ich jetzt aber noch nicht nachgemessen. Der RFM kann eigentlich 10 MHz, eigenartig.
Hab meine letzten Änderungen (Vcc Messung abwählbar und Anzeige der BSEC Version beim Start und SPI 400 kHz Takt) mit eingefügt,
das ganze mal übersetzt, keine Fehler. Ich teste dann nachher mal, falls ich dazu komme und berichte hier ...
Gruß Thomas
Zitat von: hdgucken am 01 Januar 2018, 03:32:56
Das Problem mit den peaks hatte ich auch vereinzelt, es fehlten dann Daten und der Rest hat sich dadurch verschoben, gab viele crc Fehler im Log.
Hatte daraufhin mit dem SPI Takt für den RFM etwas experimentiert und siehe da, mit 400kHz sind die Spikes und crc Fehler weg !
Das ist ja interessant.
Ich hatte zu Beginn den BME680_cc_sensor auf einem NanoLGW laufen, da kam so gut wie nie ein Paket heil rüber, die waren fast immmer irgendwo defekt.
Beispiel (sinngemäß):
Geschickt: 1 2 3 4 5 6 7 8 9
Angekommen: 1 2 3 91 5 6 35 8 9
Ich hatte das dann erst mal auf die total unglückliche Antenneverlegung im NanoLGW geschoben und auf der Breadboard-Variante (die auch ein OLED drauf hat), war es dann deutlich besser.
Das muss ich gleich mal auf dem Nano mit 400kHz probieren.
Das würde ja bedeuten, dass das nicht auf der HF-Strecke kippt sonder auf dem Weg in den Sende-FiFo :o
Ein gutes neues Jahr mit guter frischer Luft unter IAQ 100 an alle :)
400kHz SPI hat die Situation auf dem NanoLGW nicht verbessert, es wollte einfach nicht vernünftig senden.
Dann ist mir eingefallen, dass ich früher schon mal ähnliche Problem beim RFM69 hatte und habe mal die Ramp-Up-Time länger gemacht (vom default 40 uS auf 1 ms verlängert), und siehe da, er sendet wunderbar.
Scheinbar ist der Einschaltstrom, wenn die PA hoch kommt, für den Spannungsregler zu heftig.
Zitatvoid RFMxx::InitializeLaCrosse() {
/* 0x01 */ WriteReg(REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY);
/* 0x02 */ WriteReg(REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00);
/* 0x05 */ WriteReg(REG_FDEVMSB, RF_FDEVMSB_90000);
/* 0x06 */ WriteReg(REG_FDEVLSB, RF_FDEVLSB_90000);
/* 0x11 */ WriteReg(REG_PALEVEL, RF_PALEVEL_PA0_ON | RF_PALEVEL_PA1_OFF | RF_PALEVEL_PA2_OFF | RF_PALEVEL_OUTPUTPOWER_11111);
/* 0x12 */ WriteReg(REG_PARAMP, RF_PARAMP_10);
/* 0x13 */ WriteReg(REG_OCP, RF_OCP_OFF);
/* 0x19 */ WriteReg(REG_RXBW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2);
/* 0x28 */ WriteReg(REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN);
/* 0x29 */ WriteReg(REG_RSSITHRESH, 220);
/* 0x2E */ WriteReg(REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0);
/* 0x2F */ WriteReg(REG_SYNCVALUE1, 0x2D);
/* 0x30 */ WriteReg(REG_SYNCVALUE2, 0xD4);
/* 0x37 */ WriteReg(REG_PACKETCONFIG1, RF_PACKET1_CRCAUTOCLEAR_OFF);
/* 0x38 */ WriteReg(REG_PAYLOADLENGTH, PAYLOADSIZE);
/* 0x3C */ WriteReg(REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE);
/* 0x3D */ WriteReg(REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF);
/* 0x6F */ WriteReg(REG_TESTDAGC, RF_DAGC_IMPROVED_LOWBETA0);
ClearFifo();
}
Hallo HCS,
Zitat
400kHz SPI hat die Situation auf dem NanoLGW nicht verbessert, es wollte einfach nicht vernünftig senden.
Dann ist mir eingefallen, dass ich früher schon mal ähnliche Problem beim RFM69 hatte und habe mal die Ramp-Up-Time länger gemacht (vom default 40 uS auf 1 ms verlängert), und siehe da, er sendet wunderbar.
Scheinbar ist der Einschaltstrom, wenn die PA hoch kommt, für den Spannungsregler zu heftig.
Das ist ja mal ein genialer Einfall ;), das teste ich mal, denke nämlich auch, das der RFM mit 1MHz SPI locker zurecht kommen müßte.
Den Test vom Universalsensor hab ich noch nicht gemacht, probiere erst mal das kurz :)
Läuft seit ca. 40 Minuten, 1 mal crc Fehler, da waren aber alle Werte durcheinander, könnte ein eingefangenes Fragment von etwas anderem im Äther sein :)
SPI Clock wieder ohne Begrenzung, PA_RAMP time 1ms.
Sonst sieht es gut aus, ich beobachte das mal ...
CRC-Fheler können schon mal vorkommen, bei mir laufen genug 868-Sensoren, die da mal dazwischenhauen können.
Das Problem mit der urprünglichen Ramp war, dass das NanoLGW eigentlich so gut wie nie ein korrektes Paket ans Zile bekommen hat.
Ich hatte auch mal vor längerer Zeit mit mit einem rtl-sdr geschaut, was da eigentlich rauskommt und da war es so, dass kurz ein Signal kam und dann schlicht das Trägersignal abgesoffen ist.
Das passt auch zu meinem Test heute morgen, da habe ich einfach mal die Sendeleistung um 4dB runter genommen, da ging es dann auch.
Und als ich im Datenblatt das Register für die Sendeleitung nachgelesen habe, ist mir dann die Ramp-Time ins Auge gesprungen ...
Trotzdem überdenke ich das CRC nochmal, da kommt aktuell recht einfach ein Müll durch, bei dem es aufgeht.
Eventuell packe ich auch noch einen treshold rein, Dinge wie IAQ und Luftdruck ändern sich ja nur langsam.
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 :o Ein Problem jagt das Andere. Aber sonst wär's ja auch langweilig ;D
Gruß Thomas
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.
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.
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.
Hallo HCS;
Zitat von: HCS am 06 Januar 2018, 21:59:41
Angepasste hdgucken sources und ein neues LGW anbei.
Deine Version heißt v1.6f, Thomas' Version (https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=92950) hier (https://forum.fhem.de/index.php/topic,78619.msg743327.html#msg743327) 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
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) 8)
Ich hänge mal meinen Stand für die weitere Bearbeitung mit ran ;):
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
eine Kleinigkeit hab ich noch, um den Gas Widerstandswert im Fhem Plot in kOhm darzustellen, einfach:
$fld[3]/1000
in der Zeile für Gas2 unter "Function" eintragen.
siehe Anhang:
Gruß Thomas
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?
Zitat von: HCS am 09 Januar 2018, 16:17:40
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?
Zitat von: oli82 am 09 Januar 2018, 17:01:47
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 ...
Zitat von: HCS am 09 Januar 2018, 17:11:39
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.
Hallo HCS,
Zitat von: 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 :o
Projekt anbei ...
Gruß Thomas
Hallo Thomas,
Zitat von: hdgucken am 09 Januar 2018, 19:45:13
Hab V1.9 fertig, BME680 I2C Adresse einstellen ist vorbei, geht jetzt automatisch !!!
ist das
JeeLink_LaCrosseGateway.bin aus Deinem ZIP-Archiv (http://jeelink_lacrossegateway.bin) die Firmware vom Universalsensor?
Oder einfach die v1.31-prel(irgendwas) von HCSs Firmware für das LaCrosse Gateway?
Danke + Gruß
Peter
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
Hallo Peter,
Zitat von: PeMue
Hallo Thomas,
ist das JeeLink_LaCrosseGateway.bin aus Deinem ZIP-Archiv (http://jeelink_lacrossegateway.bin) die Firmware vom Universalsensor?
Oder einfach die v1.31-prel(irgendwas) von HCSs Firmware für das LaCrosse Gateway?
Ist die aktuellste V1.31 von HCS für den Universalsensor, genau wie die "36_LaCrosse.pm" :)
Gruß Thomas
Version 2.0 ist fast fertig, autodetect Lichtsensor geht auch schon,
fehlt noch das OLED Display, dann ist es fast perfekt ;)
Bis später ...
Ich hoffe, dass ich am WE endlich dazu komme, das LGW 1.31 und die 36_LaCrosse einzuchecken ...
Hab die V2.0 fertig.
OLED und Lichtsensor werden jetzt automatisch erkannt.
Es wird jeweils die primäre und sekundäre Adresse getestet, wenn nicht vorhanden,
läuft der Sensor ohne Display/Lichtsensor.
Mann kann aber auch weiterhin das Display und den Lichtsensor im Sketch komplett deaktivieren,
wenn man sie nicht verwenden möchte.
Der RFM69 ist nur manuell im Sketch deaktivierbar, muss eigentlich immer vorhanden sein.
Oder sollte er auch noch automatisch erkannt werden ?
@juergs: hab die RFMxx überarbeitet, jetzt ohne TPinCallback und Soft-SPI in RFMxx.h auswählbar ;)
AS_BH1750-master ist wegen autodetect auch geändert !
Anbei das Projekt :)
ZitatKleine Spielerei: das Display wird auf geringe Helligkeit gedimmt, wenn Licht < 10 lux,
sozusagen ein "Nachtmodus".
Gute Idee! :)
Noch eine Nachfrage zur Reichweite, lässt sich diese noch optimieren?
Jürgen
Hallo Jürgen,
Zitat von: juergs
Noch eine Nachfrage zur Reichweite, lässt sich diese noch optimieren?
Das ist mit Sicherheit eine Frage der "optimalen Antenne", da muss man einfach ein wenig experimentieren 8)
Ein Geheimrezept gibts da nicht wirklich, ist immer abhängig von den örtlichen Gegebenheiten :-[
Gruß Thomas
Zitat von: hdgucken am 14 Januar 2018, 00:35:08
Hab die V2.0 fertig.
... und mein nanoLGW zeigt über USB auch schon die ersten Grundreflexe (Ausstecken nach Flashen ist notwendig, Baudrate 115200 kbaud):
<\n>[296080.00] P: 999.1| T: 30.53| rH: 23.09| IAQ: 25.00 (0)| Gas: 3768.00| UBat: 3.7V<\r>
<\n>[299080.00] P: 999.1| T: 30.54| rH: 23.07| IAQ: 25.00 (0)| Gas: 3752.00| UBat: 3.7V<\r>
<\n>[302080.00] P: 999.1| T: 30.52| rH: 23.07| IAQ: 25.00 (0)| Gas: 3741.00| UBat: 3.7V<\r>
<\n>[305080.00] P: 999.1| T: 30.53| rH: 23.05| IAQ: 25.00 (0)| Gas: 3715.00| UBat: 3.7V<\r>
<\n>[308080.00] P: 999.1| T: 30.51| rH: 23.07| IAQ: 25.00 (0)| Gas: 3712.00| UBat: 3.7V<\r>
<\n>[311080.00] P: 999.1| T: 30.50| rH: 23.08| IAQ: 25.00 (1)| Gas: 3702.00| UBat: 3.7V<\r>
<\n>[314081.00] P: 999.1| T: 30.48| rH: 23.12| IAQ: 30.47 (1)| Gas: 3683.00| UBat: 3.7V<\r>
<\n>[317081.00] P: 999.1| T: 30.46| rH: 23.15| IAQ: 34.31 (1)| Gas: 3673.00| UBat: 3.7V<\r>
<\n>[320081.00] P: 999.1| T: 30.45| rH: 23.19| IAQ: 35.40 (1)| Gas: 3663.00| UBat: 3.7V<\r>
<\n>[323081.00] P: 999.1| T: 30.44| rH: 23.21| IAQ: 39.37 (1)| Gas: 3650.00| UBat: 3.7V<\r>
<\n>[326081.00] P: 999.1| T: 30.44| rH: 23.20| IAQ: 45.34 (1)| Gas: 3630.00| UBat: 3.7V<\r>
<\n>[329081.00] P: 999.1| T: 30.46| rH: 23.27| IAQ: 43.40 (1)| Gas: 3615.00| UBat: 3.7V<\r>
Anbei die compilierte Version.
Was ist denn der erste Parameter?
Zitat von: hdgucken am 14 Januar 2018, 00:35:08
Der RFM69 ist nur manuell im Sketch deaktivierbar, muss eigentlich immer vorhanden sein.
Oder sollte er auch noch automatisch erkannt werden ?
Das wäre natürlich noch obercool ;D ;D ;D
Zitat von: hdgucken am 14 Januar 2018, 00:35:08
AS_BH1750-master ist wegen autodetect auch geändert !
Du kannst ja Alexander aka hexenmeister (https://forum.fhem.de/index.php?action=profile;u=4065) fragen, ob er Deine Änderungen übernehmen will.
Gruß PeMue
Edit1:Und der Sensor wird auch vom LGW sauber gefunden, siehe Anhang.
Edit2:Irgendwie habe ich Widerstände im Bereich von 100-300 kOhm bei den vorigen Versionen im Kopf, ist der Punkt bei gas2 (über USB) notwendig bzw. richtig? Oder brauche ich ein Userreading?
Ich habe das LGW 1.31 und das für den UniversalSensor angepasste 36_LaCrosse gerade eingecheckt.
Siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg748764.html#msg748764
Hallo Peter, hallo HCS,
Zitat von: HCS
Ich habe das LGW 1.31 und das für den UniversalSensor angepasste 36_LaCrosse gerade eingecheckt.
Cool ... :D
Zitat von: PeMue
... und mein nanoLGW zeigt über USB auch schon die ersten Grundreflexe (Ausstecken nach Flashen ist notwendig, Baudrate 115200 kbaud):
<\n>[308080.00] P: 999.1| T: 30.51| rH: 23.07| IAQ: 25.00 (0)| Gas: 3712.00| UBat: 3.7V<\r>
<\n>[311080.00] P: 999.1| T: 30.50| rH: 23.08| IAQ: 25.00 (1)| Gas: 3702.00| UBat: 3.7V<\r>
<\n>[314081.00] P: 999.1| T: 30.48| rH: 23.12| IAQ: 30.47 (1)| Gas: 3683.00| UBat: 3.7V<\r>
Der erste Parameter ist die Zeit in ms seit Start des Sensors. Sieht man auch schön, daß die sinnvolle IAQ Ausgabe ca. nach 5 Minuten beginnt.
Sieht doch sehr gut aus, freut mich, daß es funktioniert !
Zitat
Das wäre natürlich noch obercool ;D ;D ;D
Du kannst ja Alexander aka hexenmeister (https://forum.fhem.de/index.php?action=profile;u=4065) fragen, ob er Deine Änderungen übernehmen will.
Na dann muss ich wohl nochmal ran ;)
Das mit hexenmeister ist ne gute Idee, kann ihn ja mal anschreiben :)
Edit2:
Irgendwie habe ich Widerstände im Bereich von 100-300 kOhm bei den vorigen Versionen im Kopf, ist der Punkt bei gas2 (über USB) notwendig bzw. richtig? Oder brauche ich ein Userreading?
Hab gerade mal bei mir geschaut, hab da bei Gas1 z.B. 14786, da stimmt was nicht, Gas2 ist null, aber das wär ok :o
Gruß Thomas
Hallo Leute,
V2.1 mit autodetect des RFM69 ist fertig ;)
Wenn aktiviert aber nicht vorhanden, läuft der Sensor nur mit der seriellen Ausgabe.
Neu: wenn das Setup erfolgreich beendet wurde, blinkt die OnBoard LED 3 mal kurz als Bestätigung.
Viel Spass damit ;)
Gruß Thomas
Hallo Thomas.
Danke für die Version.
Was mir bisher nicht ganz klar ist:
Der Sensor von dir sendet die Daten per Wlan oder sendet er über das RFM69?
Danke für die Aufklärung
Gruß
Oli
Hallo Oli,
Zitat von: oli82 am 16 Januar 2018, 09:41:52
Der Sensor von dir sendet die Daten per Wlan oder sendet er über das RFM69?
der Sensor sendet entweder über RFM69 (wenn vorhanden) oder er gibt die Daten per USB aus.
Gruß Peter
Wenn ein RFM69 dran ist, tut er so, als ob er ein LaCrosse-Sensor wäre. Mit einem LGW1.31 und aktuellem FHEM braucht man auf FHEM-Seite dann nichts weiter tun, funktioniert alles wie bei einem TX29 u.Ä., nur dass halt weitere Readings im LaCrosse-Device entstehen.
Danke euch beiden für die Erklärung.
Dann zünde ich mal den Lötkolben ;)
Hallo Thomas,
Zitat von: hdgucken am 14 Januar 2018, 00:35:08
Hab die V2.0 fertig.
mit demselben BME680, mit dem HCS erste Testsoftware gelaufen ist, habe ich gemessen.
Dann habe ich Deine v2 draufgespielt. Aber ich habe einen Mismatch von Faktor 10 im Widerstand:
- bei HCS hatte ich bis 500 kOhm
- bei Deiner v2 habe ich nur max. 50 kOhm
Ist da ggf. ein Faktor 10 vergraben?
Werde jetzt mal die v2.1 kompilieren und testen.
Danke + Gruß
Peter
Zitat von: PeMue am 20 Januar 2018, 17:08:22
Hallo Thomas,
mit demselben BME680, mit dem HCS erste Testsoftware gelaufen ist, habe ich gemessen.
Dann habe ich Deine v2 draufgespielt. Aber ich habe einen Mismatch von Faktor 10 im Widerstand:
- bei HCS hatte ich bis 500 kOhm
- bei Deiner v2 habe ich nur max. 50 kOhm
Ist da ggf. ein Faktor 10 vergraben?
Werde jetzt mal die v2.1 kompilieren und testen.
Danke + Gruß
Peter
Das Timing spielt beim BME680 eine entscheidende Rolle. Je nach dem bekomme ich bei meinem kleinen Testsketch sehr komische Werte, jedenfalls im Vergleich mit dem original Bosch Sketch.
Grüße Jörg
Hallo Peter,
ups, da muß ich mal nachsehen :o
Hab übrigends V2.2 fertig. Jetzt alles besser ;D
https://forum.fhem.de/index.php/topic,78619.msg752916.html#msg752916 (https://forum.fhem.de/index.php/topic,78619.msg752916.html#msg752916)
Gruß Thomas
hab gerade mal V2.0 mit aktueller V2.2 verglichen, nichts gefunden.
Hast Du die Abweichung schon in der seriellen Ausgabe ? Oder auf dem OLED bzw. in FHEM ?
Gruß Thomas
Hallo Thomas,
Zitat von: hdgucken am 21 Januar 2018, 11:37:00
hab gerade mal V2.0 mit aktueller V2.2 verglichen, nichts gefunden.
Hast Du die Abweichung schon in der seriellen Ausgabe ? Oder auf dem OLED bzw. in FHEM ?
ich vergleiche denselben Sensor, einmal mit HCS Firmware prel3 betrieben (also nicht als LGW, sondern mit serieller Ausgabe) und Deine v2. Mir fällt halt auf, dass zwischen der Widerstandsausgabe in etwa der Faktor 10 liegt, siehe Bilder.
Da es derselbe Sensor ist und dieselbe BSEC Library, sollte die Größenordnung stimmen?
Gruß PeMue
Zitat von: PeMue am 21 Januar 2018, 16:49:50
ich vergleiche denselben Sensor, einmal mit HCS Firmware prel3 betrieben (also nicht als LGW, sondern mit serieller Ausgabe) und Deine v2. Mir fällt halt auf, dass zwischen der Widerstandsausgabe in etwa der Faktor 10 liegt, siehe Bilder.
Da es derselbe Sensor ist und dieselbe BSEC Library, sollte die Größenordnung stimmen?
Ja nach Heizdauer und Zieltemperatur der Hotplate kommen ganz unterschiedliche Widerstandswerte zustande.
Evtl. hatte die prel3 auch noch die vorhergehende BSEC verwendet.
Ich würde mir da mal nicht so viel draus machen ...
Zitat
Ja nach Heizdauer und Zieltemperatur der Hotplate kommen ganz unterschiedliche Widerstandswerte zustande.
Evtl. hatte die prel3 auch noch die vorhergehende BSEC verwendet.
Ich würde mir da mal nicht so viel draus machen ...
Stimmt, die BSEC Software ist schon etwas neuer.
Ist aber dennoch eigenartig, Faktor 10 klingt aber schon nach einem Verrechnungsfehler irgendwo auf dem Weg nach FHEM bzw. in FHEM ?!
Was sagen die Werte auf der Seriellen, auch so ?
Zitat von: hdgucken am 21 Januar 2018, 19:41:00
Was sagen die Werte auf der Seriellen, auch so ?
Muss ich mal schauen, aber ich denke ja. Ich werden mal die v2.2 kompilieren und dann starten und gleichzeitig seriell mitloggen. Zumindest das sollte passen. Dann sehen wir weiter.
Gruß PeMue