Offenbar hat meine Teleinformation (MQTT) Indizes, während der Rest eine verbrauchte Leistung hat (MQTT und Z2M).
Oben die Tagesinformation in den Aufgaben, das ermöglicht auch zu sehen, wie weit die Berechnung ist, für die Ungeduldigen 
Seltsam, ich habe sie auf meiner Seite. Kannst du mir bestätigen, dass du:
- auf die MQTT-Seite gegangen bist
- Dann drückst du F12 und gehst zum Tab « Netzwerk »
- Dann gibst du in die Suche « Borne VE » ein, um nur diesen zu haben
- Wähle den letzten « device?order_dir=asc&search=… » aus und erweitere die Features des Geräts
- Suche nach dem Feature des Verbrauchten Stroms (Typ « energy ») und beobachte seine ID.
- Suche dann nach dem Feature des Typs « thirty-minutes-consumption » und schaue auf sein « energy_parent_id », es muss mit der vorherigen ID übereinstimmen. Notiere dann seine ID
- Ähnlich, suche nach dem Feature « thirty-minutes-consumption-cost » und schaue auf sein « energy_parent_id », es muss mit der vorherigen ID übereinstimmen, diesmal von dem Feature des Typs « thirty-minutes-consumption ».
Wenn diese Bedingungen nicht erfüllt sind, wird es nicht funktionieren. Aber das würde bedeuten, dass in der Hierarchie « Meine Geräte » des « Energietrackings » sie nicht richtig kalibriert sind. Ich habe diese Einschränkung gemacht, um:
- einerseits eine zu lange Liste zu vermeiden
- andererseits eine Berechnung in einer falschen Hierarchie zu vermeiden.
Hast du diese Funktionen manuell vor dem Update von Pierre-Gilles erstellt oder automatisch mit dem Update?
Ich hatte all diese Funktionen schon lange vorher erstellt, und da ich gerade am Telefon bin, werde ich sie später am PC genauer anschauen.
Ich habe gerade überprüft und die Eltern-Kind-Beziehungen sind in Ordnung.
Allerdings stimmt die parent_id der Ladebox nicht mit der ID meines Hauptzählers überein, obwohl mein Energieverfolgungsbaum korrekt ist und ich nicht weiß, ob das normal ist:
Nach Überprüfung ist die parent_id meiner Teleinformationen-Index dieselbe wie die parent_id der Ladebox und auch dieselbe wie die parent_id meiner Zigbee-Steckdosen, und alle sind auf Ebene 1 unter dem Hauptzähler.
Hallo @mutmut,
Entschuldige, eine Familiennotfall hat mich daran gehindert, weiterzumachen.
Ich habe gerade einen Build des Bildes mit den oben erwähnten Änderungen
UND einem Fix, der, hoffe ich, das Problem mit den Funktionen, die du nicht gesehen hast, behebt, neu gestartet
terdious/gladys:dev-energy-calculate
-
Falls du es nochmal testen könntest.
-
Und einen Neustart-Test von Gladys während einer Neuberechnung machen, um mir zu sagen, was du von den Logs in den Aufgaben hältst (z. B. wartest du 5 Minuten, bevor du ausschaltest, und beim Wiedereinloggen gehst du zu den Aufgaben, du solltest sehen, wo es stand - welcher Tag - es war zum Zeitpunkt des Ausschaltens, was es ermöglicht, die Neuberechnung an diesem Datum fortzusetzen)
-
Wenn du eine lange Aufgabe startest, die länger als 1 Stunde dauert, solltest du eine Ansammlung von Aufgaben « 30 Minuten » sehen, ich habe Logs hinzugefügt, um sicherzustellen, dass die Aufgaben « Verbrauch » und « Kosten » dieselben Perioden berechnen.
Build abgeschlossen:
Danke @Terdious, ich werde diese Woche nochmal testen, ich habe gerade erst ein Speicherleck-Problem gelöst, das schon eine Woche anhielt und mein Frontend einfrieren ließ 
Und das Schlimmste daran ist, dass der Übeltäter ein NOUS B3Z-Modul war, das 4 Updates pro Sekunde an mein z2m geschickt hat und dann Gladys in den PLS-Modus versetzt hat, eine Qual, das zu finden 
Dabei ist mein Matter/Matterbridge kaputt gegangen, ich werde mich also später darum kümmern.
Jetzt scheint es wieder richtig zu laufen (ich drücke die Daumen), also lasse ich es erstmal so, damit sich die Gladys Plus-Backups wieder beruhigt neu starten können.
Ich halte dich auf dem Laufenden, sobald ich dein letztes Bild mit deinen Anforderungen getestet habe.
Und wie hast du es dann geschafft, die Anzahl deiner NOUS-Sendungen zu reduzieren?
@_Will_71 Ich bin in den Einstellungen-Tab des Moduls gegangen und habe eine 10-Sekunden-Verzögerung für den Payload-Versand eingestellt:
Ein Neustart von z2m, dann von Gladys und das Problem war behoben.
Ich habe auch die Historie der Funktionen deaktiviert und das hat die gesamte Historie gleichzeitig gelöscht.
Es ist kein lebenswichtiger Doppelrelais, nur das Einschalten von 2 verschiedenen Lichtern, also keine Auswirkungen auf mein System.
Erster Post des Jahres, also beste Wünsche für 2026, das gestartet ist, und ein schönes Feedback für @Terdious 
Die Infos im Aufgaben-Log sind super klar!
Die Daten sind perfekt!
Nur eine Frage zu
Fortschritt: Datum JJJJ-MM-TT, bedeutet das, dass das angezeigte Datum erledigt ist oder noch in Berechnung ist?Da ich es nicht wusste, habe ich die Berechnung am Vortag neu gestartet, um sicherzugehen.
Bei den Docker-Logs, ist es normal, dass sie so ausführlich sind?
Denn ich habe das für jeden berechneten Tag auf einem einzigen Gerät und ich denke, wenn es für alle ist, werden die Logs wie ein Luftballon anschwellen. Jedenfalls sieht man gut, dass es arbeitet
Hallo @mutmut,
Danke für deine Tests und dein Feedback am Neujahrstag ^^
Es handelt sich um den Tag, an dem der Fortschritt gerade berechnet wird. Wenn also ein Neustart erforderlich ist, muss dieser am selben Tag erfolgen (damit die Information mit der Auswahl für den Neustart übereinstimmt). Ich kann « Fortschritt in Arbeit » statt einfach « Fortschritt » hinzufügen, um es verständlicher zu machen. Um es zu erkennen, kann man beim Anzeigen des betreffenden Tages sehen, dass die Berechnung im Laufe des Tages unterbrochen wurde / oder den Vortag ansehen, um zu sehen, dass alle Stunden des Tages korrekt ausgefüllt sind ^^
Ja, ich dachte, es könnte interessant sein, im Falle eines Debugs genügend Informationen zu haben, und bin davon ausgegangen, dass Gladys eine maximale Loggröße verwaltet. Aber tatsächlich ist es vielleicht zu viel …
Ich habe gerade gesehen, dass ich das gleiche Problem wie @froch mit den Zeiten im Tempo habe:
In meinem Beispiel sollte ich nur die ersten sechs Balken für die Niedertarifzeit haben (von 0 bis 6 Uhr), aber ich habe Niedertarifwerte um 6 Uhr, obwohl ich in der Hochtarifzeit sein sollte.
Es scheint, dass, wenn ein Wert die Endzeit überschreitet und danach aufgezeichnet wird, er in den nächsten Zeitschlitz verschoben wird.
Seltsam ist, dass die Kosten dieses Abschnitts tatsächlich auf den Niedertarifkosten blau basieren (die um 6 Uhr enden).
Ich beziehe mich auf meinen Beitrag hier zu einem falschen Wert eines meiner Tempo-Indizes (wahrscheinlich aufgrund eines Fehlers beim Senden von Daten meines teleinfo2mqtt-Systems).
Ich habe gerade die Werte vom 11/11/25 (mit Yaak) abgerufen, um zu überprüfen, was passiert ist, und ich habe einen falschen Wert, der sich eingeschlichen hat (800 kWh zu viel)
Gibt es eine Möglichkeit, diesen Wert zu ändern/zu löschen?
Gibt es keine Werteprüfung vor/nach der Berechnung der Energieverfolgung und keine Möglichkeit, einen falschen Wert nicht zu berücksichtigen/zu löschen?
Zugegeben, man müsste definieren, was für Gladys ein falscher Wert ist…
Und für die 30-Minuten-Verbrauchsberechnungen, wird das auf der Summe jedes Werts jeder Zeile, auf einem Durchschnitt oder auf jedem Wert alle 30 Minuten usw. gemacht?
Ich habe auch eine Anfrage gestellt, um unnötige Werte für die Indizes zu bereinigen
Hallo @mutmut
Gut beobachtet, das sah tatsächlich nach einem falsch aufgezeichneten Wert aus.
Um Werte zu ändern oder zu löschen, verwende ich 
DBeaver, um die Datenbank zu öffnen und anzuzeigen, nachdem Gladys gestoppt und die DB gesichert wurde.
Danach habe ich chatGPT gebeten, mir die Abfrage zu erstellen. Ich hatte etwas Mühe mit dem Format der Spalte ‹ created_at ›, daher gebe ich dir nicht alle Antworten weiter, aber die gesamte Abfrage mit Überprüfung vor/nachher lautet:
SELECT device_feature_id, value, created_at
FROM t_device_feature_state
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000';
UPDATE t_device_feature_state
SET value = 158021
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000'
AND value = 958021;
SELECT device_feature_id, value, created_at
FROM t_device_feature_state
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000';
Um die Abfrage in DBeaver auszuführen (nachdem die Tabelle geöffnet wurde - dies konfiguriert das Skript direkt auf der richtigen DB/Tabelle):
Dann fügst du die Abfrage in das Fenster ein und ersetzt den
device_feature_id in jedem Teil der Abfrage (ich habe bereits die richtigen Werte und Daten in der Abfrage basierend auf deiner Tabelle eingegeben - aber überprüfe trotzdem nochmal ^^).Du kannst überprüfen, auf welche Daten die Abfrage angewendet wird, bevor du etwas änderst, indem du nur die erste Abfrage ausführst. Dazu platzierst du den Cursor irgendwo in der ersten Abfrage vor dem « ; » und führst sie mit dem ersten Button aus:
Und du überprüfst unten auf der Seite, ob es der richtige Wert/das richtige Datum ist
Schließlich, wenn alles gut ist, führst du die gesamte Abfrage mit diesem Button aus:
Du wirst die beiden Registerkarten der select-Abfragen Vorher/Nachher unten auf der Seite haben:
Das ist das Problem… Und als ich dir meinen persönlichen Fall schildere, dass ich in dieser Winterzeit bis zu 140 kWh/Tag verbrauche, wurde mir klar, dass @pierre-gilles ein Feld in den Energiepreisen integriert hat, das sehr interessant sein könnte, um eine Inkonsistenz zu erkennen:
Tatsächlich müsste man nur angeben, dass der Wert in kVA und somit nur als Zahl einzutragen ist. Anschließend kennt man die Auslösekurven eines Kunden-Leistungsschalters und insbesondere, dass es unmöglich ist, mit mehr als 18 kWh + 10% (also 19,8 kWh) zu arbeiten, also über 30 Minuten = 19,8 / 2 = 9,9 kWh.
In diesem Fall könnte man diese mathematische Formel integrieren, um:
- Werte, die höher sind, nicht in die Berechnungen einzubeziehen
- Die als inkonsistent erkannten Werte zu melden und zu speichern
- In Zukunft diese Inkonsistenzen auch für Zusatzgeräte zu integrieren (in einem Feature die maximalen Verbrauchswerte eines Geräts wie einer Geschirrspülmaschine angeben). Ich denke an bestimmte Tasmota-Geräte, die mir bereits im Jahr 2024 bei einer Aktualisierung Werte von ‹ 0 › gemeldet haben und die daher denselben Effekt haben werden, den du gerade erlebt hast.
Es ist die Summe der Differenzen zwischen allen aufeinanderfolgenden Werten im Intervall, weder ein Durchschnitt noch eine punktuelle Erfassung.
Schließlich bin ich schon lange der Meinung, dass es ein Mittel geben sollte, um die Feature-Werte direkt in Gladys zu überprüfen/korrigieren/aufzunehmen. Aber das stellt eine sehr große Aufgabe dar, und ich verstehe, dass es nicht einfach ist, dies zu entwickeln. Man sieht es in HA, es ist aufwendig und ich finde es bei der Nutzung überhaupt nicht einfach/einfach zu bedienen. Daher muss man zusätzlich an etwas sehr benutzerfreundliches denken, obwohl es letztlich sehr wenige nutzen werden. Das macht nicht unbedingt Lust, daran zu arbeiten ^^
PS: Bei einem persönlichen Projekt unter Freunden haben wir ebenfalls diese Notwendigkeit, und wir schieben die Arbeit an diesem Teil seit Jahren vor uns her 
Deine Idee zu einem Maximalwert im Zusammenhang mit dem Abonnement, das nicht überschritten werden darf, um einen falschen Wert zu vermeiden, gefällt mir sehr.
Jetzt verstehe ich besser, warum es mit meinen 6 Indizes so lange dauert! Für Indizes, die sich im Laufe des Tages nicht ändern, wäre nur eine Berechnung nötig, statt +30.000 pro Index pro Tag
Okay, es ist in 30-Minuten-Intervallen, also ist mein Argument nicht ganz korrekt, aber wenn ich auf 48 Berechnungen umsteige, ist das schon enorm!
Was ich bei diesem 30-Minuten-Berechnungsintervall nicht verstehe:
- 10:36:53 → 158021
- 10:36:55 → 958021, also eine Differenz von +800.000
- 10:37:01 → 158021, also eine Differenz von -800.000
Die Summe sollte 0 sein, oder?
Ich erinnere mich an eine Diskussion über eine mögliche Hardware-Änderung, aber immer noch in Verbindung mit demselben Gerät. Könnte das der berühmte Reset counter sein, der verhindert, dass die Summe 0 ergibt?
Genau das ist es. Da es einen „negativen Wert“ gibt, betrachtet er dies entweder als Rücksetzung auf 0 oder als Ersatz des Zählers durch einen mit einem negativen Wert.
Man muss den richtigen Mittelweg zwischen allen Anwendungsfällen finden. In diesem Fall zeigt uns ein positiver Fehlerwert mit Rückkehr zum richtigen Wert, dass nicht alle Fälle berücksichtigt wurden.
Daher wird die Lösung, um eine inkonsistente Wert „bestmöglich“ zu erkennen, diesen Fall lösen.
Es werden jedoch weiterhin Fälle auftreten, in denen ein Gerät fehlerhafte Werte zurücksendet, die im „Sicherheitsbereich“ liegen, den wir einrichten könnten, aber das ist unmöglich zu überprüfen, daher bleibt die einzige Lösung in den Händen der Benutzer.
In der Tat, man muss sehen, ob man diese Logik ändern kann. Aber in diesem Fall ist es wirklich nur für die anfänglichen Berechnungen schwer. Bei der anschließenden Verfolgung der 30-Minuten-Intervalle hat dies keine spürbare Zeitauswirkung.
Nein, die Matter-Integration verwaltet nicht die neue Entwicklung zur Energieverfolgung, das ist eine Entwicklung, die noch gemacht werden muss!
Ich bin der Meinung, dass ein Editor in Gladys, mit dem man die Werte der Sensoren anzeigen und ändern kann, super wäre.
Jedenfalls ist es viel einfacher zu entwickeln als eine pseudo-Erkennung von inkonsistenten Werten, die nie alle Fälle abdecken wird und die falschen Werte, die innerhalb der Grenzen bleiben, nicht löst.
Kannst du eine Funktionsanfrage erstellen?
In der Zwischenzeit ist der Tutorium von @Terdious super, um die Änderung direkt in der DB vorzunehmen!