*gelöst* HM-MOD-RPI-PCB nach Umstieg auf Bookworm nur noch init/disconnected

[Otto123]

ersten Beitrag den Betreff editieren 

[webdandy]

Hallo,
könnte mir hier vielleicht jemand auf die Sprünge helfen.
Ich bekomme bei einer frischen Bookworm Installation auch ständig einen disconnect.

Folgendes habe ich schon getan:

Code Auswählen Erweitern

enable_uart=1
dtoverlay=miniuart-bt
core_freq=250

Code Auswählen Erweitern

systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

Code Auswählen Erweitern

ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64  1. Feb 10:16 /dev/ttyAMA0
ls -l /dev/serial*
lrwxrwxrwx 1 root root 7  1. Feb 09:57 /dev/serial0 -> ttyAMA0
Habe ich etwas vergessen?

Ich erhalte immer noch:

Code Auswählen Erweitern

024.02.01 10:11:07 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2024.02.01 10:11:10 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2024.02.01 10:11:13 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2024.02.01 10:11:16 1: HMUARTLGW myHmUART did not respond after all, reopening
2024.02.01 10:11:16 3: myHmUART device closed

Danke & Grüße
Fabian

[Otto123]

Hallo Fabian,

welche Generation Pi?
Der 5er muss offenbar anders vorbereitet werden.

Gruß Otto

[webdandy]

Hallo Fabian,

welche Generation Pi?
Der 5er muss offenbar anders vorbereitet werden.

Gruß Otto

Hallo Otto,
sorry zu erwähnen, ich benutze einen 4er.
Grüße
Fabian

[Otto123]

Beim 4er fällt mir die Lüftersteuerung ein: in raspi-config abschalten
Oder Modul stromlos machen, also auschalten und lange warten, bzw. Modul abziehen und eine Weile warten. Insbesondere auch wenn initialUsbcheck vorher zugeschlagen hatte.

[webdandy]

Lüftersteuerung habe ich gerade deaktiviert und stromlos hatte ich den Pi auch schon.
Leider keine Verbesserung:

Code Auswählen Erweitern

2024.02.01 11:43:18 3: Setting myHmUART serial parameters to 115200,8,N,1
2024.02.01 11:43:18 1: /dev/ttyAMA0 reappeared (myHmUART)
2024.02.01 11:43:22 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2024.02.01 11:43:25 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2024.02.01 11:43:28 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2024.02.01 11:43:31 1: HMUARTLGW myHmUART did not respond after all, reopening
2024.02.01 11:43:31 3: myHmUART device closed
2024.02.01 11:43:31 3: Setting myHmUART serial parameters to 115200,8,N,1
2024.02.01 11:43:31 1: /dev/ttyAMA0 reappeared (myHmUART)

Was hatte es mit 99-com.rules zu tun bei den vorherigen Posts?

[webdandy]

Um alles auszuschließen, habe ich ein neues HM-MOD-RPI-PCB aufgesteckt und siehe da, jetzt funktioniert es plötzlich.
War wohl blöderweise das Modul kaputt gegangen...
Jetzt bleibt es "opened" und alls ist schicki.

Danke Otto für Deine Tips.

Grüße
Fabian

[Otto123]

Klingt merkwürdig, aber naja nicht ganz ausgeschlossen. Versuch das nochmal, nachdem das Modul eine Weile rum gelegen hat sozusagen bevor es in den Eimer wandert.

[4eversr]

Ich bin heute mit meinem FHEM von einem Raspberry Pi 2 mit "Buster" auf einen Raspberry Pi 4 mit "Bookworm" umgestiegen.
Es hat alles reibungslos geklappt, mein komplettes FHEM läuft nun einwandfrei mit dem HM-MOD-RPI-PCB auf Bookworm. War mit Backup und ZIP-restore ein Kinderspiel.

Das einzig Ärgerliche/Merwürdige:
Die Monitorausgabe über HDMI an meinen Eizo Monitor funktioniert exakt seit dem Zeitpunkt nicht mehr, wo ich das hier in die /boot/firmware/config.txt zusätzlich eingetragen habe:

enable_uart=1
dtoverlay=miniuart-bt
core_freq=250

Danach dieses Verhalten:
Ich schließe mein, übrigens originales/zertifiziertes, Raspberry-Pi4 Netzteil an, ich sehe den kompletten Bootvorgang noch auf dem HDMI Bildschirm, und dann wenn der Bootvorgang gefühlt bei 90% wäre wird mein Bildschirm schwarz und bleibt es für immer. - Über SSH erreiche ich den Raspberry Pi einwandfrei und auch FHEM funktioniert danach klaglos. Bildschirm bleibt schwarz. Das Verhalten trat direkt nach dem Eintragen und Reboot auf (FHEM war zu diesem Zeitpunkt noch gar nicht installiert, kein CUL/USB-Device angesteckt, es war eine ganz frische Bookworm Installation, die mit apt-get update & upgrade zuvor auf den letzten Stand gebracht wurde)

Super seltsames Verhalten. Habe auch mal testweise ein hdmi_safe=1 in der Config getestet, das Verhalten bleibt. (Übrigens: Bookworm in 64bit als "Lite" ohne Desktopumgebung)


EDIT:
Hat sich hier fürs Form erledigt, denn es scheint nichts mit FHEM / den Settings direkt zu tun zu haben.
ICh lass das hier trotzdem mal drin, falls jemand ähnliche Probleme hat: Scheint ein Bookworm/Linux-Kernel Problem in Zusammenhang mit manchen (Eizo)-Monitoren zu sein. Habe jetzt mal statt meines Eizo Monitores ein 0815-Chinapanel angeschlossen, das wird beim Booten auch kurz schwarz, fängt sich dann aber wieder. - Der Eizo wird Schwarz, fängt sich aber nicht mehr. - Ich vermute durch das apt-get update & upgrade habe ich mir irgendein Bookworm Update reingezogen, was plötzlich zu diesem Verhalten führt, meine ersten Starts mit Bookworm & Eizo-Monitor verliefen alle reibungslos, so dass ich das Problem wohl fälschlich mit den Änderungen in der config.txt in Verbindung brachte.

[Jens_B]

Auch wenn es nicht mit FHEM zu tun hat, versuche ich mich mal an einer Lösung für das Eizo Problem:
Ich könnte mir vorstellen, das die Vertikalfrequenz nicht passt. Welche Frequenzen kann der Eizo denn?
Hast Du mal probiert in der Config.txt den HDMI Mode festzulegen? Bei meine 1. Gehversuchen mit einem PI 1 damals mußte ich das an einem älteren Samsung Monitor auch machen, sonst gabs kein Bild.





Ist nur so eine Idee.