NEWS
influxdb2 Watt zu Wh summieren
-
ich versuche mich ein wenig in Flux einzuarbeiten.
Da sich unser Stromanbieter mit Einbau des 2 Richtungszählers viel Zeit lässt hatte ich mir die Umrechnung des Überschusses des Balkonkraftwerks als Aufgabe gestellt.
Überschuss wird alle 5 Sekunden aktualisiert. Gestern sah das so aus:
Im Zeitraum 12:00 - 13:00 Uhr könnte man etwa 300 Wh schätzen. Über den ganzen Tag gerechnet kommt jedoch nur 236,46 Wh. Das Ergebnis soll nur eine Annäherung sein aber das kommt hier überhaupt nicht hin. Aber wo ist der Fehler ?
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: false) |> reduce(fn: (r, accumulator) => ({ Wh: float(v: r._value / 3600.0) + accumulator.Wh} ), identity: {Wh:0.0} ) // Wh=236,46Die Ursache ist klar, du hast jede Menge 1 Sekunden Häppchen, die kein Ergebnis liefern, obwohl die Einspeisung >0 noch vorhanden ist. Ein erster Ansatz wäre, "createEmpty" auf true zu setzen und die dann leeren Windows mit dem vorherigen Wert zu füllen. die "fill()" Funktion kann allerdings in der ersten Zeile immer noch "empty" liefern, womit die reduce Funktion ein Problem hat. Also müsste man dieses eine "empty" noch rausfiltern. Wahrscheinlich ist da ein "if...then" Konstrukt das beste. Es gibt aber sicher noch bessere Lösungen, die ich jetzt nicht parat habe.
|> aggregateWindow(every: 1s, fn: mean, createEmpty: true) |> fill(usePrevious: true) -
ich versuche mich ein wenig in Flux einzuarbeiten.
Da sich unser Stromanbieter mit Einbau des 2 Richtungszählers viel Zeit lässt hatte ich mir die Umrechnung des Überschusses des Balkonkraftwerks als Aufgabe gestellt.
Überschuss wird alle 5 Sekunden aktualisiert. Gestern sah das so aus:
Im Zeitraum 12:00 - 13:00 Uhr könnte man etwa 300 Wh schätzen. Über den ganzen Tag gerechnet kommt jedoch nur 236,46 Wh. Das Ergebnis soll nur eine Annäherung sein aber das kommt hier überhaupt nicht hin. Aber wo ist der Fehler ?
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: false) |> reduce(fn: (r, accumulator) => ({ Wh: float(v: r._value / 3600.0) + accumulator.Wh} ), identity: {Wh:0.0} ) // Wh=236,46Ein alternativer und wahrscheinlich performanterer Vorschlag wäre:
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: true) |> fill(usePrevious: true) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) |> sum()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.
-
Ein alternativer und wahrscheinlich performanterer Vorschlag wäre:
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: true) |> fill(usePrevious: true) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) |> sum()Oh sehr interessant. Hatte das mal mit eine v1 versucht und die Ergebnisse waren einfach falsch, da influxdB keine saubere Definition bzw. Berechnung des Zeitintervalls vollzog.
Für mich ist das eine klassische Anwendung einer Integralrechnung.Leider hat es bei mir nie für die Werte in der dB (Stützstellen) funktioniert, was für kurze Zeiträume ja recht einfach manuell nachrechenbar ist.
Entsprechend das Thema auf Eis gelegt, aber da ich nun eine v2 betreibe, vielleicht mal wieder Zeit das anzugehen:
Seht ihr die Standardfunktion nicht passender?
Danke fürs Feedback
-
Ein alternativer und wahrscheinlich performanterer Vorschlag wäre:
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: true) |> fill(usePrevious: true) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) |> sum()@marc-berg sagte in influxdb2 Watt zu Wh summieren:
performanterer Vorschlag wäre:
.. sitze gerade auf'm Rad und hab gleich zwei Zähne mehr aufgelegt um das zu probieren 😁
-
Oh sehr interessant. Hatte das mal mit eine v1 versucht und die Ergebnisse waren einfach falsch, da influxdB keine saubere Definition bzw. Berechnung des Zeitintervalls vollzog.
Für mich ist das eine klassische Anwendung einer Integralrechnung.Leider hat es bei mir nie für die Werte in der dB (Stützstellen) funktioniert, was für kurze Zeiträume ja recht einfach manuell nachrechenbar ist.
Entsprechend das Thema auf Eis gelegt, aber da ich nun eine v2 betreibe, vielleicht mal wieder Zeit das anzugehen:
Seht ihr die Standardfunktion nicht passender?
Danke fürs Feedback
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Seht ihr die Standardfunktion nicht passender?
Vom mathematischen Standpunkt ist das natürlich die ideale Funktion. Aber man nimmt halt immer das, was man kennt ...
-
Ein alternativer und wahrscheinlich performanterer Vorschlag wäre:
import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1s, fn: mean, createEmpty: true) |> fill(usePrevious: true) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) |> sum()@marc-berg sagte in influxdb2 Watt zu Wh summieren:
Ein alternativer und wahrscheinlich performanterer Vorschlag wäre:
das ergibt mit 783,35 Wh ein dem Chart ähnelndem, annehmbarem Ergebnis - prima !
Da gibt's was für mich zum aufarbeiten denn ich dachte es verstanden zu haben ;-)Vielen Dank
-
Oh sehr interessant. Hatte das mal mit eine v1 versucht und die Ergebnisse waren einfach falsch, da influxdB keine saubere Definition bzw. Berechnung des Zeitintervalls vollzog.
Für mich ist das eine klassische Anwendung einer Integralrechnung.Leider hat es bei mir nie für die Werte in der dB (Stützstellen) funktioniert, was für kurze Zeiträume ja recht einfach manuell nachrechenbar ist.
Entsprechend das Thema auf Eis gelegt, aber da ich nun eine v2 betreibe, vielleicht mal wieder Zeit das anzugehen:
Seht ihr die Standardfunktion nicht passender?
Danke fürs Feedback
da hatte ich auch mit experimentiert aber dann zurückgestellt weil ich erst mal die Basis lernen muss und folgendes auch nicht wirklich verstanden habe.
Es kommt aber mit 781,82 Wh etwas annehmbares raus !
fom(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow( every: 1d, fn: (tables=<-, column) => tables |> integral(unit: 1s) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) ) |> sum() -
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Seht ihr die Standardfunktion nicht passender?
Vom mathematischen Standpunkt ist das natürlich die ideale Funktion. Aber man nimmt halt immer das, was man kennt ...
@marc-berg said in influxdb2 Watt zu Wh summieren:
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Seht ihr die Standardfunktion nicht passender?
Vom mathematischen Standpunkt ist das natürlich die ideale Funktion. Aber man nimmt halt immer das, was man kennt ...
@agrippinenser said in influxdb2 Watt zu Wh summieren:
da hatte ich auch mit experimentiert aber dann zurückgestellt weil ich erst mal die Basis lernen muss und folgendes auch nicht wirklich verstanden habe.
Es kommt aber mit 781,82 Wh etwas annehmbares raus !
fom(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow( every: 1d, fn: (tables=<-, column) => tables |> integral(unit: 1s) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) ) |> sum()Danke fürs Feedback.
So wie ihr sagt, ist für mich ein Integral die theoretisch einleuchtenste Funktion. Teste, wenn ich den Frust von den alten Versuchen abgebaut habe auch gerne nochmal damit. Denke ähnlich wie @agrippinenser es schreibt, fehlt es mir dann flott ebenso schnell an der Basis/das Verständnis in influxdB. Wie man ein Integral berechnet, bilde ich mir noch ein grob auf die Kette zu bekommen aber leider beißt sich das, wie gesagt, mit meiner "Taschenrechner-Prüfung" mit der Funktion ....
Was soll zB die Defintion der Unit in der Intergralfunktion? Bei einer linearen Interpolation würde ich ein eine Definition der Integralgrenzen erwarten, mehr nicht. Den Rest liefern die Einträge in der dB.Mir leuchtet halt nicht ein wie die Integralfunktion zu nutzen ist und das konnte mir im influxdB Forum auch niemand erklären ..... Für die Doku dazu bin ich scheinbar zu blöd.
Nu denn, gebe die Hoffnung nicht auf, das irgendwann nochmal aufgelöst zu bekommen....
-
@marc-berg said in influxdb2 Watt zu Wh summieren:
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Seht ihr die Standardfunktion nicht passender?
Vom mathematischen Standpunkt ist das natürlich die ideale Funktion. Aber man nimmt halt immer das, was man kennt ...
@agrippinenser said in influxdb2 Watt zu Wh summieren:
da hatte ich auch mit experimentiert aber dann zurückgestellt weil ich erst mal die Basis lernen muss und folgendes auch nicht wirklich verstanden habe.
Es kommt aber mit 781,82 Wh etwas annehmbares raus !
fom(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow( every: 1d, fn: (tables=<-, column) => tables |> integral(unit: 1s) |> map(fn: (r) => ({ r with _value: r._value / 3600.0})) ) |> sum()Danke fürs Feedback.
So wie ihr sagt, ist für mich ein Integral die theoretisch einleuchtenste Funktion. Teste, wenn ich den Frust von den alten Versuchen abgebaut habe auch gerne nochmal damit. Denke ähnlich wie @agrippinenser es schreibt, fehlt es mir dann flott ebenso schnell an der Basis/das Verständnis in influxdB. Wie man ein Integral berechnet, bilde ich mir noch ein grob auf die Kette zu bekommen aber leider beißt sich das, wie gesagt, mit meiner "Taschenrechner-Prüfung" mit der Funktion ....
Was soll zB die Defintion der Unit in der Intergralfunktion? Bei einer linearen Interpolation würde ich ein eine Definition der Integralgrenzen erwarten, mehr nicht. Den Rest liefern die Einträge in der dB.Mir leuchtet halt nicht ein wie die Integralfunktion zu nutzen ist und das konnte mir im influxdB Forum auch niemand erklären ..... Für die Doku dazu bin ich scheinbar zu blöd.
Nu denn, gebe die Hoffnung nicht auf, das irgendwann nochmal aufgelöst zu bekommen....
@dieter_p @Agrippinenser
Aber so wie ich die Integral Funktion verstehe und mit meinen bescheidenen Mathe-Kenntnissen zusammenbringe, sollte die Query doch so aussehen, oder?import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> integral(unit: 1h) -
@dieter_p @Agrippinenser
Aber so wie ich die Integral Funktion verstehe und mit meinen bescheidenen Mathe-Kenntnissen zusammenbringe, sollte die Query doch so aussehen, oder?import "date" // gestern 00:00:00 - 23:59:59 START = date.truncate(t:-1d, unit:1d) STOP = date.add(d: 86399s, to: START) from(bucket: "iobroker") |> range(start: START, stop: STOP) |> filter(fn: (r) => r["_measurement"] == "solar.ueberschuss") |> filter(fn: (r) => r["_field"] == "value") |> integral(unit: 1h)@marc-berg
Danke. das ähnelt eher dem, was ich verstehe/erwarte.Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Sonst muß ich mal gucken, wie ich das testen kann. Ich nutze kein Graphana und möchte da im Endergebnis ein Blockly- mit der Query auf die Datenbank loslassen und das Ergebnis wieder im IObroker (DP) verwenden. Deswegen holpert es es schon manchmal dort bei meinen Tests.:confused:
-
@marc-berg
Danke. das ähnelt eher dem, was ich verstehe/erwarte.Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Sonst muß ich mal gucken, wie ich das testen kann. Ich nutze kein Graphana und möchte da im Endergebnis ein Blockly- mit der Query auf die Datenbank loslassen und das Ergebnis wieder im IObroker (DP) verwenden. Deswegen holpert es es schon manchmal dort bei meinen Tests.:confused:
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Hehe, genau das verstehe ich auch noch nicht! Wenn du da mal eine Erkenntnis hast, lass es mich bitte wissen.
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.
-
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Hehe, genau das verstehe ich auch noch nicht! Wenn du da mal eine Erkenntnis hast, lass es mich bitte wissen.
@marc-berg said in influxdb2 Watt zu Wh summieren:
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Hehe, genau das verstehe ich auch noch nicht! Wenn du da mal eine Erkenntnis hast, lass es mich bitte wissen.
hab gerade die Gedanken kreisen lassen..... der Zeitstempel ist doch in influxdB in msec aufgelöst. Bilde ich nun ein Integral von x bis y. Macht er das bestimmt/vielleicht, aber es wäre schöner die Einheit des Ergebnisses direkt zu definieren. Hier in kWh nicht kWmsec
Wenn das die unit Defintion bewirkt also /3600000 das Ergebnis, würde ich es verstehen. Bleibt es zu verifizieren.
-
@marc-berg
Danke. das ähnelt eher dem, was ich verstehe/erwarte.Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Sonst muß ich mal gucken, wie ich das testen kann. Ich nutze kein Graphana und möchte da im Endergebnis ein Blockly- mit der Query auf die Datenbank loslassen und das Ergebnis wieder im IObroker (DP) verwenden. Deswegen holpert es es schon manchmal dort bei meinen Tests.:confused:
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Sonst muß ich mal gucken, wie ich das testen kann. Ich nutze kein Graphana und möchte da im Endergebnis ein Blockly- mit der Query auf die Datenbank loslassen und das Ergebnis wieder im IObroker (DP) verwenden. Deswegen holpert es es schon manchmal dort bei meinen Tests
Ich finde den Data Explorer der InfluxDB GUI dafür ideal. Insbesondere, weil die Spalten, Datentypen und Group Fields mit angezeigt werden, die besonders wichtig für das Verständnis von Stream, Table, etc. sind.
-
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Sonst muß ich mal gucken, wie ich das testen kann. Ich nutze kein Graphana und möchte da im Endergebnis ein Blockly- mit der Query auf die Datenbank loslassen und das Ergebnis wieder im IObroker (DP) verwenden. Deswegen holpert es es schon manchmal dort bei meinen Tests
Ich finde den Data Explorer der InfluxDB GUI dafür ideal. Insbesondere, weil die Spalten, Datentypen und Group Fields mit angezeigt werden, die besonders wichtig für das Verständnis von Stream, Table, etc. sind.
-
@dieter_p sagte in influxdb2 Watt zu Wh summieren:
Was ich noch nicht verstehe ist die unit bei der Integralfunktion. Die Funktion könnte/sollte doch einfach von dB-Eintrag zu dB-Eintrag interpolieren und nicht künstlich da ein Raster drüberlegen.... macht es doch nicht besser.
Hehe, genau das verstehe ich auch noch nicht! Wenn du da mal eine Erkenntnis hast, lass es mich bitte wissen.
@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
🧑🎓 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:
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
Ich versuche erstmal, den Inhalt zu verstehen. Klappt soweit, bis auf diese Passage:
Kannst du das bitte erklären?Edit: jetzt hab ich's. Mit den Testdaten wurde das dann klar.
-
Ich versuche erstmal, den Inhalt zu verstehen. Klappt soweit, bis auf diese Passage:
Kannst du das bitte erklären?Edit: jetzt hab ich's. Mit den Testdaten wurde das dann klar.
-
@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 sagte in influxdb2 Watt zu Wh summieren:
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:
Also ich kann das absolut nachvollziehen, die berechneten 46,25Wh in der zweiten Testreihe sind offensichtlich falsch. Ich habe mal versucht, an den Eingangsdaten ein wenig herumzuändern, um auf den berechneten Wert zu kommen. Vielleicht ließe sich so herausfinden, was falsch läuft. Ist mir aber noch nicht gelungen.
Für mich ist das ein Bug in der Integral Funktion. Wenn ich noch ein wenig Zeit finde, werde ich mal noch ein paar Testdaten erzeugen, um zu sehen, wann richtig und wann falsch gerechnet wird.Genutzt wird ja scheinbar diese Go-Funktion. Ließe sich daraus etwas ablesen?
https://github.com/influxdata/flux/blob/master/stdlib/universe/integral.go#L148NUC10I3+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.
-
@haus-automatisierung sagte in influxdb2 Watt zu Wh summieren:
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:
Also ich kann das absolut nachvollziehen, die berechneten 46,25Wh in der zweiten Testreihe sind offensichtlich falsch. Ich habe mal versucht, an den Eingangsdaten ein wenig herumzuändern, um auf den berechneten Wert zu kommen. Vielleicht ließe sich so herausfinden, was falsch läuft. Ist mir aber noch nicht gelungen.
Für mich ist das ein Bug in der Integral Funktion. Wenn ich noch ein wenig Zeit finde, werde ich mal noch ein paar Testdaten erzeugen, um zu sehen, wann richtig und wann falsch gerechnet wird.Genutzt wird ja scheinbar diese Go-Funktion. Ließe sich daraus etwas ablesen?
https://github.com/influxdata/flux/blob/master/stdlib/universe/integral.go#L148@marc-berg sagte in influxdb2 Watt zu Wh summieren:
Also ich kann das absolut nachvollziehen, die berechneten 46,25Wh in der zweiten Testreihe sind offensichtlich falsch.
Ja genau - ich hatte mit der Integralfunktion komische Werte rausbekommen und dann eine kleine Testreihe mit Werten erstellt, welche man nachvollziehen kann und das Ergebnis kennt. Ich weiß nicht wo mein Fehler liegt...
-
bei mir weichen die heutigen Ertragsdaten mit integral deutlich ab. Der Workaround von @haus-automatisierung liefert hingegen genau. Ich hoffe man kann die Werte entziffern
Support us
377
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge