[gelöst] HM-MOD-RPI-PCB auf Raspberry Pi 5

[Joker]

Hi,
ich benutze seit vielen Jahren Homematic Classic auf einem Raspberry Pi 3 mit einem HM-MOD-RPI-PCB als Funkmodul.

Nun habe ich mir einen Raspberry Pi 5 aufgesetzt mit RaspberryMatic und HmIP-RFUSB zur Anbindung von HomeMatic IP Geräten.

Da ich jetzt FHEM (bisher auch auf dem Pi 3) auch auf den Pi 5 umziehen möchte, will ich das HM-MOD-RPI-PCB auch dort nutzen (Homematic Classic will ich über CUL_HM weiter betreiben). Ich versuche das mittlerweile seit 2 Tagen, aber es läuft nicht:
Das Reading "cond" im HMUARTLGW wechselt immer zwischen "init" und "disconnected".
Natürlich habe ich schon mit den diversen DT-Overlays herumgespielt, die Raspi Dokumentation über die UART Konfiguration rauf und runter gelesen und auch die diversen Wiki-Seiten (z.B. hier). Jetzt habe ich keine Idee mehr.
Hier ein List vom Device:

Code Auswählen Erweitern

Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DevState   1
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         4
   FUUID      66f7bb3e-f33f-a1b2-0730-eb0e7cedd2afb4fa
   LastOpen   1727513949.07155
   NAME       HMUART1
   NOTIFYDEV  global
   NR         42
   NTFY_ORDER 47-HMUART1
   PARTIAL    fd001c01f4050000350a86534043db0000d24200d24300004400001bb0
   RAWMSG     0500003CA0845E36CF9500000083582D000000000008CC06
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   eventCount 138
   model      HM-MOD-UART
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1727513950.07283
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2024-09-28 10:34:42   D-type          HM-MOD-UART
     2024-09-28 10:59:10   cond            init
     2024-09-28 10:34:42   loadLvl         suspended
     2024-09-28 10:59:09   state           opened
Attributes:
Daher lange Rede kurzer Sinn: Hat jemand das HM-MOD-RPI-PCB am Raspberry Pi 5 (mit Bookworm) am laufen oder sonst eine Idee woran das liegen könnte? Auf dem anderen Pi funktioniert es wie gesagt ohne Probleme.

[Otto123]

Hi,

hier steht wie es geht https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule

Code Auswählen Erweitern

Beim Pi 5 muss die UART0 aktiviert werden:

# serielle Schnittstelle UART0 aktivieren
# für Raspberry OS die Lage der Firmware Datei kann bei anderen OS abweichen
config="/boot/firmware/config.txt"

bash -c "cat <<EOF >> $config
dtoverlay=uart0
EOF"
Also in der /boot/firmware/config.txt darf nur dieses Overlay und dieser Eintrag zusätzlich zum Originalzustand  stehen!

Gruß Otto

[Joker]

Hmja, das kenn ich leider schon... ich hab schon etliche Varianten probiert die man so findet... und auch nur mit
dtoverlay=uart0
ist das Verhalten wie oben beschrieben 

So sieht meine /boot/firmware/config.txt aktuell aus:

Code Auswählen Erweitern

pi@automationpi:~ $ cat /boot/firmware/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]
dtoverlay=uart0
Es handelt sich ansonsten um ein frisch installiertes Raspberry Pi OS Lite 64bit...

[Otto123]

was liefert

Code Auswählen Erweitern

ls -l /dev/ttyAMA0

[Joker]

Code Auswählen Erweitern

pi@automationpi:~ $ ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Sep 28 15:48 /dev/ttyAMA0

Code Auswählen Erweitern

pi@automationpi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 8 Sep 28 15:48 /dev/serial0 -> ttyAMA10

Code Auswählen Erweitern

pi@automationpi:~ $ ls -l /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64 Sep 28 15:48 /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 74 Sep 28 15:48 /dev/ttyAMA10
Sieht für mich auch soweit korrekt aus. /dev/serial0 zeigt zwar auf ttyAMA10, aber das sollte ja eigentlich keine Rolle spielen wenn im HMUARTLGW Device /dev/ttyAMA0 als Schnittstelle verwendet wird....

[Otto123]

Die Erkenntnis im Wiki beruht auf dem Thread https://forum.fhem.de/index.php?topic=138389.45
Ich kann es mangels Pi5 nicht praktisch nachvollziehen.
Laut deinem list im ersten Post hat das Modul noch nie mit FHEM gesprochen.

Es ist das Modul was am anderen Pi funktioniert? Es gab hier doch schon wirklich mal ein Defektes.

[Joker]

Aktuell ist es nicht dasselbe Modul. Der erste Pi ist mein Produktivsystem - ich hatte zuerst dessen HM-MOD-RPI-PCB testweise an den Pi5 gesteckt und dann gemerkt dass es scheinbar Probleme gibt. Daher wieder zurück gesteckt, denn sonst ist mein halbes Haus funktionslos (und es funktioniert natürlich auch wieder am ersten Pi).

Jetzt steckt ein anderes HM-MOD-RPI-PCB am Pi5, das zuvor aber an einem weiteren Pi steckte (und natürlich funktionierte), den ich zur Reichweitenerweiterung per socat als weiteres HMUARTLGW im FHEM eingebunden hatte. Lange Rede kurzer Sinn: Das Modul was aktuell rumzickt hat an einem anderen Pi funktioniert...

[Otto123]

es gibt mehrere Dinge die stören könnten:
Hast Du initalUsbCheck aus?
Hast Du den Pi mal vom Strom getrennt? Also nicht nur reboot.

[Joker]

Ja, initialUsbCheck habe ich komplett entfernt.
Vom Strom getrennt habe ich schon etliche Male. Ich habe gerade aus Verzweiflung mal das HM-MOD-RPI-PCB abgenommen und alle Lötpunkte nachgelötet -> auch keine Änderung.
Jetzt habe ich das Modul wieder an den Pi zur Reichweitenerweiterung angesteckt -> funktioniert dort sofort.

Ich bin ratlos 

[Otto123]

tue nichts aus Verzweiflung, da geht noch mehr kaputt 

FHEM läuft mit user fhem und user fhem ist in der Gruppe dialout?
die serielle console ist deaktiviert (siehe wiki)?

[Joker]

Ja... das passt alles. User ist fhem:

Code Auswählen Erweitern

pi@automationpi:~ $ cat /etc/systemd/system/fhem.service
# $Id: fhem.service 28505 2024-02-11 21:07:06Z betateilchen $

[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target

# In case of suspicious reconnect problems after reboot
# you can try to replace the above lines for
# network target by the below lines with
# network-online.target
#
# network-online.target will only work if
# "modern" network management tools (e.g. NetworkManager)
# are used.
#
# Wants=network-online.target
# After=network-online.target

#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always

[Install]
WantedBy=multi-user.target
User fhem ist in der Gruppe dialout:

Code Auswählen Erweitern

pi@automationpi:~ $ id fhem
uid=999(fhem) gid=20(dialout) groups=20(dialout)
Konsole sollte deaktiviert sein. Ich habs über raspi-config -> Serial Interface ausgeschaltet. Wobei es glaube ich beim Pi 5 sogar egal wäre, weil soweit ich es verstanden habe die Konsole auf dem ttyAMA10, also auf dem separaten Anschluss läuft...

[Otto123]

weil soweit ich es verstanden habe die Konsole auf dem ttyAMA10, ...

so hatte ich es auch verstanden, deswegen habe ich es auch so ins Wiki geschrieben.
Der Pi 5 hat doch auch keine Lüftersteuerung die über GPIO geht  Bluetooth läuft bei dem auch separat. Ich verstehe es nicht ...

[Joker]

Hier mal noch was interessantes. Ich habe ja wie gesagt einen Pi3 mit HM-MOD-RPI-PCB als Produktivsystem. Den habe ich mal auf "close" gesetzt, dann "attr verbose 5" und dann auf "open". Das Log zeigt folgendes (als erste Message, danach geht es natürlich weiter):

Code Auswählen Erweitern

2024.09.29 21:13:33 3: Opening HMUART1 device /dev/ttyAMA0
2024.09.29 21:13:33 3: Setting HMUART1 serial parameters to 115200,8,N,1
2024.09.29 21:13:33 3: HMUART1 device opened
2024.09.29 21:13:34 4: HMUARTLGW HMUART1 StartInit
2024.09.29 21:13:34 5: HMUARTLGW HMUART1 send: 00 00
2024.09.29 21:13:34 5: HMUARTLGW HMUART1 send: (8): fd00030001009e03
2024.09.29 21:13:34 5: DevIo_SimpleWrite HMUART1: fd00030001009e03
2024.09.29 21:13:34 5: HMUARTLGW HMUART1 read raw (44): fd000400f604019585fd000c000000436f5f4350555f424c7251fd000d00010402436f5f4350555f424c7f7b
2024.09.29 21:13:34 5: HMUARTLGW HMUART1 read (8): fd000400f604019585 crc OK
Wenn ich genau das gleiche am Pi 5 mache, dann passiert folgendes:

Code Auswählen Erweitern

2024.09.29 20:23:15 3: Opening HMUART1 device /dev/ttyAMA0
2024.09.29 20:23:15 3: Setting HMUART1 serial parameters to 115200,8,N,1
2024.09.29 20:23:15 3: HMUART1 device opened
2024.09.29 20:23:16 4: HMUARTLGW HMUART1 StartInit
2024.09.29 20:23:16 5: HMUARTLGW HMUART1 send: 00 00
2024.09.29 20:23:16 5: HMUARTLGW HMUART1 send: (8): fd00030001009e03
2024.09.29 20:23:16 5: DevIo_SimpleWrite HMUART1: fd00030001009e03
2024.09.29 20:23:16 5: HMUARTLGW HMUART1 read raw (14): 010402436f5f4350555f424c7f7b
2024.09.29 20:23:19 1: HMUARTLGW HMUART1 did not respond for the 1. time, resending
Man sieht es wird was empfangen, und auch nicht nur irgendein Schmutz. Sondern genau das Ende der erwarteten Nachricht, wenn man die beiden vorletzten Zeilen jeweils vergleicht.
Was zur Hölle? 

[Joker]

Ich werd komplett irre.
Mit der obigen Erkenntnis, dem Suchbegriff "Pi 5 UART Data missing" und der Einschränkung auf "letzten Monat" in Google, habe ich folgenden Thread gefunden:
https://forums.raspberrypi.com/viewtopic.php?t=376532&sid=a0f2c92156b8ae9ae8b56924d4c88ed9

Nach der Durchsicht habe ich mit

Code Auswählen Erweitern

sudo rpi-update pulls/6377einen Patch der noch nicht offiziell veröffentlich ist gezogen (https://github.com/raspberrypi/linux/pull/6377).

Und was soll ich sagen. Hier der neue List des HMUART auf dem Pi5:

Code Auswählen Erweitern

nternals:
   AssignedPeerCnt 0
   CNT        27
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     27
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         4
   FUUID      66f96f16-f33f-d3cd-168d-2d20282afd74a4e3
   LastOpen   1727640128.77513
   NAME       HMUART1
   NOTIFYDEV  global
   NR         42
   NTFY_ORDER 47-HMUART1
   PARTIAL   
   RAWMSG     040200
   RSSI       -51
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   eventCount 30
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      26ED12
   Helper:
     CreditTimer 12
     FW         66561
     Initialized 1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
       Delay      0.00267505645751953
     loadLvl:
       lastHistory 1727640138.54374
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2024-09-29 22:02:18   D-HMIdAssigned  26ED12
     2024-09-29 22:02:18   D-HMIdOriginal  59E589
     2024-09-29 22:02:18   D-firmware      1.4.1
     2024-09-29 22:02:18   D-serialNr      OEQ0610409
     2024-09-29 22:02:08   D-type          HM-MOD-UART
     2024-09-29 22:02:18   cond            ok
     2024-09-29 22:02:18   load            0
     2024-09-29 22:02:18   loadLvl         low
     2024-09-29 22:02:08   state           opened
Attributes:
   verbose    5
  

[Otto123]

Glückwunsch! Klingt irgendwie verrückt...