[HowTo] HMUARTLGW im WLAN mit HM-MOD-RPI-PCB / ESP8266 (Wemos D1) und Tasmota

[Capu]

Nachdem ich regelmäsig Probleme mit einem von der Grundinstallation relativ weit entfernten Aussen-Bewegungsmelder (HM-SEN-MDIR-O-3) hatte, hab ich mich gestern mal an das Thema "Erweiterung meines Homematic Funknetzes) begeben.
Zuerst wollte ich ein weiteres HM-MOD-RPI-PCB mittels RPi Zero bzw. Zero 2 ins Netz einbinden, aber die sind gerade etwas schwer zu bekommen oder vom Preis total unaktraktiv.
Durch den Wiki Eintrag zum HM-MOD-RPI-PCB wurde ich dann auf die Möglichkeit gestossen das ganze mittels eines ESP8266 ins WLAN einzubinden.
Da die im Wiki genannte Software ESPLink outdated ist und die Threads zu ESPEasy/ESPMega mit Tips zur Installation teilweise schon sehr alt sind, hab ich mich dann gestern dazu entschlossen einen ganz anderen Weg zu probieren und bei Erfolg auch ein aktuelles HowTo zu schreiben.
Meiner Meinung nach ist der Weg sogar noch einfacher als sich mit ESPMega eine eigene Firmware zu kompilieren, da man auf schon fertige Binaries zurückgreifen kann. Im Fall von Tasmota zudem noch welche, die sehr gut supported sind und weiterentwickelt werden.

Schritt 1: Bastelarbeit Teil 1
- HM-MOD-RPI-PCB Bausatz zusammenlöten


Schritt 2: ESP8266 flashen
Auf einem Windows PC (mit Internetanbindung) ist der einfachste Weg Tasmota zu flashen den "TASMOTIZER zu verwenden.
- Tasmotizer herunterladen
- Wemos D1 mittels USB mit dem PC verbinden
- Tasmotizer öffen (siehe Bild). Der COM-Port wird sehr zuverlässig selber gefunden.
- Bei "Select Image" greifen wir direkt auf das aktuelle Release im Internet zu, wählen also die Checkbox "Release 10.1.0" und wählen aus dem Dropdown Menü die Version "tasmota-zbbridge.bin" aus.
- Da der Wemos ein "self-resetting" Device ist und wir den ESP vor dem flashen löschen wollen, werden auch noch die letzten beiden Checkboxen ausgewählt.

Die Version tasmota-zbbridge wird verwendet, da hier schon das ser2net Modul "TCP_Bridge" mitkompiliert wurde und man es sich so sparen kann eine eigene Version zu konfigurieren und zu kompilieren.

Nach dem erfolgreichen Flashvorgang startet der ESP automatisch neu.
Wir geben dem ESP ein wenig Zeit für den Reboot und das laden von Tasmota und klicken im Tasmotizer auf "Send config".
Im folgenden Fenster wählen wir "Wifi" mit der dazugehörigen Checkbox aus und geben die WLAN Daten für das gewünschte WLAN ein und bestätigen mit "Save".
Die Daten werden an den ESP gesendet und er startet neu und verbindet sich mit dem zuvor eingegebenen WLAN.
Nachdem wir dem ESP ein wenig Zeit gegeben haben Tasmota zu starten und sich mit dem WLAN zu verbinden, klicken wir im Tasmotizer auf "Get IP" und uns wird die aktuelle IP des ESP präsentiert.
- ESP vom PC trennen und auf anderem Wege (z.B. mit einem USB Netzteil) mit Strom versorgen.

Schritt 3: Tasmota konfigurieren
- Die eben über den Tasmotizer herausgefundene IP-Adresse öffnen wir nun im Webbrowser
- Im Tasmota Menü "Configuration" -> "Configure Module" auswählen und in der Modulauswahl den Modultyp "Generic (18)" auswählen und mit "Save" bestätigen

-> der ESP startet neu und nach eingen Sekunden befinden wir uns wieder im Tasmota Hauptmenü.

- Wir wechseln wieder in die Modulkonfiguration "Configuration" -> "Configure Module"
- Da ich mich der Einfachheit halber an die Pinbelegung aus dem Wiki gehalten habe (HM-Pin1 VCC 3.3V -> ESP 3V3, HM-Pin9 Gnd -> ESP G, HM-Pin8 RX -> ESP D8, HM-Pin 10 TX -> ESP D7),
müssen jetzt D7 und D8 des ESP in Tasmota konfiguriert werden. Bei D7 wählen wir "TCP Rx" und bei D8 "TCP Tx" aus. Nach bestätigen mit "Save" startet der ESP neu und wir gelangen ins Hauptmenü.

Schritt 4: TCP Bridge in Tasmota konfigurieren
Standardmäsig ist die TCP Bridge nach dem flashen noch nicht konfiguriert und aktiviert. Das holen wir nun nach.
- Wechseln in die Tasmota Console mit Auswahl von "Consoles" -> "Console" aus dem Hauptmenü heraus.

Man sieht nun die ESP Console in der alle 5 Minuten eine Statusmeldung ausgegeben wird und ein Eingabefeld.
- Setzen der seriellen Übertragungsrate mit Eingabe von

Code Auswählen Erweitern

TCPBaudRate 115200
mit "Enter" bestätigen. Die Datenrate von 115200 Baud ist vom HM-MOD-RPI-PCB vorgegeben.
- Starten der TCP Bridge mit

Code Auswählen Erweitern

TCPStart port,ip-adresse
Dabei ist "port" der IP-Port unter welcher das UART später erreichbar ist und "ip-adresse" die IP Adresse des FHEM Servers welcher die Verbindung herstellt. Verbindungsversuche von anderen IP Adressen werden abgelehnt.
Beispiel:

Code Auswählen Erweitern

TCPStart 8888,192.168.4.2
Die TCP Bridge lauscht auf Port "8888" und akzeptiert Verbindungen von der Adresse 192.168.4.2.
Die Eingabe wieder mit "Enter" bestätigen.

Die Tasmota Konsole bestätigt den Start der TCP Bridge.

Nach einem Neustart des ESP wäre die Bridge wieder deaktiviert, also muss sie quasi in den ESP Autostart gepackt werden. Dies kann mit s.g. Rules bewerkstelligt werden.
- Rule für die TCP Bridge erstellen und aktivieren
Ausgehend vom o.g. Beispiel geben wir in der Console

Code Auswählen Erweitern

Rule1 ON System#Boot do TCPStart 8888,192.168.4.2 endon
ein und bestätigen dies mit "Enter". Port und IP sollten natürlich an die eigenen Wünsche und Erfordernisse angepasst werden.
Nun nur noch die Rule aktivieren mit

Code Auswählen Erweitern

Rule1 1
und den ESP einmal neu starten.
Bei jedem Neustart wird jetzt die TCP Bridge mit den in der Rule hinterlegten Parametern gestartet.

ESP fertig!

Schritt 5: Bastelarbeiten Teil 2
- HM-Modul mit Wemos D1 verbinden
Wie schon erwähnt hab ich mich an die Pin- und Portbelegung aus dem Wiki gehalten.
Man kann die 2 Platinen direkt mit Drähten "Freiluftverdraten", ich hab mich aber für eine stabilere Lösung entschieden um ggf. auch mal schnell den ESP austauschen zu können. (siehe Bilder unten)
Hier nochmal die Pinbelegung:
HM-Pin1 VCC 3.3V -> ESP 3V3
HM-Pin9 Gnd -> ESP G
HM-Pin8 RX -> ESP D8
HM-Pin 10 TX -> ESP D7

Schritt 6: WLAN-HM-MOD-RPI-PCB in FHEM einbinden
Hier einfach ans Wiki halten, warum alles neu tippen was schon im Wiki steht
Je nach euren Wünschen und Bedürnissen als alleiniges IODev für Homematic, oder als zusätzliches Device mit einem virtuellen Controller (VCCU) einbinden.
Bei der Definition des Devices

Code Auswählen Erweitern

Define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>
ist die "IP-Adresse" natürlich die IP des ESP im WLAN und die "Portnummer" der Port welcher mit TCPStart im ESP konfiguriert wurde!

Da mein HM-Funkmodul mit der Firmwareversion 1.2.9 ankam, hab ich dieses auch gleich mit dem im Wiki beschrieben Weg mit einem Update versorgt (ja, über WLAN und dem ESP) und das hat super funktioniert.
Wenn euer WLAN in Ordnung ist und nicht eh schon aus dem letzten Loch pfeift, sollte es auch mit der Latenz kein Problem geben. Bisher konnte ich keinen WLAN oder ESP bedingten Abriss der Kommunikation feststellen und das ganze
funktioniert sehr stabil.

Vielleicht hilft dieses kleine HowTo ja dem ein oder anderen weiter.

Anmerkung zu meiner Platine: Natürlich schneid ich die noch kleiner wenn die Testphase abgeschlossen ist und pack das ganze in ein Gehäuse

[tndx]

Danke für die detaillierte Anleitung. Wollte ich auch schon immer mal ausprobieren, aber solange das mit ESPlink zuverlässig läuft, fehlte der entscheidende Trigger

Was das Kompaktmachen angeht, schau dir diese Platine an:
https://forum.fhem.de/index.php/topic,115222.0.html

Macht zwar auch nichts anderes, als die 4 Pins miteinander zu verbinden, aber doch deutlich kompakter, zumal man bei dem HM-MOD-RPI-PCB auf die Trägerplatine bei der Konstellation verzichten kann.

[Capu]

Danke für das Danke!
Ja, die Platine habe ich im Forum schon gesehn. Von der Größe her natürlich kaum zu schlagen. 
Aber zum einen wollte ich das Projekt gestern sofort umsetzen, zum anderen wollte ich bewusst beides "gesockelt" und den HM-MOD-RPI-PCB komplett haben,
für den Fall das man doch mal auf eine kabelgebundene Variante wechselt oder sonstige Ideen. Zusammenlöten geht immer besser als auseinander! 

Langzeitberichte was die Stabilität von Tasmota und den ESP angeht reiche ich natürlich nach. Hab grad erst ne uptime vom ESP von 18h, die aber Fehlermeldungsfrei im FHEM.

Wenn ich Zeit und Lust hab wird dann noch die Lochrasterplatine zurecht geschnitten und ein Gehäuse gezeichnet und gedruckt. Erstmal war wichtig das mich das Bewegungsmelder
nicht mehr nervt. Und das ist (erstmal) gelöst!

Nachtrag: Klar, wer ein laufendes ESPLink hat, der braucht nichts neues. Aber für User wie mich, die ESP's nur z.B. tasmotisieren und es nicht so mit selber Firmware bauen/kompilieren haben,
war das für mich die schnellere und einfachere Methode.

[Otto123]

Hi,

ich bin gespannt. Ich habe das mal  mit einem ESP32 und LAN probiert https://forum.fhem.de/index.php/topic,122643.msg1172069.html#msg1172069
Im Gegensatz zu anderen Anbindungen hat mir das nicht 100% gefallen.
Ich muss mir das nochmal anschauen.

Danke für Deine Beschreibung

Otto

[Capu]

Hi Otto,
ja, kenne den Thread. Hab ich gestern Abend auch gelesen. Werde das mit eventuellen Timing Problemen oder falschen Daten im Auge behalten.

Die einzige wirkliche Fehlermeldung die bisher kam

Code Auswählen Erweitern

2022.01.28 22:14:09 1: myWLAN_HmUART is against deletion (1 : myHmUART:ok,myWLAN_HmUART:disconnected), continuing with rereadcfg anyway
ist durch das händische einsortieren des neuen IODevs gemäß Wiki (VCCU) entstanden:

Solange kein Modul die Einträge in der fhem.cfg entsprechend einsortiert, muss diese Korrektur von Hand erfolgen. Dies ist einer der wenigen Fälle, wo direktes Editieren der fhem.cfg z.B. mit dem eingebautem Editor unumgänglich ist. Soll der im Standard-WEBinterface von FHEM eingebaute Editor verwendet werden, muss zuerst das Attribut

attr WEB editConfig 1

in FHEM gesetzt werden. Anschließend die kompletten define Blöcke mit allem was dazu gehört entsprechend in die empfohlene Struktur bringen. Datei sichern und rereadcfg eingeben.

Ist also nachvollziehbar.

Wirklich Bedenken hatte ich beim FW Update des HM-MOD-RPI-PCB über den Weg, aber Versuch macht klu(ch/)g.

Code Auswählen Erweitern

2022.01.28 22:19:20 1: HMUARTLGW myWLAN_HmUART starting firmware upgrade
2022.01.28 22:19:45 1: HMUARTLGW myWLAN_HmUART firmware update successfull
Das war absolut kein Problem und ging auch fix.

[tndx]

Ist zwar OT, aber mit einem WT32 ginge auch diese Variante:
https://github.com/andyboeh/esphome-hmlgw

Lt. Beschreibung sollte es auch über WLAN funktionieren.

Vorteil: geht nicht nur mit CUL_HM, sondern auch mit "echten" CCUs.

[Capu]

Echte CCUs? Was ist das denn? 

Ok, das ist für CCU-User natürlich ein massiver Vorteil.
Und wie das immer so ist. Solche GITs oder Threads oder Blogs findet man erst wenn man selber was zusammen gebastelt hat. Murphys Law!

[Capu]

Zwischenfazit:
Der ESP läuft seit knapp einer Woche ohne Probleme und hat wie gewünscht meinen HM-Funkbereich erweitert.
Bei allen HM Geräten ist nur die VCCU als IOGrp eingetragen. 12 Geräte haben sich daraufhin für den neuen "AP" entschieden, 27 sind beim alten Kommunikationsweg geblieben.

Nachdem ich die Doku oben geschrieben hatte, hab ich mich natürlich weiter damit beschäftigt.
Natürlich ist das "roundtrip delay" bei dem Modul direkt auf dem Zentral-Raspi geringer und weniger schwankend.
raspiUART: ~ 0.0029 - 0.0031
wlanUART: ~ 0.0380 - 0.0480 (out-of-the-box)

Dann hab ich mich ein wenig mit den Themen powersaving von Tasmota beschäftigt. Da war mir noch nicht so ganz klar, das ich eigentlich 2 Dinge im Blick behalten muss.
Tasmota UND den ArduinoCore der darunter liegt und quasi das BIOS des ESP ist, während Tasmota eher das Betriebssystem ist.
Lange Rede kurzer Sinn, powersaving reduzieren "JA", sleep time auf 0 setzen "NEIN"!!
Wer da tiefer Einsteigen möchte kann sich das Thema "dynamic sleep" anschauen.

Tuning:
Durch verändern des "sleep" Wertes in der Tasmota Konsole konnte ich das roundtrip-delay positiv beeinflussen.
Tasmota Standardwert ist:

Code Auswählen Erweitern

sleep 50
Habe bei meinem ESP die Werte Stück für Stück runter gesetzt und bin letztendlich bei

Code Auswählen Erweitern

sleep 10
geblieben.

wlanUART: ~ 0.0085 - 0.0150 (aktuell nach tasmota tweaking)


Eine kleine Sache war dann doch ein Problem in meiner Umgebung:
In einem Raum nutze ich ein Xiaomi (Zigbee) Temperatur-/Luftfeuchtesensor als externen Temperaturgeber für ein HM-CC-RT-DN (mit virt.Kanal und allem drum und dran).
Dieses Konstrukt funktioniert wenn es läuft sehr gut, ist aber was die Timings angeht etwas... nennen wir es mal fragil.
Also sich das Thermostat entschlossen hatte lieber mit dem WLAN-Modul zu kommunizieren, funktionierte das ganze Konstrukt nicht mehr und am Thermostat kamen die Temperaturwerte nicht an.
Das Problem lies sich aber durch verändern des IOGrp Wertes im Thermostat leicht beheben. Durch

Code Auswählen Erweitern

set attr thermostat IOGrp VCCU:UART
hab ich dem Thermostat ein bevorzugtes IODev mitgegeben, es funkt wieder mit dem Raspi-UART und es funktioniert wieder.

Mittlerweile ist die Platine auch in ein Gehäuse umgezogen (siehe Anhang) und wird bei mir so in Betrieb bleiben

[Capu]

Nach 7 Monaten Betrieb hier noch ein abschliessendes Fazit.
Seit Anfang Februar läuft der ESP mit dem HM-MOD-RPI-PCB mit den abschliessenden Anpassung aus dem letzten Post bei mir im Dauereinsatz.
Probleme bzgl. der Antwort- bzw. Reaktionszeiten konnten keine festgestellt werden.
Den "assigned IDs" nach haben sich meine HM Geräte interessantweise genau 50:50 auf beide Gateways aufgeteilt, das ist wohl aber eher Zufall.
Wie beschrieben wurde nur ein Thermostat fix auf ein GW gebunden. Der Rest der Geräte entscheidet selber.

Fazit:
Hat sich für mich gelohnt, war ein überschaubarer Aufwand, dank Tasmota auch ohne große Kenntnis von ESP Programmierung sehr einfach umzusetzen
und funktioniert sehr gut.

[Otto123]

Das klingt insgesamt gut - ich habe den Thread mal im Wiki verlinkt.

[ms_steini]

hm, irgendwie funktioniert das bei mir nicht,
flaschen geht, send config geht auch...

aber bei get IP  kommt nur xx.xx.xx.xx

was mache ich falsch ??   (SSID und Passwort habe ich natürlich kontrolliert)

[steffen83]

Dann Connect dich Mal auf die ssid tasmota.... Und gehe dann dort auf die 192.168.4.1 und Stelle darüber dein WLAN ein

[xray]

Ich habe eben auch 2x probiert das zbbridge Images auf den Wemos zu flashen und hatte auch Probleme mit dem WiFi.
Folgendes habe ich gefunden:
https://github.com/arendst/Tasmota/issues/11420
Zwar alt, könnte aber daran liegen. Ich teste es am WE weiter...