Hallo @spenceur
Könntest du mir bitte das Modell deines Zigbee-Schlüssels nennen?
Ich habe mein Problem von allen Seiten betrachtet, meine Installation auf das absolute Minimum reduziert und habe immer noch Aggregationsfehler. Viel weniger, aber ich habe immer noch welche.
Ich habe die VM gestoppt, die Gladys ausgeführt hat, und sie direkt auf dem NAS installiert, den Schlüssel auch direkt an den NAS angeschlossen, ohne einen Hub zu verwenden, nur eine Sirene und 7 Öffnungssensoren, ein Caldav-Konto, Enedis und Gladys Plus integriert.
Ich hätte gerne mit einem anderen Dongle getestet.
@Philou den Dongle zu wechseln wird meiner Meinung nach nichts ändern
Eine Option, die du ausprobieren könntest, wäre, die SQLite-Datei zu holen und eine kleine SQL-Abfrage auszuführen, um zu bestimmen, welches Gerät die meisten Werte sendet!
Die Datenbank befindet sich unter:
/var/lib/gladysassistant/gladys-production.db
Denke daran, Gladys zu stoppen, bevor du die Datei abrufst, um eine Beschädigung zu vermeiden.
Anschließend holst du die Datei auf deinen lokalen PC (außerhalb von Gladys) und führst mit einem Tool wie TablePlus die folgende Abfrage aus:
SELECT COUNT(t_device_feature_state.id), device_feature_id,
t_device_feature.name as feature_name, t_device.name as device_name
FROM t_device_feature_state
JOIN t_device_feature ON t_device_feature.id = device_feature_id
JOIN t_device ON t_device.id = t_device_feature.device_id
GROUP BY device_feature_id
ORDER BY COUNT(t_device_feature_state.id) DESC;
Damit erhältst du die am meisten redseligen Geräte
Wann beginnt deine Instanz? 453 Werte sind doch nichts
Die Idee hier ist, zu berechnen, wie viele Werte pro Sekunde Gladys erhält, um zu sehen, ob ein Sensor wirklich extrem aggressiv ist. Aber 453 Werte, wenn es über einige Tage sind, ist wirklich nichts.
Du kannst die Tabelle t_device_feature_state ansehen und nach diesem Sensor filtern, um zu sehen, mit welcher Frequenz er sendet, aber das scheint mir völlig in Ordnung zu sein…
Seit heute Morgen und schon seit mehreren Tagen hatte ich nur Fehlschläge.
Frische Installation direkt auf dem NAS (ohne VM), mit Dongle direkt am NAS (ohne USB-Hub), habe ich alle meine Geräte neu gepairt und mich wieder nur mit Fehlschlägen wiedergefunden.
Ich habe mich daher für eine Minimalinstallation entschieden.
Seitdem hatte ich zwei Fehlschläge, den von dieser Nacht also und einen anderen gestern, 4 Stunden nach der Installation
Ich bemerke auch diese Meldungen in den Logs, die darauf hinweisen, dass bestimmte Funktionen der Sirene nicht unterstützt werden, aber ich bezweifle, dass dies blockierend ist.
Ok, das sieht normal aus. Nicht außergewöhnlich, aber überhaupt nicht schlecht
Ist das eine SSD? Eine SSD NVMe? Eine HDD?
Und auf deinem NAS laufen bestimmt gleichzeitig einige Dinge, oder? Nichts, das die Festplatte „voll auslastet“ und Gladys blockieren könnte?
Eigentlich bräuchtest du ein Tool wie Netdata ( https://www.netdata.cloud/ / es ist kostenlos und Open Source), um zu sehen, ob auf deinem NAS Aktivitäten stattfinden, die alles blockieren.
Ich werde das mal vertiefen, danke für den Tipp, daran hatte ich überhaupt nicht gedacht
Ich hatte einen Minecraft-Server laufen, den habe ich erstmal abgeschaltet.
Es ist ein RAID SHR (Synology-eigenes Format) auf 4 WD RED-Festplatten mit 5400 U/min und 2 TB, plus eine Hot-Spare-Festplatte.
Ja, ich habe etwas Aktivität darauf, Mail-Server, nächtliche Backups, Kreuzreplikationen, Medienserver, eine kleine Website, kurz gesagt, genug, um die Festplatten zu beschäftigen, aber auch nichts Verrücktes.
Aber wenn ich die Festplattenauslastung während der Aggregationen betrachte… Überraschung!
Kannst du eine zusätzliche Festplatte anschließen? Wenn nicht, füge eine SSD (nicht im RAID) hinzu und lege das Docker-Gladys-Volume darauf. So bist du zumindest isoliert und hast eine SSD.
Wenn es während der Aggregationen Festplattenaktivität gibt, ist das normal.
Um einen SSD hinzuzufügen, habe ich eine NVMe im M.2-Format bestellt, das ich als Cache für die gesamte RAID-Gruppe verwenden werde, danke für den Rat! Ich habe das Glück, ein Modell zu haben, das das ermöglicht.
Ich habe das Gerät gelöscht, die Datenbank bereinigt, Gladys neu gestartet und die Aggregationen laufen jetzt cremig. Es scheint also, dass dieses Gerät Probleme verursacht. Xiaomi WSDCGQ11LM Steuerung über MQTT | Zigbee2MQTT
Noch nicht, jetzt lasse ich nach jeder Änderung, egal wie klein sie ist, ein paar Stunden laufen, um zu bestätigen, dass alles stabil ist. Ich habe gerade eine neue hochgeladen, ich werde sie überwachen.
Kleine Aktualisierung: Tests laufen noch.
Ich konnte 2 Xiaomi-Geräte in meinem Erdgeschoss ohne größere Probleme hinzufügen, es ist eher stabil, aber wenn ich ein Gerät aus dem Obergeschoss hinzufüge, beginnen die Aggregationen zu stürzen.
Bei mir gibt es
in meiner Garage (-1) NAS + Zigbee-Stick, einige Türsensoren, Xiaomi-Temperatursensor
im Erdgeschoss (0) mehrere Türsensoren, eine Sonoff-Steckdose, eine Neo-Sirene, ein Xiaomi-Sensor, ein Tuya-LED-Streifen
im 1. Stock eine Sonoff-Steckdose, 4 abgetrennte Xiaomi-Sensoren
im 2. Stock eine zweite Neo-Sirene
So funktioniert es im Moment.
Ich habe festgestellt, dass die Zigbee-Verbindungen viel besser funktionieren, wenn der „Router“ (der USB-Stick) in der Nähe ist. Ich hatte viele Verbindungsfehler und es funktioniert besser, wenn man die Geräte in der Nähe des Hauptrouters verbindet und sie dann verschiebt, anstatt sie direkt an ihrem endgültigen Standort zu verbinden.
Und sobald ich ein Gerät aus meinem 1. Stock hinzufüge, beginnen die Aggregationen zu stürzen.
Viele Tests sind geplant, um die Ursache zu finden, der erste ist die Hinzufügung eines NVMe-Caches an meinem NAS. Ich habe bereits eine erste NVMe-Karte im M2-Format bestellt, aber ich habe gerade erfahren, dass man zwei benötigt, damit der Cache lesbar und beschreibbar ist und nicht nur lesbar. Ich habe also eine zweite bestellt.
Seit dem NVMe-Cache ist die Verarbeitung der drei Aggregationen von 1 Minute und 50 Sekunden auf 10 Sekunden gesunken, also mehr als 10 Mal schneller. Bisher konnte ich die Prozentsätze steigen sehen, manchmal sogar zurückgehen, um dann wieder zu steigen usw. Jetzt geht es in einer geraden Linie. Die Reaktivität der Oberfläche ist im Moment einfach hervorragend, besser als zuvor, und mein gesamtes NAS profitiert davon. Ich habe alle meine Sensoren hinzugefügt, die erste Aggregation ist wie am Schnürchen gelaufen, abzuwarten. Ob das mein Problem löst oder nicht, ich habe die Bedeutung der Speicherung eindeutig unterschätzt. Danke @pierre-gilles, dass du mich in diese Richtung gelenkt hast
