HMUARTLGW: Fehlermeldungen

[Joker]

Hallo,

ich betreibte mein Homematic System mit einer VCCU bestehend aus folgenden IOs:
- HMLAN (das alte runde Teil von eQ-3)
- HM-MOD-RPI-PCB (1): Direkt auf dem Raspi auf dem FHEM läuft
- HM-MOD-RPI-PCB (2): Auf einem zweiten Raspi, angebunden per socat

Das HMLAN würde ich gerne ersetzen, da es ab und zu Schluckauf hat (ist dann disconnected und muss resetted werden).

Dafür habe ich nun seit einigen Tagen zusätzlich ein weiteres HM-MOD-RPI-PCB an einem ESP8266 angeschlossen (mit Hilfe der Platine von amunra). Auf dem ESP läuft ESPEasy mit dem Ser2Net Server.
Alle HM-MOD-RPI-PCBs sind natürlich per HMUARTLGW angebunden.

Prinzipiell funktioniert das auch alles ganz wunderbar, allerdings sehe ich im Log immer mal wieder in unregelmäßigen Abständen drei Arten von Fehlermeldungen:

1.

Code Auswählen Erweitern

2018.10.29 05:46:03 1: HMUARTLGW HMUARTWIFI1 frame with wrong length received: 23, should: 22: FD0012011805000038D5847036C2B000000000BE31537FDF

2.

Code Auswählen Erweitern

2018.10.29 06:53:24 1: HMUARTLGW HMUARTWIFI1 invalid checksum received, dropping frame (FD001201D305000031AF865A31DC27000000A0724D4EF9)!

3.

Code Auswählen Erweitern

2018.10.29 07:07:46 1: HMUARTLGW HMUARTWIFI1 did not respond for the 1. time, resending

Das hört sich für mich alles ziemlich bedenklich an. Jemand eine Idee woran das liegen könnte?

[pc1246]

Moin
Haben die, bzw. der neue, HMUART auch alle die aktuelle FW von Dir aufgespielt bekommen?
Gruss Christoph

[Joker]

Yepp, 1.4.1 ist drauf auf allen HMUARTs 

[MadMax-FHEM]

Der Fehler Nummer "1" ist (soweit ich mich erinnere) das "Korrigieren" eines FW-Bugs.
D.h. diese Ausgabe zeigt an, dass der FW-Bug aufgetreten ist und korrigert wurde...
...so hab ich das zumindest im entsprechenden Thread verstanden...

Die anderen beiden: keine Ahung...

EDIT: gut zu "3" hätte ich noch eine Idee: evtl. WLAN-Latenz!?

Gruß, Joachim

[Joker]

Der Fehler Nummer "1" ist (soweit ich mich erinnere) das "Korrigieren" eines FW-Bugs.
D.h. diese Ausgabe zeigt an, dass der FW-Bug aufgetreten ist und korrigert wurde...
...so hab ich das zumindest im entsprechenden Thread verstanden...

Ok...
Du weißt nicht zufällig noch welcher Thread das war? Google schweigt sich da leider aus. Aber ich habe grade mal in den Sourcecode vom HMUARTLGW geschaut, und es sieht mir so aus als sollte wenn dieser Bug auftritt eine andere Meldung kommen ("invalid checksum received, recalculated with slen xxx").

EDIT: gut zu "3" hätte ich noch eine Idee: evtl. WLAN-Latenz!?

Hm. Die Frage ist wie man das prüfen bzw. behebn könnte. Ich könnte den ESP mal näher an den Access Point stellen. Aber das WLAN Signal ist eigentlich ganz gut an der Stelle wo er ist.

[MadMax-FHEM]

Hmm, vielleicht lag ich auch falsch hab mich nur erinnert, dass es eine Meldung gab/gibt (die so ähnlich "klang") die eben einen FW-Bug "behebt/signalisiert"...

Google hat mich mit dem Fehler hier hin geführt: https://forum.fhem.de/index.php?topic=82139.0

Bringt aber auch keine Lösung...


Bzgl. 3 sollte es WLAN Latenz sein müsste man wissen welche Telegramme das sind, also welche die tatsächlich so laufen:

HM-Modul -> ESP -> fhem -> ESP -> HM-Modul

Bei Telegrammen die das HM-Modul selbst abarbeiten sollte und max. eine Quittung an fhem schickt sollten da weniger zuschlagen...

Wie man das herausfinden kann...
...hmm, wahrscheinlich mit WireShark wenn man weiß was über die "Leitung" geht und in welcher Zeit das geschehen sein muss...

Aber wie gesagt das war nur eine wilde Vermutung...

EDIT: äh der erwähnte Thread war (vermutlich) der HMUART-LGW-Thread... https://forum.fhem.de/index.php/topic,54511.msg460972.html#msg460972 der hat aber schon eine gewisse Länge...

Gruß, Joachim

[Otto123]

Auf dem ESP läuft ESPEasy mit dem Ser2Net Server.

Nach meiner Meinung und Erfahrung keine gute Idee.
Nimm/Versuch esp-link v2.2.3 -> läuft bei mir absolut stabil.

Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled und UART pins auf swapped stellen.

Gruß Otto

[Joker]

Ok, kann ich mal versuchen. Ich habe ESPEasy genommen, weil ich ursprünglich noch ein OLED an dem wemos hatte, entsprechend der Beschreibung in dem einen PDF.
Da ich das Display aber wieder entfernt habe (finde ich doch unnötig) könnte ich ja doch esp-link nehmen.

Jetzt ist mir gerade noch was aus dem Wiki ins Auge gesprungen:

Will man das TRX1-Modul nicht verwenden, so kann man auch das UART-Modul direkt mit Rx/Tx des Raspberry Pi verbinden. Das Bild rechts zeigt die entsprechende Verkabelung. Hier sollten allerdings Stützkondensatoren an die Stromversorgung des UART angebracht werden, da Spannungsschwankungen sonst zu schwer interpretierbaren Fehlern führen können.

Öhm... ich verwende ja die amunra Platine, und da habe ich nur den wemos und das UART-Modul aufgelötet. Hätten da noch irgendwo Kondensatoren hin gemusst?

[Otto123]

Ich habe das Original Modul zum Stecken genommen und eine kleine Adapterplatte mit einem ESP-12F drauf und Spannungsregler 3,3 Volt genommen. Das läuft so. (Da ist ja der Stützkondensator auf dem HMUART Modul)
Ansonsten ist der ESP wegen Stützkondensator sehr empfindlich, also besser einen drauf machen, hat die amunra Platine aber doch bestimmt?

[Joker]

Sagen wir mal so, nicht dass ich wüßte 
Habe zumindest beim bestücken und auf den Fotos in den entsprechenden Anleitungen nichts dergleichen gesehen.

[Otto123]

 
Ich habe mal versucht einen ESP12 nackig an zwei AA Zellen zu betreiben, kurze Drähte usw. das ging schief. 
Der zieht zeitweise ganz schon Strom und das sicher Impulseartig.
Also ein Elko 10-100µ und eine Scheibe 100nF wären sicher eine gute Maßnahme.

[gloob]

Sagen wir mal so, nicht dass ich wüßte 
Habe zumindest beim bestücken und auf den Fotos in den entsprechenden Anleitungen nichts dergleichen gesehen.

Der Wemos bringt genug Kapazitäten mit um die Spannung zu stabilisieren. Ich betreibe damit ein Homematic Funkmodul, auch auf der amunra Platine, seit 1 1/2 Jahren ohne Probleme. Was nutzt du denn als Spannungsversorgung? Ein USB Netzteil und dann mit USB Kabel an den Wemos.

[Otto123]

Der Wemos bringt genug Kapazitäten mit um die Spannung zu stabilisieren. Ich betreibe damit ein Homematic Funkmodul, auch auf der amunra Platine, seit 1 1/2 Jahren ohne Probleme. Was nutzt du denn als Spannungsversorgung? Ein USB Netzteil und dann mit USB Kabel an den Wemos.

Ok wenn auf der Platine als Basis ein Wemos ist, ist das in Ordnung. Ich kenne die amunra Platine nicht 

[Joker]

Ok wenn auf der Platine als Basis ein Wemos ist, ist das in Ordnung. Ich kenne die amunra Platine nicht 

Ah OK sorry. Ich dachte eigentlich ich hätte oben Wemos geschrieben, aber ich schrieb leider ESP8266  . Also gut, dann sollte das hardwaremäßig eigentlich passen.

Was nutzt du denn als Spannungsversorgung? Ein USB Netzteil und dann mit USB Kabel an den Wemos.

Ja genau. Ich nutze ein Netzteil mit dem ich den wemos per micro-USB versorge. Ist ein "kleines" mit 1A, aber das sollte für den wemos schon reichen oder?

Ich habe jetzt jedenfalls auf esp-link V2.2.3 umgeflashed. Ich beobachte mal wie es sich verhält und melde mich wieder.

[frank]

Bzgl. 3 sollte es WLAN Latenz sein müsste man wissen welche Telegramme das sind, also welche die tatsächlich so laufen:

HM-Modul -> ESP -> fhem -> ESP -> HM-Modul

Bei Telegrammen die das HM-Modul selbst abarbeiten sollte und max. eine Quittung an fhem schickt sollten da weniger zuschlagen...

Wie man das herausfinden kann...
...hmm, wahrscheinlich mit WireShark wenn man weiß was über die "Leitung" geht und in welcher Zeit das geschehen sein muss...

für einen groben vergleich kann man sich die keepAlive kommunikation anschauen.
mit "attr hmuart logIDs sys" bekommt man in fhem.log zyklisch eine meldung mit "roundtrip delay".
über notify mit "attr readLog 1" könnte man diese verzögerung loggen.

im list vom hmuart sieht man ebenfalls diese verzögerung. bei meinem hmuart auf einem pi3 der als fhem server dient liegt der wert meistens bei etwas mehr als 3ms.