NEWS
influxdb2 Watt zu Wh summieren
-
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Du hast vielleicht eine Glaskugel Wird der Button auch bei Https verschwinden (Deine Einschätzung)? Dann kann ich mir die den Aufwand schenken und direkt andere Methoden lernen.
Glaskugel ist gerade auf Urlaub. Als brauchbare Alternative könnte man die CLI mit dem "raw" Parameter nutzen:
influx query 'from(bucket: "iobroker") |> range(start: -10d) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Wetter.isRainingNow")' --raw >> test.csvVielen Dank. Probiere das am Testsystem.
Edit: Mmmh, auch mit dem CSV-Export stimmt die Integralrechnung über Flux bei mir überein. Erstmal positiv.
-
@marc-berg sagte in influxdb2 Watt zu Wh summieren:
Was ich noch nicht verstehe ist die unit bei der Integralfunktion.
Ich habe mich damit auch schon länger beschäftigt und bin irgendwie etwas ratlos, warum falsche Werte rauskommen. Hier mal meine Testreihe. Eventuell kann das von Euch jemand nachvollziehen:
https://gist.github.com/klein0r/a3391b36b60eb0bb9ed344be1705ad82
@haus-automatisierung @Marc-Berg
Das ist kein bug, sondern ein feature glaube ich. Ich habe mir das mal genauer angeschaut und eine Erklärung gefunden:
Die Integral-Funktion ergänzt hier erst Zwischenwerte zwischen den einzelnen Zeitstempeln durch Interpolation und führt darüber dann das Integral aus.
Hier mal anhand Matthias' Beispiel dargestellt:
Falls die Messung mit festen Zeitintervallen erfolgt, sind die 46,25 Wh tatsächlich korrekt errechnet, denn wir kennen ja die echten Werte zwischen Minute 0 und 4 nicht - müssen also sinnvollerweise einen Mittelwert annehmen.
Bei Messwerterhebung durch Wertänderungs-Trigger wären die 54,16 Wh richtig. Möchte man hier integral() nutzen, müsste man zu jedem Triggerzeitpunkt zwei Werte speichern: Den Wert vor Trigger und den Wert nach Trigger - sinnvollerweise mit einem kleinen Zeitversatz.
-
@haus-automatisierung @Marc-Berg
Das ist kein bug, sondern ein feature glaube ich. Ich habe mir das mal genauer angeschaut und eine Erklärung gefunden:
Die Integral-Funktion ergänzt hier erst Zwischenwerte zwischen den einzelnen Zeitstempeln durch Interpolation und führt darüber dann das Integral aus.
Hier mal anhand Matthias' Beispiel dargestellt:
Falls die Messung mit festen Zeitintervallen erfolgt, sind die 46,25 Wh tatsächlich korrekt errechnet, denn wir kennen ja die echten Werte zwischen Minute 0 und 4 nicht - müssen also sinnvollerweise einen Mittelwert annehmen.
Bei Messwerterhebung durch Wertänderungs-Trigger wären die 54,16 Wh richtig. Möchte man hier integral() nutzen, müsste man zu jedem Triggerzeitpunkt zwei Werte speichern: Den Wert vor Trigger und den Wert nach Trigger - sinnvollerweise mit einem kleinen Zeitversatz.
@sten-tor Wow, vielen Dank! So ergibt das Ganze natürlich wieder Sinn. Wenn man mit den Standard ioBroker-Adaptern arbeitet um Werte zu protokollieren, dann wird es ja etwas schwierig den vorigen Wert ebenfalls zu speichern.
-
@haus-automatisierung @Marc-Berg
Das ist kein bug, sondern ein feature glaube ich. Ich habe mir das mal genauer angeschaut und eine Erklärung gefunden:
Die Integral-Funktion ergänzt hier erst Zwischenwerte zwischen den einzelnen Zeitstempeln durch Interpolation und führt darüber dann das Integral aus.
Hier mal anhand Matthias' Beispiel dargestellt:
Falls die Messung mit festen Zeitintervallen erfolgt, sind die 46,25 Wh tatsächlich korrekt errechnet, denn wir kennen ja die echten Werte zwischen Minute 0 und 4 nicht - müssen also sinnvollerweise einen Mittelwert annehmen.
Bei Messwerterhebung durch Wertänderungs-Trigger wären die 54,16 Wh richtig. Möchte man hier integral() nutzen, müsste man zu jedem Triggerzeitpunkt zwei Werte speichern: Den Wert vor Trigger und den Wert nach Trigger - sinnvollerweise mit einem kleinen Zeitversatz.
@sten-tor super, das deckt sich mit den Testreihen, die ich durchgeführt habe. Wenn ich (anders, als in Matthias' Beispiel) konstante Zeitabstände in den Testdaten habe, rechnet die integral Funktion korrekt:
Wenn ich allerdings einen Messwert > 0 an den "Berechnungsgrenzen" einfüge (hier die 1000):
wird der erste Wert IMMER nur mit 50% berücksichtigt, egal, welcher Wert folgt. Und das beißt sich aus meiner Sicht mit der Interpolations-Theorie.NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@sten-tor super, das deckt sich mit den Testreihen, die ich durchgeführt habe. Wenn ich (anders, als in Matthias' Beispiel) konstante Zeitabstände in den Testdaten habe, rechnet die integral Funktion korrekt:
Wenn ich allerdings einen Messwert > 0 an den "Berechnungsgrenzen" einfüge (hier die 1000):
wird der erste Wert IMMER nur mit 50% berücksichtigt, egal, welcher Wert folgt. Und das beißt sich aus meiner Sicht mit der Interpolations-Theorie.@marc-berg Probier doch mal, die Parameter unit und interpolate (https://docs.influxdata.com/flux/v0.x/stdlib/universe/integral/) zu verändern:
- unit z.B. auf 1s und/oder
- interpolate auf "" setzen (sollte lt. Doku eigentlich defaultmäßig sein, aber vielleicht ist das falsch implementiert)
Bringt das was?
-
@marc-berg Probier doch mal, die Parameter unit und interpolate (https://docs.influxdata.com/flux/v0.x/stdlib/universe/integral/) zu verändern:
- unit z.B. auf 1s und/oder
- interpolate auf "" setzen (sollte lt. Doku eigentlich defaultmäßig sein, aber vielleicht ist das falsch implementiert)
Bringt das was?
@sten-tor sagte in influxdb2 Watt zu Wh summieren:
@marc-berg Probier doch mal, die Parameter unit und interpolate (https://docs.influxdata.com/flux/v0.x/stdlib/universe/integral/) zu verändern:
- unit z.B. auf 1s und/oder
- interpolate auf "" setzen (sollte lt. Doku eigentlich defaultmäßig sein, aber vielleicht ist das falsch implementiert)
Bringt das was?
Habe ich alles schon durch. Wenn ich die unit auf kleinere Werte setze, kommt immer ein Vielfaches raus. Also das Doppelte bei 60m>30m oder das Vierfache bei 60m-->15m, etc.
Interpolate bringt bei "" das gleiche Ergebnis wie ohne Parameter, mit "linear" wilde (teils negative) Werte, die ich mir nicht herleiten kann.NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@sten-tor super, das deckt sich mit den Testreihen, die ich durchgeführt habe. Wenn ich (anders, als in Matthias' Beispiel) konstante Zeitabstände in den Testdaten habe, rechnet die integral Funktion korrekt:
Wenn ich allerdings einen Messwert > 0 an den "Berechnungsgrenzen" einfüge (hier die 1000):
wird der erste Wert IMMER nur mit 50% berücksichtigt, egal, welcher Wert folgt. Und das beißt sich aus meiner Sicht mit der Interpolations-Theorie.@marc-berg sagte in influxdb2 Watt zu Wh summieren:
wird der erste Wert IMMER nur mit 50% berücksichtigt, egal, welcher Wert folgt. Und das beißt sich aus meiner Sicht mit der Interpolations-Theorie.
Sicher? Wenn ich dein Beispiel mit Interpolation nachrechne, komme ich genau auf das von deiner InfluxDb angezeigte Ergebnis. Die Interpolation ist ja quasi der Mittelwert der Grenzwerte * Zeit:
Min 0 - 10: (1000W+500W)/2 * 1/6h = 125 Wh
Min 10 - 20: (500W+1500W)/2 * 1/6h = 166,67 Wh
Min 20 - 30: (1500+0W)/2 * 1/6h = 125 WhSumme: 416,67 Wh
-
@sten-tor sagte in influxdb2 Watt zu Wh summieren:
@marc-berg Probier doch mal, die Parameter unit und interpolate (https://docs.influxdata.com/flux/v0.x/stdlib/universe/integral/) zu verändern:
- unit z.B. auf 1s und/oder
- interpolate auf "" setzen (sollte lt. Doku eigentlich defaultmäßig sein, aber vielleicht ist das falsch implementiert)
Bringt das was?
Habe ich alles schon durch. Wenn ich die unit auf kleinere Werte setze, kommt immer ein Vielfaches raus. Also das Doppelte bei 60m>30m oder das Vierfache bei 60m-->15m, etc.
Interpolate bringt bei "" das gleiche Ergebnis wie ohne Parameter, mit "linear" wilde (teils negative) Werte, die ich mir nicht herleiten kann.@marc-berg sagte in influxdb2 Watt zu Wh summieren:
mit "linear" wilde (teils negative) Werte
Ja, ist bei mir auch so.
linearliefert ganz komisches Zeug. Habe ich hier noch ergänzt:https://gist.github.com/klein0r/a3391b36b60eb0bb9ed344be1705ad82
🧑🎓 Autor des beliebten ioBroker-Master-Kurses
🎥 Tutorials rund um das Thema DIY-Smart-Home: https://haus-automatisierung.com/
📚 Meine inoffizielle ioBroker Dokumentation -
@marc-berg sagte in influxdb2 Watt zu Wh summieren:
mit "linear" wilde (teils negative) Werte
Ja, ist bei mir auch so.
linearliefert ganz komisches Zeug. Habe ich hier noch ergänzt:https://gist.github.com/klein0r/a3391b36b60eb0bb9ed344be1705ad82
Influx interpoliert in deinem Beispiel Werte für VOR dem ersten Messwert, weil dein Range 10 Minuten vor dem ersten Wert anfängt. Da die Steigung nach dem ersten Punkt positiv ist, wird der Wert vor dem ersten Punkt negativ:
Setz doch mal dein Range-Start/Stop auf den ersten bzw. letzten Timestamp der Werte - dann müsste das gleiche rauskommen.
-
Influx interpoliert in deinem Beispiel Werte für VOR dem ersten Messwert, weil dein Range 10 Minuten vor dem ersten Wert anfängt. Da die Steigung nach dem ersten Punkt positiv ist, wird der Wert vor dem ersten Punkt negativ:
Setz doch mal dein Range-Start/Stop auf den ersten bzw. letzten Timestamp der Werte - dann müsste das gleiche rauskommen.
@sten-tor sagte in influxdb2 Watt zu Wh summieren:
Setz doch mal dein Range-Start/Stop auf den ersten bzw. letzten Timestamp der Werte
Okay muss ich mal testen, aber in der Praxis wähle ich ja z.B. in einem Grafana-Dashboard nie genau die Zeiträume, zu denen es auch Daten gibt.
EDIT: Du hast Recht, dann sind es wieder 46,25 Wh. Also identisch zum "leeren" Parameter.
Support us
457
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge