"ingest" für Verbraucher

[esusxunil]

Ich bin beim Lesen der News über das neue Modul ingest gestolpert, was meinem Verständnis nach ja nur zur Korrektur der Daten bei Verwendung einer Balkonkraftwerkes nötig ist.

Ein Feature dort ist mir aber ins Auge gesprungen. Und zwar die Lösung des Problem, dass die Messdaten ja nicht synchronisiert rein kommen und daher interploiert werden können.

Das Problem der nicht synchronisierten Messdaten tritt ja auch bei Verbrauchern auf.

Beispiel:
Backofen (gemessen über Shelly-EM) wird eingeschaltet. Zur korrekkten Anzeige müssten nun die Werte vom Shelly und vom Hausverbrauch synchron sein. Gibt derzeit nun eigentlich immer zwei Szenarien:

Szenario 1:
Shelly meldet Verbrauch vor dem Anstieg des Hausverbrauches. In dem Fall sinkt der Verbrauch der anderen Verbraucher ins negative und Solectrus zeigt, bis der korrigierte Hausverbrauch gemeldet wird, ein Ausrufezwichen an.

Szenario 2:
Shelly meldet Verbrauch nach dem Anstieg des Hausverbrauches. In dem Fall steigt der Verbrauch der anderen Verbraucher kurzfristig um den realen Verbrauch des Backofens an und Solectrus zeigt einen schmalen Spike in der Statistik an.

Meine Idee wäre nun das man ingest so aufbohrt, dass dieser auch diese Messdaten synchronisieren/interpolieren könnte.

[ledermann]

Richtig, momentan ist der Einsatz von Ingest nur dann sinnvoll und empfehlenswert, wenn man ein BKW zusätzlich zur Dachanlage hat und den Hausverbrauch korrigieren möchte. Hat man ein solches nicht, gibt es nichts zu korrigieren und Ingest reicht alle Messwerte unverändert nach InfluxDB durch, was man sich dann natürlich sparen kann.

Denkbar sind weitere Ausbaustufen von Ingest. Aufgrund der Architektur besteht prinzipiell die Möglichkeit, Messwerte vor dem eigentlichen Schreiben nach InfluxDB abzugleichen oder zu korrigieren - wie beispielsweise für das von dir geschilderte Szenario.

Beim Einschalten sowie beim Ausschalten eines separaten Verbrauchers kommt es aufgrund der nicht synchronisierten Messwerte zu kleinen Artefakten. Es wäre schön, wenn dies korrigiert werden könnte.
Ich überlege, wie ein solcher Algorithmus aussehen könnte.

Denkbar wäre eine verzögerte Weitergabe der Einzelverbraucher-Messwerte: Wenn ein Messwert z.B. vom Backofen kommt, wird dieser so lange zurückgehalten, bis ein neuer Messwert des Hausverbrauchs kommt (der dann vermutlich entspreched hoch ist). Dann werden beide gleichzeitig weitergeleitet - mit identischem Zeitstempel. Schwierig wird es dann aber, wenn der Takt stark voneinander abweicht (z.B. 5s vs. 20s) - oder wenn ein Sensor vorübergehend ausfällt. Ich bin mir nicht sicher, ob das so ideal ist, zumindest finde ich Eingriffe in den Zeitstempel etwas problematisch, weil ich dann ja Dinge nach InfluxDB schreibe, die nicht der Reatlität entsprechen.

Für eine Interpolation fehlt mir momentan die Fantasie, wie das aussehen könnte. Der Hausverbrauch wird ja momentan bereits berechnet (nicht gemessen), und zwar rückwärts aus den anderen Werten, um den BKW-Ertrag berücksichtigen zu können. Wie könnten denn jetzt zusätzlich die Kleinverbraucher mit einfließen, um die Artefakte zu vermeiden? Den Hausverbrauch weiter zu verändern, fühlt sich für mich falsch an, weil das dann ja nicht mehr zu den anderen Werten passt (Erzeugung, Batterie, Wallbox etc). Wenn überhaupt, dann müsste man die Einzelverbraucher ran und diese anpassen.

Hast du konkrete Ideen für eine Berechnungsweise?

[esusxunil]

Ich gebe dir Recht, trivial ist das Problem überhaupt nicht.
Dass eigentlich jede Lösung nicht der Realität entspricht, fände ich nicht so schlimm, denn schon die Werte die wir jetzt bekommen, entsprechen ja nicht 100% der Realität und sind in dem Moment wo wir sie haben ja eigentlich schon veraltet, jedoch spätestens durch die Taktung, wenige Augenblicke später.
Ziel sollte es sein, die Messtoleranz die wir alleine durch die Taktung haben nicht zu verschlimmern, sondern im Idealfall zu korrigieren oder zu verkleinern.

Fall 1 (Shelly liefert neuen Wert vor dem neuen Hausverbrauch):
Ich finde den Ansatz mit der verzögerten Weitergabe (nur bei Einzelverbraucher-Messwerten) gar nicht so verkehrt, diese würde zumindest 50% der Fälle, also alle bei denen der Einzelwert vor dem Hausverbrauch ankommt, lösen.
In dem Fall würde man den Takt vom Hausverbrauch als "Mastertakt" nehmen und immer wenn der Wert aktualisiert wurde, schreibt man alle Messwerte der Einzelverbraucher in einem Rutsch mit weg.
Sollte ein Sensor eines Einzelverbrauchers ausfallen, oder langsamer takten, der Wert also mal nicht geändert sein, schreibt man ihn halt nicht mit weg.
Sollte ein Sensor eines Einzelverbrauchers schneller takten als der "Mastertakt", würde es ja auch nicht viel Sinn ergeben Ihn zwischendurch wegzuschreiben. Klar verliert man dann etwas Auflösung bei dem Einzelwert, ein in Bezug setzen mit dem in der Zwischenzeit nicht aktualisiertem Hausverbrauch würde ab ebenfalls zu falschen Werten führen.

Fall 2 (Shelly liefert neuen Wert nach dem neuen Hausverbrauch):
Der andere Fall, indem wir einen aktualisierten Hausverbrauch haben, ein Einzelverbrauch eines gerade ein-/ausgeschalteten Gerätes aber noch nicht aktualisiert wurde, ist deutlich schwieriger.

Ideen hierzu:

Folgende Kriterien deuten auf Anomalien hin:

1. die Summe der Einzelverbraucher übersteigt den Hausverbrauch (führt aktuell zu Fehlermeldung auf der Oberfläche)
2. Wert der sonstigen Verbraucher macht einen großen Sprung nach oben oder unten
3. Wert Hausverbrauch macht einen großen Sprung nach oben oder unten ohne dass die Einzelverbrauchswerte ebenfalls einen Sprung gemacht haben.

Schwellwerte könnte man konfigurierbar machen. Bei mir sollten die sonstigen Verbraucher nie über 200 Watt liegen – für alles andere habe ich z.B. Sensoren.

Bei einer erkannten Anomalie könnte man nun folgendes tun:

1. Den Datensatz erstmal nicht schreiben, sondern nur merken.
2. Wenn vor der nächsten Aktualisierung des Hausverbrauches bei der Änderurng eines Einzelverbrauchers die Anomalie verschwindet, den Datensatz nun mit aktualisiertem Einzelverbraucher und Timestamp doch noch schreiben.
3. Wenn bei der nächsten Aktualisierung des Hausverbrauches die Anomalie verschwindet, den alten Datensatz verwerfen und nur den komplett neuen Datensatz mit aktualisiertem Hausverbrauch schreiben.
4. Wenn bei der nächsten Aktualisierung des Hausverbrauches die Anomalie bestätigt wird, dann beide Datensätze schreiben, dann hat es wohl einen Grund (z.B. keinen Sensor für Grossverbraucher)

[ledermann]

Danke für den sehr nützlichen Input! Da werde ich nun aber eine Weile drüber nachdenken müssen ;-)