Statistic Adapter berechnet falschen Average
-
@hg6806
Bisher habe ich nie nachgerechnet ob die Werte stimmen...
Aber du schaust für den aktuellen Tag auch den DP dayAvg unter statistics.x.temp an und nicht unter statistics.x.save? -
Ursprünglich wollte ich alle Stromverbräuche von Haushalt, Wärmepumpe und Wallbox über den ganzen Tag mitteln und dann daraus Faktoren bilden. Über den Stromverbrauch des Zählers wollte ich dann grob ermitteln wer dann wieviel verbraucht hat am Tag.
Ich weiß, das wäre recht ungenau geworden. Tagsüber bei PV lade ich eher das Auto, nachts läuft eher die Wärmepumpe. Aber es wäre mal interessant zu wissen was prozentual so auf die Verbraucher abfällt.Da aber das mit dem Average über den Statistics-Adapter nicht funktioniert, werde ich eine eigene Mittelung versuchen, die auch nur dann mittelt/zählt, wenn auch wirklich der Bezugszähler aktiv ist, heißt aus dem Netz zieht. Das wird dann genauer, aber ich muss mich erst in das Mittelungs-Thema einfinden.
-
Ja, sind beide falsch. Wie schon geschrieben, gibt es dazu Issues auf Github.
-
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Ja, sind beide falsch
wie gesagt liegt "falsch" alleine im Auge des Betrachters!
-
Meiner Meinung nach NICHT.
Denn eine Average muss auch 0 oder auch 1 mit einbeziehen.
Sonst hätte eine Grenze ab wann überhaupt gemittelt werden soll, definierbar sein müssen. Die gibt es aber hier nicht.
Ich weiß doch gar nicht wann überhaupt die Mittelung anfängt!Ich rede hier nicht von einem Ladestrom, sondern von einer Stromaufnahme einer Wallbox. und wenn die die meiste Zeit 0 ist, muss das in die Mittelung mit einbezogen werden.
-
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Denn eine Average muss auch 0 oder auch 1 mit einbeziehen.
Die Werte sind ja aktuell nicht zeitlich gewichtet. Das heißt, es werden alle Werte addiert und durch die Anzahl der Werte geteilt. Jede Änderung = neuer Eintrag in die Liste.
Also angenommen Du hast
0, 1800, 2300, 0über den Tag - dann ist die Summe4100.4100 / 4 = 1025 WDurchschnitt. Ist halt für Werte (welche sich sehr selten ändern) nicht so gut zu gebrauchen. -
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Ich weiß doch gar nicht wann überhaupt die Mittelung anfängt!
Das Ende sieht man doch unter save: 15 minütlich, täglich, stündlich, monatlich, vierteljährlich, wöchentlich und jährlich
-
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Meiner Meinung nach NICHT.
Denn eine Average muss auch 0 oder auch 1 mit einbeziehen.da drehen wir uns im Kreis!
Daher letztmals:
wenn ich die durchschnittliche Leistungsaufnahme des Autos an der Wallbox haben will, um zukünftige Ladezeiten einschätzen zu können, interessieren mich die 0-Werte an denen die Wallbox ruht, nicht die Bohne -
Dann ist genau das die Erklärung für die seltsamen Werte.
Ich bin davon ausgegangen, dass zeitlich gewichtet wird. -
Das ist mir auch bewusst.
Mit Mittelung anfangen hatte ich gemeint, aber welchen Wert (weil ich dachte 0 oder 1 wird nicht einbezogen) und nicht zu welcher Zeit. -
Ich glaube du hast mich noch nicht verstanden.
Ladezeiten vom Auto interessieren mich nicht, bzw. weiß ich das ja generell durch den Ladestrom.
Hier geht es um den generellen Stromverbrauch und Gewichtung bzw. Gegenüberstellung von Haushalt, Wärmepumpe und Wallbox.
Und wenn die 0 der Wallbox nicht mit einbezogen wird, bzw. zeitlich gewichtet wird, verfälscht es meine Berechnung. -
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Ich glaube du hast mich noch nicht verstanden.
Oh, ich denke er hat Dich sehr wohl verstanden.
Das Problem ist, dass man "Average" auf verschiedene Arten definieren kann und der Adapter eine verwendet, die nicht Deine Anforderungen abdeckt, sondern die der allermeisten Anwender.
Wie @haus-automatisierung schon schreibt, ist der Tagesdurchschnitt völlig korrekt berechnet.
Der Adapter nimmt halt die Summe der Werte und teilt sie durch die Anzahl Werte. Das, was man allgemein als "Durchschnitt" bezeichnet.
Selbst wenn man das auf Stunden runterbrechen würde, gibt es irgendwann Leute die das anders haben möchten.Beispiel:
Du verbrätst von 12:00 bis 12:30 1.000 W. Von 12:30 bis 13:00 2.000 W.
=> 1.000 + 2.000 / 2 = 1.500 W
Diese Aussage ist erstmal für die betrachtete Stunde korrekt.
Kommen jetzt von 13:00 bis 14:00 nochmal 2.000 W dazu, macht das
=> 1.000 + 2.000 + 2.000 / 3 = 1.667 W
Hier wird's ja bereits falsch, weil ungewichtet. Es werden 1.5 Std. lang 2.000 W verbraten und nur 30 Minuten lang 1.000 W.
Das ganze Dilemma könnte man nur auflösen, wenn man regelmäßig in Zyklen die gerade bezogene Leistung protokolliert. Aber was ist dann genau genug? 1 Minute? 30 Sekunden? 1 Sekunde?Ich kenne und nutze den Adapter nicht. Sowas mache ich per SQL.
Aber vielleicht kannst Du dem Adapter ja an der Ecke auf die Sprünge helfen und ihm per Script jede Stunde eine 0 oder 1 extra spendieren, so dass Du in Summe auf eine ausreichende Anzahl Werte kommst.
Aber auch das wird falsche Werte liefern müssen, wenn innerhalb einer Stunde z.B. mal 1.500 und mal 3.000 W gemessen werden.Ich muss aber gestehen, dass ich die Anforderung noch nicht geblickt habe.
Wenn ich die Verbräuche von Wallbox, Wärmepumpe usw. in Beziehung setzen will, würde ich den Gesamtverbrauch (pro Zeiteinheit. Tag?) nehmen und keinen - wie auch immer ermittelten - Durchschnitt.
Demnach auch nicht die Leistung (W), sondern die Arbeit (kWh).Eine andere Herangehensweise:
Bei jeder Änderung der aktuellen Leistung berechnet man die Arbeit über den letzten Wert und die Zeit zwischen den Änderungen. Das speichert man in einem eigenen DP.
Die Statistik darüber dürfte zumindest Näherungsweise genauer sein. -
@codierknecht
EXKURS:
ich habe für die Vorbereitung auf meine Wärmepumpe den gleitenden (geglätteten) Durchschnitt der Gasmenge berechnen um einen halbwegs gleichmäßigen Verbrauch ohne Taktung o.ä. zu erhalten.
Leider sendete der ESP32CAM nicht wie geplant immer alle 3 Minuten, wenn der Wert bei 0 stand.ich habe dann ein Monsterkonstrukt gebastelt
um dem Schieberegister ausreichend 0-Werte unterzujubeln, da sonst der Mittelwert nicht "schlüssig" war -
Nun, da es mir an Programmierkenntnissen mangelt, war meine Vorangehensweise, dass ich einfach über den Statistics Adapter den täglichen Stromverbrauchsdurchschnitt (Leistung) von Haushalt, Wärmepumpe und Wallbox bekomme und dann über eine Dreisatzberechnung mit dem Zählerstand und Sourceanalytixadapter kurz vor Tageswechsel den Verbrauch pro Tag (Arbeit in kWh) bekomme und wieder in Sourceanalytics schreibe.
Natürlich nur näherungsweise.
Aber da der Statistics Adapter nicht zeitlich mittelt funktioniert das so nicht.Da werde ich also doch den steinigen Weg einschlagen und selbst versuchen eine zeitliche Mittelung zu schreiben und wie oben erwähnt, dann nur im Bezugsfall aktiv zu haben. So bekomme ich die genauesten Werte.
Dafür brauche ich aber Ruhe und Zeit was im Moment Mangelware ist.Das Blockly von @Homoran schaue ich mir dann auch mal an.
Hintergrund war übrigens der, dass ich durch eine 2. PV Anlage und zusätzlichem Speicher, der Strombezug derart gering geworden ist, dass ich einen 2. Zähler für die Wärmepumpe abgemeldet habe, somit mir aber die Zähler-Bezugswerte für die Wärmepumpe fehlen.
-
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
dass ich einen 2. Zähler für die Wärmepumpe abgemeldet habe, somit mir aber die Zähler-Bezugswerte für die Wärmepumpe fehlen
Also hast Du nur die jeweilige Momentanleistung zur Verfügung?
Dann musst Du - Wohl oder Übel - die Arbeit selbst über die Zeit ermitteln.Hatte ich zu Zeiten des Ferrariszählers auch machen müssen.
Ist halt eher ein Schätzeisen
-
Was mir gerade einfällt.
Sourceanalytix kann das ja auch.
Also eine Leistung kumulieren und damit die Zeit mit einbeziehen und Arbeit in kWh daraus basteln.
Wenn ich die momentane Leistung nun als neuen Datenpunkt nur im Bezugsfall erfasse und direkt in Sourceanalytix speise, habe ich direkt den gewünschten Wert ohne noch den Stromzählerwert mit einzubeziehen.Wobei das mit dem Testen schwierig wird, da ich wahrscheinlich vor November oder gar Dezember keinen Bezugsfall haben werde.
