Die Diagramme scheinen die im Gladys eingestellte Zeitzone nicht zu berücksichtigen, wodurch eine Zeitverschiebung der Daten auftritt (1 Stunde für die Zeitzone Paris).
Deshalb weiß ich nicht, woher das kommt. Wenn ich dieses Diagramm meines Laptop-Akkus betrachte, wäre ich um 08:00 Uhr losgefahren und um 11:55 Uhr zurückgekehrt.
Die entsprechenden Einträge in der Tabelle t_device_feature_state sind folgende:
Die Uhrzeit meines Raspberry ist korrekt:
Und die Zeitzone in Gladys ist auf GMT+1 eingestellt:
Deshalb verstehe ich nicht, woher die eine Stunde Zeitverschiebung kommt 
Interessant @Tolkyen! Aus Neugier, woher kommen deine Werte?
Tatsächlich scheint es eine Stunde Unterschied zu geben.
Könntest du die Konsole deines Browsers auf dem Dashboard öffnen, neu laden und die Anfrage GET IP_DEINER/api/v1/device_feature/aggregated_states? ansehen?
Und uns die JSON-Antwort hier reinstellen 
Ich will sehen, ob es ein Serverproblem oder ein Frontend-Anzeigefehler ist
Ich verwende die Anwendung Presence Publisher für den Batteriewert meines Telefons und meine Anwesenheit.
Hier ist das JSON nach der GET-Anfrage http://IP_DE_MON_PI/api/v1/device_feature/aggregated_states?interval=1440&max_states=100&device_features=mqtt-galaxynote9-battery
[HTTP/1.1 200 OK 86ms]
[{« device »:{« name »:« GalaxyNote9 »},« deviceFeature »:{« name »:« Galaxy Note 9 Akku »},« values »:[{« created_at »:« 2021-12-02T17:10:00.000Z »,« value »:54},{« created_at »:« 2021-12-02T17:25:00.000Z »,« value »:53},{« created_at »:« 2021-12-02T17:40:00.000Z »,« value »:52},{« created_at »:« 2021-12-02T17:55:00.000Z »,« value »:52},{« created_at »:« 2021-12-02T18:10:00.000Z »,« value »:48},{« created_at »:« 2021-12-02T18:25:00.000Z »,« value »:47},{« created_at »:« 2021-12-02T18:40:00.000Z »,« value »:46},{« created_at »:« 2021-12-02T18:55:00.000Z »,« value »:44},{« created_at »:« 2021-12-02T19:10:00.000Z »,« value »:42},{« created_at »:« 2021-12-02T19:25:00.000Z »,« value »:41},{« created_at »:« 2021-12-02T19:45:00.000Z »,« value »:40},{« created_at »:« 2021-12-02T20:00:00.000Z »,« value »:40},{« created_at »:« 2021-12-02T20:15:00.000Z »,« value »:39},{« created_at »:« 2021-12-02T20:30:00.000Z »,« value »:39},{« created_at »:« 2021-12-02T20:45:00.000Z »,« value »:38},{« created_at »:« 2021-12-02T21:00:00.000Z »,« value »:37},{« created_at »:« 2021-12-02T21:15:00.000Z »,« value »:37},{« created_at »:« 2021-12-02T21:30:00.000Z »,« value »:37},{« created_at »:« 2021-12-02T21:45:00.000Z »,« value »:36},{« created_at »:« 2021-12-02T22:05:00.000Z »,« value »:34},{« created_at »:« 2021-12-02T22:25:00.000Z »,« value »:34},{« created_at »:« 2021-12-02T22:40:00.000Z »,« value »:34},{« created_at »:« 2021-12-02T22:55:00.000Z »,« value »:35},{« created_at »:« 2021-12-02T23:10:00.000Z »,« value »:45},{« created_at »:« 2021-12-02T23:25:00.000Z »,« value »:55},{« created_at »:« 2021-12-02T23:40:00.000Z »,« value »:74},{« created_at »:« 2021-12-02T23:55:00.000Z »,« value »:84},{« created_at »:« 2021-12-03T00:10:00.000Z »,« value »:92},{« created_at »:« 2021-12-03T00:25:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T00:40:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T00:55:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T01:10:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T01:30:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T01:45:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T02:00:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T02:15:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T02:30:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T02:45:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T03:00:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T03:20:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T03:35:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T03:50:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T04:05:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T04:20:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T04:40:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T04:55:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T05:10:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T05:25:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T05:40:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T05:55:00.000Z »,« value »:100},{« created_at »:« 2021-12-03T06:10:00.000Z »,« value »:97},{« created_at »:« 2021-12-03T06:25:00.000Z »,« value »:93},{« created_at »:« 2021-12-03T06:40:00.000Z »,« value »:91}]}]
Könntest du mir die dazugehörigen DB-Werte zeigen? Oder mir einfach sagen, ob diese Werte gut sind oder nicht?
Eigentlich möchte ich vergleichen, ob die von der API zurückgegebenen Werte gut sind oder im Gegenteil bereits falsch, um zu sehen, ob das Problem vom Backend oder vom Frontend kommt
Hier sind die entsprechenden DB-Werte:
- Tabelle t_device_feature_state_aggregate
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|25.0|2021-12-01 23:08:30.201 +00:00|
|22.0|2021-12-01 23:23:31.792 +00:00|
|22.0|2021-12-01 23:40:40.647 +00:00|
|22.0|2021-12-01 23:56:07.923 +00:00|
|26.0|2021-12-02 00:08:41.407 +00:00|
|25.0|2021-12-02 00:23:46.843 +00:00|
|33.0|2021-12-02 00:40:40.587 +00:00|
|40.0|2021-12-02 00:55:41.045 +00:00|
|42.0|2021-12-02 01:02:26.640 +00:00|
|42.0|2021-12-02 01:02:52.282 +00:00|
|42.0|2021-12-02 01:17:52.988 +00:00|
|50.0|2021-12-02 01:35:40.807 +00:00|
|65.0|2021-12-02 01:51:04.835 +00:00|
|80.0|2021-12-02 02:06:05.795 +00:00|
|89.0|2021-12-02 02:22:09.764 +00:00|
|96.0|2021-12-02 02:37:13.891 +00:00|
|100.0|2021-12-02 02:52:15.646 +00:00|
|100.0|2021-12-02 03:07:19.726 +00:00|
|100.0|2021-12-02 03:22:23.787 +00:00|
|100.0|2021-12-02 03:37:27.571 +00:00|
|100.0|2021-12-02 03:52:30.694 +00:00|
|100.0|2021-12-02 04:07:31.926 +00:00|
|100.0|2021-12-02 04:22:37.040 +00:00|
|100.0|2021-12-02 04:37:39.550 +00:00|
|100.0|2021-12-02 04:52:40.525 +00:00|
|100.0|2021-12-02 05:07:41.597 +00:00|
|100.0|2021-12-02 05:22:42.267 +00:00|
|100.0|2021-12-02 05:39:05.699 +00:00|
|100.0|2021-12-02 05:55:17.492 +00:00|
|100.0|2021-12-02 06:10:28.649 +00:00|
|100.0|2021-12-02 06:25:40.858 +00:00|
|100.0|2021-12-02 06:40:45.551 +00:00|
|100.0|2021-12-02 06:55:47.611 +00:00|
|99.0|2021-12-02 07:11:04.254 +00:00|
|97.0|2021-12-02 07:26:08.659 +00:00|
|94.0|2021-12-02 07:41:10.997 +00:00|
|94.0|2021-12-02 08:00:41.909 +00:00|
|80.0|2021-12-02 11:57:10.334 +00:00|
|79.0|2021-12-02 12:15:41.014 +00:00|
|78.0|2021-12-02 12:30:42.156 +00:00|
|74.0|2021-12-02 12:45:41.144 +00:00|
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|34.0|2021-12-02 23:07:53.886 +00:00|
|34.0|2021-12-02 23:25:41.196 +00:00|
|34.0|2021-12-02 23:40:40.659 +00:00|
|35.0|2021-12-02 23:55:41.747 +00:00|
|45.0|2021-12-03 00:10:44.620 +00:00|
|55.0|2021-12-03 00:25:45.664 +00:00|
|74.0|2021-12-03 00:40:53.666 +00:00|
|84.0|2021-12-03 00:56:02.976 +00:00|
|92.0|2021-12-03 01:11:04.401 +00:00|
|100.0|2021-12-03 01:26:08.855 +00:00|
|100.0|2021-12-03 01:43:03.981 +00:00|
|100.0|2021-12-03 01:59:05.630 +00:00|
|100.0|2021-12-03 02:14:10.224 +00:00|
|100.0|2021-12-03 02:31:09.721 +00:00|
|100.0|2021-12-03 02:46:11.790 +00:00|
|100.0|2021-12-03 03:01:16.744 +00:00|
|100.0|2021-12-03 03:16:22.653 +00:00|
|100.0|2021-12-03 03:31:28.816 +00:00|
|100.0|2021-12-03 03:48:06.341 +00:00|
|100.0|2021-12-03 04:04:56.066 +00:00|
|100.0|2021-12-03 04:20:09.611 +00:00|
|100.0|2021-12-03 04:39:11.196 +00:00|
|100.0|2021-12-03 04:54:26.893 +00:00|
|100.0|2021-12-03 05:09:29.539 +00:00|
|100.0|2021-12-03 05:24:38.653 +00:00|
|100.0|2021-12-03 05:40:40.061 +00:00|
|100.0|2021-12-03 05:55:44.694 +00:00|
|100.0|2021-12-03 06:11:17.572 +00:00|
|100.0|2021-12-03 06:26:22.620 +00:00|
|100.0|2021-12-03 06:41:26.797 +00:00|
|100.0|2021-12-03 06:56:30.470 +00:00|
|97.0|2021-12-03 07:11:33.062 +00:00|
|93.0|2021-12-03 07:26:55.649 +00:00|
|91.0|2021-12-03 07:42:05.299 +00:00|
- Tabelle t_device_feature_state
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|34.0|2021-12-02 23:07:53.886 +00:00|
|34.0|2021-12-02 23:25:41.196 +00:00|
|34.0|2021-12-02 23:40:40.659 +00:00|
|35.0|2021-12-02 23:55:41.747 +00:00|
|45.0|2021-12-03 00:10:44.620 +00:00|
|55.0|2021-12-03 00:25:45.664 +00:00|
|74.0|2021-12-03 00:40:53.666 +00:00|
|84.0|2021-12-03 00:56:02.976 +00:00|
|92.0|2021-12-03 01:11:04.401 +00:00|
|100.0|2021-12-03 01:26:08.855 +00:00|
|100.0|2021-12-03 01:43:03.981 +00:00|
|100.0|2021-12-03 01:59:05.630 +00:00|
|100.0|2021-12-03 02:14:10.224 +00:00|
|100.0|2021-12-03 02:31:09.721 +00:00|
|100.0|2021-12-03 02:46:11.790 +00:00|
|100.0|2021-12-03 03:01:16.744 +00:00|
|100.0|2021-12-03 03:16:22.653 +00:00|
|100.0|2021-12-03 03:31:28.816 +00:00|
|100.0|2021-12-03 03:48:06.341 +00:00|
|100.0|2021-12-03 04:04:56.066 +00:00|
|100.0|2021-12-03 04:20:09.611 +00:00|
|100.0|2021-12-03 04:39:11.196 +00:00|
|100.0|2021-12-03 04:54:26.893 +00:00|
|100.0|2021-12-03 05:09:29.539 +00:00|
|100.0|2021-12-03 05:24:38.653 +00:00|
|100.0|2021-12-03 05:40:40.061 +00:00|
|100.0|2021-12-03 05:55:44.694 +00:00|
|100.0|2021-12-03 06:11:17.572 +00:00|
|100.0|2021-12-03 06:26:22.620 +00:00|
|100.0|2021-12-03 06:41:26.797 +00:00|
|100.0|2021-12-03 06:56:30.470 +00:00|
|97.0|2021-12-03 07:11:33.062 +00:00|
|93.0|2021-12-03 07:26:55.649 +00:00|
|91.0|2021-12-03 07:42:05.299 +00:00|
Offensichtlich gibt es eine Verzögerung.
Ich habe dasselbe Problem wie du und habe eine GitHub-Issue erstellt: Graphs have between 1 hour and 2 hours delay · Issue #1430 · GladysAssistant/Gladys · GitHub
Also, es ist kein Bug (ja, ja ^^), sondern einfach eine technische Entscheidung, die ich aufgrund meiner Beobachtungen getroffen habe (die vielleicht noch einmal hinterfragt werden können).
Jede Aggregation berechnet die aggregierten Werte nur für den Zeitraum vor dem aktuellen Zeitraum.
Für die stündliche Aggregation werden nur die Stunden berechnet, die bereits abgeschlossen sind.
Zum Beispiel, wenn es 14:50 Uhr ist, berechnet die stündliche Aggregation nur bis zur letzten vollständig abgeschlossenen Stunde, also bis 13:59:59.
In der UI zeigt das Frontend nur die aggregierten Daten an, und daher gibt es bei den Intervallen, die in Stunden angegeben sind, eine Stunde Verzögerung, da die letzte Stunde noch nicht aggregiert wurde.
Bei den täglichen Intervallen gibt es immer einen Tag Verzögerung.
Ich habe Tests durchgeführt, um eine Abfrage zu erstellen, die eine Doppelabfrage durchführt: aggregierte Daten + Live-Daten, aber das sah optisch überhaupt nicht gut aus, weil die Live-Daten natürlich detaillierter waren als die aggregierten Daten.
Was wir eventuell tun könnten, ist eine « heiße » Aggregation während der Abfrage durchzuführen, aber mit einer Anzahl von Ereignissen im Verhältnis zur verstrichenen Zeit im aktuellen Intervall, damit die Daten in der UI auf dem gleichen « Detaillierungsniveau » sind (sonst wird es unschön).
Danach wäre es eine aufwendigere Verarbeitung, die die Abfragen verlangsamen könnte, also muss man sehen, ob es sich lohnt, und ich glaube nicht, dass es so einfach ist, ein sauberes Ergebnis zu erzielen. Ich habe Angst, dass man den Unterschied zwischen den aggregierten Daten und den « Live-Daten, die während der Abfrage aggregiert wurden » sieht.
Ich weiß nicht, ob das klar ist?
Für die aktuellen Daten gäbe es nicht die Möglichkeit, eine 24-Stunden-„Gleitende“ Berechnung mit einem 5-Minuten-Schritt zu machen? (also häufiger neu berechnen, statt live)
Man muss testen, ob es gut aussieht, aber das Ergebnis wird zwangsläufig anders sein und das könnte man in der Kurve sehen
Bei einer 24-Stunden-Ansicht behält man nur 100 Werte. Also 24*60 = 1440 Minuten pro Tag / 100 = ein Wert alle 14,4 Minuten im Durchschnitt
Das „im Durchschnitt“ ist sehr wichtig, denn die Aggregation berechnet keine festen Punkte (es ist nicht ein Punkt alle 14 Minuten), sondern versucht, 100 Punkte zu erstellen, deren Kurve der Kurve mit allen Punkten möglichst nahe kommt.
Wenn man also die Berechnungshäufigkeit für die letzten 24 Stunden erhöht, hat man keine Kenntnis von der „Gesamtübersicht“ des Tages und wird zwangsläufig ein anderes Ergebnis als eine echte 24-Stunden-Ansicht erhalten.
Ich bin zwar einverstanden, dass die aktuelle Lösung etwas an diesen Live-Daten in diesen Intervallen fehlt.
Kurz gesagt, man muss den Code schreiben und verschiedene Tests mit vielen verschiedenen Datensätzen durchführen, um zu sehen, was visuell am besten funktioniert..
In der Tat, in diesem Fall gibt es vielleicht ein doppeltes Problem, darunter ein Zeitzonenproblem.
Könntest du in der Datenbank in der Tabelle t_device_feature_state & t_device_feature_state_aggregate nachschauen und das mit dem vergleichen, was du im Frontend abrufst?
Um zu sehen, ob das Problem von der Datenbank, dem Backend oder dem Frontend kommt?
Eigentlich ist alles in Ordnung…
Wenn ich einen Sensor nehme, der sehr regelmäßig Zustände sendet:
- das letzte Event war um 21:50 Uhr
- die letzte stündliche Aggregation erfolgte um 21:20 Uhr (für Daten bis 21:00 Uhr)
- das Frontend-Diagramm zeigt Daten bis 21:00 Uhr an
Mein Gefühl der Verzögerung kam von Sensoren, die nicht regelmäßig Zustände senden (manchmal nur ein Zustand alle zwei Stunden).
Toll!
Nach der Verbesserung der Funktionsweise bin ich einverstanden, eine Mischung aus Live-Daten und aggregierten Daten in der UI wäre cool.
Allerdings hatte ich beim anfänglichen Entwicklungsprozess (der, soweit ich mich erinnere, bereits 2 Monate gedauert hatte) nicht so einfach eine saubere Lösung gefunden und es deshalb vorerst beiseitegelegt.
Falls es sich um eine häufige Anforderung handelt, kann ich Zeit dafür investieren, aber ich denke, es ist wirklich keine einfache Entwicklung.