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:
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?
Hi,
was gibt Dir dies in der FHEM Kommandozeile zurück
{qx(systemctl status serial-getty\@ttyAMA0.service)}
Gruß Otto
Hallo Otto,
der Befehl gibt folgendes zurück:
● 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
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 :)
{qx(cat /boot/config.txt | grep -v '^#')}
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:
dtparam=audio=on
enable_uart=1
Hat das Modul die Firmware 1.4.1 ?
Passiert es eigentlich dauerhaft auf closed oder pendelt es immer hin und her?
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.
Ich habe es gefunden. "Wer lesen kann ist klar im Vorteil".
D-firmware 1.4.1 2019-12-11 06:34:45
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?
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.
ist initialUsbCheck aktiv list initialUsbCheck
Wenn ja, dann attr initialUsbCheck disable 1und save hinterher nicht vergessen.
Installiert Conbee irgendwas was an den seriellen Schnittstellen rum macht? Ich kenne das leider nicht.
Nein, einen InitialUsbCheck habe ich nicht aktiv.
lange fhem freezes könnten auch eine ursache sein.
=> zb modul freezemon definieren.
Ich habe das Modul installiert und das steht in der Get Freeze:
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)
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.
ist nicht der "9.13 d:tmr-CUL_HM_procQs(N/A) tmr-HMUARTLGW_StartInit" das Problem an sich? Also nicht freeze und dann disconnect sondern kein connect und deshalb freeze?
Ich glaube nicht, dass da ein Zusammenhang besteht. Das würde ja bedeuten, dass es außerhalb der Freezes mal
einen connect geben würde. Der erfolgt aber nicht. HMUart springt immer von init auf disconected und startet dann wieder mit init.
Ich werde natürlich versuchen die Freezes zu beheben. Mal sehen ob mir das gelingt.
Ich denke, hier redet er kurz:
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)
Aber ich bin ratlos. Ich würde mal schauen ob das conbee (läuft da ein Dienst / Tool ?) irgendwas macht und es deaktivieren. Keine Ahnung wie ...
Ich schau mir den Conbee nochmal an, wenn das nichts bringt, mache ich testweise mal einen Neuinstallation nur mit dem HMUART.
wenn ich mich recht erinnere, gab es doch mal die "notwendigkeit", den hmuart komplett vom gpio zu entfernen, warten und wieder zu montieren.
oder habe ich das geträumt. :)
Das habe ich auch gelesen und schon probiert :-(. Leider ohne Erfolg.
Zitat von: frank am 13 April 2020, 20:20:16
wenn ich mich recht erinnere, gab es doch mal die "notwendigkeit", den hmuart komplett vom gpio zu entfernen, warten und wieder zu montieren.
oder habe ich das geträumt. :)
Hast Du nicht, das war aber eigentlich bei der ersten Inbetriebnahme und hing meines Erachtens mit der Originalfirmware zusammen.
War das ein Bausatz?
Vielleicht mal Buchse nochmals löten.
Ja, das war ein Bausatz. Prüfe ich auch nochmal.
hast du eventuell schon mal an den gpio rumgespielt, oder entsprechende sw benutzt?
Nein, an den GPIOs habe ich nicht herum gespielt.
Gibt es hier schon etwas neues ?
Ich habe das Gleiche Problem.