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

[w6s8]

so, ich habe etwas experementiert: Sobald OLED-Display nicht mehr angeschlossen ist, werden die korrekten Werte geliefert.
Dann habe ich einen anderen (aber gleichen) OLED angeschlossen und der Fehler war wieder da.
Vielleicht hilft das beim suchen.

beim Display handelt es sich um ganz normalen 0,96'', 2 Farbigen (Gelb/Blau) i2c OLED mit fester Adresse 0x78 aus China

[schmadde]

Ich nutze das LacrosseGateway nun schon recht lange (ca. 3 Jahre wenn ich mich nicht irre) und habe das Problem, dass es sich immer mal wieder aufhängt und dann so lange keine Daten mehr aufzeichnet, bis ich es bemerke und neu starte. Das kann Wochen und Monate dauern, bis ich mal wieder wissen will wie kalt es draussen ist ohne raus gehen zu müssen und fest stelle, dass schon lange keine Daten mehr kommen.

Ich habe nun vor ein paar Tagen die aktuelle Firmware aufgespielt und einen Nagios-Monitor auf die IP-Adresse und HTTP Port 80 gesetzt. Der antwortet aber immer noch, liest nur keine Werte mehr (Status in fhem "disconnected"). Das Attribut timeout ist auf 120,30 gesetzt, hilft aber nicht, genauso wenig wie ein reboot über fhem.

Habt Ihr eine Idee wie ich das debuggen kann oder wenigstens einen halbwegs brauchbaren nagios Monitor drauf setzen?

Ich nutze den in Verbindung mit zwei RFM69 (einer für Lacrosse Sensoren, einer für EC3000) und einem DHT22 - der ESP ist ein AFAIR originaler NodeMCU, gesockelt, Netzteil irgendein Handynetzteil, das 1,5A liefern kann. Ich würde das ganze gerne demnächst mit einem OLED Display, einem dritten RFM69 für PCA301 und einem seriellen Port für meine ETA Heizung (lese ich derzeit direkt vom Banana Pi aus) versehen, aber erstmal muss das stabil laufen.

Irgendwelche Ideen für Debugging?

Aus dem Log:

Code Auswählen Erweitern


2021.02.14 12:51:12 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 12:53:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 14:50:52 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 14:52:52 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:12:05 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 15:14:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:54:46 1: [Freezemon] myFreezemon: possible freeze starting at 15:54:45, delay is 1.001 possibly caused by: tmr-LaCrosseGateway_OnConnectTimermyLGW)
2021.02.14 19:08:08 1: [Freezemon] myFreezemon: possible freeze starting at 19:08:07, delay is 1.004 possibly caused by: tmr-LaCrosseGateway_OnConnectTimermyLGW) tmr-HMLAN_KeepAlive(HMLAN1)
2021.02.14 22:45:42 1: [Freezemon] myFreezemon: possible freeze starting at 22:45:41, delay is 1.001 possibly caused by: tmr-HMLAN_KeepAlive(HMLAN1) tmr-LaCrosseGateway_OnConnectTimer(myLGW)
2021.02.15 06:59:49 3: Opening myLGW device 192.168.50.13:81
2021.02.15 06:59:50 1: myLGW: Can't connect to 192.168.50.13:81: Connection timed out
2021.02.15 07:14:55 1: 192.168.50.13:81 reappeared (myLGW)


Letztes Lebenszeichen vom Sensor war gestern 15:18:

Code Auswählen Erweitern


2021-02-14_15:17:27 Seitenterasse temperature: 0.6
2021-02-14_15:18:19 Seitenterasse battery: ok
2021-02-14_15:18:19 Seitenterasse temperature: 0.6
2021-02-15_07:15:35 Seitenterasse battery: ok
2021-02-15_07:15:35 Seitenterasse temperature: -9.6
2021-02-15_07:15:35 Seitenterasse T: -9.6
2021-02-15_07:16:27 Seitenterasse battery: ok
2021-02-15_07:16:27 Seitenterasse temperature: -9.6


[pc1246]

Moin
Erstmal kurz zum Posten: Ueber den Smilies ist eine Raute ( # ) damit kann man solche Log-Auszuege in Codetags setzen. Das freut alle Mitleser, und besonders die am Handy! Das geht auch nachtraeglich!
Zu Deinem Problem, wie ist denn Deine WLAN Konfiguration? Bei mir hat sich das extrem verbessert, seitdem ich von der Fritzbox weg bin! Die hat das Problem mit "vielen" Teilnehmern!
Keiner weiss genau was "viel" ist, aber viele erleben das Problem!
Meine beiden haben ein Display, und wenn ich da vorbeigehe, und sehe, dass wieder mal das eine Symbol nicht da ist, dann greife ich ein. Aber seit dem Weggang von der FB ist das massiv weniger geworden. Meistens nur dann wenn das Netz, durch Router-update, weg ist. Dann gibt es wohl keinen reconnect.
Gruss Christoph

[HCS]

Habt Ihr eine Idee wie ich das debuggen kann oder wenigstens einen halbwegs brauchbaren nagios Monitor drauf setzen?

Nö, keine Ahnung von nagios.

Die Frage ist erst mal, was da überhaupt passiert, also ob das LGW tatsächlich aussteigt oder einfach nicht mehr erreichbar ist.

Mit den aktuellen Mitteln sollte man eigentlich einen Fehlertoleranten Betrieb hinbekommen.
Dazu gibt es die Attribute timeout und watchdog
Beispiel:

Code Auswählen Erweitern

attr lgw209 timeout 120
attr lgw209 watchdog 1200

timeout 120 legt fest, dass FHEM alle 120 Sekunden das LGW anfrägt, "ob es noch lebt"
Das LGW antwortet mit einem "ich lebe noch"
Wenn die Antwort ausbleibt, wird die Verbindung zum LGW geschlossen und neu aufgebaut.

watchdog 1200 legt fest, dass das LGW, wenn 1200 Sekunden lang keine "lebst Du noch" Anfrage von FHEM gekommen ist, es sich selbst rebootet.

Die beiden Werte kann man in sinnvollen Grenzen nach den eigenen Bedürfnissen festlegen.

Überwachung: da wäre (keine Ahnung, wie man das in nagios macht) das denkbar:
Auf der Setup-page vom LGW einen zweiten DataPort (z.B. 82) öffnen
Auf diesem schickt das LGW alle Daten, die an FHEM gehen, parallel raus.
Einen TCP-Client auf den Port 82 setzen und die eingehenden Daten mitlesen
Wenn z.B. eine gewisse Zeit keine Zeile mehr kommt, die mit "OK 22" beginnt, dann wird kein EC3000 mehr empfangen.
Oder die "LGW ALIVE" Meldungen auswerten, das ist die Antwort auf die "Lebst Du noch?" Anfrage von FHEM.
In meinem Fall (siehe Anhang) ist timout auf 30 gesetzt, was aber für einen "Normalbetrieb" etwas zu kurz ist.

Beispiel, was (ist ein Test-LGW, das nur EC3000 empfängt) da so an Daten kommen sollte ist angehängt.

[schmadde]

Ich habe einen Unifi UAP-AC-Pro Accesspoint der Sichtkontakt zum LGW hat und keine 5 Meter entfernt ist. Ich schliesse ein Problem dort eher aus. Es gibt zwar noch eine alte Fritzbox, deren 2,4GHz WLAN als secondary definiert ist, die ist aber 2 Stockwerke weiter oben und hat kaum Empfang und da ist auch nichts mehr angeschlossen ausser dem LAN Kabel und keine User aktiv - die dient nur dem dortigen Fernseher als AP, bis die Unifi 6 LR wieder lieferbar sind.

Ich gebe zu, dass Debugging mit so wenig Infos nicht möglich ist, aber kann man das irgendwie sinnvoll monitoren?

[HCS]

Ich gebe zu, dass Debugging mit so wenig Infos nicht möglich ist, aber kann man das irgendwie sinnvoll monitoren?

Du hast meinen Beitrag übersehen?

[schmadde]

Die Frage ist erst mal, was da überhaupt passiert, also ob das LGW tatsächlich aussteigt oder einfach nicht mehr erreichbar ist.

Wenn ich das so genau wüsste - Ich weiss nur, dass das LGW auf HTTP Anfragen auf Port 80 noch korrekt antwortet. Dieser Nagios-Monitor liefert jedenfalls immer noch o.k. zurück.
Aber im FHEM ist es "disconnected".

timeout habe ich schon auf "120,30" gesetzt, das hat nix geholfen. Ich habe jetzt auch den watchdog gesetzt und hoffe das hilft.

[HCS]

timeout habe ich schon auf "120,30" gesetzt, das hat nix geholfen. Ich habe jetzt auch den watchdog gesetzt und hoffe das hilft.

Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway

[pc1246]

Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway

Moin
Das lese ich heute zum ersten Mal!
Siehe auch im Wiki: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Reconnect
Das koennte so einiges erklaeren!
Gruss Christoph

[HCS]

Das lese ich heute zum ersten Mal!

Hatte ich schon mal gelesen 

https://forum.fhem.de/index.php/topic,43672.msg546877/topicseen.html#msg546877

Aber das Wiki wäre wohl anzupasen, da brauchen wir dann wieder mal jemand, der sich aufopfert 

[schmadde]

Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway

Ja, habe ich, vielen Dank für die Tipps. Das Monitoring auf Port 82 lässt sich so mit nagios nicht umsetzen. Ich finde leider auch kein passendes Pattern im fhem-logfile auf das ich check_logfile ansetzen könnte. Evtl. kann ich den "Freezemon" eine Mail schicken lassen, da muss ich mich mal wieder tiefer in fhem reingraben.

Noch eine Frage zum SC16IS750 Serial Port: den muss ich einfach mit SPI Kabel anschliessen, ggfs in Reihe zu einem OLED Display, das noch dazukommt, auf der Platine ist kein Platz dafür vorgesehen? Gibts irgendwelche Beispiele wie ich den seriellen Port aus einem FHEM Modul oder einem externen Script ansprechen kann? Ich habe aktuell ein Perl Script das noch nicht in FHEM integriert ist mit dem ich meine Heizung auslesen kann und konnte sie auch mal steuern. Ich habe aber immer wieder Probleme mit den USB-Serial Konvertern und wollte eigentlich einen Arduino oder ESP32 mit einem richtigen UART dranhängen, aber jetzt wo ich gesehen habe, dass das LGW eine Serielle Schnittstelle übers Netz bereitstellen kann würde ich erstmal das versuchen. Ist das möglich?

[HCS]

2021.02.14 12:51:12 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 12:53:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 14:50:52 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 14:52:52 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:12:05 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 15:14:22 1: 192.168.50.13:81 reappeared (myLGW)

Dieser Auzug aus dem Log sieht übrigens eher nach WiFi-Zirkus aus.

Der Arduini-Core oder eher das darunterliegende Espressif-IDF hatte definitiv Probleme im Bereich WiFi.
In den letzten Versionen wurde da aber einiges gemacht.
Weiter oben hat es auch schon mal von irgend jemand die vorhandenen WiFi-Probleme beseitigt.
Ich kann mal ein LGW gegen den aktuellen Core 2.7.4 compiliert bereitstellen, dann könntest Du schauen, ob es stabiler wird.

Allerdings habe ich damit noch das Problem, dass der 2.7.4 Core größer geworden ist und man aktuell nicht per OTA von LGW 1.35 auf 1.36 kommt.
Diese Version müsste man also per USB auf das LGW hochladen.

Noch eine Frage zum SC16IS750 Serial Port: den muss ich einfach mit SPI Kabel anschliessen, ggfs in Reihe zu einem OLED Display, das noch dazukommt

Parallel zum OLED, nicht in Reihe, siehe auch hier: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Variante:_DEVKIT_1.0_Maximalausbau
Und es ist I2C und nicht SPI

Gibts irgendwelche Beispiele wie ich den seriellen Port aus einem FHEM Modul oder einem externen Script ansprechen kann? Ich habe aktuell ein Perl Script das noch nicht in FHEM integriert ist mit dem ich meine Heizung auslesen kann und konnte sie auch mal steuern. Ich habe aber immer wieder Probleme mit den USB-Serial Konvertern und wollte eigentlich einen Arduino oder ESP32 mit einem richtigen UART dranhängen, aber jetzt wo ich gesehen habe, dass das LGW eine Serielle Schnittstelle übers Netz bereitstellen kann würde ich erstmal das versuchen. Ist das möglich?

Ich befürchte, dass das nichts wird. Das LGW stellt die serielle Schnittstelle des SC16IS750 auf einem TCP-Port bereit.
Um sie zu nutzen, muss irgend etwas als TCP-Client damit arbeiten. Dein Script müsste also einen TCP-Client implementieren, der mit dem Port vom LGW kommuniziert.

Der UseCase ist eigentlich eher, dass man etwas wie einen CUL an den SC16IS750 hängt und das entsprechende FHEM-Modul ihn dann verwendet.
Eine Serielle Schnittstelle, die dann auf einem Rechner wieder als solche bereitgetsellt wird (also so, wie es die gängigen USB->TCP Ports machen) war und ist nicht der Plan.
Und ich glaube, dass so etwas besser für Dein Vorhaben geeignet wäre.

[pc1246]

Hatte ich schon mal gelesen 

https://forum.fhem.de/index.php/topic,43672.msg546877/topicseen.html#msg546877

Aber das Wiki wäre wohl anzupasen, da brauchen wir dann wieder mal jemand, der sich aufopfert 

Moin
Okay, dass das schon so lange da steht!? Kurze Frage noch, 2016 hast Du geschrieben, dass man das mit dem Komma behalten kann. In der commandref taucht das gar nicht mehr auf.
Geht/ging es trotzdem noch?
Gruss Christoph

[HCS]

Okay, dass das schon so lange da steht!? Kurze Frage noch, 2016 hast Du geschrieben, dass man das mit dem Komma behalten kann. In der commandref taucht das gar nicht mehr auf.
Geht/ging es trotzdem noch?

Ja, die alte Variante geht auch noch, taugt aber halt nicht so arg.
In der commandref wollte ich niemand neu dazu animieren, die alte Variante noch in Betrieb zu setzen.

[schmadde]

Dieser Auzug aus dem Log sieht übrigens eher nach WiFi-Zirkus aus.

Der Arduini-Core oder eher das darunterliegende Espressif-IDF hatte definitiv Probleme im Bereich WiFi.
In den letzten Versionen wurde da aber einiges gemacht.
Weiter oben hat es auch schon mal von irgend jemand die vorhandenen WiFi-Probleme beseitigt.
Ich kann mal ein LGW gegen den aktuellen Core 2.7.4 compiliert bereitstellen, dann könntest Du schauen, ob es stabiler wird.

Welchen Arduino Core sollte man denn auf dem NodeMCU/ESP8266 haben? Ich nehme mal an, der wird nicht mitgeflasht beim OTA Update vom LGW. Bei mir ist wenn ich das richtig interpretiere 2.5.0 drauf, ich habe daran noch nie was gemacht, sollte der neuer sein und wo bekomme ich ihn her (bin ESP Newbie).

Grade ist das LGW wieder abgeschmiert, diesmal hat es nichtmal mehr gepingt. Ich hab jetzt mal ein stärkeres Netzteil hingehangen (5V 3A) und werde ein Display einlöten um zu sehen wieviel da noch lebt.

Der UseCase ist eigentlich eher, dass man etwas wie einen CUL an den SC16IS750 hängt und das entsprechende FHEM-Modul ihn dann verwendet.
Eine Serielle Schnittstelle, die dann auf einem Rechner wieder als solche bereitgetsellt wird (also so, wie es die gängigen USB->TCP Ports machen) war und ist nicht der Plan.
Und ich glaube, dass so etwas besser für Dein Vorhaben geeignet wäre.

Hm. o.k. dann werde ich wohl doch einen extra Arduino oder ESP hernehmen. Doof nur, dass man den einzigen UART meist nicht sinnvoll verwenden kann weil der fürs Flashen und debuggen gebraucht wird. Das Problem hatte ich auch schon am Raspberry an dem die Heizung aktuell hängt. Netzverbindung bräuchte ich nichtmal, weil das serielle Kabel der Heizung bis ins Serverrack reicht.