NEWS
Statistic Adapter berechnet falschen Average
-
@hg6806 warte mal bis morgen früh!
wenn du gemäß Doku korrekt konfiguriert haben solltest, könnte der "echte" Mittelwert erst bei erstellen der finalen Ergebnisse erscheinen.
Zur Info, die Sache ist noch immer offen. Habe mal einen neuen DP generiert und den generell mit 1 addiert ob es an der 0 liegt.
Wie auch schon vorher, es wird nur das Laden an sich gemittelt und nicht den Verbrauch über den ganzen Tag.
Es gibt auch einen "Save"-Wert, der die Mittelung des letzten Tages anzeigt. Auch hier falsch.
Darüber gibt es auch schon Issues auf Github, was aber nicht weiterverfolgt wird.Für Min/Max-Werte eignet sich der Adapter aber sehr gut. PV-Leistung max. in 2024 19,2kW!!! :grin:
Ich würde versuchen eine eigene Mittelung zu schreiben, aber NUR wenn der Bezugszähler (Smartmeter) anfängt zu zählen. Und zwar für Haushalt, Heizung und Wallbox. Damit kann ich prozentual die Bezuge aufteilen.
-
Zur Info, die Sache ist noch immer offen. Habe mal einen neuen DP generiert und den generell mit 1 addiert ob es an der 0 liegt.
Wie auch schon vorher, es wird nur das Laden an sich gemittelt und nicht den Verbrauch über den ganzen Tag.
Es gibt auch einen "Save"-Wert, der die Mittelung des letzten Tages anzeigt. Auch hier falsch.
Darüber gibt es auch schon Issues auf Github, was aber nicht weiterverfolgt wird.Für Min/Max-Werte eignet sich der Adapter aber sehr gut. PV-Leistung max. in 2024 19,2kW!!! :grin:
Ich würde versuchen eine eigene Mittelung zu schreiben, aber NUR wenn der Bezugszähler (Smartmeter) anfängt zu zählen. Und zwar für Haushalt, Heizung und Wallbox. Damit kann ich prozentual die Bezuge aufteilen.
@hg6806 ich fürchte wir reden aneinander vorbei!
Dein Interesse benötigt andere Voraussetzungen als die Ermittlungen des durchschnittlichen Ladestroms.würde auch für Solarproduktion gelten.
Es ist dabei Blödsinn , die Stunden der Nacht mit einzubeziehenkein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
Hallo zusammen,
ich möchte den durchschnittlichen Stromverbrauch meiner Wallbox pro Tag berechnen.
Das Problem ist aber dass entweder die 0 nicht einbezogen wird oder erst bei einer Aktualisierung berechnet wird, ich denke aber eher erstes.
In einem Beispiel habe ich heute in der Mittagszeit für nur 2-3h mein Auto mit 1800-2300W geladen. Vorher und nachher waren es 0W.
Als Mittel habe ich nun 2180W. Wenn man das über den ganzen Tag bis jetzt sieht, dürfen es nur ein paar hundert Watt sein.@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? -
@hg6806 ich fürchte wir reden aneinander vorbei!
Dein Interesse benötigt andere Voraussetzungen als die Ermittlungen des durchschnittlichen Ladestroms.würde auch für Solarproduktion gelten.
Es ist dabei Blödsinn , die Stunden der Nacht mit einzubeziehenUrsprü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.
-
@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? -
@hg6806 sagte in Statistic Adapter berechnet falschen Average:
Ja, sind beide falsch
wie gesagt liegt "falsch" alleine im Auge des Betrachters!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@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.
-
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.🧑🎓 Autor des beliebten ioBroker-Master-Kurses
🎥 Tutorials rund um das Thema DIY-Smart-Home: https://haus-automatisierung.com/
📚 Meine inoffizielle ioBroker Dokumentation -
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:
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
-
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:
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 Bohnekein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@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.Dann ist genau das die Erklärung für die seltsamen Werte.
Ich bin davon ausgegangen, dass zeitlich gewichtet wird. -
@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 BohneIch 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. -
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."Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@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 -
@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.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.
-
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.
770
Online32.5k
Benutzer81.9k
Themen1.3m
Beiträge