HM-MOD-RPI-PCB disconnected

[Druzil]

Seit ein paar Tagen habe ich Probleme mit meinen Homematic Komponenten. Ich verwende an meinem Pi das HM-MOD-RPI-PCB Modul und steuere damit einige Homematic Rolladenschalter und einen HM-Taster zur Lichtsteuerung.
Das HM-MOD-RPI-PCB Modul scheint nun nicht mehr richtig zu initialisieren und geht in den Status "disconnected". Meine Geräte zeigen daraufhin alle einen IOErr.

Auszug aus dem Logfile:

Code Auswählen Erweitern

2020.04.13 14:07:47 3: Opening myHmUART device /dev/ttyAMA0
2020.04.13 14:07:47 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.04.13 14:07:47 3: myHmUART device opened
2020.04.13 14:08:17 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.04.13 14:08:17 1: /dev/ttyAMA0 reappeared (myHmUART)
2020.04.13 14:08:21 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2020.04.13 14:08:24 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2020.04.13 14:08:27 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2020.04.13 14:08:30 1: HMUARTLGW myHmUART did not respond after all, reopening
2020.04.13 14:08:30 3: myHmUART device closed

Hat jemand von euch eine Idee, wo der Fehler liegen könnte bzw. wo ich mal schauen muss?

[Otto123]

Hi,

was gibt Dir dies in der FHEM Kommandozeile zurück

Code Auswählen Erweitern

{qx(systemctl status serial-getty\@ttyAMA0.service)}

Gruß Otto

[Druzil]

Hallo Otto,

der Befehl gibt folgendes zurück:

Code Auswählen Erweitern

● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
   Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html

Gruß
Christian

[Otto123]

Ok, das ist gut. Damit scheidet eine Idee aus.

Ich denke irgendetwas stört Deine serielle Schnittstelle. Es klingt ja als ging es schon mal, was hat sich geändert?

Überprüfen wir mal noch die config.txt

Code Auswählen Erweitern

{qx(cat /boot/config.txt | grep -v '^#')}

[Druzil]

Das ist ja das Seltsame. Ich habe schon eine ganze Weile nicht mehr an dem Raspi bzw. dem Fhem gebastelt. Lief alles einwandfrei.

Der Befehl gibt folgendes zurück:

Code Auswählen Erweitern

dtparam=audio=on
enable_uart=1

[Otto123]

Hat das Modul die Firmware 1.4.1 ?

Passiert es eigentlich dauerhaft auf closed oder pendelt es immer hin und her?

[Druzil]

Es pendelt hin und her. Versucht einen init und dann steht es wieder auf disconnected.

Ob ich das Firmware Update auf 1.4 gemacht hab kann ich dir nicht sagen, ist schon eine Weile her, dass ich das installiert habe. Kann ich die Firmware irgendwo auslesen?

Alternativ kann ich auch mal probieren die 1.4 nochmal zu flashen.

[Druzil]

Ich habe es gefunden. "Wer lesen kann ist klar im Vorteil".

D-firmware    1.4.1   2019-12-11 06:34:45

[Otto123]

Das hin und her ist mMn typisch für: Es kämpfen mehrere Prozesse um die Schnittstelle.
Hast Du irgendetwas installiert in letzer Zeit? Oder gab es zum Zeitpunkt des Auftretens einen Neustart / Stromausfall?

[Druzil]

Installiert habe ich nichts. Das letzte war ein Conbee Stick, das ist
aber auch schon 2-3 Monate her. Einen Stromausfall will ich allerdings nicht ausschließen.

[Otto123]

ist initialUsbCheck aktiv

Code Auswählen Erweitern

list initialUsbCheck

Wenn ja, dann

Code Auswählen Erweitern

attr initialUsbCheck disable 1und save hinterher nicht vergessen.

Installiert Conbee irgendwas was an den seriellen Schnittstellen rum macht? Ich kenne das leider nicht.

[Druzil]

Nein, einen InitialUsbCheck habe ich nicht aktiv.

[frank]

lange fhem freezes könnten auch eine ursache sein.
=> zb modul freezemon definieren.

[Druzil]

Ich habe das Modul installiert und das steht in der Get Freeze:

Code Auswählen Erweitern

1 - 2020-04-13: s:17:59:40 e:17:59:42 f:2.395 d:tmr-HUEBridge_GetUpdate(deCONZ) tmr-Shelly_status(shellyBad) tmr-Shelly_status(shellyKueche) tmr-HMUARTLGW_CheckCmdResp(myHmUART)
1 - 2020-04-13: s:18:00:43 e:18:00:45 f:2.409 d:tmr-HUEBridge_GetUpdate(deCONZ) tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyKueche) tmr-Shelly_status(shellyBad)
1 - 2020-04-13: s:18:00:46 e:18:00:47 f:1.521 d:tmr-HMUARTLGW_CheckCmdResp(myHmUART) tmr-RFHEM_GetUpdate(FhemBuero)
1 - 2020-04-13: s:18:01:46 e:18:01:48 f:2.406 d:tmr-HUEBridge_GetUpdate(deCONZ) tmr-MQTT2_SERVER_keepaliveChecker(myBroker)
1 - 2020-04-13: s:18:02:50 e:18:02:56 f:6.097 d:no bad guy found :-(
1 - 2020-04-13: s:18:02:57 e:18:03:06 f:9.13 d:tmr-CUL_HM_procQs(N/A) tmr-HMUARTLGW_StartInit(myHmUART) tmr-CUL_HM_updateConfig(N/A) tmr-HttpUtils_Err(N/A) tmr-HttpUtils_Err(N/A) tmr-HttpUtils_Err(N/A) tmr-HttpUtils_Err(N/A) tmr-HttpUtils_Err(N...
1 - 2020-04-13: s:18:03:12 e:18:03:17 f:5.412 d:tmr-CUL_HM_sndIfOpen(myHmUART) tmr-CUL_HM_procQs(N/A)
1 - 2020-04-13: s:18:03:57 e:18:03:59 f:2.065 d:tmr-CUL_HM_sndIfOpen(myHmUART) tmr-Shelly_status(shellyKueche) tmr-Shelly_status(shellyBad)
1 - 2020-04-13: s:18:05:00 e:18:05:02 f:2.1 d:tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyBad) tmr-Shelly_status(shellyKueche)
1 - 2020-04-13: s:18:06:03 e:18:06:05 f:2.119 d:tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyKueche) tmr-Shelly_status(shellyBad)
1 - 2020-04-13: s:18:07:06 e:18:07:08 f:2.203 d:tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyBad) tmr-Shelly_status(shellyKueche)
1 - 2020-04-13: s:18:08:09 e:18:08:11 f:2.322 d:tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyBad) tmr-Shelly_status(shellyKueche)
1 - 2020-04-13: s:18:09:12 e:18:09:14 f:2.337 d:tmr-MQTT2_SERVER_keepaliveChecker(myBroker) tmr-Shelly_status(shellyBad) tmr-Shelly_status(shellyKueche) 

[frank]

und gibt es einen zusammenhang mit den disconnects?
das sieht man in fhem.log natürlich besser. von diesen freezes könnte eventuell der 9s-freeze "tötlich" sein.

alle anderen würden mich extrem stören, sollten aber keine ursache für die disconnects sein.