HomeMatic Funkmodul HM-MOD-RPI-PCB für Raspberry Pi lässt sich nicht ansprechen

[dieterpau]

Ich betreibe seit ca. 2 Jahren eine fhem Haussteuerung auf einem Raspberry Pi3 mit dem genannten Modul ohne Probleme. Als ich vor ca. 4 Wochen Versuche mit der Steuerung von GPIO-Pins des Raspberry über fhem durchgeführt habe, begannen die Probleme mit dem Funkmodul. Ob hier ein Zusammenhang besteht, kann ich nicht beurteilen. Nachdem die Versuche mit GPIO27 und GPIO16 nicht funktioniert haben, klappt die Steuerung über GPIO20 und GPIO21.
Mein Problem mit dem Funkmodul für die HomeMatic Komponenten ist geblieben. Im Moment lassen sich alle HM-Komponenten nicht ansprechen. Hier meine Definition des Funk-Moduls im fhem:
INTERNALS
CNT                1
Clients           :CUL_HM:
DEF                 /dev/ttyAMA0
DevState        1
DevType         UART
DeviceName   /dev/ttyAMA0@115200
FD                   5
FUUID             5c5b3922-f33f-f3ef-b9dc-57d55499b19e4a2c
FirmwareFile   /opt/fhem/FHEM/firmware/coprocessor_update.eq3
LastOpen        1550919353.53785
NAME              HMUART
NR                   77
PARTIAL
STATE              opened             
TYPE                HMUARTLGW
XmitOpen        0
hmPair             1
model              HM-MOD-UART

READINGS
D-type             HM-MOD-UART
cond                init                     der Wert wechselt ständig zwischen init und disconnected
loadLvl             suspended
state                opened

Im fhem-Log erscheinen alle paar Sekunden diese Einträge:
2019.02.23 14:06:53.708 1:HMUARTLGW HMUART did not respond for the 1. time, resending
2019.02.23 14:06:56.715 1: HMUARTLGW HMUART did not respond for the 2. time, resending
2019.02.23 14:06:59.719 1: HMUARTLGW HMUART did not respond for the 3. time, resending
2019.02.23 14:07:02.725 1: HMUARTLGW HMUART did not respond after all, reopening
2019.02.23 14:07:02.729 3: HMUART device closed
2019.02.23 14:07:02.746 3: Setting HMUART serial parameters to 115200,8,N,1
2019.02.23 14:07:02.751 1: /dev/ttyAMA0 reappeared (HMUART)

Ich habe entsprechend den Anweisungen im wiki.fhem.de/wiki/ für das Modul nochmals alles kontrolliert und einen Firmware-Update und ein Flaschen der Firmware durchgeführt. Ohne Erfolg. Ich habe ein  neues Funkmodul Modul aufgesteckt, leider auch ohne Erfolg. Nun habe ich keine Idee mehr, an was es liegen kann und hoffe, dass mir jemand weiterhelfen kann.

[Pfriemler]

Ich bin da nicht der Experte, aber beim ständigen Statuswechsel eines auf dem GPIO gesteckten HM-Funkmoduls ist meist die serielle Schnittstelle durch das Raspberry-Betriebssystem in Benutzung.
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule wurde beachtet?

[Beta-User]

Gleiche Vermutung, andere Ursache: irgendwelche libs aktiviert, die auf die GPIO zugreifen?

Anmerkungen noch:
- der Thread-Titel ist verbesserungsfähig, besser wäre sowas wie "Allgemeine GPIO-Nutzung und HM-MOD-RPI-PCB verursacht Probleme"
- Das ist eigentlich eher ein SBC-Thema
(- persönlich stehe ich der GPIO-Nutzung am Pi für was anderes als dem HM-Modul und ggf. einer RTC sehr kritisch gegenüber; ich bin froh, keinen Pi mehr als Server-Hardware zu nutzen, der hat auch "gewisse" Nachteile. Verknüpft man Steuerungslogik und Hardware, kann man das später schlecht bis kaum trennen. Muß aber jeder selber wissen...)

[dieterpau]

Ich habe folgende Aktionen nochmals durchgeführt, so wie sie im Wiki ../Raspberri_PI#Verwendung_UART.....  beschrieben sind.

root@raspberrypi:/home/pi# systemctl stop getty@ttyAMA0.service
root@raspberrypi:/home/pi# systemctl disable getty@ttyAMA0.service
root@raspberrypi:/home/pi# systemctl mask getty@ttyAMA0.service
Created symlink from /etc/systemd/system/getty@ttyAMA0.service to /dev/null.
root@raspberrypi:/home/pi#

Anmerkung: Am Ende der config.txt steht
# HomeMatic Funkmodul
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250

Reboot durchgeführt

root@raspberrypi:/home/pi# ls -la /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Feb 24 11:09 /dev/ttyAMA0
root@raspberrypi:/home/pi#

root@raspberrypi:/home/pi# ls -l /dev/serial*
lrwxrwxrwx 1 root root  7 Feb 24 11:08 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Feb 24 11:08 /dev/serial1 -> ttyS0

/dev/serial:
insgesamt 0
drwxr-xr-x 2 root root 60 Feb 24 11:08 by-id
drwxr-xr-x 2 root root 60 Feb 24 11:08 by-path
root@raspberrypi:/home/pi#

Danach sieht eigentlich alles normal aus, aber der Fehler ist weiterhin vorhanden.

[Pfriemler]

Gleiche Vermutung, andere Ursache: irgendwelche libs aktiviert, die auf die GPIO zugreifen?

Irrelevant. Das HM-Funkmodul steckt zwar auf dem GPIO, nutzt dort aber nur die serielle Schnittstelle. Üblicherweise ist die als Konsole freigeschaltet, das muss man deaktivieren.

config.txt habe ich auch so. In der cmdline.txt steht bei mir

Code Auswählen Erweitern

dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=b8a2428f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

"console=serial0,115200" sollte da also NICHT drinstehen. Bin aber aktuell nicht sicher, ob das wirklich erforderlich ist.

Liefern die Tests im Abschnitt "Troubleshooting" des Wiki die richtigen Ausgaben?

[dieterpau]

Die Tests habe ich entsprechend dem Wiki unter Troubleshooting durchgeführt. In meiner vorangegangenen Antwort habe ich die Ergebnisse aus der Console kopiert und in die Antwort eingefügt.
Meine cmdline.txt sieht geringfügig anders aus. Diese wurde nie geändert. Damit hat es über 2 Jahre funktioniert.
Ich habe versucht Bluetooth-Prozesse in Linux zu identifizieren. Diese habe ich gekilled. Aber der HMUART läst sich weiterhin nicht ansprechen und wechselt ständig zwischen "init" und "disconnected".

[Otto123]

Hi,

klingt danach, das irgendetwas Deine serielle Schnittstelle verwendet. Nachdem was Du schreibst hängt es wahrscheinlich mit deinen GPIO Versuchen zusammen.

Einzige Idee, steckt das HM Modul an einen USB seriell Wandler oder bau deine Versuche mit GPIO zurück.

Gruß Otto

[Pfriemler]

Richtig, Otto ...

irgendwelche libs aktiviert, die auf die GPIO zugreifen?

Vielleicht doch nicht irrelevant. GPIO17 und GPIO18 werden auch auf das Modul geführt. GPIO17 ist nur über eine (normalerweise leere) Lötbrücke konnektiert, aber über GPIO18 kann das Modul resettet werden. Das könnte auch das Problem sein.

[dieterpau]

Meine ersten Versuche mit der GPIO Ansteuerung habe ich entsprechend den Angaben auf der Internetseite https://www.elektronik-kompendium.de/sites/raspberry-pi/2202101.htm durchgeführt, allerdings mit GPIO27 (Pin13). Zudem habe ich den User fhem in die Gruppe gpio eingetragen. Nachdem dies nicht funktioniert hat (warum weiß ich nicht), habe ich die die damit erzeugten Verzeichnisse unter /sys/class/gpio wieder gelöscht. Ich habe das System dann auch mal rebootet. Und dann fingen irgenwann mal die Probleme an. Ich habe dann über fhem die Ansteuerung getestet und device vom Typ RPI_GPIO angelegt. Das funktioniert nicht mit allen Pins (warum weiß ich nicht). Letztlich habe ich GPIO20 (Pin38) und GPIO21 (Pin 40) genutzt und das funktioniert. Im Verzeichnis /sys/class/gpio sind dann folgende Verzeichnisse angelegt:
root@raspberrypi:/sys/class/gpio# ls -la
insgesamt 0
drwxrwx---  2 root gpio    0 Feb 24 15:14 .
drwxr-xr-x 52 root root    0 Feb 25 09:46 ..
-rwxrwx---  1 root gpio 4096 Feb 24 15:14 export
lrwxrwxrwx  1 root gpio    0 Feb 24 15:14 gpio20 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio20
lrwxrwxrwx  1 root gpio    0 Feb 24 15:14 gpio21 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio21
lrwxrwxrwx  1 root gpio    0 Feb 24 15:14 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx  1 root gpio    0 Feb 24 15:14 gpiochip100 -> ../../devices/gpiochip2/gpio/gpiochip100
lrwxrwxrwx  1 root gpio    0 Feb 24 15:14 gpiochip128 -> ../../devices/gpiochip1/gpio/gpiochip128
-rwxrwx---  1 root gpio 4096 Feb 24 15:14 unexport
root@raspberrypi:/sys/class/gpio#
Könnte dort irgendetwas fehlen oder falsch sein?
Ich habe auch beide device gpio20 und gpio21 über fhem gelöscht. Die beiden Einträge im Verzeichnis sind dann auch verschwunden. Der Fehler trat aber weiterhin auf.