Raspberry stürzt hin und wieder einfach ab - Log File Hinweise?

[twoxx]

dazu hätte ich bereits in der vergangenheit mehrfach die möglichkeit gehabt.

Die Möglichkeit hast Du grundsätzlich in jedem Post, denn das Icon ist im öffentlichen Bereich immer verfügbar. Ob dieses auch begründet wäre, steht auf einem anderen Blatt.

Dafür, dass Dir das nicht wichtig ist, trittst Du aber mit einer bemerkenswerten Vehemenz auf.

Gruß Xel66

da hast du recht. ich konzentriere mich auf homematic und nicht auf dich

[Xel66]

ich konzentriere mich auf homematic

Das sei Dir unbenommen. Und wenn dann der Inhalt Deiner Beiträge auch einer technischen Überprüfung standhalten, ist allen geholfen.

Gruß Xel66

[twoxx]

ich konzentriere mich auf homematic

Das sei Dir unbenommen. Und wenn dann der Inhalt Deiner Beiträge auch einer technischen Überprüfung standhalten, ist allen geholfen.

Gruß Xel66

gleiches gilt für dich

[eiGelbGeek]

Könntest Du prüfen ob beim Update von 3.53.30 auf .34 sinnloserweise nochmal ein Funkmodul-Firmware-Update ausgeführt wird?

Falls es wirklich wissen willst.... das tue ich gerade und bis dato läuft es ohne Probleme... aber abwarten ob es so bleibt

Bildschirmfoto 2020-12-20 um 02.14.30.png (35.08 KiB) 1159 mal betrachtet

[eiGelbGeek]

Wenige Minuten später bricht das ganze HM Netzwerk wieder zusammen ....

[twoxx]

Könntest Du prüfen ob beim Update von 3.53.30 auf .34 sinnloserweise nochmal ein Funkmodul-Firmware-Update ausgeführt wird?

Falls es wirklich wissen willst.... das tue ich gerade und bis dato läuft es ohne Probleme... aber abwarten ob es so bleibt



01.png
02.png
03.jpeg
04.png
05.png
Bildschirmfoto 2020-12-20 um 02.14.30.png

super! vielen dank für deinen einsatz.

aber was genau hast du gemacht.

die anzeige deines ersten posts der hm_mode datei vor ein paar tagen zeigte "root@homematic-ccu2".

die jetzige hm_mode datei zeigt nun "kevin@debmatic".

dein screenshot der ausgabe dieser hm_mode datei zeigt nur den hm-teil, nicht jedoch den hmip-teil.

der screenshot deiner webui zeigt version 3.55.5.60.
der screenshot deiner webui vor ein paar tagen zeigte indes raspymatic version 3.53.34.

das alles passt noch nicht zur fragestellung.

denn das nach einem update auf 3.53.34 die funkprobleme beginnen, wird ja nicht bestritten (zumindest nicht von mir)

die hypothese war ja: firmware 4.2.6 bei 3.53.30 funktioniert. bei update auf 3.53.34 wird firmware 4.2.6 nochmal geflasht obwohl das nicht erforderlich wäre.
und das dieses erneute flashen dann vielleicht zu den funkproblemen auf .34 im vergleich zu .30 führt.

wenn du von einer installierten raspymatic- firmware 3.53.30 auf 3.53.34 updatest... wird dabei nochmal die funkmodul-firmware 4.2.6 geflasht?

obwohl das ja nicht sein müsste, weil ja aufgrund version .30 die modul-firmware 4.2.6 schon im modul existiert und der update-prozess das erkennen müsste und die firmware 4.2.6 nicht erneut geflasht werden darf/sollte.

für mich sehen deine screenshots jetzt erst mal so aus als ob du von debmatic 3.55.5.60 auf 3.53.34 downgegraded hättest. was ja keinen sinn macht, wenn wir den verlauf der firmware 4.2.6 bei update 3.53.30 -> 3.53.34 beobachten wollen.

wenns dir also nichts ausmacht, könntest du in deiner virtuellen maschine eine raspymatic version 3.53.30 laufen lassen (muss nicht mal das backup geladen sein) und diese dann auf version 3.53.34 updaten und dabei beobachten ob unsinnigerweise nochmal die firmware 4.2.6 geflasht wird obwohl diese schon im funkmodul vorhanden war?

wenns keine virtuelle maschine wär würd ich sagen:
schliess am raspy-hdmi-port einen monitor an und schau ob beim updateverlauf das flashen des funkmoduls protokolliert ist.

[Huttmann]

Streitigkeiten auslösen wollte ich nicht.
Einen Fehler zu finden, der ca. 1x/Woche in einem komplexen System auftritt ist sehr schwer. Loggen auf ioBroker ist mir zunächst etwas aufwendig.
Wenn der Fehler auftritt sind die Geräte über das Funkmodul nicht steuerbar, Fehlermeldungen kommen massenhaft (Kommunikation gestört).
Ich habe 1x LAN-GW classic, zu dem Zeitpunkt war kein HAP-IP an. Ich habe nur ca. 7 IP-Geräte im Einsatz. Aurel Aussenantenne.

[eiGelbGeek]

die jetzige hm_mode datei zeigt nun "kevin@debmatic".

Das ist eine Virtuelle Machine mit debmatic.... das Problem besteht ja nicht nur in Raspberrymatic

die anzeige deines ersten posts der hm_mode datei vor ein paar tagen zeigte "root@homematic-ccu2".

Das war ein RaspberryPi 3+ mit RaspberryMatic und ein BackUp aus einer ccu2

dein screenshot der ausgabe dieser hm_mode datei zeigt nur den hm-teil, nicht jedoch den hmip-teil.

Da habe ich den Screenshot wohl zuweit abgeschnitten... aber der hmip-teil ist identisch

der screenshot deiner webui zeigt version 3.55.5.60.
der screenshot deiner webui vor ein paar tagen zeigte indes raspymatic version 3.53.34.

Ich hatte die Hoffnung das in 3.55.5 der Bug vielleicht schon behoben ist.....



PS: Raspberrymatic mit der Version 3.53.30 mit dem selben BackUp läuft ohne Einschränkungen und Problemen seit gestern wieder und die zu den Problemen lief es seit Release auch ohne Probleme.

[eiGelbGeek]

für mich sehen deine screenshots jetzt erst mal so aus als ob du von debmatic 3.55.5.60 auf 3.53.34 downgegraded hättest. was ja keinen sinn macht, wenn wir den verlauf der firmware 4.2.6 bei update 3.53.30 -> 3.53.34 beobachten wollen.

Wollen wir das wirklich? Nein ... denn es steht immer noch fest das es nicht die Funkmodul Firmware ist.... Warum sollte die Virtuelle Machine seine IPv4 Adresse verlieren, wenn das Funkmodul (welches bei mir ja sogar im Testaufbau Extern war durch die HB-RF-ETH Platine!) nicht korrekt arbeitet.... ?!?
Es ist irgendein Software Bug der sich ab 3.53.34 im HmIP Bereich eingeschlichen hat......

und nein ich habe keine Downgrades gemacht..... 3.55.5.60 war eine frische Installation aus einen VM Snapshot...

[twoxx]

für mich sehen deine screenshots jetzt erst mal so aus als ob du von debmatic 3.55.5.60 auf 3.53.34 downgegraded hättest. was ja keinen sinn macht, wenn wir den verlauf der firmware 4.2.6 bei update 3.53.30 -> 3.53.34 beobachten wollen.

Wollen wir das wirklich? Nein ... denn es steht immer noch fest das es nicht die Funkmodul Firmware ist.... Warum sollte die Virtuelle Machine seine IPv4 Adresse verlieren, wenn das Funkmodul (welches bei mir ja sogar im Testaufbau Extern war durch die HB-RF-ETH Platine!) nicht korrekt arbeitet.... ?!?
Es ist irgendein Software Bug der sich ab 3.53.34 im HmIP Bereich eingeschlichen hat......

und nein ich habe keine Downgrades gemacht..... 3.55.5.60 war eine frische Installation aus einen VM Snapshot...

Schade,
wir hätten so tatsächlich feststellen können ob die Funkmodul Firmware einen Anteil zum Problem hat.
Jerome hatte festgestellt, das bei Funkmodul Firmware 4.2.6 im HMIP-Bereich eine Abweichung von ca. 25khz besteht,
was vielleicht auch zu den Funkproblemen beiträgt. Es wäre dann einfach noch besser möglich gewesen das ganze einzugrenzen, wenn
tatsächlich bei einem Update von 3.53.30 auf .34 KEIN erneutes flashen der Funkmodul-Firmware passieren würde. Weil Du ja
sagst, dass bei .30 keine Probleme auftreten aber bei.34 dann.

Da Du ja sagst, das Probleme im HMIP-Bereich da sind und Jerome eben auch beim Funk im HMIP-Bereich Unstimmigkeiten da sind,
wäre es einfach hilfreich dem nachzugehen.

Aber ich merke, Du willst da wohl keine Zusammenarbeit.

Eine Frage noch: Wenn es wirklich nach Deiner Meinung nach ein Bug im HMIP-Bereich ist.......
warum verliert dann Deine virtuelle Maschine seine IPv4-Adresse? Die IP-Adressen der Zentrale hat ja nix mit dem HMIP-Bereich des Funks zu tun (weder mit ipv4 noch mit ipv6).