[gelöst] Zweites IODev funktioniert nicht (HMUARTLGW) mit Wemos mini pro/ESP07

[andies]

Guten Abend, kann mir jemand helfen? Ich betreibe eine VCCU mit einem HMUARTLGW, das seit 44 Tagen ununterbrochen läuft:

Code Auswählen Erweitern


Internals:
   AssignedPeerCnt 9
   CNT        127
   Clients    :CUL_HM:
   DEF        uart://192.168.2.24:23
   DEVCNT     127
   DevState   99
   DevType    UART
   DeviceName 192.168.2.24:23
   FD         21
   FUUID      5c782b57-f33f-1115-716d-c1fad8d8908bd62b
   LastOpen   1562680419.55019
   NAME       WLAN_HmUART
   NOTIFYDEV  global
   NR         27
   NTFY_ORDER 50-WLAN_HmUART
   PARTIAL   
   RAWMSG     040202
   RSSI       -84
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 1
   msgLoadHistory 0/1/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 1/1/0/-/-/-/-/-/-/-/-/-/-
   owner      676767
   owner_CCU  VCCU
   Helper:
     CreditTimer 55
     FW         66561
     Initialized 1
     SendCnt    2
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.059114933013916
     loadLvl:
       lastHistory 1562681026.9069
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     4D0FD6     +4D0FD6,00,00,00
     54F832     +54F832,00,00,00
     5CFFFD     +5CFFFD,00,00,00
     5D0541     +5D0541,00,00,00
     600D4A     +600D4A,00,00,00
     62EBE5     +62EBE5,00,00,00
     62FF12     +62FF12,00,00,00
     63A514     +63A514,00,00,00
     696D3B     +696D3B,00,00,00
   READINGS:
     2019-07-09 15:53:46   D-HMIdAssigned  676767
     2019-07-09 15:53:46   D-HMIdOriginal  67181D
     2019-07-09 15:53:46   D-firmware      1.4.1
     2019-07-09 15:53:46   D-serialNr      PEQ0172450
     2019-07-09 15:53:20   D-type          HM-MOD-UART
     2019-07-09 15:53:47   cond            ok
     2019-07-09 15:58:44   load            1
     2019-07-09 15:53:47   loadLvl         low
     2019-07-09 15:53:39   state           opened
   helper:
Attributes:
   group      intern
   hmId       676767
Angeschlossen ist das Gerät an eine VCCU, listing kommt gleich. Ich habe nun heute versucht, ein zweites HMUARTLGW anzuschließen, weil ich mit einem IODev nicht alle Geräte abdecken kann. Das zweite Gerät hat eine eigene Stromversorgung, die ausreichend ist (um gleich mal typische Fehler auszuschließen) und hängt an einem ESP8266-07, damit ich eine externe WLAN-Antenne anschließen kann sowie einem HM-MOD-RPI-PCB (seriell verbunden). Auf dem ESP ist ESPEasy, Mega. Anscheinend gelingt die interne Kommunikation, denn der Log sagt mir:

Code Auswählen Erweitern


138: INIT : I2C
139: INIT : SPI not enabled
164: INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support)
166: EVENT: System#Wake
175: WIFI : Set WiFi to STA
208: WIFI : Connecting WLAN-XXXXXX attempt #0
210: WIFI : Not configured in Station Mode!!: WLAN-XXXXXX
212: EVENT: System#Boot
1552: WD : Uptime 0 ConnectFailures 0 FreeMem 22288 WiFiStatus 0
4085: WIFI : Connected! AP: WLAN-XXXXXX (18:XX:XX:YY:YY:ZZ) Ch: 1 Duration: 3771 ms
4087: EVENT: WiFi#ChangedAccesspoint
4093: WIFI : DHCP IP: 192.168.2.15 (ESP-Easy-UART2) GW: 192.168.2.1 SN: 255.255.255.0 duration: 27 ms
4096: EVENT: WiFi#Connected
4106: Webserver: start
5773: Ser2N: Client connected!

Das Gerät selbst wurde in FHEM erkannt, erscheint jetzt aber disconnected:

Code Auswählen Erweitern


Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.2.15:23
   DevState   0
   DevType    UART
   DeviceName 192.168.2.15:23
   FUUID      5d2499c7-f33f-1115-3f9d-b793b6e7ea150f63
   LastOpen   1562681445.77934
   NAME       WLAN_HmUART2
   NEXT_OPEN  1562681521.83265
   NOTIFYDEV  global
   NR         29
   NTFY_ORDER 50-WLAN_HmUART2
   PARTIAL   
   STATE      disconnected
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1562681446.78294
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2019-07-09 15:53:20   D-type          HM-MOD-UART
     2019-07-09 16:10:58   cond            disconnected
     2019-07-09 15:53:20   loadLvl         suspended
     2019-07-09 16:11:01   state           disconnected
Attributes:
   group      intern
   hmId       676767
Manchmal ist sie auch opened:

Code Auswählen Erweitern

Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.2.15:23
   DevState   1
   DevType    UART
   DeviceName 192.168.2.15:23
   FD         42
   FUUID      5d2499c7-f33f-1115-3f9d-b793b6e7ea150f63
   LastOpen   1562681545.05441
   NAME       WLAN_HmUART2
   NOTIFYDEV  global
   NR         29
   NTFY_ORDER 50-WLAN_HmUART2
   PARTIAL   
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1562681546.68715
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2019-07-09 15:53:20   D-type          HM-MOD-UART
     2019-07-09 16:12:26   cond            init
     2019-07-09 15:53:20   loadLvl         suspended
     2019-07-09 16:12:25   state           opened
Attributes:
   group      intern
   hmId       676767

Habe ich hier in der Installation irgendwas falsch gemacht? Die VCCU sieht so aus:

Code Auswählen Erweitern


Internals:
   DEF        676767
   FUUID      5c782b58-f33f-1115-bbc6-37d194c0c08dd8f1
   IODev      WLAN_HmUART
   NAME       VCCU
   NOTIFYDEV  global
   NR         33
   NTFY_ORDER 50-VCCU
   STATE      WLAN_HmUART:ok,WLAN_HmUART2:init
   TYPE       CUL_HM
   assignedIOs WLAN_HmUART,WLAN_HmUART2
   chanNo     01
   READINGS:
     2019-07-09 16:12:57   IOopen          1
     2019-07-09 16:12:57   state           WLAN_HmUART:ok,WLAN_HmUART2:init
   helper:
     HM_CMDNR   68
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         WLAN_HmUART
         WLAN_HmUART2
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      WLAN_HmUART
   IOList     WLAN_HmUART,WLAN_HmUART2
   IOgrp      VCCU
   expert     2_raw
   group      intern
   model      CCU-FHEM
   subType    virtual
   verbose    1
   webCmd     virtual:update

Die Reihenfolge in der fhem.cfg ist schon angepasst; in der commandref habe ich nichts gefunden und im Wiki auch nicht. Ich sehe nur im FHEM-Log Fehlermeldungen der Form

Code Auswählen Erweitern

2019.07.09 15:54:54 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.07.09 15:54:58 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.07.09 15:55:01 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.07.09 15:55:04 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.07.09 15:55:07 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.07.09 15:56:45 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.07.09 15:56:51 1: 192.168.2.15:23 disconnected, waiting to reappear (WLAN_HmUART2)
2019.07.09 15:56:51 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.07.09 15:56:56 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.07.09 15:56:59 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.07.09 15:57:02 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.07.09 15:57:03 1: 192.168.2.15:23 disconnected, waiting to reappear (WLAN_HmUART2)
2019.07.09 15:57:03 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.07.09 15:57:07 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.07.09 15:57:10 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.07.09 15:57:13 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.07.09 15:57:14 1: 192.168.2.15:23 disconnected, waiting to reappear (WLAN_HmUART2)
2019.07.09 15:57:15 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.07.09 15:57:19 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.07.09 15:57:22 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.07.09 15:57:25 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.07.09 15:57:28 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.07.09 15:57:28 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)

[Otto123]

Hallo andies,

ich habe es mit ESPEasy nie hinbekommen. Mein Tipp: nimm esp-link
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_mit_ESP8266

Das erste Wlan Gateway ist auch mit esp-easy am Start?
Das "manchmal ist er opened" ist ein Trugschluss, der hat noch nie mit dem Teil geredet. Sieht man an den fehlenden Readings.

Gruß Otto

[andies]

Oh Mist. Das sieht nicht gut aus.

Der erste ist mit ESPEasy drin, das läuft. Ich tippe eher auf ein Softwareproblem innerhalb von FHEM, weil ich schon den Wiki nicht richtig kapiert habe (irgendwelche AssignId falsch oder was auch immer). Der erste läuft ununterbrochen seit mindestens 44 Tagen!   

[Otto123]

Ich tippe eher auf ein Softwareproblem innerhalb von FHEM, weil ich schon den Wiki nicht richtig kapiert habe (irgendwelche AssignId falsch oder was auch immer).

Den Satz versteh ich nicht.
Ich tippe eher darauf, das Teil  läuft mit ESP Easy nicht. Ist das der gleiche Aufbau, Softwareversion, Verkabelung wie der Erste? Funktioniert das HMUART Modul an sich -> getestet?

Was kapierst Du am Wiki nicht? Ich habe in dem Artikel vieles verzapft, ich würde es gern besser machen.

[andies]

Ich meint mit "Software", dass ich irgendwas bei meinem FHEM-Device falsch eingestellt habe. Und ich zitiere mal aus dem Wiki und stelle die Fragen, die ich hatte.

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage.

Heißt das jetzt, man kann oder gar man soll IODev löschen? Der letzte Satz sagt: VCCU setzt das Attribut, aber das hat nach dem ersten Satz ja keine Funktion?

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installation. IOList beinhaltet die Komma-getrennte Liste der IOs (keine Leerzeichen!), so wie sie in FHEM angelegt sind.

Das betrifft mich jetzt, richtig? Ich will zwei HMWLAN haben. Also trage ich das händisch ein - aber da war ich mir schon unsicher. Ist das alles, was ich tun muss? Unklar war auch, welche hmID ich nehme. Denn da heißt es auch:

Wird die VCCU mit einer von vorhandenen Schnittstellen abweichenden hmId angelegt, so wird die hmId der ihr zugewiesenen Schnittstelle(n) automatische angepasst.

Der Nachsatz ist unklar. Es gibt zwei hmIds, einmal von der VCCU und dann von der Schnittstelle. welche Id wird jetzt angepasst? Es gibt ja mehrere Schnittstellen und welche hmId wird wo und wie angepasst?

Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert.

Fehlt da ein und: "...zugewiesen und werden die notwendigen..."? Oder ist es eher: "zugewiesen, dann werden die notwendigen..."?

Nochmal zu meinem Problem. Wenn der HMWLAN nicht mit FHEM redet, ist es ein reines HMWLAN- und kein VCCU-Problem? Wo kann ich prüfen, weshalb die nicht miteinander sprechen?

[Otto123]

Also dein primäres Problem: Dein zweiter IO redet nicht mit FHEM. Das ist ein reines IO Problem und keines mit der VCCU.
Und ich bleibe mal beharrlich mit dem ESP: Bei ESP Easy musste man früher explizit eine Version mit "Serial Server" selbst kompilieren oder irgendwie zusammenstückeln. Den Serial Server braucht es aber, sonst geht die Weitergabe des Seriellen Gerätes nicht. Einfach nur die Geräte an die serielle Schnittstelle des ESP anschließen war nicht die Lösung.
Du bist sicher, dass du da jetzt die richtige Version hast?
Du bist sicher, dass das HMUART Modul an sich funktioniert?

Deine Fragen zur VCCU beantworte ich noch. Da brauch ich etwas. Mache ich aber in dem Post, also nicht wundern.

Der letzte Satz sagt: VCCU setzt das Attribut,

Falschlesemodus aktiv! Das steht dort nicht! Das Attribut spielt keine Rolle mehr, die VCCU setzt das Internal IODev entsprechend. Das Internal spielt die entscheidende Rolle und nicht das Attribute. Lass das attr wie es ist, es steht ja nicht da "Du sollst es löschen".

Ich will zwei HMWLAN haben. Also trage ich das händisch ein - aber da war ich mir schon unsicher. Ist das alles, was ich tun muss?

Ja! Zumindest für die VCCU.
Damit es im System wirklich eine Auswirkung hast, musst Du bei allen Geräten das attr IOgrp setzen!

Es gibt ja mehrere Schnittstellen und welche hmId wird wo und wie angepasst?

sichtbar im Sinne der DEF wird nichts angepasst. Aber alle IOs einer VCCU agieren mit der hmId der VCCU! Es ist also nicht notwendig eine hmId beim IO einzutragen, es ist aber auch egal.
Der letzte Satz, den Du zitierst hast, ist eigentlich redundant? Das muss ich mir im gesamten text anschauen. habe ich gemäß Deiner ersten Variante geändert.

Deine VCCU finde ich, abschließend betrachtet, in Ordnung. Wie gesagt der Fehler liegt beim WLAN_HmUART2

[andies]

Danke Otto, dann suche ich da mal weiter. Ich habe in der tat eine selbst kompilierte Version von ESPEasy und den Buffer bei Serial massiv heraufgesetzt, der war sehr klein. Da gab es ein Problem, das ich vor Monaten mal hatte (buffer overflow oder so). Also ich muss die Kommunikation mit FHEM anschauen, ok.

Viele Grüße an meine alte Unistadt Leipzig, schön habt Ihr es da. 

[Otto123]

 

Und wenn Du unsicher bist: esp-link funktioniert mit drei Mausklicks - out-of-the-box wie man so schön sagt.

[andies]

Viele Grüße nach Leipzig, Otto: Ich brauche mal wieder Deine Hilfe. Ich bin nach wie vor dabei, einen ESP07 an HM-MOD-RPI-PCB und dann an FHEM anzuschließen. Den ESP07 habe ich gewählt, weil man da die Wifi-Antenne separat anschließen kann, ich zwei davon gekauft und zu spät bemerkt habe, dass auch der Wemos Mini Pro das kann.

Zuerst habe ich (siehe oben) das mit dem Serial Server von ESPEasy probiert. Fehlanzeige. Erschwerend kommt hinzu, dass Tx beim Booten des ESP frei sein muss, weil der sonst in irgendeinen Programmierstatus wechselt; das kriege ich derzeit mit einem Minitaster hin und das ignoriere ich mal, weil ich sonst alles in die Ecke werfe.

Heute habe ich nun esp-link installiert (für diejenigen, die das auch mit einem ESP07 probieren, das geht so:

Code Auswählen Erweitern

esptool.py --port /dev/<was-immer-der-Port-ist> --baud 115200 write_flash -fm dout -fs 1MB 0x00000 boot_v1.7.bin 0x1000 user1.bin  0xFC000 esp_init_data_default.bin 0xFE000 blank.bin
)

Wifi wird gefunden, man verbindet sich. Status in FHEM ist opened. ABER ich glaube mich zu erinnern, dass man an den Readings erkennt, ob das Gerät eingebunden wurde. Ich vermute, das ist nicht der Fall:

Code Auswählen Erweitern

Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.2.54:23
   DevState   1
   DevType    UART
   DeviceName 192.168.2.54:23
   FD         34
   FUUID      5d2499c7-f33f-1115-3f9d-b793b6e7ea150f63
   LastOpen   1566233343.44563
   NAME       WLAN_HmUART2
   NOTIFYDEV  global
   NR         29
   NTFY_ORDER 50-WLAN_HmUART2
   PARTIAL   
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     1
         time       1566233344.45046
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2019-08-17 18:40:08   D-type          HM-MOD-UART
     2019-08-19 18:49:04   cond            init
     2019-08-03 14:11:30   loadLvl         suspended
     2019-08-19 18:49:03   state           opened
Attributes:
   group      intern
   hmId       676767
Kannst Du hier erkennen, woran das liegt:

Code Auswählen Erweitern

2019.08.19 18:43:11 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 18:43:11 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:11 5: SW: fd00030001009e03
2019.08.19 18:43:15 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 18:43:15 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:15 5: SW: fd00030001009e03
2019.08.19 18:43:16 4: HMUARTLGW WLAN_HmUART2 Reopen
2019.08.19 18:43:16 3: WLAN_HmUART2 device closed
2019.08.19 18:43:16 5: HttpUtils url=http://192.168.2.54:23/
2019.08.19 18:43:16 4: IP: 192.168.2.54 -> 192.168.2.54
2019.08.19 18:43:16 1: 192.168.2.54:23 reappeared (WLAN_HmUART2)
2019.08.19 18:43:17 4: HMUARTLGW WLAN_HmUART2 StartInit
2019.08.19 18:43:17 5: HMUARTLGW WLAN_HmUART2 send: 00 00
2019.08.19 18:43:17 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:17 5: SW: fd00030001009e03
2019.08.19 18:43:20 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 18:43:20 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:20 5: SW: fd00030001009e03
2019.08.19 18:43:23 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 18:43:23 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:23 5: SW: fd00030001009e03
2019.08.19 18:43:26 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.08.19 18:43:26 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:26 5: SW: fd00030001009e03
2019.08.19 18:43:29 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.08.19 18:43:29 4: HMUARTLGW WLAN_HmUART2 Reopen
2019.08.19 18:43:29 3: WLAN_HmUART2 device closed
2019.08.19 18:43:29 5: HttpUtils url=http://192.168.2.54:23/
2019.08.19 18:43:29 4: IP: 192.168.2.54 -> 192.168.2.54
2019.08.19 18:43:29 1: 192.168.2.54:23 reappeared (WLAN_HmUART2)
2019.08.19 18:43:30 4: HMUARTLGW WLAN_HmUART2 StartInit
2019.08.19 18:43:30 5: HMUARTLGW WLAN_HmUART2 send: 00 00
2019.08.19 18:43:30 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:30 5: SW: fd00030001009e03
2019.08.19 18:43:33 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 18:43:33 5: HMUARTLGW WLAN_HmUART2 send: (8): fd00030001009e03
2019.08.19 18:43:33 5: SW: fd00030001009e03
2019.08.19 18:43:34 5: HMUARTLGW WLAN_HmUART2 Attr del verbose
2019.08.19 18:43:37 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 18:43:40 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.08.19 18:43:43 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
Stromversorgung ist sehr gut, doppelt kontrolliert, daran liegt es ebenfalls nicht. Serielle Verbindung liegt an. Ich will eigentlich nicht vermuten, dass der HM-MOD-RPI-PCB das Problem ist - denn der ist neu. Oder doch?

[Otto123]

Hi,

ich verwende beim ESP8266 die zweite Serielle Schnittstelle D7/D8 GPIO13 / GPIO15
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_mit_ESP8266

Das FHEM Modul hat mit dem HMUART auf dem ESPnoch nicht gesprochen - würde ich sagen.

Gruß Otto

[andies]

ich  verwende beim ESP8266 die zweite Serielle Schnittstelle D7/D8 GPIO13 / GPIO15

Habe ich gerade auch versucht:

Code Auswählen Erweitern


2019.08.19 21:07:53 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 21:07:56 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 21:08:00 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.08.19 21:08:04 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.08.19 21:08:04 1: 192.168.2.54:23 reappeared (WLAN_HmUART2)
2019.08.19 21:08:08 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 21:08:11 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 21:08:14 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.08.19 21:08:18 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.08.19 21:08:18 1: 192.168.2.54:23 reappeared (WLAN_HmUART2)
2019.08.19 21:08:22 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.08.19 21:08:25 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.08.19 21:08:28 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending

Ich würde mal sagen, mit meinem ESP07 geht das nicht. Das kann am ESP oder UART-Modul liegen. Da der ESP07 eine Art Exot ist, mach ich mal den verantwortlich und beende das. Ich besorge mir einen Wemos Mini Pro und versuche es mit dem.

[andies]

Ich habe inzwischen ein wenig recherchiert und denke, ich habe das Problem gefunden. Das ist bei den Teilen schlecht dokumentiert. Wir alle wissen, dass man GPIO 0, GPIO 2 und GPIO 15 beim booten nicht beliebig belegen darf, sonst startet der ESP nicht korrekt oder er startet im Programmiermodus oder was auch immer, zum Beispiel https://zoetrope.io/tech-blog/esp8266-bootloader-modes-and-gpio-state-startup/

Was aber oft nicht erwähnt wird: Auch der GPIO 1, also Tx, kann nicht beliebig sein. Vielmehr muss Tx beim starten auf HIGH gezogen werden, sonst startet der ESP nicht richtig. Zwei Quellen hierfür,

• https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/
• http://rabbithole.wwwdotorg.org/2017/03/28/esp8266-gpio.html

Beachtet man das nicht und verwendet den Wemos/ESP07 als UART mit der seriellen Schnittstelle, kann man hier wahnsinnig werden.

Lösung: Pull-up Resistor an Tx.

[andies]

Also, ich habe mich hier verbissen (ich benötige sowohl eine externe WLAN- als auch HM-Antenne, deshalb nutze ich den Wemos pro und kann nicht andere Dinge nehmen) und ich komme nicht wirklich voran. Interessanterweise gibt es über den Pro wenig zu lesen und ein paar Sachen habe ich ja schon herausgefunden, siehe oben Tx muss beim booten offen sein (das ist Firmwareunabhängig). Weitere Dinge sind:

• Beim pro sind 16MB verbaut, man kann aber nur 4MB nutzen, siehe https://www.letscontrolit.com/forum/viewtopic.php?t=3320#p17761
  Also bei esptool mit "-fs 4MB" flashen, alles andere ergibt Mist.
• Angeblich muss man mit "-fm DIO" und nicht "-fm DOUT" flashen (selbe Quelle), ich habe da keine Unterschiede feststellen können. Was es mit DIO und DOUT auf sich hat, steht hier: https://github.com/espressif/esptool/wiki/SPI-Flash-Modes
• Der Wemos pro hat angeblich keinen CH340 verbaut (obwohl das Stefan Frings sagt, http://stefanfrings.de/esp8266/#wemosd1mini), siehe http://www.monohelixlabs.com/wemos-d1-mini-pro-esp8266.htm
  Ich kann da kein Problem erkennen, außer dass man mit dem pro durchaus 115200 baud und mehr flashen kann. Beim einfach mini geht wohl maximal 57600. Aber auch das ist kein wirkliches Problem.

Es ist nach wie vor so, dass ich den Serial Server nicht zum laufen kriege (unter verschiedenen Versionen von ESPEasy, ich probiere jetzt ESPLink, das ich vor diesen Erkenntnissen nicht mal habe hochladen können). Da ich den HM-MOD-UART bereits getauscht habe, kann es nicht daran liegen. Spannung ist ebenfalls konstant 5V, Stützkondensatoren sind dran, Lötstellen wurden überprüft. Ich vermute nach wie vor ein Problem, das mit den Besonderheiten des Wemos pro zu tun hat und wahrscheinlich geht beim flashen irgendwas schief. Natürlich habe ich jedes Mal den Speicher gelöscht vor dem upload.

Der oben genannte Pullup funktioniert bei mir übrigens nicht. Ich muss in der Tat die Verbindung trennen, Strom an und dann Verbindung herstellen. Sonst fährt der wemos pro nicht hoch und bleibt im Boot-Modus.

[andies]

ESP Link lässt sich flashen und gibt dieselben Fehlermeldungen:

Code Auswählen Erweitern

2019.09.29 10:21:28 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
2019.09.29 10:21:32 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 10:21:35 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 10:21:38 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 10:21:41 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
Anbei meine Konfiguration, die sieht doch ok aus, oder?

Im Log sehe ich nur

Code Auswählen Erweitern

193740> Accept port 23, conn=0x3fff6478, pool slot 0
195600> HTTP GET /console/text: 200, 4ms, h=21928 usw usf.
die Microcontroller Console zeigt mir gar keine Ausgaben.

Merkwürdig.

[Otto123]

Moin,

aus meiner Erfahrung ist die config nicht richtig. Ich betreibe es immer so wie im Wiki beschrieben:

Gruß  Otto