Inbetriebnahme eines HM-MOD-UART mit ESPEasy

Begonnen von chons, 14 August 2017, 22:19:47

Vorheriges Thema - Nächstes Thema

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
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

#1
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:
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

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):
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

3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

Rampler

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


INIT : Booting version: v2.0.0-dev11
INIT : Warm boot #2
FS   : Mounting...
FS   : Mount successful, used 72288 bytes of 957314
sonderzeichen ....
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

chons

Zitat von: Rampler am 14 August 2017, 22:57:10
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.

Zitat von: Rampler am 15 August 2017, 07:44:25
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.
Zitat von: Rampler am 15 August 2017, 07:44:25
Was mich wundert, dass ich trotzdem noch Meldungen im Log des ESP sehe (obwohl alle Log Level auf 0 stehen):
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

chons

#7
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:
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

chons

#9
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

#10
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:
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):
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

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:
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.

Zitat von: Rampler am 17 August 2017, 13:35:14
Möglicherweise hängt es doch damit zusammen (Ser2net Beschreibung espeasy):
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

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 !

ZitatHast 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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

PeMue

Hallo Chons,

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

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Rampler

#15
Melde mich auch mal wieder..
Hier mal ein Auszug aus dem Log über eine Nacht:
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 ?
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

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

Zitat
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

Zitat von: chons am 21 August 2017, 22:54:46
Verstehe ich das richtig, dass ESPLink auch sporadisch die Probleme mit "resending" hat?
Nein, ESP-Link läuft ohne Probleme !!
Zitat von: chons am 21 August 2017, 22:54:46
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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

chons

Zitat von: Rampler am 22 August 2017, 08:18:47
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

ZitatIch 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
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

chons

Zitat von: Rampler am 23 August 2017, 18:38:37
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

#21
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:
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  8)

Edit: Mit amunra's Version von ESPEasy habe ich dieselben Effekte, also muss ich morgen mal die Hardware anschauen  >:(
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

#22
Hallo PeMue,

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

Zitat von: PeMue am 24 August 2017, 21:40:39
À 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

#23
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

#24
Hallo Chons,

Zitat von: chons am 24 August 2017, 22:36:09
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.

Zitat von: chons am 24 August 2017, 22:36:09
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.

Zitat von: chons am 24 August 2017, 22:36:09
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  ???

Zitat von: chons am 24 August 2017, 22:36:09
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.
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

#25
Zitat von: PeMue am 25 August 2017, 15:52:51
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!

Zitat von: PeMue am 25 August 2017, 15:52:51
Werte an (aber mit der Bedienung der Software werde ich auch nicht so richtig warm).
Ging mir am Anfang genauso.

Zitat von: PeMue am 25 August 2017, 15:52:51
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.

Zitat von: PeMue am 25 August 2017, 15:52:51
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

#27
Zitat von: chons am 25 August 2017, 17:25:24
Ä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:
00_HMUARTLGW.pm        14240 2017-05-10 09:27:09Z mgernoth

Zur Sicherheit: Rx an Rx und Tx an Tx, oder?
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

#28
Zitat von: PeMue am 25 August 2017, 18:27:04
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:
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...

Rampler

#30
Zitat von: chons am 25 August 2017, 20:59:58
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...
Hallo Chons,
was genau hast Du denn angepasst im ESPEASY (in Bezug auf Core 2.4.0 RC1) ?
Diese "eine Resending Meldung" kommt auch bei ESPLink, ansonsten läuft ESPLink absolut einwandfrei, ohne resendings.. !
..Spannung wächst ...
VG
Klaus
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

PeMue

#31
Zitat von: chons am 25 August 2017, 19:43:44
Nein, am USB UART Wandler TX/RX gekreuzt anschließen.  ;)
Ups, dann habe ich gedanklich ein Problem. Am Raspberry Pi wird Rx->Rx und Tx->Tx angeschlossen (so man den ELV Unterlagen glauben darf) und am USBseriell Wandler werden diese gekreuzt? Habe auf jeden Fall mal meine beiden Module angeschlossen und siehe da: sie funktionieren (sprich das falsch angeschlossene wurde nicht "gegrillt"). Das neue habe ich gleich auf Firmware v1.4.1 aktualisiert. Jetzt geht es wieder an die "Große" HMUART Platine, aber erst gibt es Frühstück bzw. muss ich mein Samstagsprogramm absolvieren.

Gruß PeMue

Edit: Mein Weltbild ist wieder in Ordnung. In der ELV Dokumentation wird die Steckerbelegung auf Modulseite dargestellt, beim Raspberry Pi sind Tx und Rx im Vergleich dazu vertauscht, daher ist die Sache auch hier gekreuzt.
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

#32
Zitat von: Rampler am 26 August 2017, 08:21:28
Hallo Chons,
was genau hast Du denn angepasst im ESPEASY (in Bezug auf Core 2.4.0 RC1) ?
Diese "eine Resending Meldung" kommt auch bei ESPLink, ansonsten läuft ESPLink absolut einwandfrei, ohne resendings.. !
..Spannung wächst ...
VG
Klaus
Das bereits 2016 gemeldete RX Buffer Thema ist nun in der 2.4 0 RC Version drin und ich habe in ESPEasy den Buffer von 128 auf 256 erhöht.
Nacher schaue ich mir das Ergebnis bzw. die Logs an und berichte hier.

chons

Zitat von: PeMue am 26 August 2017, 09:15:21
Edit: Mein Weltbild ist wieder in Ordnung. In der ELV Dokumentation wird die Steckerbelegung auf Modulseite dargestellt, beim Raspberry Pi sind Tx und Rx im Vergleich dazu vertauscht, daher ist die Sache auch hier gekreuzt.
Und jetzt darfst Du drei mal raten, warum die amunra Platine V1.0 nichts geworden ist ;)

PeMue

Zitat von: chons am 26 August 2017, 17:52:04
Und jetzt darfst Du drei mal raten, warum die amunra Platine V1.0 nichts geworden ist ;)
Wird auch landläufig Erfahrung genannt  8) 8) 8)

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

Erkentnisse zum Thema ESPEasy 2.0.0. und Core 2.4
"resending's" sind deutlich weniger geworden, aber mMn immer noch nicht zufreidenstellend und ich habe nun den Ser2Net Server in Verdacht (evtl. machen die Loops Probleme?), heißt ich muss weiter testen.

PeMue

Irgendwie ist da der Wurm drin. Ich nehme jetzt mal die Platine und pack den Feinstaubsensor dran. Vielleicht sind ja die I/O-Pins des WemosD1 mini in die Binsen gegangen.
Hier ein log mit verbose = 5:
2017.08.27 18:26:41 4: HttpUtils url=http://192.168.188.35:23/
2017.08.27 18:26:42 1: 192.168.188.35:23 reappeared (PMHMUART02)
2017.08.27 18:26:43 4: HMUARTLGW PMHMUART02 StartInit
2017.08.27 18:26:43 5: HMUARTLGW PMHMUART02 send: 00 00
2017.08.27 18:26:43 5: HMUARTLGW PMHMUART02 send: (8): fd00030001009e03
2017.08.27 18:26:43 5: SW: fd00030001009e03
2017.08.27 18:26:46 1: HMUARTLGW PMHMUART02 did not respond for the 1. time, resending
2017.08.27 18:26:46 5: HMUARTLGW PMHMUART02 send: (8): fd00030001009e03
2017.08.27 18:26:46 5: SW: fd00030001009e03
2017.08.27 18:26:49 1: HMUARTLGW PMHMUART02 did not respond for the 2. time, resending
2017.08.27 18:26:49 5: HMUARTLGW PMHMUART02 send: (8): fd00030001009e03
2017.08.27 18:26:49 5: SW: fd00030001009e03
2017.08.27 18:26:52 1: HMUARTLGW PMHMUART02 did not respond for the 3. time, resending
2017.08.27 18:26:52 5: HMUARTLGW PMHMUART02 send: (8): fd00030001009e03
2017.08.27 18:26:52 5: SW: fd00030001009e03
2017.08.27 18:26:55 1: HMUARTLGW PMHMUART02 did not respond after all, reopening
2017.08.27 18:26:55 4: HMUARTLGW PMHMUART02 Reopen

Das Modul reagiert schlichtweg gar nicht  >:( >:( >:(

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

Zitat von: PeMue am 27 August 2017, 18:30:58
Das Modul reagiert schlichtweg gar nicht  >:( >:( >:(
Ja, so sieht es aus...  :(

Mir gehen dann auch langsam die Ideen aus, aber Du könntest erneut (bestimm schon x Mal gemacht) die Stomversorgung am HM-UART prüfen (bekommt er genug Saft?) sowie die TX/RX Leiterbahnen durchmessen und auch mal einen anderen ESP nehmen.

PeMue

Zitat von: chons am 27 August 2017, 19:57:10
Mir gehen dann auch langsam die Ideen aus, aber Du könntest erneut (bestimm schon x Mal gemacht) die Stomversorgung am HM-UART prüfen (bekommt er genug Saft?) sowie die TX/RX Leiterbahnen durchmessen und auch mal einen anderen ESP nehmen.
Mit einem anderen ESP (und einer anderen Leiterplatte, die erste ist auf dem Dach "recycelt" als Feinstaubsensor funktioniert die Sache. Man sollte halt den WeMosD1 mini nicht unbedingt verpolen.

Danke nochmal für Deine Hilfe.

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chons

Zitat von: PeMue am 03 September 2017, 12:50:29
Mit einem anderen ESP (und einer anderen Leiterplatte, die erste ist auf dem Dach "recycelt" als Feinstaubsensor funktioniert die Sache. Man sollte halt den WeMosD1 mini nicht unbedingt verpolen.

Danke nochmal für Deine Hilfe.

Gruß Peter
Schön zu lesen/hören, dass es nun funktioniert.

Die HM-MOD-UART über ESPEasy SoftSerial Modul Problematik steht noch auf der ToDo Liste - aktuell leider low Prio.

FrankieSOC

Hey chons,

deine Version klappt super, habe sie jetzt seit 4 Wochen am laufen und hatte bis jetzt nur einmal den ESP neu starten müssen.
Ich hatte entdeckt das vom ESPEasy eine DEV12 gibt.

Leider weiß ich nicht, wie ich den "Swap Serial Port" integrieren kann.
Hast du einen Tipp für mich?

Viele Grüße
Frank

chons

#41
Ich habe in der "Serial.ino" den BUFFER erhöht:
#define INPUT_BUFFER_SIZE          256
Ich meine, dass ich auch in der Arduino Core UART Lib den Buffer angepasst hatte... ich bin mir nicht ganz sicher...
und das "_P020_Ser2Net.ino" Modul wie angehängt geändert.
Lade die dev12 herunter und überschreibe die "_P020_Ser2Net.ino" Datei mit der angehängten Version.

Es hat sich in dem Bereich eh nichts getan und ich bezweifle, dass der Umstieg auf dev12 etwas bringen wird, da keine improvements weder im Serial Server noch im UART Bereich durchgeführt wurden.
Das Thema steht bei mir auf der ToDo Liste - leider lässt die Zeit es nicht zu...

mrhaefele@gmx.de

Hallo,

könntest Du bitte die _P130_SSSRV.ino mit den swap Rx/Tx Pins zur Verfügung stellen. Wäre dir echt dankbar.

Gruß Udo

chons


mrhaefele@gmx.de

Tausend Dank! Werd ich heute Abend gleich mal ausprobieren /wenn Kind und Frau im Bett ist   ;-)    )   

Gruß

mrhaefele@gmx.de

Hi,

die Datei ist (fast) identisch mit der Version, die ich habe, bis auf dir Puffergröße (128 ==> 256). Aber wie bekomme ich in der "Software Serial Server (P130)" die Möglichkeit rein, dass ich die Rx/Tx Pins swappen kann? Welche Datei muss ich anpassen? Könntest Du diese bitte zur Verfügung stellen?

Gruß Udo

mrhaefele@gmx.de

Hallo chons,

einen Teilerfolg habe ich hinbekommen, indem ich die von dir gepostete P020 (P020 Ser2Net Plugin) genommen habe aus einem früheren Post. Damit konnte ich die Pins swappen mit P020 (jedoch tut mein Rotary Drehschalter nicht mehr).

Ich habe generell aber noch nicht verstanden, was der Unterschied zwischen dem P020 und dem P130 plugin ist. Brauche ich dann das P130 überhaupt. Macht das P130 das selbe wie das P020?
Ich dachte immer aus dem Post hier, dass ich den Software Serial Server brauche um überhaupt ein WLAN-Interface zum HMUART zu bauen.

Was jetzt aber komisch ist, ist, dass mein Rotary Switch (an D6/D7) nicht mehr funktioniert mit dem P020. Hat vorher mit dem P130 funktioniert (beim P130 hat halt der SSERV nicht fumktioniert).

PS: Vielleicht sag ich kurz, was ich eigentlich gerade bastle. Ich habe mir mit einem Wemos D1 mini, HM-UART, einem Rotary switch und 0,96 Zoll Display ein kleines Gerät gebastelt, mit dem ich, wie bekannt aus https://forum.fhem.de/index.php?topic=62651.0 einen HM-UART-WLAN Repeater  habe, der zusätzlich über den Rotary Switch noch andere Infos umschalten kann. Mit dem im Rotary Switch eingebauten Druckschalter schalte ich das Display ab und wieder an.
- Rotary ist auf D6/D7 und D5
- HMUART ist auf Rx/Tx
- Display über I2C an D1/D2

Kannst Du mir bitte auf die Sprünge helfen?

Danke und Gruß

Udo



andies

Ich habe es in anderen Threads versucht, inzwischen fällt mir auf, dass dieser hier am nächsten meinem Problem ist. Ich will das ELV Homematic-UART-Modul (ohne Trägerplatine, also die mit der Aufschrift TRX1) an einem Wemos betreiben. Der Wemos mini enthält ESPEasy Mega
Version 20102 - Mega,
Libraries ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3,
GIT version mega-20180524

der Ser2Net-Server ist aufgesetzt und so wie auf der Seite https://www.letscontrolit.com/wiki/index.php/Ser2Net eingestellt.

Ich finde aber keine Möglichkeit, irgendetwas auf "swapped" zu stellen. Passt denn dann noch die Belegung, dass Rx/Tx des HM-UART an die beiden D7/D8 des Wemos geschaltet werden? Oder muss ich die direkt an Rx/Tx des Wemos stecken (und was muss ich dabei beachten)? Ich sehe in den Logs eine serielle Verbindung, aber eben nur mit einem Sonderzeichen, also so hier
178889: Ser2N: N>: �
180626: WD : Uptime 3 ConnectFailures 0 FreeMem 19528
181989: Ser2N: Client connected!
182990: Ser2N: N>: �
185989: Ser2N: N>: �
189089: Ser2N: N>: �
191989: Ser2N: N>: �
195089: Ser2N: Client connected!
196089: Ser2N: N>: �
199190: Ser2N: N>: �
202189: Ser2N: N>: �
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

PeMue

Zitat von: andies am 03 Juni 2018, 19:11:05
Der Wemos mini enthält ESPEasy Mega
Version 20102 - Mega,
Libraries ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3,
GIT version mega-20180524

der Ser2Net-Server ist aufgesetzt und so wie auf der Seite https://www.letscontrolit.com/wiki/index.php/Ser2Net eingestellt.

Ich finde aber keine Möglichkeit, irgendetwas auf "swapped" zu stellen.
Das geht auch nicht mit Ser2Net. Dazu brauchst Du das Plugin SSSRV, das (meine ich) amunra damals mit einkompiliert hat. Ich habe im Bastelbereich das Plugin etwas erweitert, habe es aber nur mit R120 oder höher, sicherlich nicht mit ESPEasy Mega compiliert. Hol Dir doch einfach mal die ältere Version und teste.
Oder Du steckst das ELV Modul auf die Hardware Pins Rx und Tx (kreuzen), das dürfte die schnellere Variante sein.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

davedeluxe

Hallo zusammen,

gibt es zu dem Projekt einen neuen Stand? Bzw. ist eine lauffähige Version auf git verfügbar o.ä.?

Grüße Dave

Rampler

Zitat von: davedeluxe am 25 Februar 2020, 15:26:05
Hallo zusammen,

gibt es zu dem Projekt einen neuen Stand? Bzw. ist eine lauffähige Version auf git verfügbar o.ä.?

Grüße Dave

JA, der HMUART funktioniert schon einige Zeit tadellos mit dem ESPEASY / Letscontrolit.
Ich habe erst gestern auf die aktuellste Version migriert. Das Plugin "Communication - Serial Server" ist bereits mit dabei (Normal Version).  Guckst Du hier: https://github.com/letscontrolit/ESPEasy/releases
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

carlos

Hallo,
Kannst du bitte auch noch ein Bild  rein stellen, wie du den konfiguriert hat.
Danke

Gruß
Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Rampler

Hallo Carlos,
TCPPort habe ich 23 genommen
Baudrate 115200
Datenbits 8
Parität none
Stopbits 1

Du musst den HMUART über TX/RX anschließen. TX auf RX und umgekehrt.
Solltest Du die Platine beim HMUART verwenden, musst Du noch R1 und R2 überbrücken ...
Auch unter Advanced/Tools den Serial port enablen ..



3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

davedeluxe

Langsam abr sicher verzweifle ich daran...
Ich habe den wemos mit der Release mega-20200222 normal betankt, den HM-MOD-RPI-PCB angeschlossen (RX/TX getauscht).
Ich habe alle Settings wie in deinem Screenshot dargestellt und auch Serial unter Advanced aktiviert.

Aber ich erhalte nach wie vor immer wieder diese Meldung in FHEM:
HMUARTLGW WIFI_HM did not respond for the 1. time, resending...

Jemand nen Tipp?

andies

Ist das ein Original wemos? Ich habe letztens fünf Clone weggeworfen, die gingen einfach nicht.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Rampler

@davedeluxe
Die Verkabelung passt meines erachtens ...

Ich habe meine HMUART's so definiert...
define HMUART2 HMUARTLGW uart://192.168..x.x:23

Dumme Frage, Ping geht durch oder... ?
Mal anderes USB Netzteil probiert ?

Mal die 3,3 V gemessen ?
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

Rampler

Grad nochmal im Schaltplan nachgesehen, ein 100 uF, sowie ein 100nF auf der 3,3 V Leitung wären auch noch ein Versuch wert.
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

PeMue

Zitat von: davedeluxe am 26 Februar 2020, 16:12:40
Langsam aber sicher verzweifle ich daran...

Jemand nen Tipp?
Hast Du mal die 3,3 V gemessen? Ggf. ohne Spannung die Leitungen gegeneinander durchklingeln, um Kurzschlüsse auszuschließen (die Enden sind doch etwas lang  ;)).

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

davedeluxe

#58
Hey, danke für die schnellen und zahlreichen Hinweise.
Ich habe ihn ebenfalls so definiert: define WIFI_HM HMUARTLGW uart://192.168.xx.xx:23

Die Spannung passt und kurzschlüsse sind auch keine vorhanden.
Ich erhalte das gleiche Phänomen wenn ich gar keinen HM-MOD-RPI-PCB angeschlossen habe sondern nur den Serial Server definiere.
Des Weiteren habe ich auch schon 2 verschiedene Wemos getetstet von 2 verschiedenen Herstellern (ja ich bin verzweifelt)
Der Langzeit-Ping ist ebenfalls in Ordnung.

Was ich sehen kann ist das bei den Readings:
D-type   HM-MOD-UART
cond   init
loadLvl   suspended
state   disconnected

cond immer alle 12 Sekunden auf disconnected springt und ca 1-3 Sekunden später wieder auf init.

Nachtrag:
Den Wemos am Serial Monitor erscheint zur selben Zeit immer eine kryptische Zeile (egal welche Baudrate ich einstelle)

eisman

hi,

defmod HMLAN1 HMUARTLGW uart://192.168.1.201:1000@115200

mit 9600 hatte ich die selben probleme...


mfg
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

davedeluxe

Zitathi,

defmod HMLAN1 HMUARTLGW uart://192.168.1.201:1000@115200

mit 9600 hatte ich die selben probleme...
Leider auch nicht, den Port habe ich zusätzlich auch schon verändert.

eisman

hi,

gemeint war @115200

ohne diesen Eintrag geht es auch nicht,

unter Tools/advanced
Serial Settings
Enable Serial port:   
Baud Rate:   
115200

Communication - Serial Server ❔ ℹ
Name:   HMLANUART
Enabled:   
TCP Port:           1000
Baud Rate:   115200
Data bits:           8
Parity:           none
Stop bits:           1
Reset target after boot:       no parity
RX Receive Timeout (mSec):  0
Event processing:               none

mfg
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

davedeluxe

Ja das habe ich verstanden und auch so getestet  :)
Wie gesagt, den Port habe ich ZUSÄTZLICH auch mal verändert.
Alle anderen Einstellungen sind ebenfalls genau wie von dir beschrieben.

eisman

1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

davedeluxe

Gratuliere :)

Kann es möglich sein das der HM-MOD-RPI-PCB defekt ist?
Könnte das so ein Verhalten hervorrufen?
Denn ob ich den HM-MOD-RPI-PCB dran habe oder nicht macht vom Verhalten her keinen Unterschied.

Ich habe zu den 5 neuen Wemos die unterwegs sind mal noch nen neuen HM-MOD-RPI-PCB bestellt.
Falls noch jemand ne Idee ider nen Kommentar dazu hat, gerne her damit. Ich melde mich sobald die neuen Teile da sind.

Danke soweit an alle Beteiligten!

eisman

hi,

Kann es möglich sein das der HM-MOD-RPI-PCB defekt ist? ja
das verhalten ist mir nur aufgefallen, wenn die Einstellungen nicht 115200 oder tx und rx vertauscht waren.
und auch wenn das @115200 gefehlt hat.

mfg
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

davedeluxe

Okay dann hoffe ich das es daran liegt, denn alles andere habe ich jetzt mehrfach überprüft.

Danke!

andies

Ich tippe auf den Wemos. ,,Verschiedene Händler" ist leider ein Trugschluss, wenn du in einem bestimmten Zeitfenster gekauft hast (es sei denn, die sehen unterschiedlich aus). Es kommt manchmal vor, dass die Chinesen eine fehlerhafte Charge in grosser Stückzahl produzieren. Die wird dann am Händlermarkt ,,entsorgt", d.h. viele Kleinhändler kaufen die für einen Bruchteil auf und verkaufen sie an Leute wie uns weiter. Ich habe das auch mit Fernbedienungen erlebt. So eine Charge kann dann schon mal wochenlang im Handel sein.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

eisman

hi,

und dann kommen noch Fehler in ESPEasy mega-20200222!
bin zurück auf die ESPEasy mega-20190630

z.B.  LCD von 40 Zeichen auf 3 Zeichen
       LED ohne Funktion
       sporadische Aussetzer
       usw.

mfg
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

davedeluxe

Es lag am HM-MOD-RPI-PCB...
Ich habe den neuen an den Wemos angeschlossen und alles läuft großartig.

Danke an alle Beteiligten für die Mühe!

Sprollonis

Zitat von: Rampler am 26 Februar 2020, 09:37:05
Hallo Carlos,
TCPPort habe ich 23 genommen
Baudrate 115200
Datenbits 8
Parität none
Stopbits 1

Du musst den HMUART über TX/RX anschließen. TX auf RX und umgekehrt.
Solltest Du die Platine beim HMUART verwenden, musst Du noch R1 und R2 überbrücken ...
Auch unter Advanced/Tools den Serial port enablen ..

Hallo zusammen,
könntet Ihr den Hinweis noch im Wiki unterbringen - hat mich zwei Abende gekostet bis ich den Hinweis gefunden habe und er brachte dann den Erfolg. Dachte erst meine Module sind defekt. Habe dabei aber viel gelernt.

Danke an alle Vorkämpfer in dieser Sache

Gruß

Sprollonis



andies

Das höre ich zum ersten mal. Welche Platine ist das? Dann trage ich das ein.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Tungsten

Hallo Zusammen,

ich habe ein HM-MOD-UART-AW-SH-2 welches über so ein Verbindungsboard mit einem D1 mini verbunden ist.

Habe nun ESPeasy auf dem D1 mini installiert und ein Communication - Serial Server Device angelegt.

Kennt jemand dieses Verbindungsboard? Sind TX und RX bereits gekreuzt oder wo stelle ich das in ESPeasy ein?
Finde dazu nichts.

Danke Euch!