Hallo alle,
ich habe heute den RPI-PCB Sender auf meinen PI 2 gebaut. Bringe das Teil aber nicht ordentlich zum laufen. Im FHEM log bekomme ich immer:
2019.04.07 21:11:49 1 : /dev/ttyAMA0 reappeared (HMLAN1)
2019.04.07 21:11:53 1 : HMUARTLGW HMLAN1 did not respond for the 1. time, resending
2019.04.07 21:11:56 1 : HMUARTLGW HMLAN1 did not respond for the 2. time, resending
2019.04.07 21:11:59 1 : HMUARTLGW HMLAN1 did not respond for the 3. time, resending
2019.04.07 21:12:02 1 : HMUARTLGW HMLAN1 did not respond after all, reopening
2019.04.07 21:12:02 3 : HMLAN1 device closed
Ich habe das Modul definiert mit:
define HMLAN1 HMUARTLGW /dev/ttyAMA0
Dann das Attribut gesetzt (mit meiner HMiD):
attr myHmUART hmId xxxx
Kann mir jemand einen Tipp geben wie ich weiter machen kann, oder welche Details zur Hilfe noch zu geben wären. Vielen Dank!
System: Raspi 2B mit externer Antenne im LAN
Wie ist dein UART konfiguriert?
https://wiki.fhem.de/wiki/HMUARTLGW#Aktivierung_der_seriellen_Schnittstelle_auf_RPi1.2F2.2F3_unter_Jessie
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Und zeig mal ein Bild der HM Baugruppe.
Hatten hier die letzte Zeit schon das eine oder andere falsch gelötet...
Gesendet von meinem Doogee S60 mit Tapatalk
bzw. vergleich einfach mal mit den Bildern im Artikel.
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
@amemomade: Genau so habe ich mein UART konfiguriert. Anbei der Status:
sudo ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Apr 8 08:42 /dev/ttyAMA0
@Otto123, Frank_Huber: Habe Bilder kontrolliert und das Teil ist richtig zusammengebaut.
Habt Ihr noch eine Idee woran es sonst noch liegen kann?
Moin,
was liefert?
ls -l /dev/serial*
Du hast einen Pi2 da ist nicht viel zu tun. Die Log Ausgabe klingt danach: Das Modul reagiert nicht, also keine Verbindung der UART zum Modul.
Auch kein Schluss/Zinnbrücke zwischen den Anschlüssen? Stecker auf der richtigen Seite?
Gruß Otto
Hast Du GPIO in FHEM definiert?
falls ja müssen die GPIO_14 und GPIO_15 in FHEM gelöscht werden.
(den Fehler hatte ich mal auf meinem Test-PI gemacht)
@Otto123:
ls -l /dev/serial*
lrwxrwxrwx 1 root root 7 Apr 8 08:24 /dev/serial0 -> ttyAMA0
@Frank_Huber:
GPIO habe ich in FHEM nicht defniert
Ich schau jetzt nochmal nach einer Lötbrücke...
... da ist keine Lötbrücke und ich meine auch, dass ich das richtig montiert habe ... trotzdem die Bilder, falls Euch was auffällt.
Sieht eigentlich alles gut aus. Klingt aber wirklich danach, als ob in FHEM irgendeiner die Schnittstelle blockiert.
Hast du den USB Check abgeschaltet?:attr initialUsbCheck disable 1nicht das der beim FHEM Start irgendwas macht.
Es gab irgendwie (früher) hartnäckige Fälle, da musst das Modul runter, alles ne Weile aus und dann wieder zusammenbau und Start. Aber das hattest Du ja gerade wegen der Bilder.
Hast Du einen USB Adapter CP2102 oder so rumliegen? Damit könntest Du es mal am USB testen.
Gruß Otto
MEISTER!!! Danke! Es war der USB check... ich dachte ich hätte den schon abgeschalten, aber scheinbar dann nicht ordentlich gesichert. Jetzt funktionierts.
Schönen Tag Dir noch!
Schön!
Danke für die prompte Rückmeldung - ich habe das noch im Wiki (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Originaler_Einsatzzweck_im_Raspberry) nachgetragen.
Zitat von: Otto123 am 08 April 2019, 08:53:22
Moin,
Hi Otto, ich habe eine Frage und wusste nicht, wie ich Dich am besten erreichen kann (daher kapere ich diesen Thread). In dem Wiki-Artikel
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Zusammenbau_und_Verwendung
steht, dass man das UART-Modul oben und unten an die Verbindungsplatine setzen kann und mW hast Du das eingefügt. Mich irritiert, dass dann doch die im selben Artikel genannte Verkabelung nicht mehr passt und die Bohrlöcher doch durchkonnektiert sind. Dann wäre 3.3V auf, ich glaube, Rx usw.
Kannst Du (mich) da aufklären?
Moin,
richtig, alle Löcher sind durchkontaktiert. Damit ist ja oben wie unten. Die Bilder zeigen es doch gut. Dabei wird ja nichts gedreht, die beiden Platinen werden ja nur in unterschiedlicher Reihenfolge übereinander gelegt und die "Durchkontaktierung" wird ja quasi nur verlängert.
Ich habe den Abschnitt Zusammenbau und Verwendung gemacht. Es ist wichtig dies so zu tun wie die beiden Bilder es zeigen.
https://wiki.fhem.de/w/images/a/ae/HM-MOD-UART-Oben.jpg
https://wiki.fhem.de/w/images/6/65/HM-MOD-UART-Unten.jpg
Es gab leider Fälle, da hat jemand eine der beiden Platinen auf die andere Seite gedreht, da passiert genau das was Du meinst.
Diese beiden Bilder zeigen die gleiche Platine jeweils von der anderen Seite. Steht aber auch so im Text:
https://wiki.fhem.de/w/images/1/11/Verkabelung-HM-MOD-uart.png
https://wiki.fhem.de/w/images/a/a6/Hm-uart_trx1.png
ZitatDie Anschlüsse sind dem nachstehenden Bild zu entnehmen, allerdings ist hier nicht die UART-Platine, sondern das TRX1-Gegenstück zu sehen!
Gruß Otto
Kapiert. Dann schreibe ich da noch einen Satz dazu, damit es Noobs wie mich nicht verwirrt.
EDIT: Done.
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 (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
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?
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.
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.
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
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
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
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
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
zeig mal ein list vom hmuart.
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
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.
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
# 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
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.
Lies mal https://wiki.fhem.de/wiki/Raspberry_Pi (https://wiki.fhem.de/wiki/Raspberry_Pi) und dort ,,Kontrolle der seriellen Schnittstelle", da passt was nicht.
Ich denke Du hast das vergessen:
# 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
Hallo Otto und andies,
vielen Dank für die Unterstützung.
Letztendlich hat der Hinweis von Otto zum Erfolg geführt.
# 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