Welche InfluxDB

Kann mir jemand sagen, mit welcher InfluxDB Version die aktuelle openEMS Edge version läuft. Ich habe momentan die openEMS 2.5.0 mit InfluxDB 1.x laufen. Da gehen zwar Daten rein, die ich auch mir Grafana anzeigen kann, aber im openems UI dins die Diagramme leer. Brauch ich da die 2.x Version von InfluxDB? Die gibt es aber wohl nur als 64bit-Variante. Bekomme ich die überhaupt auf einem 32-Bit Raspberry zum laufen?

Hallo Thomas,

generell sollte jede aktuelle OpenEMS-Version mit InfluxDB 1 und 2 funktionieren. Ich vermute, du nutzt 2022.5.0, damit müsste es gehen.

Gibt es eine Fehlermeldung in der Konsole? Stimmen Datum und Uhrzeit?

Gruß,
Stefan

die 2022.5.0 hatte ich bis vor kurzem. Damit lief es aber auch nicht. Daher habe ich auf die 2022.6.0 geupdatet in der Hoffnung, dass es damit läuft. Geändert hat sich allerdings nichts.
Sowohl Openems als auch die InfluxDB sind beide auf dem Raspberry unter dem gleichen Benutzer (openems) installiert und im Log von OpenEMS tauchen keine Fehlermeldungen auf. Datum und Zeit stimmen zwangsweise, da die gleiche Maschine, auch. In Grafana (auch auf dem Raspi) kann ich die Daten wunderbar sehen, nur im Openems UI sehe ich nichts.




Danke für die detaillierte Rückmeldung. Ich setze InfluxDB v.A. am OpenEMS Backend ein, vielleicht hängt es damit zusammen.

Kommt im OpenEMS Edge (journalctl -lfu openems) oder im OpenEMS UI (Browserconsole) eine Fehlermeldung?

Hallo Stefan,
ich bin gerade auf dem Weg zum Flughafen. Ich melde mich wenn ich wieder da bin.

Hallo Stefan,
aus dem urlaub zurück hab ich gleich mal geschaut. I dem moment in dem ich auf die Historie klicke kommen im Log folgende Warnungen:

15.7.2022, 12:23:16
WARN
io.openems.common.websocket.OnRequestHandler
[ctrlApiWebsocket0] JSON-RPC Error Response "Energy values are not available for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()" for Request {"method":"edgeRpc","params":{"edgeId":"0","payload":{"method":"queryHistoricTimeseriesEnergy","params":{"timezone":"Europe/Berlin","fromDate":"2022-07-15","toDate":"2022-07-15","channels":["_sum/ConsumptionActiveEnergy","pvInverter0/ActiveProductionEnergy","pvInverter1/ActiveProductionEnergy","_sum/GridBuyActiveEnergy","_sum/GridSellActiveEnergy","_sum/ProductionActiveEnergy","_sum/EssActiveDischargeEnergy"]}}}}
15.7.2022, 12:23:16
WARN
io.openems.edge.bridge.modbus.api.ModbusWorker
[modbus2] FC4ReadInputRegisters [meter0;unitid=1;ref=0/0x0;length=80] execution failed: Transaction failed: Executing transaction 06 0C 00 00 00 06 01 04 00 00 00 50 failed (tried 1 times) Executing transaction failed (tried 1 times): Executing transaction 06 0C 00 00 00 06 01 04 00 00 00 50 failed (tried 1 times) General exception - failed to read - null
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-19640] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-7118] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-26758] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-21] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-2] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()
15.7.2022, 12:23:16
WARN
io.openems.shared.influxdb.InfluxConnector
Got negative Energy value [-26739] for query: data = from(bucket: "smarthomewt")|> range(start: 2022-07-14T22:00:00Z, stop: 2022-07-15T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy" or r["_field"] == "pvInverter0/ActiveProductionEnergy" or r["_field"] == "pvInverter1/ActiveProductionEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference()

Kurz danach erscheint dieser Fehler:

15.7.2022, 12:23:19
ERROR
io.openems.shared.influxdb.InfluxConnector
InfluxDB query runtime error. Query: from(bucket:"smarthomewt") |> range(start:2022-07-14T21:55:00.000000000Z, stop:2022-07-15T22:00:00.000000000Z) |> filter(fn: (r) => r["_measurement"] == "data") |> filter(fn: (r) => (r["_field"] == "_sum/ConsumptionActivePower" or r["_field"] == "_sum/GridActivePower" or r["_field"] == "_sum/ProductionActivePower" or r["_field"] == "_sum/ProductionDcActualPower")) |> aggregateWindow(every:5m, fn:mean), Error: panic: runtime error: invalid memory address or nil pointer dereference 

Diese Warnung kommt von OpenEMS. Energiewerte müssen streng monoton steigend sein. Nur dann kann aus der Differenz letzter minus erster Wert der Energiewert für einen bestimmten Zeitraum berechnet werden. Hier scheinen die Daten nicht richtig zu sein. Welche Geräte/Zähler setzt du ein? Wir hatten das schon öfters bei Geräten, dass die internen Energiezähler nicht richtig funktioniert haben. In dem Fall kann OpenEMS die Energiewerte auch selbst aus den Leistungswerten berechnen.

Dieser Fehler kommt direkt von der InfluxDB; leider gibt es dafür wohl keine Lösung.

Mit InfluxDB 1.8.10-1 (Debian-Paket) tritt der Fehler bei mir nicht auf.

Es sollte die gleiche Fehlermeldung kommen, wenn die die Abfrage z. B. aus Grafana absetzt:

range(start:2022-07-14T21:55:00.000000000Z, stop:2022-07-15T22:00:00.000000000Z) |> filter(fn: (r) => r["_measurement"] == "data") |> filter(fn: (r) => (r["_field"] == "_sum/ConsumptionActivePower" or r["_field"] == "_sum/GridActivePower" or r["_field"] == "_sum/ProductionActivePower" or r["_field"] == "_sum/ProductionDcActualPower")) |> aggregateWindow(every:5m, fn:mean)

Gruß,
Stefan

Hallo Stefan,

der erste Fehler könnte aus dem Lesefehler meines SDM630 Smartmeters resultieren. Dazu hatte ich ja schon einen anderen Thread hier aufgemacht. Es ist halt so, dass wenn der Raspberry neu gestartet wurde ständig Lesefehler über ModbusTCP kommen. Mit der Zeit bessert sich das ohne weiteres zutun und nach etwa 5-6 Stunden klappt der Zugriff fehlerfrei. Ich hab absolut keine Ahnung was da die Ursache sein könnte.
Als Erzeugungseinheiten habe ich zwei Kostal Plenticore Plus. Einen 10er und einen 8.5er.
Ich bersuche mal die InfluxDB neu aufzusetzen. Vielleicht klappt es ja dann, wobe ich imme rnoch davi ausgehe, dass wenn ich von openEMS in die InfluxDB schreiben kann, aber nicht mehr auslesen, dass dann was mit dem Auslesebefehl nicht stimmt. So gibt es bei mir in der InfluxDB zum beispiel ncith das Feld “_sum/ProductionDcActualPower”.

Ergänzend zwei Scripte mit denen der Influx Server einfach geprüft werden kann:

Antwort eines Influx-Server der den Fehler hat:

curl -XPOST 127.0.0.1:8086/api/v2/query -sS \
  -H 'Accept:application/csv' \
  -H 'Content-type:application/vnd.flux' \
  -d 'from(bucket:"influx0/autogen")
        |> range(start:2022-07-17T21:55:00.000000000Z, stop:2022-07-18T22:00:00.000000000Z)
        |> filter(fn:(r) => r._measurement == "data")
          |> filter(fn: (r) => (r["_field"] == "_sum/ConsumptionActivePower" or r["_field"] == "_sum/EssActivePower" or r["_field"] == "_sum/EssSoc" or r["_field"] == "_sum/GridActivePower"))
          |> aggregateWindow(every:5m, fn:mean)'


error
panic: runtime error: invalid memory address or nil pointer dereference

Antwort desselben Servers bei Verwendung einer anderen Aggregierungsfunktion ( fn:max statt fn:mean: )

curl -XPOST 127.0.0.1:8086/api/v2/query -sS \
  -H 'Accept:application/csv' \
  -H 'Content-type:application/vnd.flux' \
  -d 'from(bucket:"influx0/autogen")
        |> range(start:2022-07-17T21:55:00.000000000Z, stop:2022-07-18T22:00:00.000000000Z)
        |> filter(fn:(r) => r._measurement == "data")
          |> filter(fn: (r) => (r["_field"] == "_sum/ConsumptionActivePower" or r["_field"] == "_sum/EssActivePower" or r["_field"] == "_sum/EssSoc" or r["_field"] == "_sum/GridActivePower"))
          |> aggregateWindow(every:5m, fn:max)'

ok

Der Aufruf funktioniert bei uns auf einem Ubuntu-System mit Influx Version 1.8.6.
Auf einem Raspberry Pi haben wir Influx in der Version 1.8.10 installiert und dort funktioniert der Aufruf leider nicht.

OpenEMS nutzt die Funktion fn:mean.

Nun ja, genau auf einem Raspberry habe ich aber die InfluxDB laufen und hatte eigentlich nicht vor, mir noch irgendwo einen PC hin zu stellen.

Hallo Thomas,

dann sehe ich 2 Optionen:

  1. du kannst influx als .tar.gz runterladen und eine eigene neuere Version davon auf dem Raspberry betreiben. Dann funktioniert der Update-Mechanismus für Influx aber nicht mehr.
  2. du änderst den Zugriff auf die historischen Daten im InfluxConnector:L437. Dort kannst du die Aggregierungsfunktion z.B. von “mean” auf “max” ändern. Die visuellen Auswirkungen z.B. in der historischen 30 Tage Ansicht dürften für viele Systeme minimal sein. Vielleicht reicht dir die Umstellung ja.

Gruß, Christian

Das ändern der Aggregationsfunktion auf “max” hat keine Änderung gebracht. Das Problem muss woanders liegen.

7.8.2022, 18:20:15
ERROR
io.openems.shared.influxdb.InfluxConnector
InfluxDB query runtime error. Query: from(bucket:"smarthomewt") |> range(start:2022-08-05T21:55:00.000000000Z, stop:2022-08-06T22:00:00.000000000Z) |> filter(fn: (r) => r["_measurement"] == "data") |> filter(fn: (r) => (r["_field"] == "_sum/ConsumptionActivePower" or r["_field"] == "_sum/GridActivePower" or r["_field"] == "_sum/ProductionActivePower" or r["_field"] == "_sum/ProductionDcActualPower")) |> aggregateWindow(every:5m, fn:max), Error: null

und vorher kommt das:

7.8.2022, 18:20:15
ERROR
io.openems.shared.influxdb.InfluxConnector
InfluxDB query runtime error. Query: data = from(bucket: "smarthomewt")|> range(start: 2022-08-05T22:00:00Z, stop: 2022-08-06T22:00:00Z)|> filter(fn: (r) => r._measurement == "data")|> filter(fn : (r) => (r["_field"] == "_sum/ConsumptionActiveEnergy" or r["_field"] == "_sum/EssActiveDischargeEnergy" or r["_field"] == "_sum/GridBuyActiveEnergy" or r["_field"] == "_sum/GridSellActiveEnergy" or r["_field"] == "_sum/ProductionActiveEnergy"))first = data |> first()last = data |> last()union(tables: [first, last])|> difference(), Error: null

Problem gelöst!
in der Standardinstallation der InfluxDB auf dem Raspberry Pi ist in der influxdb.conf unter [HTTP]
der Punkt “#flux-enabled=false” auskommentiert.
Wenn der aktiviert und auf “flux-enabled=true” gestellt wird kann OpenEMS auch Daten wieder aus der InfluxDB lesen. Das Schreiben funktioniert offenbar auf andere Weise. Zumindes funktioniert es dann mit der “max” Variante.

Zu früh gefreut. irgendwie macht OpenEMS sehr merkwürdige Dinge.


Das ist das Diagramm, welches in meiner InfluxDB vom heutigen Tag aufgezeichnet wurde. Das sieht ja halbwegs gescheit aus. Aber warum habe ich bei 102,5kWh Erzeugung 102,4kWh Verbrauch wo doch der Großteil eingespeist wurde. Dazu kommt ja noch, dass die Autarkie und der Eigenverbrauch niemals 100% sei kann, da ich ja nachts und auch gegen 18 Uhr Netzbezug hatte. Kann das an der Modifikation von “Mean” auf “max” liegen? So macht das alles jedenfalls keinen Sinn.

UPDATE. Es liegt nicht an der Modifikation von “mean” zu “max”. Ich habe inzwischen ein 64bit Raspberry Pi System aufgesetzt und dort die InfludxDB V2 installiert. Das läuft gut mit dem original vorcomilierten jar 2…8.0
Allerdings ändert sich nichts daran, dass das System in der Historie völligen Blödsinn bei Autarkie, Eigenverbrauche, Einspeisung, Bezug und Verbrauch anzeigt. Die Diagramme sind ja OK, aber das was da unten steht ist absoluter schwachsinn.
Brauche ich da noch irgend einen Controller, damit das richtig läuft. Ich habe biser nur meine Kostal Wechselrichter und mein Grid-Smartmeter eingebunden.

Sind gerade alle Wissenden im Urlaub? Könnte jemand meine Frage im vorherigen pst beantworten? Warum stimmt die Bilanz der Energiemengen nicht in openems? Klappt das erst, wenn der Speicher im System ist? Selbst ohne Speicher muss das doch passen.

Hallo Thomas,

ja, die Energiedaten in dem Screenshot sind offensichtlich falsch.

In der Tagesgrafik zeigt OpenEMS UI die Leistungswerte an (also z. B. _sum/ProductionActivePower, _sum/GridActivePower, _sum/ConsumptionActivePower etc.)

Für die Energiewerte werden andere Channels genutzt, z. B. _sum/GridBuyActiveEnergy und _sum/GridSellActiveEnergy). Per Definition müssen diese Channels streng monoton steigend sein, da dann in der Abfrage lediglich der letzte Wert des Tages (bzw. gewählten Zeitraums) minus den ersten Wert gerechnet werden muss.

Es sieht so als, als würden die Daten des Netzzählers nicht richtig aufgezeichnet. Das ist leider ein Phänomen, das wir recht häufig sehen. Welche Netzzähler-Komponente ist denn konfiguriert?

Hier noch eine Übersicht aller _sum-Channels:

https://openems.github.io/openems.io/javadoc/io/openems/edge/common/sum/Sum.ChannelId.html

Gruß,
Stefan

Als Netzzähler ist der Microcare SDM 630 Meter konfiguriert. Dieser ist per Modbus an einen Waveshare Modbus to ethernet Gateway angeschlossen. Die Abfrage erfolgt also per ModbusTCP. Allerdings habe ich da ziemlich viele Aussetzer, was ich ja schon geschrieben habe.

Eine kurze Anmerkung zum SDM630. Wir verwenden einen Controlin SKM-005-M Meter. Dieser soll baugleich zum SDM630 sein. Der Controlin-Meter läuft mit dem SDM630 Treiber. Allerdings sind die Energiewerte um den Faktor 1000 verschoben. Ich gehe daher davon auss, dass im Treiber falsch gemappt wurde. Möglicherweise erklärt das auch eines deiner Anzeige-Probleme mit dem Meter. Ich bin diese Woche unterwegs und kann keinen Pull-Request stellen. Aber hier ein Screenshot der entsprechenden Stelle:


VG Christian

Das kann ich mir mal anschauen. Gibt es eigentlich irgendwo eine Log-Funktion um zu sehen, was da genau an Bytes über den Modbus kommt?
Mein Zähler ist auch kein Microware, aber ich benutze den Treiber in der Annahme, dass die alle Baugleich wären. Ich habe einen Eastron SDM 630 Modbus V2.
EASTRON SDM630