hmlangw auf ESP32 läuft leider nicht

[andyboeh]

Ob es über WLAN geht, kann ich nicht recht sagen, aber das dürfte hier ohnehin nicht der Grund sein. Deine Fehlermeldungen sind Fehler in der Kommunikation HM-MOD-UART <-> ESP32.

Ich verwende die 1.4.1 Firmware von hier: https://raw.githubusercontent.com/eq-3/ ... update.eq3

An sich wird beim Starten des ESP das verwendete UART-Modul abgefragt und es sollte im Log stehen, wenn was nicht passt. Bei dir kommt es aber gar nicht so weit, denn dieser sync error sollte nicht auftreten. Ansonsten bekommst du den besten Debug-Ouptut (und auch schon direkt beim Start!) wenn du deinen ESP32 per USB anhängst.

Interessant zu wissen wäre also auch noch: Wie sieht die Verkabelung aus? Lang? Kurz? Fliegend? Filigran?

Ich habe es auf zwei verschiedenen Modulen laufen, einmal einem WT32-ETH01 und einmal auf einem HB-RF-ETH - auf letzterem produktiv 24/7.

[andyboeh]

Ah ja, und noch eine Alternative, wenn du FHEM oder eine CCU-basierende Software hast, wäre eine beliebige UART-over-IP Lösung. Das gibt es integriert in ESPHome (https://github.com/oxan/esphome-stream-server) oder ohne (z.B. ESPEasy). Dann kommuniziert die CCU direkt mit dem UART-Modul, ohne Umweg über die HMLGW-Emulation.
Mein Anwendungsfall mit Homegear ist da eher speziell, deshalb benötige ich eine HMLGW-Emulation.

[t0mk]

Moin,

soweit ich weiss, gibt es auch für CCU-basierte Lösungen keine Möglichkeit, ESPEasy oder ESP-LINK zu verwenden, oder? Oder funktioniert das, wenn man, bevor die ganzen CCU-Dienste starten, eine serielle Schnittstelle "over IP" einrichtet, an der dann ein HM-MOD-UART mit der entsprechenden Firmware (V1.4.1) hängt?

Trotzdem ist deine Lösung schon ganz praktisch, da man sich über sowas keine Gedanken machen muss, und des ESP langweilt sich vermutlich eh, egal ob "UART over IP" oder hmlangw

[mariol]

Hi,

habe mal gegen usb gedebugged, da fliegen denn auch die gleichen Fehler rein.
man sieht da sogar, das der esp manchmal neu gestartet wird, der hängt sich wohl beim loggen auf, sodass der watchdog kommt.
die leitungen sind ca.8cm lang. vielleicht stört auch das wlan modul den uart? oder ist es der wroom, anstatt ein wrover?

mit der zweiten lösung, uart over tcp, gibt es denn da noch was anderes als FHEM, was so kommunizieren kann?
hatte früher homegear am laufen, und wollte gerade eine raspberrymatic mal probieren.


könnt ihr da was empfehlen ?


gruß
mario

[t0mk]

Andere Fehler sind definitiv ausgeschlossen: kein Kontakt, Kurzschlüsse, unzureichende Stromversorgung?

Poste ein Bild von deinem Aufbau, vielleicht fällt uns ja was auf.

[mariol]

Moin Moin,

Ich werde morgen nochmal meine Leitungen prüfen, ich hatte vorhin das Gefühl dass die eine Leitung einen leitungsbruch hat gebe morgen Mal eine Rückmeldung.

Ich sage aber trotzdem schon Mal vielen Dank für die tolle Unterstützung hier.

Gruß
Mario

[mariol]

Moin Moin, kleiner Zwischenstand, es sieht schon besser aus, finde ich, aber es ist noch nicht perfekt:
habe noch Fehler, und der Port 2000 antwortet noch net

Bekomme auch neben den timeout noch einen : [E][hmlgw:440]: Error parsing frame


[C][sntp:025]: Setting up SNTP...
[C][hmlgw:039]: Setting up HMLGW server...
[D][hmlgw:044]: Resetting HM module
[D][hmlgw:463]: Sending HM frame: fd0003fe0001141e
[D][hmlgw:233]: readBidcosFrame msgLen set 12 result 3
[D][hmlgw:238]: readBidcosFrame done, msgLen 12 result 17
[D][hmlgw::HMFrame:125]: HM Frame, Counter: 0, Destination: 0, Command: 0, Data
Length: 9, Data: 436f5f4350555f424c
[D][hmlgw:463]: Sending HM frame: fd00030001039e0
[E][uart:015]: Reading from UART timed out at byte 0!
[E][hmlgw:186]: readBidcosFrame
[E][uart:015]: Reading from UART timed out at byte 0!
[E][hmlgw:186]: readBidcosFrame
[D][hmlgw:233]: readBidcosFrame msgLen set 4 result 3
[D][hmlgw:238]: readBidcosFrame done, msgLen 4 result 9
[D][hmlgw::HMFrame:125]: HM Frame, Counter: 1, Destination: 0, Command: 4, Data
Length: 1, Data: 01
[D][hmlgw:233]: readBidcosFrame msgLen set 13 result 3
[D][hmlgw:238]: readBidcosFrame done, msgLen 13 result 18
[D][hmlgw::HMFrame:125]: HM Frame, Counter: 0, Destination: 0, Command: 0, Data
Length: 10, Data: 436f5f4350555f417070
[D][hmlgw:463]: Sending HM frame: fd0003000202140c
[D][hmlgw:233]: readBidcosFrame msgLen set 10 result 3
[D][hmlgw:238]: readBidcosFrame done, msgLen 10 result 15
[D][hmlgw:418]: Frame parsed successfully.
[D][hmlgw::HMFrame:125]: HM Frame, Counter: 2, Destination: 0, Command: 4, Data
Length: 7, Data: 02010003010401
[D][hmlgw:463]: Sending HM frame: fd00030103101274
[D][hmlgw:233]: readBidcosFrame msgLen set 9 result 3
[D][hmlgw:238]: readBidcosFrame done, msgLen 9 result 14
[D][hmlgw:430]: Frame parsed successfully.
[D][hmlgw::HMFrame:125]: HM Frame, Counter: 3, Destination: 1, Command: 4, Data
Length: 6, Data: 070101752369
[D][hmlgw:463]: Sending HM frame: fd000300040b003a
[D][hmlgw:233]: readBidcosFrame msgLen set 14 result 3
[D][hmlgw:213]: ESCAPE msgLen set 14 result 19
[D][hmlgw:238]: readBidcosFrame done, msgLen 14 result 20
[E][hmlgw:440]: Error parsing frame
[app:062]: setup() finished successfully!
[app:102]: ESPHome version 2022.8.0 compiled on Sep 1 2022, 07:29:42


Gruß
Mario

[andyboeh]

Sieht zwar besser aus, aber das "Error parsing frame" am Schluss sollte nicht sein, das ist auch der Grund, warum Port 2000 nicht aktiviert wird - hmlgw schafft es nicht, das Modul korrekt zu initialiseren - in deinem Fall schlägt das Lesen der Seriennummer fehl, das wäre der letzte Teil der Initialisierungssequenz.

Welche Firmware hast du mittlerweile drauf?

[mariol]

Hey, danke für den Tipp, muss ich beim flashen eine Seriennummer oder so mitangeben?

Ich habe die von dir verlinkte Firmware drauf.

Gruß
Mario

[andyboeh]

Nein, die ist im Modul einprogrammiert.