Ich habe ein funktionierendes Openems (Backend + Edge ) System mit mehreren Zählern.
Es gibt keinen Netzanschlusszähler daher ist das Setup:
Jeder Zähler ist als CONSUMPTION_METERED eingestellt
Es gibt einen “Virtual Meter Add”, der alle anderen Zähler als Grid Zähler zusammenfasst.
Nun füge ich im Moment InfluxDB für die Historischen Daten hinzu.
Der Einfachheit halber nutze ich im Moment die gehostete Version (also V2).
Mein Problem ist, dass sämtliche Zählerwerte nicht an InfluxDB übertragen werden (was sie aber sollten, weil die UI ja auch die einzelnen Channels abfragt).
Ich sehe keine Fehlermeldungen oder Ähnliches im OpenEMS Backend Log.
Ich benutze Telegraf lokal, um die (etwas vielen) Felder zu begrenzen, da die gehostete Version nur 200 Spalten unterstützt. Im Moment schließe ich aus:
Ich kümmere mich um den StackTrace.
Ich gehe aber stark davon aus, dass der Fehler daher kommt, dass channels abgefragt werden die nicht in der InfluxDB gespeichert werden.
Beispiel:
Der virtuelle Zähler (meter0) setzt sich aus den Zählern “tiefgarage” und “büro” zusammen. Die UI sucht nach den Werten für alle 3 Channels. Wenn ich aber manuell schaue, was in der InfluxDB landet, sind dort nur die Werte für den virtuellen “meter0”.
Update: Ich habe meine eigene InfluxDB 1.8 aufgesetzt um den diversen Problemen mit zu vielen Spalten zu umgehen.
Soweit läuft auch alles (inklusive Historie).
Mein vorheriger Fehler war vermutlich, dass ich die Edge Instanz nicht mit der InfluxDB verbunden habe (Ich dachte, alles läuft übers Backend).
Wenn die Edge Instanz mit InfluxDB verbunden ist, werden die Channels der Stromzähler gespeichert (sonst nur _sum). Interessanterweise funktioniert die Aufteilung in der Historie dann auch nur in einer lokalen (mit der Edge Instanz verbundenen) UI. Siehe Fotos.
Ist das so gewollt?
Im Prinzip ist es nicht notwendig, dass OpenEMS Edge direkt in die InfluxDB schreibt - das geht auch über OpenEMS Backend. Übers Backend werden aber standardmäßig weniger Daten gesendet, um das Backend bei vielen Tausend verbundenen Edges nicht unnötig zu belasten. Siehe dafür z. B. Controller.Api.Backend.
Dieses Verhalten wird im Wesentlichen über die Konfiguration persistencePriority im Controller gesteuert. Setze diese niedriger, damit mehr Daten geschickt werden.
Ich bin mittlerweile dazu gekommen, tiefer in das Problem einzutauchen.
Als Zwischenlösung hat es über die Influx Verbindung per Edge gepasst, aber dass man die Daten nicht detailliert über die UI im Backend bekommt ist auf Dauer ein Problem.
Ich habe die persistencePriority im Controller.Api.Backend testweise auf VERY_LOW gesetzt, die InfluxDB Verbindung in der Edge Instanz gelöscht und alles neugestartet. Seitdem werden die Zählerwerte nicht mehr seperat in Datenbank gespeichert. Interessanterweise sagen die Logs des SendChannelValuesWorker, dass eigentlich alle Daten an das Backend gesendet werden:
wir haben derzeit ein sehr ähnliches Problem mit zwei Edge-Instanzen, die ihre Daten an ein zentrales Backend übertragen sollen.
In der InfluxDB, die die Daten lokal vom Edge entgegen nimmt, sind die Informationen aller SmartMeter ersichtlich. In die InfluxDB des Backend werden nur die Meta- und Summen-Werte übertragen, obwohl die Persistence (alle drei Optionen) auf VERY_LOW gesetzt ist und auch das Log vermeldet, dass alle Channels übertragen werden (~1200).
@2Stuffy Ergab sich hierzu in der Zwischenzeit noch etwas?
Als Partner im Projekt Open Mobility Electric Infrastructure (OMEI) versuchen wir an der Universität Passau eine Datengrundlage aus Versuchsanlagen u.a. zu Schnellladen, Pufferbatterien und bidirektionalem Laden zu generieren und dabei auch künstliche Intelligenz als Controller zu integrieren. Das Backend soll die Daten der Edges dazu zentral speichern und eine API für die anderen Projektpartner bereitstellen.
Vielen lieben Dank für das Update @2Stuffy! Das klingt zu schön, um wahr zu sein
Dockerisiert haben wir OpenEMS schon vor längerem, als es das out of the box noch nicht gab. Ich hoffe also, dass es nichts direkt damit zu tun hat.
Da ich die Odoo-Synchronisierung gerade so zum Laufen bekommen habe und uns die Version 2025.6.0 einen kleinen Bug in der Batteriekommunikation einbrachte (PR pending), zögere ich gerade ein bisschen. Muss beides (Edge+Backend) auf 2025.8.0 dafür sein? In den Release Notes sehe ich zwar ein paar Updates am Backend, gleichzeitig nichts direkt relevantes. Jemand eine Idee, welcher Code den entscheidenden Durchbruch brachte?
Ich kann leider auch nicht versprechen, dass die neue Version Abhilfe bringt.
Mir ist noch aufgefallen, dass auch in der UI Historie jetzt andere Optionen (“phasengenau“ etc) zur Verfügung stehen (siehe Screenshot). Da allerdings die Werte vorher gar nicht erst in der Datenbank gelandet sind, kann ich mir nicht vorstellen, dass ein Update der UI hilft.
