Inbetriebnahme eines HM-MOD-UART mit ESPEasy

[chons]

In diesem Thread wird diskutiert/getestet, ob der Betrieb des HM-MOD-UART Adapters mit ESPEasy stabil möglich ist.

1. Erkenntnis: 
Die ESPEasy Software Serial Server Plugin (_P130_SSSRV.ino) Implementierung basiert auf Software Serial Lib, welche zuverlässig bis zu 57600 Baud funktioniert. Der HM-MOD-UART Adapter muss jedoch mit 115200 betrieben werden – das kann funktionieren,  muss wie in diesem Fall nicht immer bzw. zuverlässig und stabil.

2. Erkenntnis:
Betrieb mit ESPEasy Bordmitteln (UARTx) – ,,läuft" (bisher keine Langzeiterfahrung)
Schaltplan

Code Auswählen Erweitern

HMUART      WeMos D1 mini
   Rx ->   Tx
   Tx ->   Rx
ESPEasy WebUI Einstellungen ,,Devices" (siehe Screenshot ,,Serial Server")
Einen Serial Server konfigurieren siehe Screenshot ,,Serial Server"

ESPEasy WebUI Einstellungen ,,Tools" (siehe Screenshot ,,Tools")
  ,,Open Advanced settings" -> Serial Settings -> Enable Serial port ,,aktivieren" falls dies nicht bereits aktiv ist (Default: aktiv) und ,,Baud Rate" kontrollieren ,,115200". Mit ,,submit" bestätigen.
  ,,Log Settings" -> ,,alle Level" auf ,,0" stellen

ToDo:
  OLED und Sensoren auf Funktion testen. - 24h Test erfolgreich.

3. Erkenntnis: (Stand: 16.08.2017)
Swap Serial Läuft: Erknetnisse und Implementierung folgt.

ToDo:
- [Optional Prio:low] Serial swap implementieren und testen, um das Modul an GPIOs D7/D8 betreiben zu können.

[Rampler]

Hallo Chons,
klar, mache ich morgen, im Prinzip habe ich das schonmal gemacht, allerdings ohne das LOGLEVEL "alle" auf 0 waren, sondern nur der Serial Log level. Bin mal gespannt ...
Ich denke, das ist ein Schreibfehler oder:

Code Auswählen Erweitern

Offene Themen
- [Optional Prio:low] Serial swap implementieren und testen, um das Modul an GPIOs D8/D9 betreiben zu können.

sollte wohl eher so sein:
Serial swap implementieren und testen, um das Modul an GPIOs D7/D8 betreiben zu können.
(damit es kompatibel zu ESP-LINK bleibt...)

VG
Klaus

[Rampler]

Hallo Chons,
leider funktioniert der HMUART über Tx/Rx bei mir nicht !
Tx des HMUART auf RX des ESP und vice versa.
Alle Loglevel auf 0 gestellt.
Der Serial Port ist enabled.
Software ist die  GIT version:   v2.0.0-dev11.
Verdahtung mehrmals geprüft...
Adapter ist laut Fhem opened, und die cond wechselt ständig von init auf disconneted.
Was mich wundert, dass ich trotzdem noch Meldungen im Log des ESP sehe (obwohl alle Log Level auf 0 stehen):

Code Auswählen Erweitern

278 : INIT : Booting version: v2.0.0-dev11
279 : INIT : Warm boot #1
279 : FS : Mounting...
303 : FS : Mount successful, used 72288 bytes of 957314
Habe mal ein paar Screenshots angehängt...
Scheinbar habe ich Sch...e an den Fingern ...
VG
Klaus

[Rampler]

Habe mal die serielle Schnittstelle vom Arduion IDE aktiviert, da sieht man deutlich, dass bei jedem init vom FHEM auch Daten am ESP ankommen.

Code Auswählen Erweitern

INIT : Booting version: v2.0.0-dev11
INIT : Warm boot #2
FS   : Mounting...
FS   : Mount successful, used 72288 bytes of 957314
sonderzeichen ....

[Rampler]

So wieder auf ESP-LINK mit D7/D8, läuft einwandfrei.
Habe jetzt mal RX/TX D7/D8 mit Jumper versehen, dann kann ich leichter wechseln...
Hast Du evtl. noch irgendwelche Pins beschaltet ?
VG
Klaus

[chons]

Serial swap implementieren und testen, um das Modul an GPIOs D7/D8 betreiben zu können.
(damit es kompatibel zu ESP-LINK bleibt...)

ja, richtig und im ersten Post angepasst.

Software ist die  GIT version:   v2.0.0-dev11.

Ich habe mit der git Version getestet.... siehe meine Version anbei - damit wir zumindest auf der gleichen Version testen.

Was mich wundert, dass ich trotzdem noch Meldungen im Log des ESP sehe (obwohl alle Log Level auf 0 stehen):

Code Auswählen Erweitern

278 : INIT : Booting version: v2.0.0-dev11
279 : INIT : Warm boot #1
279 : FS : Mounting...
303 : FS : Mount successful, used 72288 bytes of 957314

Das sind die Boot Meldung, die sind ok, da in dem Moment noch keine "log-Settings" greifen. Bei mir sieht es nach einem Reset wie auf dem Screenshot aus.

Mein Testaufbau (gestern auf die Schnelle zusammengezimmert) ist (siehe Anhang) gestern Nacht und den ganzen Tag ohne Fehlermeldungen/Abstürze durchgelaufen.
Ich spiele alles noch einmal durch, um alles zu verifizieren - da fehlte gestern die Zeit dafür.

Du könntest in der Zwischenzeit meine Version probieren, wenn Du magst.

[Rampler]

Hallo Chons,
laut Deinem Testaufbau hast Du keine Steckerleiste verbaut !!
Habe jetzt mal die beiden 1k Widerstände auf der Platine mit der Buchsenleiste überbrückt, und siehe da, es funktioniert.
Hät ich nicht gedacht...
So jetzt kann ich weiter testen ..
VG
Klaus

[chons]

Ja, ELV geht auf Nummer sicher...
Manchmal ist weniger mehr.

Ich habe mein Test erweitert (siehe Anhang).
- HM-UART-Adapter (ohne Anhängerkupplung) - Produktiv!
- OLED SSD1306 (Stand alone)
- OLED SDD1306 (PushButton)
- BME280 (Stand alone)

[Rampler]

Habe nun auch den HMUART via ESPEASY produktiv im Einsatz.
Der DHT22 Sensor liefert zuverlässig via MQTT seine Werte.
Der ESP steht an gleicher Stelle wie vorher mit ESP-Link.
Ab und an bekomme ich folgende Meldung:

Code Auswählen Erweitern

2017.08.16 18:42:24 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
Merke aber keine funktionale Störung, bis jetzt.
Die Checksum Fehler (mit Software Serail Server) sind Geschichte !
Schade, dass in diesem Thread
https://forum.fhem.de/index.php/topic,56606.0.html
die Information nicht gewünscht ist, würde bestimmt dem einen oder anderen nutzen.
Habe schon versucht die Meldungen mit verbose  bei dem HMUART zu verhindern, jedoch sind die Meldungen mit Log Level 1 kodiert, folglich müßte ich dann verbose 0 angeben. Doch dann würde ich garnichts mehr sehen.

Die o.g. Meldung erscheint bei Dir nicht ?

VG
Klaus

[chons]

Zunächst einmal:
Danke ,,Klaus"
für deine Kooperation und Test Bereitschaft - ,,das" hat bisher geholfen, dass die bisherigen Erkenntnisse erfolgreich verifiziert  werden konnten.

News: 3. Erkenntnis ,,ESPEasy ,,Swap" Serial funktioniert (keine Langzeit Erfahrung Stand 08:2017).
Ich musste ESPEasy minimal (kein Hexerei/Raketenwissenschaft) umbauen (Details folgen).
Ich muss nur noch die Abhängigkeiten checken und einige Tests durchführen.
Vielmehr muss ich recherchieren, warum diese Option eigentlich per Default nicht implementiert ist – bisher habe ich nur das hier gefunden und verstehe nicht, warum man das nicht weiterverfolgt hat?
@Klaus(Ramlper): Antworten auf deine bisherigen Erkenntnisse folgen (Zeitmangel) ...

P.S: Die bisherige Implementierung sieht wie im Anhang aus (Die Swap Option wandert evtl. in das Ser2Srv Modul – das muss ich noch, wie bereits beschrieben testen).

P.P.S: Wegen den HMUART Meldungen würde ich mir weniger Sorgen machen – beobachte das!

Sorry - kurz angebunden

[Rampler]

Habe mal eine structure mit sieben Lichtschaltern zum Testen definiert, wovon fünf mit dem neuen HMUART2 bedient werden. Auffällig ist, das die Lichter über den HMUART2 sehr zeitverzögert reagieren, und der Protresnd der Geräte hochzählt. Durch dieses Scenario lässt sich die "resending" Message reproduzieren. Auch sehe ich bei den Devices, dass der Protresnd hochzählt. Letzendlich aber trotzdem schaltet, allerdings mit deutlicher Verzögerung.
Schalte ich die Lichter einzeln, passt alles. Die RSSI Werte der betroffenen Devices sind alle unter 75.
Mehrmaliges Ein/Ausschalten der structure bewirkt:

Code Auswählen Erweitern

2017.08.17 13:10:31 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.17 13:13:17 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.17 13:26:20 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.17 13:36:18 1: HMUARTLGW HMUART2 resend failed too often, dropping packet: 01 020000004AA01129A0832F03030201C80000
2017.08.17 13:36:23 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.17 13:36:27 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending

Möglicherweise hängt es doch damit zusammen (Ser2net Beschreibung espeasy):

Code Auswählen Erweitern

WARNING: Applications that send large data packets like P1 smart meters do not work properly with the current firmware version. This may change in the future as it depends on Arduino ESP8266 core 2.4.0 development.
VG
Klaus

[chons]

Hast Du auch den DHT22 in Betrieb, was passiert wenn Du alle Controllers, Devices (natürlich bis auf Ser2Net) abschlatest? - und Loglevel schön auf 0 lassen.

Die Meldungen:

Code Auswählen Erweitern

2017.08.17 13:10:31 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
Bedeuten, dass das Modul nicht in der vorgegebenen Zeit angesprochen werden konnte. Was die Ursache dafür ist (Loop-Zeiten, WiFi delays) kann ich aktuell noch nicht sagen - bei mir hat die Verbindung zum Modul direkt funktioniert. Wir kommen evtl. darauf zurück, wenn die SwapSerial Version auch nicht den gewünschten Erfolg bringt.

Könntest Du bitte die Serial2Server Swap Variante testen/probieren? *denke an die Rx/Tx - die sind nicht mehr an Tx/Rx des WeMos sondern an D7/D8.
Es gibt unter Devices Ser2Net eine neue Option (siehe Anhang).
Bitte fange klein an - zunächst nur den Ser2Net in Betrieb nehmen, dann Sensoren (weitere Devices) aktivieren.
Ich habe ein paar rudimentäre Tests gemacht: ESPEasy FHEM Bridge inkl. BMPE280 jede Sekunde abfragen über FHEM + 4 Rollos gleichzeitig schalten. Bisher alles unauffällig.

Möglicherweise hängt es doch damit zusammen (Ser2net Beschreibung espeasy):

Code Auswählen Erweitern

WARNING: Applications that send large data packets like P1 smart meters do not work properly with the current firmware version. This may change in the future as it depends on Arduino ESP8266 core 2.4.0 development.

Ja, ist mir bekannt. Danke.

[Rampler]

Wird gemacht !
Publizierst Du die Änderungen auf Github (ESPEASY), wenn alles funktioniert ?

VG
Klaus

[Rampler]

Hallo Chons,
Test war erfolgreich !
Swapped funktioniert einwandfrei, wenn man von den Meldungen absieht (resending).
Swapped verhält sich bei Stresstest genau so wie TX/RX !
DHT22 und MQTT auch OK !
Gute Arbeit !

Hast Du auch den DHT22 in Betrieb, was passiert wenn Du alle Controllers, Devices (natürlich bis auf Ser2Net) abschlatest? - und Loglevel schön auf 0 lassen.

Kein Unterschied, mit nacktem Ser2Net kommen auch die Meldungen..

VG
Klaus

PS: Die Meldungen können nicht von irgendwelche WLAN Latenzen kommen, da der ESP momenatn nur 2 Meter neben der Fritzbox steht

[PeMue]

Hallo Chons,

ich hänge mich mal als Mitleser mit rein und werde Deine Firmware testen.

Gruß PeMue