Zigbee2MQTT plant sich zweimal in 2 Stunden

Guten Abend.

Gladys V4 auf Raspberry Pi 3 - 64 Bit

Nach dem Update von Node-RED und den Problemen mit RFlink habe ich beschlossen, meine 433-MHz-Steckdosen durch Zigbee2MQTT-Steckdosen zu ersetzen.
Heute Abend stelle ich fest, dass die Terrassenlichter nicht angehen. Ein Blick auf das Dashboard zeigt, dass, wenn ich die Diagramme der Temperatursensoren meiner Kühlschränke auf „Letzte Stunde“ umstelle, keine Werte angezeigt werden. Beim Aufruf von http://gladys.local:8080/#/map wird nichts gefunden. Kurz gesagt, Zigbee2MQTT ist abgestürzt, etwa vor 3 Stunden, da der Bewegungsmelder mir anzeigt, dass der letzte empfangene Wert vor 3 Stunden war.
Da ich nicht in der Nähe meines Raspberry Pi bin, verbinde ich mich per SSH und führe einen sudo reboot aus.
Wenige Sekunden später ist alles wieder in Ordnung.
Später kehre ich zum Dashboard zurück und stelle fest, dass Zigbee2MQTT erneut abgestürzt ist, diesmal vor 2 Stunden, wieder dank des Bewegungsmelders.
Erneuter sudo reboot und wieder startet alles neu.
Ich habe auch festgestellt, dass man, wenn man ein Zigbee2MQTT-Gerät hinzufügt, Gladys ebenfalls neu starten muss.

Seltsam, hast du die Logs auf der Zigbee2mqtt-Seite angesehen?

Falls du etwas findest, kannst du dann im Zigbee2mqtt-Forum nachsehen, ob jemand das gleiche Problem hat:

Nein, wo findet man die?

Aber ich habe in den Einstellungen > Aufgaben festgestellt, dass die Gladys-Sicherung 53% anzeigt.
Seitdem finde ich diese Aufgabe nicht mehr.
Kann die Sicherung einen Teil von Gladys zum Absturz bringen? Ich verwende eine SD-Karte, die nicht mehr die neueste ist.

Ich habe keine neuen Abstürze festgestellt, außer dem Verbindungsverlust der beiden kostenlosen Sonoff-Temperatursensoren, die ich bei Bestellungen bei Domadoo erhalten und heute installiert habe.

Übrigens habe ich eine Infrastruktur, die langsam beträchtlich wird:

Vielleicht hat dein USB-Zigbee-Dongle seine Grenzen erreicht (einige haben eine begrenzte Anzahl an Geräten). Welches Modell hast du?

Entweder mit docker logs in der CLI (du machst vorher docker ps, um den Namen des Containers zu finden)

Oder vielleicht in der Oberfläche, ich glaube, ich sehe einen « Logs »-Tab in deinem Screenshot

Ach, tatsächlich, während die Sicherung läuft (der erste Teil der Sicherung), ist Gladys vorübergehend nicht in der Lage, neue Daten zu verarbeiten, da die Datenbank gesperrt ist.

Normalerweise ist das zwischen Mitternacht und 2 Uhr morgens, die Sicherungen, das ist das, was du beobachtet hast?

Normalerweise ist dieser Teil sehr schnell, aber wenn du mir sagst, dass du eine etwas alte SD-Karte verwendest, ist es möglich, dass es ein paar Sekunden/Minuten dauert.

Es ist die SONOFF, ich muss sie flaschen, denn ich habe 36 Peripheriegeräte und noch 4 zu installieren. Der von Domo-blog gegebene Leitfaden ist für Windows, bei mir läuft alles unter Linux, sogar das Telefon, also muss ich das Verfahren für Linux suchen.

Beim zweiten Blockadefall war es nach Mitternacht, beim ersten Fall war es eher gegen 21:30 Uhr. Ist es möglich, dass das Backup früher als erwartet durchgeführt wurde, denn mein Backup ist 107 MB groß. Wenn nur ich, meine Frau und meine Tochter im Haus sind, dauert es etwa 30 Minuten, um diese 107 MB hochzuladen.
Heute sind 30 Personen im Haus, mit fast genauso vielen Telefonen, Tablets und Computern, also würde mich ein Upload von 107 MB für mehr als 2 Stunden nicht wundern.

Nein, das ist nicht möglich, es ist wirklich immer zwischen Mitternacht und 2 Uhr (wenn du wirklich die neueste Version von Gladys hast)

Meiner Meinung nach solltest du woanders suchen, das sieht nicht nach einem Backup-Problem aus, zumal Gladys während des Uploads des Backups nicht blockiert wird. Der Blockadezustand betrifft nur den Schritt des Kopierens der Datenbank und ist relativ schnell und nicht von deinem Netzwerk abhängig.

Es sieht eher nach einem Problem mit Z2M / Dongle aus!