Frische Neuinstallation mit lokalem Zugriff (Web/SSH) und auf dem neuesten Stand.
Okay, ich frage mich, ob das nicht mit dem zusammenhängt, was wir privat besprechen. Wenn du alle fünf Sekunden sehr aggressive Szenen mit Dateneingabe machst, würde das dann nicht diese Anzeigeroute beeinflussen?
Könntest du den Browser-Inspektor öffnen und schauen, was in dieser Anfrage passiert, wenn du das Diagramm wechselst?
Genau das habe ich schon mehrmals versucht und im Browser sehe ich nichts in der Konsole.
Okay, das könnte vielleicht mit DuckDB zusammenhängen. Ich wäre neugierig zu erfahren, ob das Problem in den nächsten Stunden weiterhin besteht, jetzt, wo du nicht mehr alle fünf Sekunden aggressive Szenen machst.
Bisher sind die 1-Stunden-Charts immer noch kaputt.
Das ist ja verrückt! Da muss wohl etwas anders auf deiner Instanz sein, denn das funktioniert ja super 
Das ist ja verrückt!
Trotzdem habe ich alles ordentlich installiert, um das zu vermeiden 
24 Stunden später sind die Diagramme immer noch im Arsch. 
Könnte es nicht ein Zeitstempelproblem sein? Bei den 24-Stunden-Daten werden alle Werte der letzten 24 Stunden abgerufen, daher erscheinen die letzten und werden mit der richtigen Uhrzeit angezeigt, da die Anzeige die Zeitumwandlung durchführt, oder?
Aber bei den 1-Stunden-Daten, wenn es eine Stunde Verzögerung gibt, findet er dann nichts in der Datenbank?
@lmilcent, hast du bei den 24-Stunden-Daten vielleicht eine Stunde mehr links im Diagramm angezeigt? Auf den Screenshots, die du gibst, beginnt es um 15 Uhr und endet um 9 Uhr… seltsam, oder?
Hast du Geräte, die Werte seltener liefern (um weniger Punkte über 24 Stunden zu haben) für die echten und nicht aggregierten Daten!
Ich glaube, ich habe eine Spur.
Gladys befindet sich in der Zeitzone America/Toronto. Allerdings läuft der Zigbee2MQTT-Container nicht in derselben Zeitzone.
Ich habe alles neu installiert, inklusive der Wiederherstellung von Gladys Plus. Daher sind die Werte weniger als eine Stunde alt.
Wenn ich die Daten manuell in den Containern überprüfe:
Da Gladys jedoch die richtige Zeit anzeigt, nehme ich an, dass sie die Daten in UTC verarbeitet.
ABER ich habe das Datum im Zigbee2MQTT-Container (vor der Wiederherstellung) geändert, weil meine Thermostate mit einer Nachricht von Z2M auf die richtige Zeit gestellt werden. Daher hatte ich ein Problem damit, dass Z2M in UTC war, die Zeit meiner Thermostate wurde in UTC angezeigt.
Hallo,
ich weiß nicht, ob das mit dem Problem zusammenhängt, aber ich war während dieser Winterferien in der GMT-04-Zeitzone, mein Telefon war auf lokale Zeit eingestellt.
Als ich die Diagramme auf meinem über VPN mit dem Zuhause verbundenen Telefon ansah, sah ich die Diagramme in GMT-04, also mit einer Verschiebung von 5 Stunden im Vergleich zu Gladys zu Hause.
Der Peak bei 3000W auf dem Foto entspricht dem Start des Boilers um 22:00 Uhr, zeigt aber einen Start um 17:00 Uhr 
Ich wollte einen eigenen Post für meine Rückkehr machen, aber als ich die letzte Antwort von @lmilcent gesehen habe, dachte ich, dass es vielleicht damit zusammenhängt.
@lmilcent,
Du sagst uns dann in 24 Stunden Bescheid (naja, jetzt weniger ^^)
Ich denke, du hast recht. Das Diagramm zeigt den letzten Punkt zur aktuellen Zeit (ca. 10 Uhr) und den ersten Punkt in Pariser Zeit (ca. 16 Uhr, also 10 Uhr Ortszeit + 6 Stunden).
Natürlich funktioniert die Anzeige der letzten Stunde nicht, weil sie wahrscheinlich verschoben ist.
Trotzdem ist Gladys auf TZ=America/Toronto eingestellt, ich habe das auch manuell auf z2m angewendet, aber es ist immer noch das Gleiche.
Ja, die Einstellungen von z2m ändern nichts. Die Daten in der Datenbank werden von Gladys bei created_at und updated_at geschrieben. Gladys verwendet nicht den tatsächlichen Messzeitpunkt, sondern den Zeitpunkt des Schreibens in die Datenbank.
Es muss einfach ein Formatierungsproblem in der Abfrage vorliegen (Berücksichtigung der lokalen Zeit … oder etwas anderes). Vermutung, ohne dass ich es überprüft habe.
@pierre-gilles wird vielleicht wissen, ob das davon kommt.
Top cool, dass du das alles debuggen konntest 
@lmilcent Tatsächlich sieht es stark nach einem Zeitzonenproblem aus, super, dass wir endlich einen Nutzer in einer anderen Zeitzone haben, um all diese Probleme zu sehen 
Meiner Meinung nach gibt es einen Ort in der Stack, an dem die Zeitzone falsch verwaltet wird (das kann auf der Frontend-, Backend- oder DB-Seite sein), man muss sehen, woher das kommt, wenn jemand ein wenig ermitteln kann 
Falls nicht, kann ich gerne ein GitHub-Issue erstellen und mich dem Thema widmen, aber das wird nicht sofort sein, ich habe meine To-Do-Liste noch nicht abgearbeitet, die sich wie üblich während meines Urlaubs angehäuft hat 
Hallo @mutmut, das ist meiner Meinung nach ein anderes Thema
Im Allgemeinen ist dies bei den meisten Anwendungen das erwartete Verhalten, das Frontend zeigt die Uhrzeit eines Ereignisses aus einer anderen Zeitzone in deiner Zeitzone an. Beispiel: Wenn ein Freund, der in den USA im Urlaub ist, dir eine Nachricht über WhatsApp schickt, siehst du die Sendezeit der Nachricht in deiner Zeitzone und nicht in seiner.
Im Fall von Gladys denke ich, dass man Fall für Fall überlegen muss, zum Beispiel bei den Diagrammen ist es wahr, dass man darüber diskutieren kann. Aber das geht über den Rahmen dieser Diskussion hinaus, wenn du darüber sprechen möchtest, kannst du ein separates Thema erstellen?
Hallo @pierre-gilles, können wir ein anderes Thema machen, ohne Probleme? Verschiebst du es oder erstellen wir ein neues?