UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Agrippinenser]

@dieter_p

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]

@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:

@dieter_p

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]

@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]

@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]

@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.

[Dieter_P]

@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]

@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.

Spoiler

[Dieter_P]

@marc-berg

Also Dein Vorschlag funktioniert bei mir perfekt, Danke!

[haus-automatisierung]

@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

[Marc Berg]

@haus-automatisierung

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.

[Dieter_P]

edit: gelöscht da nicht passend zum Problem

[Marc Berg]

@haus-automatisierung

@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

[haus-automatisierung]

@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...

[Agrippinenser]

@dieter_p @Marc-Berg

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

[Dieter_P]

@agrippinenser
kämpfe ehrlicherweise noch mit dem für mich neuen Data Explorer um mir per Export Daten in Excel zu schieben und damit manuell zu rechnen/integrieren. Da gab es doch mal nen Button grrrr

Da ich noch im Hinterkopf habe, dasss zu letzt das Problem durch die Grenzen der Aggregation verursacht worden sind und ich bei meinem Beispiel um 0h und 24h keine Leistungen/Werte vorliegen hab, kann das vlt. der Grund sein warum die Rechnung passt.

Insofern muß ich nochmal mit anderen Messtellen und auch Zeitbereichen "spielen" und das validieren. Bei der Suche im influxdB-Forum nach meinem Problem wo es zu erst auftrat bilde ich mir nun ein bei der Suche recht häufig Beiträge zu falschen Ergebnissen der Integralrechnung zu sehen....

Edit:
"Schön" der CSV-Button zum Export im Data-Explorer fehlt in der aktuellen Version wenn man nicht über HTTPS zugreift sondern nur über http. Bug oder Feature egal, hält mich gerade wieder nur extrem auf.....

[Marc Berg]

@dieter_p sagte in influxdb2 Watt zu Wh summieren:

"Schön" der CSV-Button zum Export im Data-Explorer fehlt in der aktuellen Version wenn man nicht über HTTPS zugreift sondern nur über http. Bug oder Feature egal, hält mich gerade wieder nur extrem auf.....

Uhhh, das ist ja wirklich böse. Und wenn man sich die Kommentare im Influx-Forum anschaut, wird der Button wohl auch nicht wiederkommen.

[Dieter_P]

@marc-berg
Mit meinem Viertel-Wissen (Nicht Halbwissen :)) empfinde ich es auch als recht heiß, mal eben https einzuschalten. Danach könnte durch Nicht-Funktion gar keine Daten mehr in der dB eines Produktivsystems landen.

Muß also erstmal ein Testsystem "beflügeln" um damit weiter testen zu können und dann wohl irgendwann mal https im Produktivsystem zu aktivieren (wenn ich weiß wie es sicher funktioniert). Sorry aber nervt mich gerade extrem so eine Änderung, wenn man sich bewusst für http entschieden hat da es mir im Prinzip völlig Wumpe ist, wenn die Verbräuche der Waschmachine im Schlimmsten Fall in fremden Händen landen, also die Sicherheit des Heimnetzwerks/Firewall erstmal als ausreichend selbst bewusst so gewählt wurde...Sorry *Offtopic

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.

[Marc Berg]

@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.csv

[Dieter_P]

@marc-berg

Vielen Dank. Probiere das am Testsystem.

Edit: Mmmh, auch mit dem CSV-Export stimmt die Integralrechnung über Flux bei mir überein. Erstmal positiv.

[sten-tor]

@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.