Zurück am Montagmorgen habe ich gerade ein Release-Tag erstellt, Gladys v4.7.3.
Aktuell im Build hier:
https://github.com/GladysAssistant/Gladys/actions/runs/1805667854
Ja, das Gefühl ist besser, ich sag dir in ein paar Tagen wieder Bescheid.
Guten Abend,
Ich würde gerne wissen, wie das Dashboard aktualisiert wird?
Ob zyklisch oder wenn sich ein Wert ändert?
Danke
Normalerweise ist das live (bei einer Zustandsänderung wird das an die Frontend-UI weitergegeben)
Aber es gab einige Vergesslichkeiten bei bestimmten Boxen, bei denen das nicht gemacht wurde. Dafür gibt es bereits GitHub-Issues und @AlexTrovato hat dazu einen Pull Request gemacht 
Danke @pierre-gilles
Denn tatsächlich habe ich MQTT-„Status“-Funktionen, die sich nicht immer aktualisieren. Ich muss die Dashboard-Seite neu laden, aber vielleicht warte ich auch nicht lange genug, damit die Aktualisierung auf dem Dashboard erfolgt, denn die zugehörige Telegramm-Nachricht kommt gut an.
Auf welcher Box des Dashboards?
Auf einer Box „Geräte im Raum“
Ah, das ist nicht normal. Normalerweise funktioniert diese Box perfekt.
Lokal oder auf Gladys Plus das Problem?
Hallo @pierre-gilles
Das ist lokal, ich habe es nicht auf G+ getestet
Ich verstehe das nicht, ich habe einen Sensor mit 2 Funktionen auf einem Esp 8266 gebaut, der per Mqtt an Gladys überträgt
und eine funktioniert einwandfrei, aber die andere, wie ich dir sage, sendet die Telegramm-Nachricht bei ihrem Zustandswechsel, wird aber nicht im Dashboard aktualisiert und wenn ich die Webseite (Dashboard) aktualisiere, wird die Anzeige der Funktion aktualisiert. Ich werde die Recherchen vertiefen, ich halte dich auf dem Laufenden
Entschuldige für die Zeit, die du verloren hast.
Hallo,
Ich möchte etwas mit euch (und @pierre-gilles) überprüfen.
Wenn ich ein Dashboard lade, muss Gladys 100 Werte aus der DB abrufen, um sie anschließend anzuzeigen, richtig? Soweit ich weiß, sollte das keine große Festplattenlast (I/O) verursachen. Ich kann mir daher nicht erklären, warum die IO bei 100% liegt, mit einem Maximum von 19 MB/s, wenn ich ein neues Dashboard lade.
Beweis in Video:
Nein, nicht genau, das hängt vom ausgewählten Intervall ab
Hier, wenn du die letzten 24 Stunden anfordern, verwendet Gladys die stündliche Aggregation (100 Werte pro Stunde)
Über 24 Stunden bedeutet das, dass die DB 100 * 24 = 2400 Zustände abruft, DANN eine Downsampling-Schicht auf der CPU hinzufügt, um auf 100 Zustände zu kommen, die als API-Antwort gesendet werden.
Auf deinem Diagramm zeigst du 6 Diagramme * 2 Features = 12 Anfragen * 2400 = 28,8k abgerufene Zustände
Also das, was du uns zeigst, wundert mich im aktuellen Zustand nicht!
Danach könnten wir die Art und Weise, wie der Filter „24h“ funktioniert, weiterentwickeln, um die tägliche Aggregation (100 Werte / Tag) zu verwenden, aber man muss sehen, wie das aussieht, es ist nicht gesagt, dass es so sauber ist wie jetzt, man muss Tests machen
Edit: das würde nicht funktionieren, siehe folgenden Post (Dashboard - Evolutions / Bugs / etc - #134 par pierre-gilles)
Aaaaaaaaaaah jetzt verstehe ich besser!
Ich hatte mir gemerkt, dass es 100x Werte pro Stunde, 24 Stunden, 7 Tage usw. sind.
Aber nein, tatsächlich ist die Aggregation auf 24 Stunden begrenzt, und dann werden alle Daten abgerufen und wie von dir beschrieben bei Bedarf berechnet.
Also ist alles völlig normal.
Nein, du hattest (fast) richtig verstanden!
Ich zitiere den Launch-Artikel:
- Die stündliche Aggregation wird jede Stunde berechnet (die vorherige Stunde wird berechnet)
- Die tägliche Aggregation wird jeden Tag um Mitternacht berechnet (der vorherige Tag wird berechnet)
- Die monatliche Aggregation wird jeden 1. des Monats um Mitternacht berechnet (der vorherige Monat wird berechnet)
Aber genau, wenn man die Ansicht „letzte 24h“ anzeigt, stellen wir uns vor, du zeigst diese Ansicht um 18 Uhr an, dann ist die tägliche Aggregation des laufenden Tages noch nicht fertig (sie wird um Mitternacht berechnet), daher verwenden wir die stündliche Aggregation, die verfügbar ist.
Bei meinen Tests habe ich versucht, eine Mischung zu machen, indem ich:
Wenn du das Dashboard um 18 Uhr aufrufst:
- Von 18 Uhr bis 00 Uhr des Vortags über die tägliche Aggregation nehmen
- Von 00 Uhr bis 17 Uhr die stündliche Aggregation verwenden
- Von 17 Uhr bis 18 Uhr die Live-Daten nehmen
Aber das sieht wirklich nicht gut aus, die Datenmischung führt dazu, dass man auf dem Diagramm die „Sprünge“ sieht, es ist wirklich nicht sauber.
Danke für die Erklärung, so erklärt ist das völlig logisch.
Letztlich habe ich meine Dashboards so bearbeitet, dass sie standardmäßig nur die letzte Stunde anzeigen. Bei Bedarf lade ich dann die letzten 24 Stunden.
Dadurch behalte ich eine echte Reaktionsfähigkeit und vermeide, Gladys für 10 bis 20 Sekunden zu überlasten.
Sonst musst du @lmilcent investieren
Witz beiseite, aber das könnte vielleicht ein bisschen knapp für dich sein, oder?
Ich sage dir das, weil ich es getestet habe und dieses Problem nicht habe (amd64 / SSD).
Zu laut, sorry
Ich habe einen Mini-PC mit SSD bekommen, also ja, das wird definitiv viel leistungsfähiger. Ich habe ihn installiert, aber ich hatte noch keine Zeit, die Gladys-Migration durchzuführen.
Sobald das erledigt ist, gebe ich euch mein Feedback, insbesondere zu den Unterschieden in der Latenz — bei mir wird das wahrscheinlich extrem auffallen!
Danach kann ich meine RPis einfach zu RTSP-Kameras recyceln
Da ist es offensichtlich die Festplatte, die bei dir der Flaschenhals ist. Bist du auf einer Micro-SD-Karte oder einer SSD? Ich erinnere mich nicht mehr.
20 MB/s (Megabytes pro Sekunde) ist eindeutig weder HDD noch SSD
Es ist ein einfacher Raspberry Pi 4 (Raspberry Pi 4) für den Moment.