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 (https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule)). Jetzt habe ich keine Idee mehr.
Hier ein List vom Device:
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.
Hi,
hier steht wie es geht https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule
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
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:
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...
was liefert
ls -l /dev/ttyAMA0
pi@automationpi:~ $ ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Sep 28 15:48 /dev/ttyAMA0
pi@automationpi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 8 Sep 28 15:48 /dev/serial0 -> ttyAMA10
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....
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.
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 ;D (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...
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.
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 :P
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)?
Ja... das passt alles. User ist fhem:
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:
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...
Zitat von: Joker am 29 September 2024, 17:20:53weil 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 ...
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):
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:
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? :o
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
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:
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
:o :o
Glückwunsch! Klingt irgendwie verrückt...