Ja, ich werde das Log-Level ändern.
Warum machst du 400 Anfragen pro Minute? Hast du Hunderte von Geräten?
Dans le range ist es tatsächlich stylisch! 
Ich glaube, ich weiß, woher das kommt. Jedes Mal, wenn ein neuer Sensorwert veröffentlicht wird, muss Gladys überprüfen, ob eine Szene ausgelöst werden muss.
Aktuell wird folgendermaßen vorgegangen: Bei jedem empfangenen Sensorwert durchläuft Gladys jede vorhandene Szene und überprüft, ob die Szene die Bedingung erfüllt oder nicht. Es handelt sich dabei um eine einfache, synchrone forEach-Schleife, die blockierend ist.
In Bezug auf die Komplexität handelt es sich um O(n). Je mehr Szenen durchlaufen werden müssen, desto länger dauert es. Besonders in deinem Fall mit 400 Anfragen/Minute (6,6 Anfragen/Sekunde) ist das sehr viel Schleifendurchlauf. Aus Neugier, wie viele Szenen hast du?
Ich hatte diese Einschränkung im Hinterkopf und hatte ein GitHub-Issue erstellt, um das zu beheben: Each Node.js event should trigger a O(1) function, not O(n) · Issue #803 · GladysAssistant/Gladys · GitHub
Grundsätzlich ginge es darum, eine Möglichkeit zu finden, die Szenen anders im RAM zu speichern, in einem Format, in dem man überprüfen kann, ob eine Szene gültig ist, in einem einfachen 0(1), zumindest für Ereignisse des Typs « device new state »
Ich nutze das Zigbee-Netzwerk, um mit meinen Lampen Ambilight zu machen, und dadurch werden viele Anfragen gesendet 
Ich habe es sogar geschafft, mein Zigbee-Netzwerk zum Absturz zu bringen.
Daher habe ich die Anzahl der Anfragen reduziert, aber Gladys hat immer noch Probleme.
Ich habe derzeit nur eine einzige Szene, die ein geplanter Trigger ist.
Ich habe mich gefragt, ob das nicht daran liegt, dass Gladys jeden neuen Wert in der Datenbank speichert?
Bist du auf einem SSD oder einer SD-Karte?
Tatsächlich speichert Gladys die Werte in der Datenbank und wenn du auf einer SD-Karte bist, kann das zum limitierenden Faktor werden.
Allgemein empfehle ich wirklich SSDs für eine Installation, die langfristig hält.
Das Betriebssystem des Raspberry läuft auf einer SD-Karte, aber die Daten von Gladys sind auf einer Festplatte gespeichert, die per USB3 an den Raspberry angeschlossen ist.
Eine Festplatte mit Platten? Schau dir die Geschwindigkeit der Festplatte an, aber wenn du versuchst, kontinuierlich mit 6 Anfragen/Sekunde zu schreiben und zu lesen, werden die Anfragen natürlich in die Warteschlange gestellt und du wirst Verzögerungen auf Gladys-Seite sehen.
Wie hast du dein Ambilight eingerichtet?
Ich denke nicht, dass es eine gute Idee ist, Daten bei jedem Zustandswechsel zu speichern, und zusätzlich wird deine Datenbank riesig werden!
Ja, die guten alten Festplatten 
Ich habe einen Express-Server, der die Philips Hue API emuliert und dann MQTT an Zigbee sendet. Um den Bildschirm zu übertragen, verwende ich Hyperion NG.
Ich denke auch, nehmen wir an, ich lasse es 1 Stunde laufen, ich kann mir nicht einmal die Anzahl der durchgeführten Aufzeichnungen vorstellen 
Und Gladys empfängt die Ereignisse, weil Zigbee2mqtt die Rückmeldungen der Werte an Gladys sendet?
Ja, es scheint, dass Gladys die Geräte überwacht, die in der Zigbee2mqtt-Integration registriert sind (z. B. Hue Play-Geräte).
Daher werden alle von Zigbee empfangenen Werte, die in Gladys gespeichert werden, anschließend von Gladys empfangen.
Der Weg ist:
Hypérion → Philips-API (Express) → Zigbee2Mqtt → Gerät && Gladys
Ah, ich verstehe!
Aber bist du sicher, dass es Best Practice ist, die Philips Hue API so stark zu belasten? (Lebensdauer der Lampen, Zigbee-Netzwerk und so weiter?)
Ich kenne Zigbee2mqtt nicht gut genug, ich weiß nicht, ob es möglich ist, die Übertragung von Ereignissen an Gladys auf der Zigbee2mqtt-Seite zu deaktivieren. Ich überlasse @cicoub13 die Antwort darauf.
Hmm… nun ja, ich habe nur das nachgebaut, was Philips mit ihrer Hue Sync-Software macht, die es ermöglicht, die Lichter deines Bildschirms auf Lampen zu übertragen. Mal sehen, wie es sich auf Dauer schlägt.
Ich denke, man sollte eher einen Button hinzufügen, mit dem das Speichern der alten Werte deaktiviert werden kann.
Oder ja, das Senden von Ereignissen deaktivieren, aber ich denke, man sollte trotzdem in der Lage sein, in beide Richtungen mit Zigbee2mqtt zu kommunizieren.
In Gladys gibt es bereits die Möglichkeit, die Historie eines Sensors nicht zu speichern (das ist nicht in der UI des Zigbee2mqtt-Dienstes, aber es ist eine Funktion, die in Gladys Core vorhanden ist), aber das wird in deinem Fall nichts ändern, da wir in jedem Fall den letzten Wert speichern (um den letzten Wert einfach auf dem Dashboard anzeigen zu können).
Wenn wir die Möglichkeit lassen, das Speichern aller Werte komplett zu stoppen, wird der angezeigte Wert auf deinem Dashboard falsch sein.
Es wird zwar immer einen Teil des Problems geben, aber zumindest wird die Datenbank nicht überlastet, oder?
Genau!
In der UI von Zigbee2mqtt sollte ein Schalter „Verlauf der Werte speichern“ hinzugefügt werden, der dem Attribut „keep_history“ der Tabelle „device_feature“ entspricht.
Siehe Code: Gladys/server/models/device_feature.js at master · GladysAssistant/Gladys · GitHub
Willst du die Entwicklung übernehmen @JeuFore?
@cicoub13 kann dir helfen, die Struktur der Zigbee2mqtt-Integration zu verstehen, falls du Hilfe brauchst. Er hat am meisten daran gearbeitet
@cicoub13 Ich hatte einen Stromausfall
Nach dem Neustart kein z2m / mqtt mehr
2021-06-22T14:20:11+0200 <warn> service.start.js:44 (Service.start) Unable to start service zigbee2mqtt Error: (HTTP code 301) unexpected -
at /src/server/node_modules/docker-modem/lib/modem.js:301:17
at getCause (/src/server/node_modules/docker-modem/lib/modem.js:331:7)
at Modem.buildPayload (/src/server/node_modules/docker-modem/lib/modem.js:300:5)
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:275:14)
at IncomingMessage.emit (events.js:388:22)
at endReadableNT (internal/streams/readable.js:1336:12)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
reason: undefined,
statusCode: 301,
json: <Buffer >
}
2021-06-22T14:20:11+0200 <error> index.js:20 (process.<anonymous>) uncaughtException catched: uncaughtException
2021-06-22T14:20:11+0200 <error> index.js:21 (process.<anonymous>) Error: getaddrinfo ENOTFOUND containers
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26) {
errno: -3008,
code: 'ENOTFOUND',
syscall: 'getaddrinfo',
hostname: 'containers'
}
Alles ist in Ordnung mit Docker
Home Assistant hat keine Verbindungsprobleme mit diesem MQTT-Server.
Ich verstehe nicht, warum ich in diesem wackeligen Zustand bin.
Ich habe es bemerkt, weil die Box „Temperature in room“ keine aktuellen Daten hatte
Der Dienst kann nicht konfiguriert werden (der Dongle ist konfiguriert)
Viele Informationen, aber wenn du noch etwas brauchst, zögere nicht
EDIT: Ich musste meinen Server (physisch) neu starten, das hat mein Problem gelöst, wahrscheinlich hat die Dockerode-Bibliothek Mist gebaut
Ich werde wahrscheinlich in den nächsten Tagen Zeit haben, also warum nicht mal genauer hinschauen?
Hallo. Die Temperatur der Lampen wird jetzt verwaltet (mit einem schönen Slider).
Kannst du das Bild cicoub13/gladys:dev-zigbee2mqtt aktualisieren und noch einmal testen (Spoiler: Ich habe getestet und es funktioniert super)?
Das sollte bald in der für alle verfügbaren Version ankommen 
Hallo,
Okay, ich teste das Bild am Wochenende. Aber eine kleine Frage, hat jemand Probleme, die Zigbee-Container über Gladys zu erstellen 
?