[Gelöst] HM-MOD-RPI-PCB-ESP8266 - MISSING ACK (ersetzt einen HMLAN - defekt)

[zakesh]

Hallo zusammen,

nachdem mein HM-CFG-LAN defekt ging und auch nicht durch Austausch der Kondensatoren wieder in Gang zu setzen war, habe ich ihn durch einen HM-MOD-RPI-PCB ersetzt, welcher via eines ESP8266 mit FHEM kommuniziert. Eingerichtet nach der Anleitung "HM-MOD-UART-Gateway-V1.0.pdf", via EspEasy Serial Server. (Etwas älter ist die EspEasy Firmware.)
Den HMLAN1 habe ich in der fhem.cfg auskommentiert und durch das HM-MOD-RPI-PCB-ESP8266 ersetzt; das device heißt nun also HMLAN1, in der Hoffnung dass es dann möglichst wenig Probleme gibt, habe ich den Namen gleich gelassen.
define HMLAN1 HMUARTLGW uart://192.168.178.38:23
(...weitere attribute....)
Eine VCCU war vorher schon eingerichtet und sorgt dafür dass die hmId die selbe wie früher ist. (Das HMUARTLGW ist das einzige HM IO Gerät.)
Ein PRESENCE device habe ich angelegt, das pingt den ESP jede Minute. Bevor ich das gemacht hatte, kamen die Infos von den HM Komponenten, also z.B. die Temperaturen von den Heizungsreglern nach einer guten Minute nicht mehr an, bis man mal wieder selbst ein Sende-Kommando ausgelöst hatte.

Nun ist das Problem dass die Kommunikation Teilweise aber nicht zufriedenstellend klappt. D.h. die Rolladenaktoren funktionieren noch am besten mit etwas mehr Verzögerung wie früher; aber sie führen die Kommandos am zuverlässigsten aus.
Die Heizungsregler verarbeiten CMDs_pending so gut wie nie. Wenn ich aber oft genug auf burstXmit klicke, gehen die Kommandos langsam durch.
MISSING ACK habe ich öfter mal im Status.
Mich wundert dass es teilweise aber nicht ganz funktioniert. Das Gerät ist an der selben stelle wie der HMLAN war und auch die Antennenausrichtung ist gleich. Fast alle angelernten HM Geräte haben einen RSSI Wert > -80. Der ESP ist via WLAN im Netzwerk, der Accesspoint ist in einem anderen Stock, aber die Verbindung ist gut - pings gehen in wenigen ( < 5 ) Millisekunden durch. Ich könnte noch einen alten Raspberry Pi 1 her nehmen und das Modul mal darauf machen und über Kabel ins LAN und mit FHEM (Läuft auf einem Raspberry Pi 2) Verbinden. Könnten es Timing-Probleme sein, gibt es diese überhaupt mit dem Modul? Ich habe alle möglichen Threads dazu durchgelesen und konnte nichts finden.

AES hatte ich meiner Erinnerung nach direkt bei der Einrichtung des HMLAN deaktiviert und habe dazu auch nichts in meiner fhem.cfg. Muss ich das auf dem HM-MOD-RPI-PCB-ESP8266 extra noch deaktivieren?
Hat jemand eine Idee was es sein könnte?

Im Log gibt es ab und an mal:
HMUARTLGW HMLAN1 did not respond for the 1. time, resending
(2. time, resending     kommt nur nach einem Neustart mal vor)
HMUARTLGW HMLAN1 invalid checksum received, dropping frame (FD0005006104022076F8)!
HMUARTLGW HMLAN1 resend failed too often, dropping packet: 01 0200000049A0114BACA93ACFAB0201C80000

[Otto123]

Hi,

muss es "EspEasy Serial Server" sein? Ich habe das ganze mit ESP Link (gleiches PDF) laufen und das funktioniert einwandfrei.

Wichtig ist auch, das Wlan stressfrei läuft.

Gruß Otto

[zakesh]

Hi,

muss es "EspEasy Serial Server" sein? Ich habe das ganze mit ESP Link (gleiches PDF) laufen und das funktioniert einwandfrei.

Wichtig ist auch, das Wlan stressfrei läuft.

Gruß Otto

Das hat geholfen!
Nein es muss kein EspEasy sein; wurde es nur, da ich bereits einige davon am Laufen habe und die immer super funktionierten.
Vor dem flashen von esp-link habe ich es noch mal an einer anderen Position näher am AccessPoint versucht, aber das hat keinen Unterschied gemacht. Es lag also an der (alten) EspEasy Firmware, esp-link tat sofort perfekt!
Vielleicht sollte diese Info in ein Wiki - wobei ich eben auf die schnelle nur das zum HM-MOD-RPI-PCB und kein passendes gefunden habe; ist ja eigentlich nur eine uart bridge.

Vielen Dank Otto!

[teichtaucher]

Hallo, ich muss mal diesen Threat aufgreifen. Ich habe einen Wemos D1 mini mit dem HM-MOD-RPI-PCB am Laufen (nach der Anleitung HM-MOD-UART-Gateway-V1.0.pdf). Auf dem Wemos läuft ESPEasy. Allerdings habe ich auch die Probleme mit invalid checksums (HMUARTLGW WemosGateway invalid checksum received, dropping frame...) im Logfile.
Ich habe jetzt überlegt, ob ich auf ESPlink umsteige. Was mich nur wundert, in dem PDF in Kapitel 4.3 bei der Konfiguration steht nur wie das WLAN eingerichtet wird, aber sehr wenig zur Serial Konfiguration. Bei ESPEasy steht dass das ganze auf TCP Port 23 und dass die Baudrate auf 115200 gesetzt werden muss. Reicht es bei ESPlink wirklich aus, dass man die UART-Pins auf "swapped" stellt? Ist der Rest der Settings schon fest eincodiert?
Noch ne Frage: In dem PDF wird auf die ESPlink Version v2.2.3 verwiesen. Ist die noch aktuell oder gibt es was besseres?

[Otto123]

Die Baudrate ergibt sich vom UART Modul, die muss auf 115200 stehen. Port 23 war glaube ich default( finde ich keine Einstellung)
Version ist 2.2.3 -> läuft. Besser geht nicht ...

Mach ESP-Link einfach drauf, die Oberfläche ist relativ sprechend.

Gruß Otto

[teichtaucher]

Hi, danke für die schnelle Antwort! Mit UART Modul meinst du das HMUARTLGW in FHEM selbst? In dem PDF finde ich sonst nichts. Und noch ne Frage: Pins D7 und D8 passen noch beim Wemos?

[Otto123]

Nein mit dem UART Modul meine ich die Hardware. Und die wird an die serielle Schnittstelle angeschlossen und diese muss mit 115200 betrieben werden.

GPIO13 und 15 - die zweite serielle Schnittstelle des ESP8266. D7 RX, D8 TX

Beachte das serielle Schnittstellen kreuzweise verbunden werden! RX->TX TX->RX

Gruß Otto

[teichtaucher]

Hi, danke nochmal für die Klärung. Nur für die Mitleser: Ich habe es so gemacht wie in dem PDF beschrieben. Die Verkabelung hat noch gepasst, D7 und D8 als serielle Schnittstelle. Die Baudrate hat auch gepasst. Ich musste nicht (wie bei ESPEasy) die Baudrate ändern. Hat alles gepasst. Bin mal gespannt ob jetzt alles stabil läuft.
Habe bei mir alles in so einem Schalterkasten untergebracht:
https://www.obi.de/abzweigkasten/abzweigkasten-aufputz-75-mm-x-45-mm-grau-ip54/p/1612837

[teichtaucher]

Sorry, aber ich habe nochmal ne Frage: Bei mir läuft jetzt seit einem Tag der Wemos D1 mini mit esp-link stabil. Ich habe keine Einträge mehr im log von wegen invalid checksum. Was mir nur wundert: ich habe eine Readingsgroup die mir zeigt, welches HM device mit welchem IODev zuletzt gesprochen hat. Außerdem werden die RSSI Werte von HMLAN und dem HMUARTLGW. Von den RSSI Werten steht der HMUARTLGW besser da (weil zentraler platziert). Trotzdem sprechen jetzt so gut wie alle HM devices mit dem HMLAN. Vorher mit ESPEasy war das noch gut verteilt - ein Teil der devices hat mit dem HMLAN gesprochen, ein anderer mit dem HMUARTLGW. Wie entscheidet denn die VCCU, welches IODev verwendet wird? Habe nirgendwo ein preferred IODev definiert. Die VCCU soll das dynamisch entscheiden.
Und nur zur Info: in FHEM sieht alles OK aus beim HMUARTLGW. Die VCCU meldet auch beim HMUARTLGW dass die Verbindung besteht und alles in Ordnung ist.