HMUART-Modul per Terminal ansprechen (Funktionstest?)

[Pfriemler]

Mein HM-WLAN-Interface (WemosD1/ESP-link) fing vor ein paar Wochen damit an, das Log zuzumüllen mit

Code Auswählen Erweitern

2021.07.01 11:58:46 1: HMUARTLGW HMWLAN1 did not respond for the 1. time, resending
2021.07.01 11:58:49 1: HMUARTLGW HMWLAN1 did not respond for the 2. time, resending
2021.07.01 11:58:52 1: HMUARTLGW HMWLAN1 did not respond for the 3. time, resending
2021.07.01 11:58:55 1: HMUARTLGW HMWLAN1 did not respond after all, reopening
Dabei handelt es sich aber dieses Mal nicht um ein FHEM-Problem. Die Meldungen erscheinen genau so auch, wenn man das HM-Modul vom Wemos abzieht. Der Wemos/ESP-Link sind auch richtig konfiguriert, Befehle kann ich testweise mit einer Telnet-Verbindung am richtigen Pin abgreifen. Es scheint, dass das Modul seinen Dienst einfach und ohne erkennbaren äußeren Grund eingestellt hat.

In Unkenntnis der wahren und richtigen Prozesse (ich bin nicht so gut darin mich durch Quellcode zu wühlen) kann ich erkennen, dass beim Init aus FHEM nach einem

Code Auswählen Erweitern

Accept port 23, conn=0x3fff72e0, pool slot 0
noch dreimal die Bytes

Code Auswählen Erweitern

FD 00 03 00 01 00 9E 03
gesendet werden, ehe der Kram ohne erfolgte Antwort erneut beginnt.

Was kann mit dem Modul passiert sein und gibt es eine Möglichkeit, über irgendwelche Terminal-Befehle mit ihm zu reden? Ich könnte derzeit noch versuchen, das Ding über einen USB-seriell-Adapter an den FHEM-Server zu hängen und ein Firmwareupdate einzuspielen.

Jeder Tipp ist willkommen.

[frank]

ich würde das hmuart modul direkt am gpio von einem pi testen.

[Pfriemler]

Ich wusste das das kommt ...

Habe derweil auch das hier gefunden: https://forum.fhem.de/index.php/topic,54511.msg1045020.html#msg1045020
Das liest sich doch praktisch genauso wie bei mir!

Interessant ist dabei allerdings, dass mein bockendes Modul jetzt drei Wochen auf dem Tisch gelegen hat, da ist nichts mehr mit Restladungen. Dennoch: Ich checke mal die Versorgungsspannungen und versuche die Firmware zu flashen. Erneut zu flashen. Denn die 1.4.1. ist schon lange drauf gewesen, anders als es im verlinkten Thread war.

Ich schaue morgen mal mit Oszi auf die Signale. Wenn das alles nichts bringt, werde ich wohl mein derzeit übriges Pi-Modul schlachten und die Module tauschen.

Hatte nur gehofft, dass es sowas wie einen Basisbefehlessatz gibt, den man ersatzweise an das Modul probieren kann um zu sehen, ob sich da überhaupt irgendwas tut. Beim Einstromen tut es jedenfalls nichts.senden, das habe ich auch schon gecheckt.


Bei ESP-Link bleibt ja so oder so das Problem, dass auch die Statusmeldungen über den Verbindungsaufbau (sei es über HMUARTLGW oder per Telnet), selbst bei "swapped", an das Modul "gemeldet" werden. Das ist meines Wissens am GPIO nicht so.

[Pfriemler]

Also gut, frank ... nacktes Modul an einen USB-Seriell-Wandler, an den Pi, "by-ID" ausgelesen und in die DEF eingetragen, wird initialisiert, ist stabil. Gleiche S/N und Firmware gemeldet wie einst auf dem fraglichen Wemos-D1.
Ein Gerät aus der VCCU entfernt und exklusiv an das neue IO gebunden - lesen funktioniert, Schalten nicht.
(facepalm)
attr hmkey nachgetragen -> arbeitet einwandfrei.
WTF!!!
Zurück aufs Wemos  - geht nicht.

[gestein]

Hallo,

ich habe zwar eine etwas andere Konfiguration, aber im Endeffekt tritt bei mir der gleiche Effekt auf.

Ich habe das HMUART-Modul per ser2net und per LAN-Anschluss über Devolo Magic 2 in fhem eingebunden.
Auf WiFi habe ich bewusst verzichtet, da das bei mir schon öfters Probleme gemacht hat.
Das hat eigentlich sehr gut funktioniert.
Seit einiger Zeit kämpfe ich aber damit, dass das HMUARTLGW-Device (00_HMUARTLGW.pm:0.188380/2019-03-09) in fhem immer wieder auf disconnected und dann auf opened geht.
Das passiert 5-20x innerhalb kürzester Zeit und dann ist wieder länger Ruhe - manchmal für Stunden. Dann geht es wieder los.
In der Web-Oberfläche sieht man das meist gar nicht, weil es so schnell ist.
Aber die log-Einträge sind die gleichen wie bei Pfriemler.

Code Auswählen Erweitern

2021.07.01 07:46:49.472 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2021.07.01 07:46:52.483 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2021.07.01 07:46:58.350 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2021.07.01 07:47:01.384 1: HMUARTLGW HmUART2 did not respond after all, reopening


Anscheinend bricht kurzzeitig die Verbindung ab.
Auf dem Devolo hängt per LAN nur mehr ein Sonos, per Wifi ca. 10 Shellys.
Eigentlich dachte ich bis dato, dass es vielleicht ein Thema einer neuen Version von Treibern ist.
Zumindest den raspberry zero habe ich ganz frisch aufgesetzt.
Aber mir fehlt das Wissen um hier tiefer einzutauchen.

lg, Gerhard

[frank]

LAN-Anschluss über Devolo Magic 2

sind beide dosen auf der selben phase?

[gestein]

Ja, sind sie. Aber die Leitungen sind lang und dazwischen gibt es etliche Abzweigdosen.
Trotzdem zeigt Devolo eine relativ gute Verbindung (320MBit/280MBit).
Kann natürlich Marketing sein.

Lg, Gerhard

[Pfriemler]

Also mein Modul läuft seit eben wieder, und die Lösung des Problems war so einfach, dass es schon wieder weh tut.

Zurück auf dem WEMOS konnte ich mit meinem neuen Spielzeug (Micsig STO1104C) und einem Steckbrett die Kommunikation belauschen und auch dekodieren. Stromversorgung und Logikpegel sind über jeden Zweifel erhaben. Allein das HM-Modul sagt keinen Mucks und ignoriert alle Befehle.
Dann fiel mir bei der Konfigurationsübersicht auf dem ESP-link die serial baud rate auf: 57600. Moment - in der Def für den USB-Anschluss tauchte doch @115200 auf!

Code Auswählen Erweitern

<ip-des-esp-link>/console/baud?rate=115200

und zack - es läuft alles, init ok beim ersten Versuch, Daten werden ausgetauscht, FHEM ist zufrieden.

Jetzt frage ich mich, was auf dem ESP-link die Änderung der Baudrate verursacht hat...

[Otto123]

Jetzt frage ich mich, was auf dem ESP-link die Änderung der Baudrate verursacht hat...

Der Admin oder ein Bit wurde von einem Strahlen Teilchen getroffen...

[Pfriemler]

Der Admin erfreut sich noch immer bester Gesundheit.  Der hat auch nichts gemacht.
Mal ernstlich: Ich habe eine Weile nach Einrichtungshinweisen zu ESP-link und einem HMUART gesucht. Es wird gut erklärt wozu SWAP gut ist, man findet Hinweise dazu dass es mit ESPeasy schwierig sein kann weil 57600 nicht unterstützt werden - es dann aber trotzdem meistens geht. Ich kann auch durch alle Presets gehen und neustarten: nur die Pinzuweisung wird geändert, die Baudrate bleibt bestehen. Angeblich werden bei Nichtantwort auch andere Baudraten probiert. Es ist alles etwas verwirrend. Es ist nicht aufgeführt, welche Baudrate verwendet wird, wenn man ESP-link das erste Mal nutzt.

Ich frage mich jetzt, ob das Modul vielleicht schon länger auf 57600 und halbgar lief (Ausfälle hatte ich schon hin und wieder und ich meine auch einen Bericht gelesen zu haben wo jemand mit 57600 eine Verbindung hatte, wenn auch sehr unzuverlässig). Offenbar wird in allen Anleitungen davon ausgegangen dass die Baudrate nicht einzustellen ist.