Inbetriebnahme eines HM-MOD-UART mit ESPEasy

[Rampler]

Melde mich auch mal wieder..
Hier mal ein Auszug aus dem Log über eine Nacht:

Code Auswählen Erweitern

2017.08.20 13:56:19 3: HMUART2 device opened
2017.08.20 14:55:31 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 14:55:34 1: HMUARTLGW HMUART2 did not respond for the 2. time, resending
2017.08.20 19:26:05 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 19:32:18 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 20:04:49 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 20:28:05 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:00:20 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:05:58 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:17:27 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:25:38 3: CUL_HM set FL.OG.rm statusRequest
2017.08.20 21:25:38 3: CUL_HM set AZ.rm statusRequest
2017.08.20 21:25:38 3: CUL_HM set KG.rm statusRequest
2017.08.20 21:54:15 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:56:12 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:56:15 1: HMUARTLGW HMUART2 did not respond for the 2. time, resending
2017.08.20 21:58:20 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 21:58:36 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 22:00:37 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 22:33:19 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 22:35:27 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 22:37:22 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 22:37:25 1: HMUARTLGW HMUART2 did not respond for the 2. time, resending
2017.08.20 23:00:10 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 23:04:31 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 23:39:25 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.20 23:39:31 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:07:04 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:09:02 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:09:09 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:11:22 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:26:41 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:36:52 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:38:49 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:40:21 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:41:01 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:45:53 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 00:49:25 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:52:51 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:53:07 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:55:02 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:55:17 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:56:18 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 04:58:45 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:01:22 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:06:28 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:08:30 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:14:44 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:26:11 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:44:40 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:48:33 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:48:48 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:49:34 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 05:49:44 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 06:55:41 3: CUL_HM set WZ.rm statusRequest
2017.08.21 07:47:55 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 07:48:04 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 07:48:14 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 07:50:35 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 08:06:19 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
2017.08.21 08:06:23 1: HMUARTLGW HMUART2 did not respond for the 1. time, resending
Ich habe viel getestet, aber letztendlich alles ohne Erfolg. Betreibe momentan den HMUART über TX/RX.
Ich weiß, dass passt nicht ganz zusammen (zumindest verstehe ich es nicht), aber mit dem neuen HMUART habe ich sehr viele Protkoll Resends, welche sich auch im täglichen Leben auswirken, also längere Reaktionszeiten der Aktoren.
VG
Klaus

Nachtrag:
Habe soeben nochmal ESP-LINK geflasht, alles andere so gelassen, also gleicher Standort, DHT-22 angeschlossen. (Neuen WEMOS mit ESPLINK in meinen Aufbau gesteckt)
Durch das überbrücken der Widerstände auf der Trägerplatine kann ich jetzt den ESPLINK auch normal (nicht swapped) betreiben.
Danach einen set hm clear msgEvents...
Jetzt treten die Protokoll Resends nicht mehr auf.
Ich glaube fast, es macht Sinn, auf neuere Versionen vom ESPEASY zu warten...
Was meint Ihr ?

[chons]

In der ,,resending" Thematik – die ich auch sporadisch und mehrmals - mehr oder weniger - am Tag habe (laut Logfiles) - steckt einiges an Forschungspotential (Ich muss wohl den Analyser anwerfen und das Verhalten mit ESP-Link abgleichen/vergleichen).
Leider erkenne ich bisher auch keine Systematik - Uhrzeit und Situation unabhängig treten die Probleme (die bei mir gefühlt ,,keine" spürbaren Probleme bereiten) auf.
Ich lasse meine produktive Umgebung auf ESPEasy Swap Version laufen, um Erkenntnisse zu sammeln.
Ich benötige für die Analyse etwas Zeit, die mir aktuell nicht zur Verfügung steht – das kann alles entsprechend dauern  - sorry

Nachtrag:
Habe soeben nochmal ESP-LINK geflasht, alles andere so gelassen, also gleicher Standort, DHT-22 angeschlossen. (Neuen WEMOS mit ESPLINK in meinen Aufbau gesteckt)
Durch das überbrücken der Widerstände auf der Trägerplatine kann ich jetzt den ESPLINK auch normal (nicht swapped) betreiben.
Danach einen set hm clear msgEvents...
Jetzt treten die Protokoll Resends nicht mehr auf.
Ich glaube fast, es macht Sinn, auf neuere Versionen vom ESPEASY zu warten...
Was meint Ihr ?

Verstehe ich das richtig, dass ESPLink auch sporadisch die Probleme mit "resending" hat?
Oder, meinst Du das die ESPLink "swapped" Einschränkung durch die Widerstände aufgehoben ist?

Ich lasse auch mal ESPLink (swpped) ein paar Tage laufen (habe leider nur ein Testsystem ).

... das alles im ersten Beitrag zu sortieren steht auch noch an 

[Rampler]

Verstehe ich das richtig, dass ESPLink auch sporadisch die Probleme mit "resending" hat?

Nein, ESP-Link läuft ohne Probleme !!

Oder, meinst Du das die ESPLink "swapped" Einschränkung durch die Widerstände aufgehoben ist?

Korrekt, ESP-Link kann ohne Widerstände auch normal betrieben werden (nicht swapped).

Gut zu hören, dass Du auch die gleichen Probleme mit ESPEASY und resending hast, dann muss ich in meinem Infrastrukurumfeld nicht weiter suchen.
Im neuen Adruino Core 2.4.0 RC1 gibt es einige Korrekturen im Serial Umfeld. Wahrscheinlich erledigt sich die ESPEASY Serial Problematik durch den neuen Core von alleine, wenn er
denn mal Released wird.
VG
Klaus

[chons]

Gut zu hören, dass Du auch die gleichen Probleme mit ESPEASY und resending hast, dann muss ich in meinem Infrastrukurumfeld nicht weiter suchen.
Im neuen Adruino Core 2.4.0 RC1 gibt es einige Korrekturen im Serial Umfeld. Wahrscheinlich erledigt sich die ESPEASY Serial Problematik durch den neuen Core von alleine, wenn er
denn mal Released wird.

Ich habe soeben ESPEasy dev build mit der Arduino Core dev build version probiert - das Verhalten mit "resending" bleibt - bisher kein Unterschied.
ESPEasy ist in einigen Bereichen aktuell noch nicht 2.4.0 ready (seltsame Meldunge auf der Config Page etc.) - so wie ich das sehe...

[Rampler]

Ich habe soeben ESPEasy dev build mit der Arduino Core dev build version probiert - das Verhalten mit "resending" bleibt - bisher kein Unterschied.
ESPEasy ist in einigen Bereichen aktuell noch nicht 2.4.0 ready (seltsame Meldunge auf der Config Page etc.) - so wie ich das sehe...

Das gleiche bei mir auch, hier und da merkwürdige Hex-Zeichen... 6fb ...
Compiliert mit Core 2.4.0 RC1
Schade, da hatte ich doch große Hoffnungen...
VG
Klaus

[chons]

Das gleiche bei mir auch, hier und da merkwürdige Hex-Zeichen... 6fb ...
Compiliert mit Core 2.4.0 RC1
Schade, da hatte ich doch große Hoffnungen...

Jep...

Ich habe diverse seltsame und immer noch nicht nachvollziehbare Effekte.
Beispiel: FHEM Modul verbindet sich mit dem ESPEasy-Ser2Net- fragt ,,erfolgreich" die Modul Daten (D-serialNr, D-serialNr etc.) ab und liefert/meldet dann nur noch ,,did not respond for the 1. time, resending" Messages.

Meine Idee ist es herauszufinden wo es klemmt ,,zwischen HM Modul und UART" – ,,UART und Ser2Net" oder ,,Ser2Net und FHEM"?
Es interessiert mich an welcher Stelle die Probleme bestehen, auch wenn ich diese möglicherweise nicht direkt lösen kann (ich möchte im Moment nicht zu tief in ESPEasy/Arduino Core abtauchen, weil ich aktuell parallel ein anders Projekt verfolge) – ich bleibe aber dran (Diverse Werte per Push Button auf ein OLED Display auszugeben, finde ich "praktisch"(und nutze es jeden Tag) ).

ESP-Link steht ja immer noch als zuverlässige Alternative zur Verfügung und ESP Easy funktioniert (Swapped) auch, allerdings mit geringen Einschränkung (Verzögerungen).

P.S. System Abstürze inkl. Hänger die dazu führen, dass das System ,,nicht" mehr funktioniert haben wir aktuell nicht, aus diesem Grund bin ,,ich" noch entspannt und setze es bei mir produktiv ein.
Weitere Infos folgen...

[PeMue]

Hallo zusammen,

beim Testen meiner "Großen" HMUART Platine habe ich folgendes festgestellt:
- zuerst habe ich esp-link v3.0.14 geflasht und in Betrieb genommen,
  danach hat aber der Status von cond init 2017-08-24 21:32:48 auf disconnected gewechselt
- danach habe ich esp-link v2.2.3 geflasht, das hatte aber Probleme, meinen Router zu erkennen
- wieder esp-link v3.0.14 geflasht und den Haken bei RX pull-up rausgenommen

Status cond init 2017-08-24 21:32:48 wechselt sporadisch auf disconnected und im LOG habe ich folgende Meldungen:

Code Auswählen Erweitern

2017.08.24 21:34:35 1: HMUARTLGW PMHMUART02 did not respond for the 1. time, resending
2017.08.24 21:34:38 1: HMUARTLGW PMHMUART02 did not respond for the 2. time, resending
2017.08.24 21:34:41 1: HMUARTLGW PMHMUART02 did not respond for the 3. time, resending
2017.08.24 21:34:44 1: HMUARTLGW PMHMUART02 did not respond after all, reopening
2017.08.24 21:34:44 3: PMHMUART02 device closed
2017.08.24 21:34:44 1: 192.168.188.46:23 reappeared (PMHMUART02)
2017.08.24 21:34:48 1: HMUARTLGW PMHMUART02 did not respond for the 1. time, resending
2017.08.24 21:34:51 1: HMUARTLGW PMHMUART02 did not respond for the 2. time, resending
2017.08.24 21:34:54 1: HMUARTLGW PMHMUART02 did not respond for the 3. time, resending
2017.08.24 21:34:57 1: HMUARTLGW PMHMUART02 did not respond after all, reopening
2017.08.24 21:34:57 3: PMHMUART02 device closed
2017.08.24 21:34:58 1: 192.168.188.46:23 reappeared (PMHMUART02)
Ich werde morgen noch mal die Hardware durchmessen, das Layout bzw. die Lötstellen sollten ok sein. Hat jemand eine Idee, wo ich noch suchen kann? Ich wollte eigentlich nur die Leiterplatte testen und verschicken 
À propos: es dürfte ja nicht stören, wenn am I2C Bus ein BME280 hängt, oder?

Danke + Gruß

PeMue

PS: Ich habe den Titel etwas abgeändert, um nicht ganz off-topic zu sein 

Edit: Mit amunra's Version von ESPEasy habe ich dieselben Effekte, also muss ich morgen mal die Hardware anschauen 

[chons]

Hallo PeMue,

die im Screenshot dargestellten Settings sind ok! Damit scheint es bei 99,99999% der User zu funktionieren.

À propos: es dürfte ja nicht stören, wenn am I2C Bus ein BME280 hängt, oder?

Nein, aber das kann ich nicht zu 100% beantworten, da bisher nicht verifiziert. Ein BME280 habe ich hier und könnte es testen.
Könntest Du bitte hier, wenn auch off-topic , den aktuellen (link) Schaltplan für die große HMUART Platine posten.

P.S.:Ich habe von Problemen mit AVM Repeater und ESPLink gelesen, daher die Frage wie sieht deine WiFi Infra aus? Was für ein AP hast Du im Einsatz und ist ein AVM Repeater dabei?
P.P.S: Läuft es nach dem reappeard und resending (kommen nur wenn mindestens die Verbindung zum Gateway steht, und die Device Werte (Serial, Firmwareetc) bereits ermittelt wurden bzw. das Modul initialisiert wurde) oder bekommst Du es gar nicht ans laufen?
P.P.P.S: Welche HM-UART FW Version ist auf dem Modul installiert?

EDIT: Schaltplan gefunden - sieht mMn ok aus bzw. nichts auffälliges gefunden. Ein BME280 und OLED hängen bei auch dran und das ganze läuft seit gestern ohne Probleme.

[chons]

ok, ich habe esp-link v3.0.14 geflasht - bei mir AVM 7490 (oS 06.83) ohne repeater läuft es mit der amunra Platinen Version (ohne I2C).
Auch wenn ich mich nicht traue es zu schreiben, checke bitte deine Lötstellen.

P.S: Falls nichts hilft bitte hmuart verbose logs hier posten - danke.

[PeMue]

Hallo Chons,

Könntest Du bitte hier, wenn auch off-topic , den aktuellen (link) Schaltplan für die große HMUART Platine posten.

Ja, siehe erster Post: https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=79420, aber ich sehe, Du hast den schon gefunden.

P.S.:Ich habe von Problemen mit AVM Repeater und ESPLink gelesen, daher die Frage wie sieht deine WiFi Infra aus? Was für ein AP hast Du im Einsatz und ist ein AVM Repeater dabei?

Ich habe eine FritzBox 7490, keinen Repeater, die Netzabdeckung im Haus ist mit dem einen Router ganz ok.

P.P.S: Läuft es nach dem reappeard und resending (kommen nur wenn mindestens die Verbindung zum Gateway steht, und die Device Werte (Serial, Firmwareetc) bereits ermittelt wurden bzw. das Modul initialisiert wurde) oder bekommst Du es gar nicht ans laufen?

Zuerst ging gar nichts, da der WemosD1mini falsch rum drin war 
Jetzt habe ich den richtig rum eingelötet, beim BME280 war eine Leitung unterbrochen (wohl eine Unterbrechung auf der Leiterplatte, DuKos müssten aber ok sein) und er wird in ESPEasy per I2CScan auch sauber erkannt. Allerdings kommen keine Werte. Dass der BME280 funktioniert, habe ich an einem LGW getestet, ich habe da Werte gemessen bzw. die Kalibrierwerte ausgelesen. Komischerweise kommen bei ESPEasy keine Werte an (aber mit der Bedienung der Software werde ich auch nicht so richtig warm).
Beim HMUART kommt gar nichts, keine Firmwarewerte, nada. Ich habe schon die Verbindungen durchgeklingelt, aber die scheinen ok. Ich hoffe, dass ich mein HMUART Modul nicht geschrottet habe 

P.P.P.S: Welche HM-UART FW Version ist auf dem Modul installiert?

Ich meine die neueste, das ist mein "Testmodul", das ich schon mit USB in Betrieb genommen habe und dabei habe ich die Firmware aktualisiert. Das Teil ist mir einfach zu teuer, um es auf Leiterplatten zu löten und draufzulassen.

Danke + Gruß

PeMue

Edit: Mit altitude 240, Delay 1 und IDX/Var 1 kommen jetzt beim BME280 Werte  Ich werde mal das HMUART Modul per USB2seriell Wandler an den Raspberry Pi hängen, um zu schauen, ob das noch funktioniert.

[chons]

Zuerst ging gar nichts, da der WemosD1mini falsch rum drin war 

Das ist vermutlich nicht gut, dann hast Du evtl. 5V und GND auf TX und RX aufgelegt
Das ist quatsch - das kann nicht passieren, weil der 5V Pin um einen Pin verschoben ist!

Werte an (aber mit der Bedienung der Software werde ich auch nicht so richtig warm).

Ging mir am Anfang genauso.

Beim HMUART kommt gar nichts, keine Firmwarewerte, nada. Ich habe schon die Verbindungen durchgeklingelt, aber die scheinen ok. Ich hoffe, dass ich mein HMUART Modul nicht geschrottet habe 

Die Verbose Logs (Level 5) wären dann hilfreich. Ich denke, dass die Verbindung zum Server zwar aufgebaut werden kann, jedoch das HM-UART Modul über die serielle Schnittstelle nicht ansprechbar ist. Gründe könnten sein: Modul gegrillt  ,  HM-Modul Stromversorgung und/oder TX/RX fehlerhaft.

Ich werde mal das HMUART Modul per USB2seriell Wandler an den Raspberry Pi hängen, um zu schauen, ob das noch funktioniert.

Das ist eine gute Idee - Du kannst auch ein RS232 USB Adapter nehmen, dann musst Du dein RPI nicht auseinander bauen und dich mit der Installation und Konfiguration der internen Schnittstelle ärgern.

[chons]

Ähm, nur zur Sicherheit - das HM-Modul ist nackt oder ist es auf der beiliegende Trägerplatine gelötet?

[PeMue]

Ähm, nur zur Sicherheit - das HM-Modul ist nackt oder ist es auf der beiliegende Trägerplatine gelötet?

Das HM-Modul ist ohne Trägerplatine, die war mir einfach zu groß. Und (intern) denke ich, dass man die 470 Ohm Widerstände nicht braucht ...

Gruß PeMue

Edit:
Ok, da scheint irgend etwas prinzipiell nicht zu funktionieren. Am USBseriell Wandler gehen zwei Module nicht (am Modul angelätet, mit Steckern am USBseriell Wandler). Ggf. muss ich da neue Kabel verwenden.
Mein HMUART Modul hat die folgende Version:

Code Auswählen Erweitern

00_HMUARTLGW.pm        14240 2017-05-10 09:27:09Z mgernoth

Zur Sicherheit: Rx an Rx und Tx an Tx, oder?

[chons]

Edit:
Ok, da scheint irgend etwas prinzipiell nicht zu funktionieren. Am USBseriell Wandler gehen zwei Module nicht (am Modul angelätet, mit Steckern am USBseriell Wandler). Ggf. muss ich da neue Kabel verwenden.
Mein HMUART Modul hat die folgende Version:

Code Auswählen Erweitern

00_HMUARTLGW.pm        14240 2017-05-10 09:27:09Z mgernoth

Zur Sicherheit: Rx an Rx und Tx an Tx, oder?

Nein, am USB UART Wandler TX/RX gekreuzt anschließen. 

HMUART Version ist nicht neu, es gibt bereits eine neuere, diese wird in diesem Fall aber nicht kriegsentscheidend sein.
Ich meinte die Firmware des HM UART Moduls, die muss die Version 1.4.1 haben.
Die Version wird mMn kein Thema sein, ich würde mich auf TX/RX und Stromversorung fokussieren - wir müssen ja, das HM-Modul erstmal ansprechen können.

[chons]

Zur Info und zum eigentlichen Thema zurück (PeMue, Du kannst dich mit der ESPLink Thematik dennoch hier melden...)

Obwohl ich das nicht wollte (aber mein parallel Projekt ist fertig – hoffe ich... Doku und Marketing fehlt noch *die Nacht wird heute lang ) ich habe mir die Arduino Core relevanten Teile für die UART Probleme angeschaut – die Änderungen sind bereits in der Arduino Core 2.4.0 RC1 enthalten und ich habe ESPEasy entsprechend angepasst und bereits im Einsatz. Das sieht bisher gut aus, aber ich lasse das mal bei mir eine Zeit lang laufen.

Was mir bisher aufgefallen ist (nach den ESPEasy Anpassungen auf die Arduino Core 2.4.0), dass bei dem initialen (FHEM: open/reopen) Verbindungsaufbau ,,eine" resending Meldung auftaucht – das sollte aber sicher lösbar sein – sonst läuft die UART Kommunikation bisher (ein paar Stunden) stabil ohne ,,resendings" (abgesehen von WebUI mit den konfusen Meldungen.)

Mal schauen, ob es das war's?
Fortsetzung folgt...