Tinkerboard S mit RaspberryMatic plötzlich nicht mehr erreichbar

[d3h56r]

Hallo Zusammen,

ich bin vor geraumer Zeit von einem Raspberry Pi 3 auf das Tinkerboard S umgestiegen. Die Migration via Backup & Restore lief problemlos und unauffällig und auch sonst finde ich, hat sich der Umstieg gelohnt.

Leider habe ich jedoch seit dem Umstieg das Problem, dass das Tinkerboard nach (Bachgefühl) ca. zwei Wochen fehlerfreien Betriebs urplötzlich die LAN-Konnektivität verliert. Da in diesem Moment kein Zugriff mehr möglich war, hat in einer solchen Situation ein paar mal der unschöne harte Reboot das Problem beheben müssen.

Heute hatte ich die Gelegenheit, wieder mit der Situation konfrontiert zu sein. Diesmal hatte ich jedoch vorgesorgt. Also einen HDMI-Monitor und Tastatur angeschlossen. Vor dem Reboot eine Kopie von /var/log/messages nach /usr/local gemacht und anschließend via "reboot" ordentlich neugestartet, damit hier erst einmal wieder alles läuft.

Im Log steht folgendes (bereinigt um die wg. fehlender Konnektivität spammenden node-red-Einträge):

Code: Alles auswählen

Feb 12 18:29:39 homematic user.err rfd: LGWPortWrapper::keepAliveThreadFunction(): Did not receive reply on keepalive.
Feb 12 18:29:40 homematic user.err rfd: LGWPortWrapper::ReadData(): Receive error
Feb 12 18:29:42 homematic daemon.err upsmon[749]: Poll UPS [ups@192.168.2.2] failed - Server disconnected
Feb 12 18:29:42 homematic daemon.notice upsmon[749]: Communications with UPS ups@192.168.2.2 lost
Feb 12 18:30:00 homematic user.err rfd: (OEQ1234567) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:00 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:08 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:14 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:15 homematic user.err rfd: (OEQ1234567) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:16 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:17 homematic user.err rfd: (OEQ1234567) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:17 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:18 homematic user.err rfd: (OEQ1234567) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:19 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:20 homematic user.err rfd: (OEQ1234567) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:20 homematic user.err rfd: (OEQ9876543) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Feb 12 18:30:24 homematic user.warn monit[1325]: 'internetCheck' status failed (1) -- no output

Ansonsten ist mir nichts außergewöhnliches aufgefallen, außer, dass ab und an mal ein seltener PING mit einer Antwort quittiert wird, während der größte Prozentsatz keine Antwort liefert. RaspberryMatic und alle Services darauf, die nicht auf Internet-/LAN-Konnektivit angewiesen sind, arbeiten weiterhin einwandfrei.

Was kann ich Eurer Ansicht nach tun, um die Ursache weiter einzugrenzen/zu finden?

Viele Grüße!

d3h56r

[d3h56r]

Vielleicht eine ziemlich doofe Frage in Bezug auf meine Rettungsaktion gestern, aber dazu habe ich leider nichts gefunden. Das Kopieren der /var/log/messages gestern war ein ziemlicher Blindflug, weil gefühlt die Hälfte des Bildes außerhalb des Darstellungsbereichs (unterhalb) meines Monitors lag. Erst mehrmaliges Drücken von [Enter] führte zur Anzeige des getippten, bzw. von Ausgaben, die ich via "cat" versucht hatte.

Gibt es dazu einen Trick, bzw. wo kann ich ggf. die Monitor-Auflösung anpassen?

[d3h56r]

Mein Monolog zeigt mir, dass Ihr anscheinend genauso ratlos seid wie ich.

Ist aber auch kein Problem. Manchmal hilft es ja schon, Selbstgespräche zu führen. Und in Zeiten von Corona und Home Office sind Selbstgespräche ja durchaus gesellschaftsfähig geworden.

Ohne den Tag vor dem Abend loben zu wollen: seit dem Update auf die Version 3.55.10.20210213 ist das System (bislang) nicht mehr in den Fehler gelaufen...

[d3h56r]

Mal wieder ein Update von meiner Seite:

Kurz nach meinem letzten Post (~3 Tage) hatte ich wieder das Phänomen. Da mir die Familie allmählich auf die Füße getreten ist, habe ich kurzerhand noch am selben Abend wieder den Wechsel zurück auf den vorher verwendeten Raspberry 3B gemacht.

Das System läuft (auf Holz klopfend) jetzt seit > 8 Tagen stabil. Insofern scheint sich das Thema stark in Richtung Tinkerboard eingrenzen zu lassen. Sehr merkwürdig, insbesondere nachdem ich eigentlich nur positives über das Tinkerboard gelesen hatte.

PS: was mir auch aufgefallen ist, der Raspberry startet gefühlt auch schneller als das Tinkeboard – das hätte ich eigentlich anders herum vermutet?!

[Raspihausfan_1]

... Tinkerboard nach (Bachgefühl) ...

Hmm...,
offensichtlich geht das Tinkerboard S den Bach hinunter ...

Hier gibt es etwas Hilfe, Prüfung des EMMC-Speichers auf der Kommandozeile, oder, falls eine Micro-SD verwendet wird, Karte tauschen:
viewtopic.php?f=65&t=65535&start=70

[d3h56r]

Danke für den Link. Die eMMC ist komplett in Ordnung. Wunder mich auch nicht, da das Tinkerboard ja auch "nagelneu" ist.

[Raspihausfan_1]

OK, dann wären die üblichen Verdächtigen noch SD-Card und Netzteil, insbesondere, wenn das Netzteil schon älter ist (Elkos).

[d3h56r]

Danke, aber auch das habe ich beides durch. SD ist nicht in Verwendung und ich habe sowohl mein Raspi- als auch das zugehörige Tinkerboard-Netzteil dran gehabt. Beide laufen am Raspi u.a. auch problemlos. Ich habe eher den Verdacht, entweder ein grundsätzliches Boardproblem zu haben, oder aber das der LAN-Port eine Macke hat. Das bekomme ich aber abschließend vermutlich nur heraus, wenn ich mir ein zweites Tinkerboard bestelle und schaue, ob es damit fehlerfrei läuft.

[CoolmanHB]

Feb 12 18:29:42 homematic daemon.err upsmon[749]: Poll UPS [ups@192.168.2.2] failed - Server disconnected
Feb 12 18:29:42 homematic daemon.notice upsmon[749]: Communications with UPS ups@192.168.2.2 lost

vielleicht hier ein Lösungsansatz?

viewtopic.php?t=36649&start=60

[d3h56r]

Den Lösungsansatz sehe ich dort leider auch nicht. Der Logeintrag zeigt ja am Ende nur, was ich bereits weiß – auf dem Tinkerboard ist keinerlei LAN-Kommunikation mehr möglich.