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.
2018.10.29 05:46:03 1: HMUARTLGW HMUARTWIFI1 frame with wrong length received: 23, should: 22: FD0012011805000038D5847036C2B000000000BE31537FDF
2.
2018.10.29 06:53:24 1: HMUARTLGW HMUARTWIFI1 invalid checksum received, dropping frame (FD001201D305000031AF865A31DC27000000A0724D4EF9)!
3.
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?
Moin
Haben die, bzw. der neue, HMUART auch alle die aktuelle FW von Dir aufgespielt bekommen?
Gruss Christoph
Yepp, 1.4.1 ist drauf auf allen HMUARTs :)
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
Zitat von: MadMax-FHEM am 29 Oktober 2018, 23:03:17
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").
Zitat von: MadMax-FHEM am 29 Oktober 2018, 23:03:17
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.
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
Zitat von: Joker am 29 Oktober 2018, 12:49:04
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.
ZitatVerwendet 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
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:
ZitatWill 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?
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?
Sagen wir mal so, nicht dass ich wüßte ;D
Habe zumindest beim bestücken und auf den Fotos in den entsprechenden Anleitungen nichts dergleichen gesehen.
:o
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.
Zitat von: Joker am 30 Oktober 2018, 14:25:42
Sagen wir mal so, nicht dass ich wüßte ;D
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.
Zitat von: gloob am 30 Oktober 2018, 14:54:09
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 :-[
Zitat von: Otto123 am 30 Oktober 2018, 15:05:53
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 :P. Also gut, dann sollte das hardwaremäßig eigentlich passen.
Zitat von: gloob am 30 Oktober 2018, 14:54:09Was 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.
Zitat von: MadMax-FHEM am 30 Oktober 2018, 13:44:18
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.
Zitat von: frank am 31 Oktober 2018, 10:00:58
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.
Danke!
Gut zu wissen!
Aktuell hängt das Modul an meinem Testsysten und da dran 2 oder 3 HM-Geräte die meist nix tun ;)
Ist als Ersatz falls mein HM-CFG-USB mal kaputt gehen sollte...
Gruß, Joachim
Zitat von: frank am 31 Oktober 2018, 10:00:58
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.
Sehr gute Info! Werde ich mir mal heute abend ansehen. Über WLAN dürfte die Verzögerung vermutlich schon deutlich höher sein.
Zwischenmeldung übrigens: Seit dem Wechsel auf esp-link gestern abend keine der Fehlermeldungen mehr. Sieht aktuell wirklich danach aus dass ESPEasy bzw. der Ser2Net Server das Problem war. Ärgerlich, weil eigentlich war mir esp-link von Anfang an sympathischer, und ich habe ESPEasy nur wegen dem OLED-Display genommen.
Rückmeldung: Seit dem Wechsel auf esp-link habe ich keine Probleme mehr :)
Danke für alle Tips!
Habe mir die Round-Trips noch angeschaut, also diese sind bei mir wie folgt:
HMUART direkt an Raspi: ca. 3ms
HMUART an Raspi via socat: ca. 6.5ms
HMUART an wemos D1: ca. 60ms
60ms ist schon viel, aber ich glaube auch nicht ungewöhnlich für WLAN (?).
wie ist denn bei dir der weg des signals über wlan?
wlan intern oder usbstick beim pi? vom pi wlan direkt an wemos oder erst über switch/router zum zentralen wlan AP?
oder sogar weitere wlan strecken über repeater?
Bei mir ist roundtrip delay: 0.0030 am HMUART Modul lokal auf raspi und
Am ESP schwankt das zwischen maximal
ESP Wlan roundtrip delay: 0.3005 (minimum 0.150)
Pi per LAN am Router/Switch und ESP über ein Wlan direkt zum Router
ZitatESP Wlan roundtrip delay: 0.3005 (minimum 0.150)
150-300ms ist aber nicht schön, denke ich.
gibt es da nicht viele resends, etc. mit den devices?
Bisher nichts gemerkt, muss ich mal genauer beobachten. Vor allem warum das soviel ist?
Zitat von: frank am 02 November 2018, 08:30:06
wie ist denn bei dir der weg des signals über wlan?
wlan intern oder usbstick beim pi? vom pi wlan direkt an wemos oder erst über switch/router zum zentralen wlan AP?
oder sogar weitere wlan strecken über repeater?
Das WLAN vom Pi benutze ich nirgendwo. Die Pi's sind beide über LAN angebunden an einem zentralen Switch, an dem auch die Fritzbox hängt. Der Wemos hängt im WLAN von der Fritzbox.
Hi,
ich habe auf meinem ESP32 einen Roundtrip von 191ms und auch temp. resendings
die allerdings klar auf ein Problem in meiner Infrastruktur zurückzuführen sind.
Derzeit habe ich ein Problem im dLAN und will deshalb demnächst auf Mesh umstellen.
Irgendwann habe ich gemerkt, dass auch andere Geräte am dLAN/WLan Knochen zur
selben Zeit kurz droppen. (Hab ich aber auch länger gesucht).
Das kann evtl. alles Mögliche sein, von wer sendet alles auf dem WLan Kanal
bis einen "Fitzer" im Switch, oder ... hatte ich leider alles schon.
Die Roundtrip Zeiten vom ESP wundern mich jetzt nicht so, hängt für
mich einiges von der SW auf dem ESP ab. Z.B. ESP Easy hat noch einen
Webserver am Laufen, der auch "gecycled" werden muss.
Meinungen?
:)
linuxpaul