HM-MOD-RPI-PCB mit HMUARTLGW - did not respond after all, reopening

Joe4630 · 20 Oktober 2019, 23:48:35

Von mir noch ein kleiner Hinweis nachdem ich gerade nach Stunden verbracht habe einen Raspi mit HM-MOD-RPI Modul als Lan Gateway HMUARTLGW ans laufen zu bekommen habe.
Ein Hinweis von Otto123 brachte dann schließlich den Druchbruch.
Ich bin der Anleitung https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Originaler_Einsatzzweck_im_Raspberry gefolgt und habe socat auf dem Raspi installiert (ser2net funktionierte nicht), der als Gatway dient. Ich weiß nicht warum, aber der Raspi auf dem FHEM läuft, konnte keine Verbindung aufbauen:

2019.10.20 23:26:55 1: 192.168.255.186:2000 reappeared (myRemoteHmUART)
2019.10.20 23:26:59 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.10.20 23:27:02 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.10.20 23:27:05 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.10.20 23:27:08 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.10.20 23:27:08 3: myRemoteHmUART device closed
2019.10.20 23:27:08 1: 192.168.255.186:2000 reappeared (myRemoteHmUART)
usw...

Dann der Hinweis von Otto doch einmal den Raspi mit Modul eine Weile komplett ausgeschaltet zu lassen. Also Spannung weg.

Ohne was danach zu verändern lief dann die Verbindung. Ein neustart des Raspi reichete NICHT!

Vielleicht hilft das jemanden der ähnliche Probleme hat etwas Zeit zu sparen.

Viele Grüße

frank · 21 Oktober 2019, 10:10:22

ZitatOhne was danach zu verändern lief dann die Verbindung. Ein neustart des Raspi reichete NICHT!

das hört sich für mich so an, dass du dich demnächst hier wieder meldest.

hattest du mal im sys.log des pi geschaut, zb wegen serial2net?

Otto123 · 21 Oktober 2019, 10:35:54

Zitat von: Joe4630 am 20 Oktober 2019, 23:48:35
Dann der Hinweis von Otto doch einmal den Raspi mit Modul eine Weile komplett ausgeschaltet zu lassen. Also Spannung weg.

Hast Du die D-firmware 1.4.1 drauf? Ich hatte dieses Verhalten nur mit der ganz alten Firmware damals bei der ersten Auslieferung.

ole30419 · 07 Februar 2020, 08:42:29

Hallo,
ich brauch Eure Hilfe. Ich habe mir eine WiFi Raum-Thermostaten geklickt und habe es, wie in der wiki.fhem.de/wiki/BEOK beschrieben installiert. Das Thermostaten ist in Fhem erreichbar und funktioniert, aber jetzt ist meinem HM-MOD-UART-Modul auf einen PI3 Buster OS nicht mehr erreichbar, was vorher definitiv funktioniert hat.

Für die Installation vom Wifi Raum Thermostat musste ich unter anderem das ,,Crypt/OpenSSL/AES.pm" Paket nach laden und installieren nach dem reboot vom PI3 bekomme ich folgende Fehlermeldung und das HM-MOD-UART-Modul ist nicht mehr erreichbar.

Code Auswählen

2020.02.06 19:52:57 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.02.06 19:52:57 1: /dev/ttyAMA0 reappeared (myHmUART)
2020.02.06 19:53:01 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2020.02.06 19:53:04 1: HMUARTLGW myHmUART did not respond for the 2. time, resending

Gruß Karsten

Otto123 · 07 Februar 2020, 08:59:09

Moin,

was sagt das Modul im Log wenn Du es mal auf verbose 5 stellst?

Auf den ersten Blick kann ich nicht erkennen, dass das Eine was mit dem Anderen zu tun haben soll. Aber wer weiß

Gruß Otto

ole30419 · 07 Februar 2020, 09:16:13

Hallo Otto,
ich habe erstmal das zuvor gesicherte Image wieder auf die SD-Karte geschrieben und danach konnte ich die HM-Geräte wieder erreichen.
Ich werde mir heute Nachmittag mal ein zweite SD-Karte neben und noch mal die Pakete für das WiFi Raum-Thermostaten installieren und danach das Log für das HM-MOD-UART-Modul auf verbose auf 5 stellen.

Vielleicht liegt es auch nicht an dem AES.pm Paket, ich habe ja laut wiki auch sudo apt-get install libcrypt-cbc-perl, libcrypt-rijndael-perl, libssl-dev gemacht.

Gruß Karsten

Otto123 · 07 Februar 2020, 09:27:53

Hallo Karsten,

deswegen, aus den Paketen die laut Wiki installiert werden konnte ich nicht ableiten, das es dann nicht mehr geht. Aber das HMUARTLGW Modul verwendet das Modul libcrypt-rijndael-perl - wenn die anderen crypt Dinger da was "kaputt" machen könnte es schon sein.

Gruß Otto

Wzut · 07 Februar 2020, 09:36:38

Zitat von: Otto123 am 07 Februar 2020, 08:59:09
Auf den ersten Blick kann ich nicht erkennen, dass das Eine was mit dem Anderen zu tun haben soll. Aber wer weiß

ich hänge mich als Verursacher von 38_BEOK mal hier rein.
Bei mir (unter Stretch) macht Crypt/OpenSSL/AES.pm keine Probleme in Verbindung mit aes & HmUART,
die Frage ist nun ob dies unter Buster anderes sein könnte

frank · 07 Februar 2020, 09:39:12

zeig mal ein list vom hmuart.

ole30419 · 07 Februar 2020, 14:52:19

Hallo Jungs,
was soll ich sagen habe es gerade noch ein mal ausprobiert, sowie in der wiki.fhem.de/wiki/BEOK beschrieben:
-alle Pakete installiere
-danach das WiFi Raum-Thermostaten und Device angelegt
-Reboot von PI

Und bis jetzt läuft alles, HM-Gräte und das Thermostaten.

Ich hoffe das bleibt so

Danke und Gruß Karsten

MikeA · 25 März 2020, 05:01:56

Hi, ich möchte diesen Fred noch einmal aufwärmen.
ich habe aktuell das Problem bei der Portierung von einem Raspi II auf das neue Modell IV.
Fhem soll dann auf dem neuen Raspi laufen was mir aber nicht gelingt.
Die Installation von FHEM selber ist abgeschlossen, Konfiguration (fhem.cfg) vom alten Raspi übernommen, fhem startet, jedoch funktioniert das Modul nicht. Das Log zeigt dass das Modul anscheinend nicht erreichbar ist.

Code Auswählen


2020.03.25 04:32:47 3: myHmUART device closed
2020.03.25 04:32:47 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.03.25 04:32:47 1: /dev/ttyAMA0 reappeared (myHmUART)
2020.03.25 04:32:51 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2020.03.25 04:32:54 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2020.03.25 04:32:57 1: HMUARTLGW myHmUART did not respond for the 3. time, resending

In der fhem.cfg wird das Modul wie folgt angesprochen

Code Auswählen


# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 5d603185-f33f-7f7d-a601-59dec809a8283997
attr initialUsbCheck disable 1
define myHmUART HMUARTLGW /dev/ttyAMA0
setuuid myHmUART 5d603186-f33f-7f7d-134a-55590f0ef3381ba1
attr myHmUART hmId 29A216

In der Datei /boot/config.txt ist die Option gesetzt:
enable_uart=1

Die Abfrage "ls -l /dev/ttyAMA0" ergibt:
crw-rw---- 1 root dialout 204, 64 MÃ¤r 25 04:50 /dev/ttyAMA0

Die Abfrage "ls -l /dev/serial* ergibt:
lrwxrwxrwx 1 root root 5 MÃ¤r 25 04:17 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 MÃ¤r 25 04:17 /dev/serial1 -> ttyAMA0

So wie es sich mir darstellt wird die Schnittstelle richtig erkannt. Nur kann fhem sie anscheinend nicht ansprechen.
Gibt es vielleicht noch Schritte die ich nicht bedacht habe ? Habe meines Wissens alles wie hier in der Anleitung beschrieben gemacht.

Wenn ich das Modul wieder auf den alten Raspi stecke und diesen starte funktioniert alles wieder wie gehabt.

Muss ich bei dem neuen Raspi noch etwas anderes berücksichtigen ?
Hat es etwas mit der setuuid in der config zu tun ? Das hier vielleicht eine andere ID benötigt wird weil sich ja der Raspi geändert hat ?

Ich wäre füe jede Hilfe dankbar.

LG
Mike

andies · 25 März 2020, 06:24:42

Zitat von: MikeA am 25 März 2020, 05:01:56
Hat es etwas mit der setuuid in der config zu tun ?

Nein, das wird automatisch zugewiesen und sollte damit nichts zu tun haben.

andies · 25 März 2020, 06:31:12

Lies mal https://wiki.fhem.de/wiki/Raspberry_Pi und dort ,,Kontrolle der seriellen Schnittstelle", da passt was nicht.

Otto123 · 25 März 2020, 09:05:40

Ich denke Du hast das vergessen:

Code Auswählen

# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

Ich bin nicht sicher mit der Konfiguration wenn man die Schnittstellen nicht tauscht - miniuart-bt Overlay.
Versuch doch mal lieber die Konfig komplette entsprechend Wiki: https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule

MikeA · 25 März 2020, 14:58:31

Hallo Otto und andies,

vielen Dank für die Unterstützung.
Letztendlich hat der Hinweis von Otto zum Erfolg geführt.

Code Auswählen

# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

Scheint nun alles wie gewöhnt zu laufen.
Prima, jetzt habe ich ein schnelles FHEM was dann auch später die Gartenbewässerung steuern kann.
Ist doch schön wenn einem kompetente Hilfe zur Verfügung steht.

Danke an euch beide.

LG

Mike