Guten Abend, kann mir jemand helfen? Ich betreibe eine VCCU mit einem HMUARTLGW, das seit 44 Tagen ununterbrochen läuft:
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:
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:
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:
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:
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
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)
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
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!
Zitat von: andies am 09 Juli 2019, 17:25:48
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.
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.
Zitat
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?
ZitatDas 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:
ZitatWird 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?
ZitatSind 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?
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.ZitatDer 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".
ZitatIch 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!
ZitatEs 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
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.
:)
Und wenn Du unsicher bist: esp-link funktioniert mit drei Mausklicks - out-of-the-box wie man so schön sagt.
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:
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:
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:
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?
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
Zitat von: Otto123 am 19 August 2019, 20:59:07
ich verwende beim ESP8266 die zweite Serielle Schnittstelle D7/D8 GPIO13 / GPIO15
Habe ich gerade auch versucht:
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.
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.
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.
ESP Link lässt sich flashen und gibt dieselben Fehlermeldungen:
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
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.
Moin,
aus meiner Erfahrung ist die config nicht richtig. Ich betreibe es immer so wie im Wiki beschrieben (https://wiki.fhem.de/wiki/Datei:Esp-pin_Konfiguration_HMUART.png):
Gruß Otto
Das kann nicht der Grund sein - ich hatte ja swapped probiert und das machte faktisch keinen Unterschied. Zwar ließ sich dann der Wemos überhaupt starten, aber ich konnte keine baud-raten über 57600 mehr nutzen und das Homematic-Teil will 115200. Ich bin mir inzwischen ziemlich sicher, dass der Wemos pro irgendeine Spezifikation hat, die nicht dokumentiert ist und die mir das Leben schwer macht. Als nächstes werde ich mal einen Wemos nicht-pro einsetzen und schauen, ob er (out-of-the-box) funktioniert. Wenn ja, habe ich den Schuldigen am Kragen.
Es scheint ja sonst im Forum auch niemand einen pro zu benutzen, sonst hätten sich diejenigen ja mal gemeldet.
Na gut. Ich vermute immer noch Du jagst einen Geist.
Ich kann Deine Konfig mit meinem Wissen über den ESP nicht nachvollziehen. (die Zuordnung der GPIO Anschlüsse in deinem Bild erzeugen nur Stirnrunzel)
Und irgendwie sehe ich keine äußerlichen Unterschied in der Pin Belegung zwischen ESP07 und ESP12
Aus meiner Sicht kannst Du auf einem Wemos mini (egal ob pro) TX und RX gar nicht wirklich frei nutzen. Dort hängt der USB UART dran. Der stört im Zweifelsfall nur.
Ich sehe auch im Schaltplan bezüglich der Beschaltung von GPIO13 / 15 (D7 / D8 | TX02 / RX02 | der zweiten UART) keinen Unterschied.
Auch sonst ist da nichts entscheidend anders.
https://wiki.wemos.cc/_media/products:d1:sch_d1_mini_v3.0.0.pdf
https://wiki.wemos.cc/_media/products:d1:sch_d1_mini_pro_v2.0.0.pdf
Gruß Otto
Einem Leipziger kann ich nichts ausschlagen ;D. Also habe ich meine Ehe riskiert und nicht die Kids ins Bett gebracht, sondern noch einmal umgelötet und die Pins so wie im Wiki geändert. Ergebnis:
2019.09.29 19:44:37 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 19:44:40 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 19:44:44 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 19:44:48 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.09.29 19:44:48 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
2019.09.29 19:44:53 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 19:44:56 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 19:44:59 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 19:45:02 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.09.29 19:45:02 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
2019.09.29 19:45:06 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 19:45:09 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 19:45:12 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 19:45:15 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.09.29 19:45:15 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
2019.09.29 19:45:19 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 19:45:22 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 19:45:25 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 19:45:28 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.09.29 19:45:28 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
2019.09.29 19:45:32 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.29 19:45:35 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.29 19:45:38 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.29 19:45:41 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
2019.09.29 19:45:41 1: 192.168.2.38:23 reappeared (WLAN_HmUART2)
usw usf
<edit> Ich habe nicht die Version 3.0, das ist mW die Leolin-Originalversion. Ich habe v2.0 vom Wemos mini pro.
:) :) :)
Naja die Pins ändern ist es nicht, Du musst auch die Konfig des esp-link son ändern wie es im Bild des Wiki steht. Also NICHTS konfiguriert außer UART pins SWAPPED
Der erste Link ist der Plan vom Wemos mini - nur um zu zeigen, da ist praktisch kaum ein Unterschied.
Steht den was im debug log vom esp-link ?
Mir geht auch noch der Satz durch den Kopf:
Zitataber ich konnte keine baud-raten über 57600 mehr nutzen und das Homematic-Teil will 115200.
Ich habe noch gar nicht gefunden wo man die baudrate beim esp-link einstellt, der läuft doch per default mit 115200 ? :-\
die baudraten hatte ich noch beim ESPEasy eingestellt. Hier meine Einstellung. Im log steht nichts!! Das irritiert mich auch.
Zitat von: andies am 29 September 2019, 20:03:18
Im log steht nichts!! Das irritiert mich auch.
das glaub ich nicht! Ich meine das debug Log vom esp-link! ganz links ganz unten im Menü
Und Du hast nur diese Pins angeschlossen?
(UART) <-> (Wemos swapped)
3.3V <-> 3.3V
GND <-> GND
Rx <-> D8
Tx <-> D7
Und der Wemos steckt ansonsten nur Strom? Keine anderen Schnittstellen / Monitore aktiv?
ja, ich meine nichts vewertbares:
187558> MQTT: Recv type=PINGRESP id=0000 len=2; Pend type=NULL id=00
247547> MQTT: Send type=PINGREQ id=0000 len=2
247558> MQTT: Recv type=PINGRESP id=0000 len=2; Pend type=NULL id=00
307547> MQTT: Send type=PINGREQ id=0000 len=2
307559> MQTT: Recv type=PINGRESP id=0000 len=2; Pend type=NULL id=00
367547> MQTT: Send type=PINGREQ id=0000 len=2
367559> MQTT: Recv type=PINGRESP id=0000 len=2; Pend type=NULL id=00
390640> HTTP GET /: 302, 5ms, h=19568
390669> HTTP GET /home.html: 200, 17ms, h=19560
390761> HTTP GET /pins: 200, 9ms, h=15504
390763> HTTP GET /wifi/info: 200, 7ms, h=17208
390765> HTTP GET /system/info: 200, 7ms, h=18896
393257> HTTP GET /log.html: 200, 11ms, h=19560
393302> HTTP GET /console.js: 200, 12ms, h=19560
393330> HTTP GET /log/dbg: 200, 7ms, h=19568
393722> HTTP GET /log/text: 200, 8ms, h=19568
422001> Accept port 23, conn=0x3fff65e0, pool slot 0
427547> MQTT: Send type=PINGREQ id=0000 len=2
428594> MQTT: Recv type=PINGRESP id=0000 len=2; Pend type=NULL id=00
430183> Accept port 23, conn=0x3fff66f8, pool slot 1
437711> HTTP GET /log/text: 200, 6ms, h=19184
444068> Accept port 23, conn=0x3fff65e0, pool slot 0
457220> Accept port 23, conn=0x3fff65e0, pool slot 0
Gesendet von iPad mit Tapatalk Pro
ja, anschluss wie oben (gerade noch einmal überprüft) und keine weiteren Anschlüsse.
Gesendet von iPad mit Tapatalk Pro
Ja ok, das debug log sieht bei mir auch so aus. Nichts bezüglich UART drin, außer die Meldung die Du auch hast.
Und das UART Modul hast Du mal separat geprüft? Direkt auf dem Pi. Mit einem USB Seriell Wandler am USB?
ich habe inzwischen zwei (eines fabrikneu), die ich immer wechsle - keine Änderung.
Gesendet von iPad mit Tapatalk Pro
Zitat von: andies am 29 September 2019, 20:22:49
ich habe inzwischen zwei (eines fabrikneu),
Naja das war nicht die Frage auch mal auf Funktion getestet? Die hast Du doch selbst zusammen gelötet? Oder nimmst Du nur das Sendemodul ?
Im Wiki werden von dem ja nicht mal direkt im Bild die Anschlüsse gezeigt sondern nur das Gegenstück.
ich hatte einmal nur das sendemodul genommen und bin dann in beiden fällen auf das gesamte ELV-Modul (HM-MOD-PC-UART) gewechselt, weil sich das leichter auf den 2,54mm Platinen verlöten lässt.
Es könnte natürlich sein, dass beide ELV-Module defekt sind,aber das halte ich für sehr unwahrscheinlich. Wie gesagt, das zweite ist eine Woche alt.
Gesendet von iPad mit Tapatalk Pro
Das die kaputt sind glaub ich auch nicht. Ich habe auch noch nicht gehört das die sehr sensibel sind. Magst Du ein Bild vom Modul posten - nur zur Sicherheit :) :)
der dht-22 ist nicht (mehr) verbunden.
[edit] besseres bild.
Ok Bild sieht gut aus. Keine Idee mehr. Außer die UART Module mal noch anders zu testen und Firmware zu flashen. Es gab mit der Originalfirmware so eine Art "enable" Problem.
Hast Du keinen USB seriell Wandler und kannst die mal an USB anstecken?
danke für die Hilfe! Ich halte Euch auf dem laufenden, ich schlafe erstmal eine Nacht darüber. Das Zeug hält mich seit Monaten auf Trab. Selten war das so zäh, alles andere ging Mausklick und go...
Gesendet von iPad mit Tapatalk Pro
Ich war mir sicher, dass es am Wemos Modul liegt und habe ein neues Modul, diesmal non-pro, eingebaut. Gleiche Installation, flashing, esp-link usw usf. Ergebnis leider wieder
2019.09.30 17:36:30 1: 192.168.2.15:23 reappeared (WLAN_HmUART2)
2019.09.30 17:36:34 1: HMUARTLGW WLAN_HmUART2 did not respond for the 1. time, resending
2019.09.30 17:36:37 1: HMUARTLGW WLAN_HmUART2 did not respond for the 2. time, resending
2019.09.30 17:36:40 1: HMUARTLGW WLAN_HmUART2 did not respond for the 3. time, resending
2019.09.30 17:36:44 1: HMUARTLGW WLAN_HmUART2 did not respond after all, reopening
Hmm. Langsam gehen mir die Ideen aus.
nabend,
Ich war mir ja ziemlich sicher das es nicht der Wemos ist. :)
Tue Dir doch den Gefallen und steck mal das Modul mit 4 Drähten an einen USB Adapter.
Aber das die Module defekt sind glaub ich auch nicht. Entweder ist da noch was falsch zwischen Schnittstelle und Modul (der Draht, irgendwas, Du :))
Also ich kann mich erinnern, es gab trouble solange die Module nicht die neue Firmware hatten. So nach dem Motto aus und einschalten allein hilft nicht, man musste das Modul vom Raspberry abziehen und wieder aufstecken zum resetten.
Oder findest Du einen in Berlin der mal das Modul auf seinen Raspberry steckt? Oder steckst es mir in einen Umschlag und ich teste das mal? Ich bin jetzt demnächst auch nicht in Berlin ...
Gruß Otto
Also ich war gerade dabei, einen ungenutzten RPi herauszuholen und kam auf die Idee, nochmal die Lötstellen durchzumessen. Und siehe da, was sehe ich: Eine Verbindungen zweiter Bahnen, wo keine sein soll. Und ich weiß auch, wo der Kontakt herkommt. Diese Spannungswandler 230V->5V haben kein exaktes 2,54mm Rastermaß, also habe ich zwischen zwei Bahnen ein Loch gebohrt, beim Einsetzen aber anscheinend den Wandler auf die andere Seite gesetzt (was eigentlich nicht hätte gehen dürfen, wegen des falschen Rastermaßes). Das zusätzlich gebohrte Loch habe ich dann fälschlicherweise bei dem Verbindungskabel zwischen UART-Modul und Wemos benutzt und da ist nun ein Kontakt mehr am Modul. Angeblich hat der Anschluss, der da Verbindung hat, keine Bedeutung, aber das ist sicher die Ursache für mein Dilemma.
Ich kann das leider jetzt nicht mehr prüfen, weil ich weg muss, aber ich vermute mal, ich habe die Ursache. Ist nur die Frage, ob dass das UART überlebt hat. Sonst kaufe ich halt ein drittes, man muss für solche Fehler auch hart bestraft werden.
🙈🙈🙈
Zitat(der Draht, irgendwas, Du :))
Na da bin ich gespannt ;) hoffen wir das nichts kaputt ist
Läuft. Wie immer saß das Problem vor dem Gerät.
Gab es da nicht ein Kürzel für? In jedem Fall Danke fürs Mitfiebern!
🍻🐣🙏👍👌🎈🌊🥂
Du meinst LaOla Welle :) ;D