LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

[HCS]

Heute ist es ein USR-TCP232-T morgen USR-K2/2 (ist vielleicht eine bessere alternative  ) etc. => ich würde die Erkennung vernachlässigen und auf der Config-Page eine Checkbox "USB/Seriel-Mode" anbieten.

Du meinst siehe Anhang 
Da habe ich bereits gestern Nacht umgeschwenkt.

Wird die Checkbox ausgewählt, ist ein STA-Mode (SSID/PW etc.) nicht möglich - ideal wäre es die Felder auszugrauen (nice to have).

Wird die Checkbox ausgewählt, dann wird man die Setup-Page nach dem nächsten reboot eh nicht mehr zu sehen bekommen ...

Viel ändert man nach einer init-Einrichtung ja nicht bzw. kaum etwas und wenn es mal nötig ist, dann resetet man das LGW und richtet es neu ein - ist ja auch in paar sekunden erledigt.

Neu einrichten ist doof, weil man z.B. sein PCA301 Kanalzuordnung verliert.

Es wird die Möglichkeit geben, die Settings auch über die serielle Schnittstelle zu setzen, egal ob wifi gerade aktiv ist oder nicht.
Man wird dann auf der seriellen Schnittstelle sowas (so ungefähr, oder genau so, oder sonstwie) schicken können:
"SETUP UseWiFi false; IO0 OLED mode=thp;  IO1 OLED Off; CorrT -2.5; ISID 211"
oder
"SETUP UseWiFi true"
oder
"SETUP Altitude 220; CorrT -2.5; CorrH -4;"

was die Settings entsprechend ändert und speichert (und vermutlich dann wie die Setup-Page einen reboot macht)

Wie erkennst das LGW das heute wenn ich das LGW in USB-Mode betreibe bzw. WiFi deaktiviere?

Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP 

Das LGW muss sich im "nicht wifi" Mode auch die ganzen debug Meldungen beim booten auf der seriellen schenken.

Es wird aber nichts dran vorbeiführen, das JeeLink device anzupassen, da es von einer JeeLink-Reset-Logik ausgeht und die beim ESP8266 halt eine andere ist.
Und da der USR-TCP kein RTS hat, geht es damit schon gar nicht.

[PeMue]

Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP 

Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner 

Wenn die Reset "Schrulle" weg ist, würde ich das Ganze so machen:
- Einrichten wie gehabt per Web Page (man muss sich einmal an seinen Router per WLAN anlernen, ansonsten funktioniert der grafische Setup halt nicht)
- dann einfach per Haken WiFi abschalten
Wenn man neu einrichten will, muss man halt per fhem wieder WiFi anschalten (ich hoffe, das geht  ).

Gruß PeMue

[amunra]

Du meinst siehe Anhang 
Da habe ich bereits gestern Nacht umgeschwenkt.

Ja, genauso

Neu einrichten ist doof, weil man z.B. sein PCA301 Kanalzuordnung verliert.

War mir nicht bewust, dass das LGW die "Zentrale" spielt. Ich war der Meinung, dass das LGW die Daten sammelt, FHEM speichert diese und gibt sie dem LGW zurück - und WEB-Config die Daten nur visualisien bzw. auch pushen kann.

Es wird die Möglichkeit geben, die Settings auch über die serielle Schnittstelle zu setzen, egal ob wifi gerade aktiv ist oder nicht.
Man wird dann auf der seriellen Schnittstelle sowas (so ungefähr, oder genau so, oder sonstwie) schicken können:
"SETUP UseWiFi false; IO0 OLED mode=thp;  IO1 OLED Off; CorrT -2.5; ISID 211"
oder
"SETUP UseWiFi true"
oder
"SETUP Altitude 220; CorrT -2.5; CorrH -4;"

was die Settings entsprechend ändert und speichert (und vermutlich dann wie die Setup-Page einen reboot macht)

Ich möchte jetzt nicht direkt den Produktmanager und die Entwicklungsabteilung zugleich unter Druck setzen bzw. einspannen, aber ein "save-settings"-Button wäre so langsam angebracht (Prio: 10 auf der ToDo Liste - Vorschlag/Grundsatz: Funktionalität vor Komfort)

Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP 

Das LGW muss sich im "nicht wifi" Mode auch die ganzen debug Meldungen beim booten auf der seriellen schenken.

Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner 

Fürs Protokoll : Da hat aber der Produktmanager vor einiger Zeit etwas anderes verprochen Ich fasse zusammen, offensichtlich hat es bisher (bis jetzt) niemand genutzt und das ist der Grund warum die Beschwerden bis heute ausgeblieben sind

Es wird aber nichts dran vorbeiführen, das JeeLink device anzupassen, da es von einer JeeLink-Reset-Logik ausgeht und die beim ESP8266 halt eine andere ist.
Und da der USR-TCP kein RTS hat, geht es damit schon gar nicht.

Ja, korrekt.

[HCS]

Ich war der Meinung, dass das LGW die Daten sammelt, FHEM speichert diese und gibt sie dem LGW zurück - und WEB-Config die Daten nur visualisien bzw. auch pushen kann.

Nein. Das LGW verwaltet die ID-Kanal-Zuordnung selbst. Kann auch nur so sein, da sich ja bis zu drei FHEMs auf ein LGW verbinden können und dann Kanalsalat vorprogrammiert wäre.

Da hat aber der Produktmanager vor einiger Zeit etwas anderes verprochen

Ich bin doch gerade dabei, das Versprechen wahr zu machen.
Falls Dir das noch nicht aufgefallen ist hier nochmal der Plan:

- Persistente Konfiguration, ob wifi genutzt werden soll -> done
- Wenn kein wifi, dann die debug Ausgaben beim Start auf der seriellen Schnittstelle unterdrücken -> 1.22
- Abfragen, Setzten und Speichern der Einstellungen auch über die serielle Schnittstelle -> 1.22
- Patch für das 36_JeeLink.pm bei justme1968 einreichen, um eine LGW-taugliche Initialisierung einstellen zu können

Die Vorschläge in Richtung "einmal per wifi konfigurieren und dann auf USB/Kabel umschwenken" habe ich verworfen.
Das führt mit Sicherheit innerhalb überschaubarer Zeit zu der Anfrage, ob das nicht auch ohne wifi in Gang zu bekommen ist.
Und: ein hardcore-wifi-Verweigerer wird, da er die Strahlungswerte nicht gewohnt ist, die Konfiguration nicht schnell genug hinbekommen, bevor sein Erbgut unwiederuflich geschädigt wurde 

Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner 

Eigentlich hatte ich schon ganz zu Beginn den Wunsch, das LGW per Jumper von wifi auf USB umstellen zu können.
Falls der Hardwarefuzzi dazu eine Idee hat (ohne auf eine der möglichen Hardwares zu verzichten), wäre das auch noch was.
Evtl. GPIO13 pullup wenn man kein WiFi will, das könnte ich bei Start dann prüfen.
Dem MOSI sollte es doch egal sein, ob da ein pullup drauf ist, oder?

..., aber ein "save-settings"-Button wäre so langsam angebracht

Da zitiere ich Dich jetzt mal:

Viel ändert man nach einer init-Einrichtung ja nicht bzw. kaum etwas und wenn es mal nötig ist, dann resetet man das LGW und richtet es neu ein - ist ja auch in paar sekunden erledigt.

und schließe mich Deiner Meinung von gestern an, dass man es nicht braucht.

[HCS]

- Patch für das 36_JeeLink.pm bei justme1968 einreichen, um eine LGW-taugliche Initialisierung einstellen zu können

Und da mal einen Schritt weiter überlegt: ich habe schon öfter drüber nachgedacht, ob ich für das LaCrosseGateway ein eigenes physisches FHEM-Modul machen sollte (also ein 36_LaCrosseGateway.pm), das genau das untestützt, was das LGW macht und nicht eine Wunderwaffe für Alles ist, mit der man für das LGW recht viel falsch verstehen (und machen) kann.

Beispiele, was man nicht braucht:
- die ganzen tune_... Attribute
- die Beep... Attribute
- das flashCommand Attrbut
- alle gets

Was man brauchen kann, aber das Falsche macht:
- set beep (das LGW kann ja so was, das Modul sendet nur leider etwas für eine ganz andere Firmware)

Was man haben könnte aber im 36_JeeLink nicht bekommen wird:
- LGW-spezifische readings wie uptime, RSSI, ... direkt im 36_LaCrosseGateway
- Einstellungen, ob z.B. das KVP mit den LGW-Infos dispatched werden soll oder einem die readings im 36_LaCrosseGateway ausreichen
- Eventuell bekommt man es hin, das LGW von FHEM aus per USB zu flashen (alternativ zu OTA)

Und vermutlich vieles mehr und ein LaCrosseGateway ist halt nun mal ein LaCrosseGateway und kein JeeLink.

Jetzt werden sich einige fragen, wie man so blöd sein kann, sich das auch noch aufzuhalsen 
Ja, gute Frage, stelle ich mir auch gerade, aber das kann ja langsam entstehen und über die Zeit wachsen.

Für neu anzulegende LGWs ist es eh egal.
Eine bestehende Installation umzustellen würde bedeuten, dass man das bisherige JeeLink device (jetzt kommt's: am einfachsten in der fhem.cfg) in ein LaCrosseGateway umschreibt.

Meinungen dazu?

[waschbaerbauch]

Manchmal frag ich mich echt was mit meinem Zeitmanagement nicht stimmt, aber ich bin voll für deinen Ansatz eines eigenen Moduls!

[HCS]

Manchmal frag ich mich echt was mit meinem Zeitmanagement nicht stimmt

Mein Plan ist, mich mit der Implemetierungsgeschwindigkeit an BER zu orientieren 
Und schon stimmt das Zeitmanagement 

[waschbaerbauch]

Das schaffst du sowieso nicht, dir fehlt ja jegliche Grundlage es zu verzögern und an allen Ecken und Enden Kohle zu schinden

[PeMue]

Hallo HCS,

mir ist aufgefallen, dass ab und  zu der erste Druckwert nicht stimmt. Wie gibt denn das LGW den Druck raus, so wie es der Sensor misst? Und danach wird mit dem Höhenattribut im fhem Modul berechnet? Ich habe jetzt mal sukzessive die BME280 Platinen an ein LGW hingehängt und jetzt schon das zweite oder dritte Mal gesehen, dass der erste angezeigte Wert zu tief ist:

Code Auswählen Erweitern

2016-08-30_19:33:57 LaCrosse_01 pressure: 992
2016-08-30_19:34:07 LaCrosse_01 temperature: 25.4
2016-08-30_19:34:07 LaCrosse_01 humidity: 39
2016-08-30_19:38:58 LaCrosse_01 pressure: 1021

Danke + Gruß

PeMue

[HCS]

Hallo HCS,

mir ist aufgefallen, dass ab und  zu der erste Druckwert nicht stimmt. Wie gibt denn das LGW den Druck raus, so wie es der Sensor misst? Und danach wird mit dem Höhenattribut im fhem Modul berechnet?

Das LGW gibt den gemessenen Druck für die mit xxxh gesetzte Höhe normalisiert zurück.
Das kann es aber erst, wenn es die Höhe kennt und die kennt es erst, wenn FHEM die initCommands gesendet hat.

Aus diesem Grund habe ich auf der setup-Page die Einstellung Altitude eingebaut, dass das LGW nicht darauf angewiesen ist, dass es von FHEM irgend wann geschickt wird.

Je länger von FHEM keine initCommands kommen desto länger stimmt der Druck nicht (bei der bisherigen Variante)
Wenn man es auf der setup-Page gesetzt hat, kann man sich das 220h oder was auch immer in den initCommands schenken.

[juergs]

Höhenangaben herausfinden:
http://www.autospur.de/Staumeldungen/wie-hoch.html
http://embedded-lab.com/blog/bmp180/
sorry, wenn's off-topic sein sollte...

[SusisStrolch]

Hier mal ein paar Neuigkeiten von der Kalibrier-Front:
Betreibe den BME280 nun mit 1000ms Standby und IIR Filter == 4.
Erstes Zwischenergebnis:
Die Temperatur-Differenz zu meinem DS18B20 Bündel ging - ohne Positionsänderungen! - von ~1,7 auf 0,9 °C zurück.

Könnte es u.a. mit an der Verlustwärme des auf dem Breakout-Board verbauten Spannungsreglers hängen?

Anbei mal ein Screenshot - Update war um 15:00...
(Der Sprung um 15:02 rührt daher, dass ich einen Offset auf den DS18B20 Mittelwert entfernt habe, welcher zur Spreizung des Diagrammes verwendet wurde)

[HCS]

Die Temperatur-Differenz zu meinem DS18B20 Bündel ging - ohne Positionsänderungen! - von ~1,7 auf 0,9 °C zurück.

Das ist ja schon mal gut.

Könnte es u.a. mit an der Verlustwärme des auf dem Breakout-Board verbauten Spannungsreglers hängen?

Da müsste man mal die Stromaufnahme des Breakut messen, dann könnte man rechnen.
Aber bei maximal 714 µA lt. Datenblatt kann da ja eigentlich nicht viel sein.

Die Temperatur-Differenz zu meinem DS18B20 Bündel ...

Ich habe mal zwei DS18B20 kalibriert. Beide als Kabelfühler, einer mit Metallhülse und einer mit Kunststoffhülse.
Für die Messungen aneinandergebündelt.

Zum Zeitpunkt der Kalibrierung hatte ich 996 hPa was einen Siedepunkt von ca. 99.5 °C ergibt.
Wie viel Salz in meinem Leitungswasser ist, kann ich nicht sagen, aber es war definitiv nicht das übrige Nudel-Koch-Wasser 
Da sollte der reale Wert dann knapp unter Null sein, aber sicher nicht bei -0.4 °C

Code Auswählen Erweitern


Eiswasser:         Metallfühler: -0.4 °C  Kunststofffühler: +0.1 °C
Kochendes Wasser:  Metallfühler: 99.3 °C  Kunststofffühler: 98.3 °C

Was auch zu beobachten war: der Sensor mit der Kunststoffhülse reagiert erheblich langsamer auf Temperaturänderungen und braucht deutlich länger, bis er an dem Punkt angekommen ist, an dem die Messung stabil steht. Eigentlich auch logisch und zu erwarten.

Wenn man eine halbwegs brauchbare Linearität annimmt, kann man damit dann wohl mit einer Zweipunktkalibrierung auf +- 0.2 °C im Zimmertemperaturbereich kommen.
Als nächstes werde ich dann mal den SHT75 bei Kühlschranktemperatur, Zimmertemperatur und irgendwo bei 50°C  (der kommt mir nicht in den Kochtopf) gegen den kalibrierten DS18B20 vergleichen und ihn in einer übersättigten Kochsalzatmosphäre auf die 75% rH testen.
Ich glaube, da stelle ich gleich alles mit rein, was rH kann.

Danach ist der SHT75 dann meine persönliche Referenz, nach der sich alle anderen Sensoren richten müssen. 

[SusisStrolch]

Ich habe mal das diff zu meinem Experimentiermodul angehängt.
Änderungen:
- BME280 in FORCED mode, Trigger via GetTemperature (das Delay hierdurch liegt bei ca. 14ms)
- In der Hardware-Page wird die Temperatur 2-stellig angezeigt

Das zusätzliche #include in ESP8266Tools.h ist notwendig, da es anscheinend eine Änderung in der neuesten IDE gab (IPAddress war undefiniert).

Probier mal aus, ob das zusätzliche Delay in GetTemperature einen Einfluß auf deine komplexeren Setup's hat.

[SusisStrolch]

Das ist ja schon mal gut.
Da müsste man mal die Stromaufnahme des Breakut messen, dann könnte man rechnen.
Aber bei maximal 714 µA lt. Datenblatt kann da ja eigentlich nicht viel sein.

Ich habe mal zwei DS18B20 kalibriert. Beide als Kabelfühler, einer mit Metallhülse und einer mit Kunststoffhülse.
Für die Messungen aneinandergebündelt.

Ich habe 3 Stück mit Metallhülse sowie den BME280 mal ganz simpel auf einen Kühlkörper genagelt.
Zwar nicht ideal vom Wärmeübergang, allerdings deutlich besser als "in der Nähe".

Da sollte der reale Wert dann knapp unter Null sein, aber sicher nicht bei -0.4 °C

Meine Charge DS18B20 streut nur um ca. 0,3° bei Raumtemperatur.
Im Eiswasser war das auch anders - je nach dem wo die Eiswürfel grade schwammen.
Deshalb jetzt der Kühlkörper - zur "Mittelwertbildung".

Danach ist der SHT75 dann meine persönliche Referenz, nach der sich alle anderen Sensoren richten müssen. 

Kommt der mit ins LaCrosseGateWay?