OpenEMS Community - Latest posts

OpenEMS UI build for ARM 32

@omedirk Omedirk — Mon, 16 Mar 2026 10:45:31 +0000

ah. i don’t have rights to push .. how to get those?

OpenEMS UI build for ARM 32

@omedirk Omedirk — Mon, 16 Mar 2026 10:09:25 +0000

happy to do so.

i reworked it a bit and choose for a commit with a dockerfile.alpine so that the original structure is untouched.
after your review we can decide what way to go (i imagine we want a single setup, not 2 options) but for the PR you can at least see the difference.

having this in the main repo would be ideal.

ps. we did a similar thing for the edge container running on arm32. happy to share that too

as you will see we run from azure, the variables are injected on IOTedge deployment.

we are in the process of figuring out whether OpenEMS can function as a replacement for our own EMS. but that means not only ‘functioning as an EMS’ but also be deployable and maintainable as an EMS..

Konfiguration des Backends: "Edge.Websocket" fehlt ?

@Howaner Franz Reiter — Mon, 16 Mar 2026 09:53:52 +0000

Die Verbindung erfolgt in neueren Versionen nicht mehr direkt zwischen Edge und Backend.

Sie wird wie folgt aufgebaut: Edge → Edge Server → Backend

Leider wird die .jar Datei vom neuen Edge Server noch nicht im Release hinterlegt.
Man muss aktuell den Edge Server selbst builden: gradlew buildBackendEdge
Die .jar ist im Anschluss unter build/openems-backend-edge.jar zu finden.

In der Felix Konsole von BackendEdge (Port 8078) kann dann eine Verbindung zum Backend aufgebaut werden und der Websocket für Edge konfiguriert werden.

OpenEMS UI build for ARM 32

@da-Kai Kai J. — Thu, 12 Mar 2026 17:35:27 +0000

Hi @omedirk,

ARM32 support would definitely be useful, especially for edge deployments. I have already played with the idea.

i would not completely remove the s6 overlay builds as they make debugging way easier, as they can keep the container alive when the services crashes.

Maybe it could make sense to keep the current images for the default builds and offer your Alpine-based variant as a separate “-slim” image.

In any case, I am curious to see what you built. It might actually be easiest if you open a PR on GitHub so we can review the changes and discuss them there.

Best regards,
Kai

OpenEMS UI build for ARM 32

@stefan.feilmeier Stefan Feilmeier — Wed, 11 Mar 2026 21:44:07 +0000

Thanks! I am not a Docker expert - @da-Kai what do you think? I’d say it’s definitely worth a look.

OpenEMS UI build for ARM 32

@omedirk Omedirk — Wed, 11 Mar 2026 21:22:49 +0000

Hi All,

i rebuild the UI docker container for edge use because we needed ARM32 support & remote access.

I need some info on whether to push this as contribution. @stefan.feilmeier, hope you can help me with that.

the new build changes the following:

moved to alpine:3 base images (smaller). no more s6 overlays, but chown-at-build. ARM32 now supported
NGINX reverse proxy setup to support remote access to the UI. No need for the backend setup to view a remote UI now when the right environment vars are enabled.

because these changes are quite extensive i don’t want to just push then.

where can i post this (the dockerfile & reverse proxy setup) for a pre-review as i dont think just pushing this as PR is too much.

Rgds

Konfiguration des Backends: "Edge.Websocket" fehlt ?

@hrohmer Heinz Rohmer — Wed, 11 Mar 2026 05:49:45 +0000

Ich habe das gleiche Problem. Version 2026.01 hat noch den Edge.Websocket mit dem sich die Verbindung vom Edge zum Backend erfolgreich einrichten lässt. Ab Version 2026.02 fehlt der Edge.Websocket und wurde wohl durch Edge.Manager ersetzt. Bei Version 2026.02 konnte ich auf dem Backend feststellen, dass der Port des Edge.Manager erst gar nicht benutzt wird. Bei Version 2026.03 war es dann so, dass der Port des Edge.Manager existiert. Im Client konnte ich dann aber das gleiche Verhalten beobachten.

Im Log konnte ich sehen, dass die Verbindung auf und sofort wieder abgebaut wird. Im Backend-Code wird eine “ID” geprüft, die übergeben wird. Vielleicht fehlt an dieser Stelle noch etwas in der Configuration im Edge?

Hat schon jemand eine Lösung für das Problem?

[FEMS] Überschussladen mit Phasenumschaltung an KEBA P40

@s_h — Tue, 10 Mar 2026 23:10:39 +0000

Darauf wollte ich hinaus. Bei VW kann es helfen “AC-Stecker automatisch entriegeln“ zu aktivieren.

[FEMS] Überschussladen mit Phasenumschaltung an KEBA P40

@Trinity — Tue, 10 Mar 2026 21:36:09 +0000

Das muss ich tatsächlich mal prüfen - ich glaube, in weiß.

Ich wurde mittlerweile auf eine Einstellung im Born aufmerksam gemacht, die mein Problem verursachen könnte. Ich werde das testen, wenn das Wetter wieder passend ist

[FEMS] Überschussladen mit Phasenumschaltung an KEBA P40

@s_h — Mon, 09 Mar 2026 16:48:29 +0000

In welcher Farbe leuchtet dann die LED im Ladeanschluss vom Born? Bei meinem ID.4 und der OpenWB kenne ich das auch, das liegt bei mir aber am Fahrzeug. Mit dem Audi etron hatte ich sowas nie.

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@energy — Mon, 09 Mar 2026 13:09:51 +0000

bin auch hier gerade drauf gestoßen:

Jedoch ist leider meine WB noch nicht enthalten, aber scheinbar tut sich dort gerade etwas.

[FEMS] Überschussladen mit Phasenumschaltung an KEBA P40

@Trinity — Mon, 09 Mar 2026 12:36:25 +0000

Hallo in die Runde … ich melde mich auch mal, da ich hier schon einige Monate mitlese.

Auch ich warte seit Sommer letzten Jahres auf eine software-technische Umsetzung des Überschussladens mit Phasenumschaltung. Die Umstellung auf den Open Beta im Dezember 25 hab ich leider zu spät realisiert und erst vor ein paar Wochen den Schalter umgelegt.

Soweit hat auch alles geklappt, zwar gibt es noch keine automatische Phasenumschaltung aber auch mit einer manuellen könnte ich erstmal schon leben. Seitdem jetzt die Sonne die letzten Tage so lange scheint, versuche ich jeden Überschuss ins Auto zu schieben. Dabei muss ich jedoch feststellen, dass in der FENECON-App auch noch nicht alles optimal läuft.

Mein Fehlverhalten stellt sich so dar, dass das Auto mit variabler Leistung 3-phasig geladen wird, aber wenn das FEMS die Ladung unterbricht, startet sie nicht wieder automatisch, wenn genug Leistung erzeugt wird. Hat jemand ein ähnliches Verhalten? Bei mir hilft dann nur Ausstecken und Einstecken …

Mein System:

FEMS mit Version 2026.3.1
Keba P40 mit Version 1.4.2
Fahrzeug: Cupra Born
Auch angeschlossen ist rabot.energy: hier ist jedoch aktuell Smart-Charging deaktiviert

Würde mich über Feedback jeder Art freuen. Danke!!

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@energy — Mon, 09 Mar 2026 12:30:53 +0000

#evcc müsste ich selbst erst tieferlegen indem Moment fehlte die Zeit und auch die App fürs Schreiben ins FEMS

#AustauschFEMS korrekt, aber dann eröffnet sich vermutlich auch die Frage um Garantie usw.

#Tibber korrekt so habe ich es auch gemacht und dann aber die WB gesperrt wenn es für mich nicht passte, dann hatte das Auto zwar gesagt “Go”, aber die WB machte dicht um nicht meinen Akku im Haus leer zu ziehen. Denn da muss man auch hinschauen, denn der Anbieter aktiviert nicht zwangsläufig das Laden zu den Zeiten wo es auch gerade günstig für einen selbst wäre und was bringt es mir dann, dass ich zwar 3 Cent Rückvergütung pro kWh erhalte, aber in dem Moment den Strom für 35 Cent beziehe statt eine Stunde später für 25 Cent - aber anderes Thema.

Bin ich auch bei dir, eben keine Unterscheidung, daher ist ja die Suche nach Mehrwerten die Börsenstromanbieter dort betreiben um sich irgendwie interessanter zu machen und sich von anderen hervortun zu können. Aber auch da nicht verwerflich, da es sich ja um profitorientierte Unternehmen handelt und der Kunde ja selbst entscheiden kann. Aber dort immer noch “besser” als die klassischen Anbieter - jedoch auch hier driften wir ab

Aber du hast mir schon sehr geholfen, ich werde mich mal weiter durchwurschteln um für mich das beste Setup hinzubekommen, vermutlich wird es auf HA + REST/Modbus schreibend hinauslaufen und die App dynamische Tarife zu deaktivieren.

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@m.hauser — Mon, 09 Mar 2026 11:19:17 +0000

Ja, das mit WARP2 und Energy Manager ist mir klar.

Kann ich zum aktuellen Zeitpunkt nicht nachvollziehen, was evcc bei dir an Problemen verursacht hätte.

Ich sehe beim FEMS eher den Betreuungsaufwand seitens Support bei Fenecon als Herausforderung, nicht, dass man dem Kunden das nicht zutrauen würde.

Im Prinzip hat ja jeder die Möglichkeit, das FEMS durch OpenEMS zu ersetzen. Dass hierbei aber auch Fenecon raus ist, ist nur logisch und nachvollziehbar.

Wenn du aber eh Tibber nutzen willst, kannst du das jetzt ja auch machen. Dazu die Wallbox auf schnell stellen und Tibber über die Fahrzeugintegration das Fahrzeug steuern lassen.

Wie schon erwähnt, sehe ich es nicht, dass Dinge wie GridRewards sich in ein lokales System einbinden lassen. Außer es gäbe hier politische Zwänge die das ermöglichen.

Tibber will ja über alles die Hand haben. Stichwort Vendor Lock-in. Was unterscheidet sonst Tibber am Ende von einem anderem x-beliebigen Börsenstromanbieter?

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@energy — Mon, 09 Mar 2026 10:44:20 +0000

Hallo @m.hauser,

erst einmal vielen Dank für für die ausführliche Antwort!

Der WARP Energy Manager wird in meinem Setup nicht mehr benötigt, da die WARP3 dies inzwischen übernehmen kann (habe ja auch nur 1 WB). Erwähne es in der Annahme, dass ich damit richtig liege (Du hattest es ja auch nur als Beschreibung deines Setups erwähnt, daher nur kurz als Hinweis)

Oh das ha_openems hatte ich noch nicht einmal gefunden, dass hatte ich mir selbst eben geschrieben, war ja kein Hexenwerk, da ich daraus eher lesend zugegriffen hatte um alles drumherum richtig zu regeln. (Batterie laut FEMS frei zur Entladung → sperre das WB-Laden falls PV Leistung nicht ausreichend oder regle runter usw.)

Ja das evcc hatte bei mir leider etwas mehr Probleme gemacht, weil es die WARP3 in einen Zustand versetzt hatte wo das Auto nicht wollte, dabei musste ich die ganze WB vom Netz nehmen um den Zustand wieder zurück zusetzen. Denn die Autos haben ja ebenfalls noch ihre Eigenheiten.

Leider bietet die FEMS nicht alle Freiheiten die das OpenEMS direkt schon bereitstellen würde (so meine Einschätzung), ich verstehe, dass man aus Sicht des Produktherstellers seine Kunden nicht überfordern möchte und sich sicher sein will, dass alles funktioniert. Aber eine Möglichkeit ggf. auf Experten Modus schalten zu können wäre ggf. dort hilfreich.

”mehrere, steuernde Instanzen” du sagst es, dass ist ja leider immer das grundsätzliche Problem dabei, daher ist es in meinen Augen immer wichtig zumindest “offen” für Integrationen zu sein und dabei wäre es extrem wichtig, dass ich Verbraucher und deren Zustände ins System (FEMS) bekomme, sodass diese für eine Auswertung bzw. für die interne Steuerung berücksichtigt werden können. Denn heute ist es wieder passiert, in der Nacht hat das FEMS die Batterie so voll gemacht, dass dieser immer noch bei 70% stand als die PV dazugekommen ist, sodass um 10 Uhr die Batterie wieder voll war und ich jetzt unnötig Strom einspeise. Und da ich heute beruflich unterwegs bin hängt eben auch nicht das Auto, welches sonst den Strom abgenommen hätte, dass sind bei mir mind. 2 Tage in der Woche der Fall.

Ebenfalls bekomme ich auch meine WP nicht eingebunden, noch nicht mal den Shelly der da vor hängt, denn dann könnte das FEMS/OpenEMS zumindest erkennen was das für ein Verbraucher ist.

#GridRewards: bei Tibber und Ostrom bin ich inzwischen bei dir, aber im Winter macht es bei mir schon zumindest Sinn weil meine PV nicht genügend Strom liefert und die WP extrem hohen Verbrauch hat. Somit kann man noch etwas “mitnehmen” fürs Auto, aber da gibt es inzwischen ein guten Tarif von octopusenergy wo ich jetzt hin wechseln werde (~27Cent regulär durchgehend und fürs Autoladen dann -12Cent, heißt 15Cent dann für das Autoladen). Auto macht in den Monaten ca. 600kWh/Monat aus. → aber das alles ist ja eher individuell und betrifft vermutlich nicht immer die Masse.

Die App dynamische Stromtarife ist in meinen Augen gerade nur sinnvoll, in den Monaten wo kaum PV Leistung und hoher Verbrauch ist. Denn in den anderen Zeiten ist sie eher kontraproduktiv und eher sogar schädlich. Übrigens auch dort bin ich von Tibber etwas verwöhnt worden, weil sie mir wirklich den Bruttopreis live angezeigt hat.

Also nehme ich derzeit noch mit, dass im Prinzip keine Lösung für das Problem/die Herausforderung besteht und auch noch nix in Planung ist das Thema ggf. anzugehen, bzw. kann ich das keiner Roadmap entnehmen. Würde für mich jetzt heißen, dass ich die App Modbus/REST schreibend erwerben müsste und die anderen Apps deaktiviere und alles von extern steuern lasse (HA, oder evcc). Das wäre extrem schade, aber evtl. ist mein use case auch zu speziell für Otto Normalverbraucher, wobei WP + WB + dynamischer Anbieter ich nicht als Sonderfall einstufen würde wenn ich PV + Batterie einsetze.

Inzwischen kann ich ja die einfachen Shellys hinzufügen, weiß jemand, ob diese Einfluss nehmen würden auf die Berechnung für die APP dynamische Strompreise. Denn dann könnte ich mir einen Fascade Service schreiben der aus meinem 3EM einen Plus Plug macht und auch die WB hinter der Fascade verstecken.

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@m.hauser — Mon, 09 Mar 2026 08:20:10 +0000

Hallo,

dein Beitrag ist sehr umfangreich, ich hoffe, ich kann auf alle deine Punkte eingehen.

Mein Setup besteht aus OpenEMS mit dynamischen Stromtarif (ToU Controller), netzdienlicher Beladung der Hausbatterie und evcc zur Steuerung meiner beiden WARP2 mit WARP Energy Manager zur Phasenumschaltung.

In OpenEMS ist evcc als lesbares Loadpoint Meter integriert. Dafür habe ich zusammen mit @iseeberg79 auch eine PR erstellt. Leider ist das Feedback dazu bisher sehr zurückhaltend, daher gehe ich davon aus, dass das eher nicht gemergt wird.

Die Logik zur Steuerung der Wallboxen liegt hier bei evcc und der Rest bei OpenEMS. Evcc kann aber eine Entladung der Hausbatterie sperren.

Aber auch hier gibt es edge cases, die bei mir nicht ganz optimal funktionieren. Beispiel: Der ToU Controller entscheidet die Entladung zu sperren, in evcc ist aber eingestellt, dass die Hausbatterie bis 80% SOC mitgenutzt werden soll.

M.E. ist aber das aber ein grundlegendes Problem, wenn es mehrere, steuernde Instanzen gibt. @stefan.feilmeier hat hier auch viel dazu geschrieben.

Bei den Grid Rewards von Tibber und Co scheitert es ja schon alleine daran, dass es keine dokumentierte Schnittstelle gibt, nach der man sein eigenes System steuern kann. Wirds vermutlich auch nicht geben, da das ja ein Geschäftsmodell von Tibber ist.

Ich werde sowas aber aus Prinzip nicht machen, da mir das nicht gefällt, alles von Cloud gesteuert zu haben. Zumal der finanzielle Gewinn eher marginal ist.

Zu der Emulation der Tinkerforge als Keba: Ich habe das auch schon gesehen, aber noch nicht getestet. Meines Wissens ist es aber aktuell so, dass die Phasenumschaltung bei einer offiziellen Keba Wallbox im FEMS auch nur via Beta Optionen funktioniert. Ob jetzt die Emulation einer Keba die Modbus Register zur Phasenumschaltung zur Verfügung stellt, habe ich auch noch nicht nachgesehen.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Sat, 07 Mar 2026 09:05:21 +0000

nach meiner anfänglichen Enttäuschung über das komplizierte Vorgehen, habe ich nun eine Lösung für mich gefunden. Ich habe mich damit arrangiert das die SetActive…. Endpunkte die AC Wirkleistung beeinflussen.

Ich balanciere das einfach selber aus. Hätte gehofft das genau das, das EMS übernimmt. Aber egal.

Meine Anforderungen waren

Eine fixe Batteriebeladung (charge power) zu erzwingen
(active power = production power - charge power)
Eine Batterieentladung zu verhindern
(wenn consumption power > production power dann active power = production power)
Eine maximale Batteriebeladung (max charge power) vorzugeben
(wenn production power - consumption power > max charge power dann active power = production power - max charge power)

Diese Logik lasse ich laufen sobald sich die pv production oder consumption ändern, spätestens aber alle 30 Sekunden damit der watchdog nicht zuschlägt. Zusätzlich ist die Netzdienliche Beladung komplett deaktiviert.

Die Fixe Batterieladung berechnet sich übrigens aus. 1. dem zu erwartendem PV Ertrag (meistens auf ±20% genau). 2. Der zu erwartenden Heizlast (Wärmepumpe und Frostwächter im Gewächshaus), 3. Dem zu erwartendem restlichen Strombedarf. Dieser Gesamtbetrag wird dann in der Nacht so verteilt das zu den günstigsten Zeiten geladen wird.

Eine Batterieentladung wird verhindert wenn der aktuelle Börsenpreis kleiner ist als ein fiktiver Batteriepreis. Hier merke ich mir wie viel Strom über Solar gespeichert wird und wie viel Strom aus dem Grid zu welchem Preis geladen wird. Solange noch gespeicherter Solarstrom da ist kann entladen werden. Sobald es nur noch gespeicherter Gridstrom ist wird der Preis verglichen.

Die maximale Batteriebeladung ersetzt bei mir die Netzdienliche Beladung. Hier kalkuliere ich so das nach 70% des zu erwartenden Solarertrags der Speicher voll sein soll. d.h. falls der Forecast nicht passt bleibt noch genug Reserve um ihn trotzdem voll zu bekommen. Ausserdem wird der Peak beim Ertrag über die Mittagszeit komplett geglättet.

Damit kann ich nun alles umsetzen was ich wollte!

Noch eins zum Schluss. Falls durch meine anfänglichen kommunizierte Enttäuschung der Eindruck entstanden ist das ich mit Fenecon oder OpenEMS nicht zufrieden bin, wollte ich nur klar stellen das dem nicht so ist. Ganz im Gegenteil. Ich freue mich immer wieder, das ich mich genau dafür entschieden habe! Besonders der Open Source Gedanke macht es sehr sympathisch!

Integration von Wallbox (Warp3) / dynamischen Tarifen / Fahrzeugladung

@energy — Fri, 06 Mar 2026 22:37:15 +0000

Hallo Community,

ich nutze seit einiger Zeit ein Fenecon-System mit FEMS und bin grundsätzlich sehr zufrieden. In der Praxis bin ich jedoch auf einige Punkte gestoßen, bei denen ich aktuell keine gute Lösung finde oder bei denen mir unklar ist, ob etwas geplant ist.

Ich habe die Themen einmal kurz zusammengefasst und danach jeweils etwas ausführlicher beschrieben.

Setup:

Speicher: Fenecon Home 10 (11 kWh)
PV: 10,23 kWp
FEMS Apps:
- Netzdienliche Beladung
- Dynamische Stromtarife
Wallbox: Tinkerforge WARP3
Weitere Systeme: Home Assistant (für Automationen im Haus)

Kurze Übersicht meiner Punkte

Fehlende Roadmap für neue Features
Keine Integration der Tinkerforge WARP3 Wallbox
Einschränkungen bei der KEBA-Integration (als warp3 Emulation)
Interaktion zwischen Fahrzeugladung und FEMS-Optimierung
Konflikte mit extern gesteuertem Laden (z. B. GridRewards)

1. Fehlende Roadmap

Mir ist bisher keine öffentlich einsehbare Roadmap für kommende Funktionen aufgefallen.

In Dokumentationen oder Beiträgen findet man häufiger Hinweise wie „demnächst“, „folgt bald“ oder ähnliche Formulierungen. Diese Aussagen existieren teilweise schon länger, ohne dass klar wird, wann oder ob bestimmte Funktionen tatsächlich umgesetzt werden.

Das macht es schwierig einzuschätzen:

welche Erweiterungen geplant sind
welche Priorität einzelne Themen haben
ob bestimmte Integrationen überhaupt vorgesehen sind

Eine grobe Roadmap (auch ohne feste Termine) würde hier sehr helfen.

2. Integration der Tinkerforge WARP3 Wallbox

Ich nutze eine Tinkerforge WARP3 Wallbox.

Diese konnte ich bisher leider nicht direkt in FEMS integrieren. Das ist etwas schade, da Tinkerforge ebenfalls einen sehr offenen Ansatz verfolgt.

Technische Details:

Die WARP3 unterstützt Modbus/TCP
Sie kann sich optional als KEBA P30 C emulieren
Dabei wird die entsprechende Registertabelle bereitgestellt

Meine Erwartung war daher, dass sie sich über die vorhandene KEBA-Integration eventuell anbinden lässt.

3. Einschränkungen bei der KEBA-Integration

Wenn ich die Dokumentation richtig verstehe, unterstützt die KEBA-Integration im FEMS aktuell keine Phasenumschaltung bzw. arbeitet nur im 3-Phasen-Modus.

Das könnte in der Praxis problematisch sein, weil:

viele Fahrzeuge bei PV-Überschuss mit 1-Phase starten
dadurch niedrigere Mindestleistungen möglich sind

Leider konnte ich das nicht testen, da die entsprechende App kostenpflichtig ist.
Falls jemand Erfahrung damit hat, würde mich interessieren:

ob tatsächlich nur 3-phasig geladen wird
oder ob die Dokumentation hier ggf. missverständlich ist.

4. Interaktion zwischen Fahrzeugladung und FEMS-Optimierung

Aktuell steuere ich das Laden meines Autos hauptsächlich über Home Assistant.

Ich habe auch evcc getestet, nutze aber HA, da es ohnehin im Haus im Einsatz ist und die benötigten Automationen dort einfach umsetzbar sind.

Das führt jedoch zu einem Problem:

Die FEMS App „Dynamische Stromtarife“ kennt das Auto nicht als Verbraucher.

Dadurch entstehen Situationen, in denen:

FEMS Prognosen erstellt, ohne das Fahrzeug zu berücksichtigen
die Batterie in Sperrmodi läuft
nachts geladen wird, um morgens Leistung bereitzustellen

Das funktioniert grundsätzlich, hat aber Nebenwirkungen.

Beispiel:

Batterie wird nachts geladen, um für den morgendlichen Verbrauch bereit zu sein
wenn das Auto jedoch gar nicht angeschlossen ist, bleibt der Speicher morgens sehr voll
sobald die PV startet, wird Energie eingespeist, statt die Batterie sinnvoll weiter zu nutzen

Gerade wenn ich beruflich unterwegs bin und das Auto nicht zuhause ist, passiert das relativ häufig.

5. Externe Steuerung durch Tarifanbieter (GridRewards)

Ich habe auch einige Anbieter getestet, die vergünstigtes Laden über Programme wie GridRewards anbieten.

Dabei wird das Laden des Fahrzeugs von außen gesteuert.

Das kann jedoch dazu führen, dass:

das Fahrzeug plötzlich lädt
FEMS dies nicht erkennt
die Hausbatterie entladen wird, um das Auto zu versorgen

Aus Sicht des Energiemanagements ist das natürlich nicht optimal.

Persönlicher Wunsch

Mein Eindruck ist, dass FEMS eigentlich genau die zentrale Instanz für solche Entscheidungen sein sollte.

Aktuell entsteht jedoch teilweise das Gegenteil:

Fahrzeuglogik liegt in Home Assistant oder der Wallbox
Tarifanbieter greifen extern ein
FEMS versucht parallel zu optimieren

Die Systeme arbeiten dadurch eher nebeneinander statt miteinander.

Besonders interessant wäre aus meiner Sicht:

eine direkte Integration der WARP3 Wallbox
oder allgemein eine offenere Schnittstelle für Wallbox-Integrationen

Die WARP3 kann inzwischen ebenfalls:

PV-Überschussladen
dynamische Stromtarife
experimentell sogar externe Batteriesysteme berücksichtigen

Wenn man diese Logik komplett in die Wallbox verlagert, würde das aber bedeuten, dass das eigentliche Energiemanagement nicht mehr im FEMS stattfindet.

Das wäre aus meiner Sicht schade, da gerade die Kombination aus:

zentralem Energiemanagement
offenen Schnittstellen
und der Open-Source-Ausrichtung

ein großer Vorteil des Systems ist.

Falls jemand ähnliche Erfahrungen gemacht hat oder Hinweise zu den oben genannten Punkten geben kann, würde mich das sehr interessieren.

Vielen Dank!

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@Sn0w3y Sn0w3y — Fri, 06 Mar 2026 12:26:09 +0000

klar kannst DU das nicht - ist auch keine Standardkomponente bei FENECON.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@Sn0w3y Sn0w3y — Fri, 06 Mar 2026 12:25:16 +0000

Ich habe mir nicht alles durchgelesen, aber hilft euch das eventuell weiter:

github.com/OpenEMS/openems

Comment by Sn0w3y - GoodWe: Fix battery charging with PV when constraint is active

develop ← iseeberg79:fix/setpoint

You're correct that the current behavior is internally consistent. `setActivePow…erLessOrEquals(0)` constrains `ACTIVE_POWER <= 0`, and because `ACTIVE_POWER = PV + battery` for the GoodWe `HybridEss`, `CHARGE_BAT` with `pvProduction` naturally satisfies that constraint. So there isn’t actually a bug here. You’re also right about the architectural side - and the solution is already implemented. GoodWe already implements `HybridEss` (`GoodWeEssImpl.java:54`) and exposes `DC_DISCHARGE_POWER` as a separate read channel that represents the real battery power. The `ACTIVE_POWER` channel documentation in `SymmetricEss` already clarifies this: > “Discharge or charging Power (including DC-PV power, if applicable). For the actual charging or discharging power of the battery, please refer to address `ess0/DcDischargePower`.” So the distinction between AC-side power and actual battery power already exists in the API. Because of that, the proposed fix isn’t the right approach. Special-casing `activePowerSetPoint == 0` in `handleRemoteMode` would break the contract between the Power Solver and the ESS. The Solver calculates a setpoint that satisfies all constraints, and `ManagedSymmetricEss.applyPower` explicitly states that implementations should not modify those parameters. If the ESS silently reinterprets the setpoint, it could violate the constraints the Solver just resolved and potentially interfere with other controllers running in the same cycle. There’s also already an established pattern in OpenEMS for targeting DC power. `Controller.Ess.FixActivePower` supports a `HybridEssMode.TARGET_DC` mode that performs exactly this translation (`ControllerEssFixActivePowerImpl.java:137–150`): ```java case TARGET_DC -> switch (ess) { case HybridEss he -> { var pv = ess.getActivePower().orElse(0) - he.getDcDischargePower().orElse(0); yield pv + power; } default -> power; }; ``` This logic reads the current PV production from the `HybridEss` channels and translates the desired DC (battery) power into the correct AC power constraint. In other words, the controller performs the DC-to-AC translation - not the inverter driver. That’s the established OpenEMS design pattern. For the `evcc` use case (“battery neutral”), the same principle applies. The external controller - or a dedicated OpenEMS controller - would need to read the `HybridEss` PV production and set `setActivePowerEquals(pvProduction)` in order to achieve `dcDischargePower = 0`. Given that, the GoodWe implementation is already behaving correctly, and this PR should probably be closed. I also dug into how evcc actually talks to OpenEMS, and the real issue comes from evcc’s OpenEMS template. The problem is with the batterymode switch: # case 1 (Normal) and case 2 (Hold/Prevent Discharge) are IDENTICAL: body: '{"value": 0}' → SetActivePowerLessOrEquals = 0 For a HybridEss setup where ACTIVE_POWER equals PV plus battery, this means PV + battery ≤ 0. In practice, you end up forcing all PV into the battery. That’s exactly what your screenshot shows. The real fix needs to happen in evcc’s template, not in the GoodWe driver. Here’s what to do: When you want “Hold” mode (battery-neutral), evcc should first read the current PV production, then set ACTIVE_POWER equal to PV. This way, the battery’s contribution stays at zero watts. OpenEMS’s own Controller.Ess.FixActivePower does it the same. In evcc terms, here’s how “Hold” mode (case 2) should work via REST: Step 1: Read the current ESS values: ``` GET /rest/channel/ess0/ActivePower → maybe 4800 W GET /rest/channel/ess0/DcDischargePower → maybe -200 W (negative means charging) ``` So, PV = ActivePower - DcDischargePower = 4800 - (-200) = 5000 W Step 2: Set the AC power target to PV production (so battery stays at 0): ``` POST /rest/channel/ess0/SetActivePowerEquals body: {"value": 5000} ``` This should keep the battery neutral and lets PV handle household loads, which is what you want (and what your screenshot shows as a problem). For “Normal” mode (case 1 or watchdog reset), evcc shouldn’t write SetActivePowerLessOrEquals = 0. Instead, just release control by writing null: ``` POST /rest/channel/ess0/SetActivePowerLessOrEquals body: {"value": null} ``` The Modbus template (openems-modbus.yaml) has this same bug with battery_set_register (register 710, which also maps to SetActivePowerLessOrEquals). Bottom line: This is something that needs to be fixed on the controller side in evcc, not in the OpenEMS inverter driver. The GoodWe already does ACTIVE_POWER exactly as documented.

[FEMS] Shelly App workaound

@Sn0w3y Sn0w3y — Fri, 06 Mar 2026 12:22:53 +0000

weil es halt nicht zu 100% durchgetestet wurde. wenn ihr ein komplett offenes system wollt, dann setzt es selber auf und nutzt OpenEMS…

Bei FENECON legt man sehr viel wert auf 100% funktion. Eine Möglichkeit, dies zu ungehen zu finden halte ich für wenig konstruktiv - ich arbeite nicht dort, wollte das nur nochmal dazu sagen..

Konfiguration des Backends: "Edge.Websocket" fehlt ?

@cgn-nv — Fri, 06 Mar 2026 11:07:03 +0000

Für erste Tests des OpenEMS möchte ich in meinem lokalen Netzwerk ein rudimentäres OpenEMS-Setup auf zwei Rasperry PIs betreiben:
rpi1: edge+edge-ui

rpi2: backend+influxdb+backend-ui

beides habe ich mit Docker gemäß den offizielen “docker-compose.yml” eingerichtet.

Auf rpi1 habe ich die unter “Getting Started” beschriebene Simulation aufgesetzt.

Die Daten vom Edge laufen aber nicht in der Datenbank auf. Die Edge-Logs zeigen folgendes:
2026-03-06T10:47:13,516 [Worker-0] WARN [on.websocket.AbstractWebsocket] [ctrlBackend0] Unable to send message: Connection is closed. {“method”:“timestampedData”,“params”:{“1772794030000”:{“_appManager/AppsNotSyncedWithBackend”:0,“_appManager/DefectiveApp”:0,“_appManager/HardwareMismatch”:0,“_appManager/State”:0,"_appManager/Wron…
2026-03-06T10:47:13,518 [_cycle ] INFO [ebuglog.ControllerDebugLogImpl] [ctrlDebugLog0] _sum[State:Warning Ess SoC:47 %|L:1376 W Grid:88 W Consumption:1464 W] ctrlBackend0[State:WARNING: UnableToSend] ess0[SoC:47 %|L:1376 W|Allowed:-10000;10000 W] meter0[88 W]

Ich gehe davon aus, dass es sich um ein Konfigurationsproblem meinerseits handelt. Wie gehe ich am besten vor, um den Fehler einzugrenzen und zu beheben?

Wäre super, wenn jemand helfen könnte.

Konfiguration des Backends: "Edge.Websocket" fehlt ?

@cgn-nv — Fri, 06 Mar 2026 07:56:18 +0000

Bei der Konfiguration des Backends über Apache Felix habe ich festgestellt, dass ich dort den “Edge.Websocket” nicht finde. Es gibt dort lediglich den “Edge.Manager”. Ist das der Ersatz für den "Edge.Websocket” ?

Backend-UI: Login-Credentials

@cgn-nv — Fri, 06 Mar 2026 07:56:10 +0000

Mit welchen Login-Credentials kann ich mich in das Backend-UI einloggen?

habe den “Metadata.Dummy” aktiviert und den “Metadata.File” gelöscht. In der Login-Maske des UI funktioniert “admin” (wie beim edge-UI) nicht. Es erscheint die Fehlermeldung “Your request has timed out. Please try again later”.

Muss ich an dieser Stelle tatsächlich einen Account anlegen?

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Thu, 05 Mar 2026 06:50:56 +0000

Das wäre ja fatal. Ich habe ja die ganze System gekauft in der Annahme das es entsprechend der Dokumentation funktioniert. Mein ganzes Einsatzscenario wäre damit hinfällig da es dann nicht funktioniert.

In der Doku ist immer von Belade und Entladeleistung der Komponente ess0 die Rede. Also von der ersten Speicherkomponente. Darunter ist ein Beispiel bei dem man 5kw Entladeleistung einstellt mit einem Bild was dann anzeigt das 5kW entladen werden. Also eine ganze einfache Sache eigentlich.

wenn ich jetzt ess0/SetActivePowerLessOrEquals auf 0 setze um z.b. eine Entladung zu verhindern, statt dessen aber plötzlich die Batterie komplett mit dem PV Ertrag geladen wird und der aktuelle Verbrauch komplett aus dem Grid bedient wird, ist das ein nicht erwartbarer Mangel. Es ist ja nicht so dass das System sich ein “bisschen” anders verhält, sondern komplett unerwartete nicht dokumentierte Dinge passieren.

Mann kann jetzt argumentieren das es doch die Bedingung erfüllt (ess0/SetActivePowerLessOrEquals). Es geht ja nichts mehr raus aus der Batterie… Aber auch wenn ich zusätzlich ess0/SetActivePowerGreaterOrEquals auf 0 setze verhält es sich so nicht.

Auch das setzen ess0/SetActivePowerEquals=0 funktioniert nicht so wie erwartet. Die Doku sagt eindeutig “Vorgabe Be- bzw. Entladeleistung” der Komponente ess0. Da steht nichts davon das da noch eine zusätzlich PV Leistung mit drauf gerechnet wird.

Irgendwie macht das alles keinen Sinn. Warum kann sich der Balancer nicht weitgehend so verhalten wie vorher und nur die Einschränkung umsetzen, die Batterie nicht zu entladen bzw. zu beladen. Hört sich jetzt nicht nach ner schwierigen Gleichung für den Balancer an.

Die App Netzdienliche Beladung kann ja auch genau diese Sachen Steuern. Beladung verhindern. Max Beladung… und alles andere wird richtig ausbalanciert. Genau so ein Verhalten hätte ich laut Dokumentation erwartet.

sowas kann ich anscheinend nicht im fenecon home einstellen.

Da ist

[FEMS] Shelly App workaound

@phamel — Wed, 04 Mar 2026 23:22:11 +0000

ich habe das mal in FEMS getestet, allerdings bekomme ich in der Übersicht kein neues Feld und im Log stehen:
io3[?|UNDEFINED]
und
[io3] JSON [switch:0] ist not a member of JSON-Object [{“ble”:{},“bthome”:{},“cloud”:{“connected”:false},“mqtt”:{“connected”:false},“pm1:0”:{“id”:0,"vol…]

Wenn ich die JSON daten von PM und Plug vergleiche sieht man, dass die Daten beim Plug im feld “switch:0” sind und beim PM im feld “pm1:0” daher wird nichts ausgelesen

im code von OpenEMS selbst sieht es aber so aus als währe Shelly PM Mini Gen3 sowie noch einige weitere wie Shelly Pro 3EM auch umgesetzt, frage ist, warum diese nicht in FEMS auswählbar sind

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@tsicking Thomas Sicking — Wed, 04 Mar 2026 16:19:36 +0000

Hallo zusammen,

In dem zitierten Post wurde es eigentlich schon erklärt: Man steuert mit setActivePowerLessOrEquals etc. immer die AC-Wirkleistung und nicht die Batterieleistung, und dann passt doch alles. Du gibst -1000W vor, sprich 1000W Beladung AC-seitig, heißt dann, dass PV-Ertrag + 1000W in die Batterie gehen.
Was du tun kannst, wenn du zum Beispiel die Batterie mit mindestens 1000W laden willst, ist folgendes:

Aktiviere den Controller Fix Active Power und stelle ihn ganz vorne in den Scheduler
Stelle ihn auf “Target DC”, Relationship “Less Or Equals”, Power auf -1000.

Wenn du sie mit genau 1000W laden willst entsprechend Relationship auf “Equals” stellen, und wenn du sie mit maximal 1000W laden willst auf “Greater Or Equals”.

Hilft das weiter?

Viele Grüße,
Thomas

[FEMS] Shelly App workaound

@Howaner Franz Reiter — Wed, 04 Mar 2026 14:33:20 +0000

Du könntest versuchen eine Shelly Plug Komponente in OpenEMS zu erstellen, die IP Adresse vom Shelly PM Mini Gen3 anzugeben und den Device Type Check auszuschalten. Die Shelly API im Hintergrund sollte die gleiche sein.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Wed, 04 Mar 2026 13:16:11 +0000

50kw ist der maximale Tagesbedarf fürs Haus und Wärmepumpe.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@bkumio Mario — Wed, 04 Mar 2026 13:07:15 +0000

cool. Halt mich auf dem aktuellen Stand.

bei 50kwh…. Willst du dein Auto günstig laden oder reicht das evtl. um eine Wärmepumpe effizient zu betreiben. Solch eine Speichererweiterung hatte ich auch schon mal im Hinterkopf wenn wir von Gas auf Wärmepumpe umsteigen oder das E-Auto günstig laden wollen. Da komme ich mit meinen 12kwh Speicher nicht weit….

Je mehr Verbrauch desto mehr lässt sich sparen. Im Momment lieg ich bei 72% Autarkie übers jahr und muss “nur” noch 2000kwh beziehen. Da lohnt sich das Investment (noch) nicht.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Wed, 04 Mar 2026 12:43:27 +0000

Werde ich.

Hab bisher auch gute Erfahrungen mit dem Support gemacht. Mir würde es ja auch reichen wenn sie sagen, sie arbeiten dran… Nur die Aussage das sie es nicht wollen, lasse ich nicht gelten, da es ja dem Produktversprechen widerspricht und bei mir maßgeblich für den Kauf der ganzen Anlage war… im besonderem für den riesigen Akku.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@bkumio Mario — Wed, 04 Mar 2026 12:33:29 +0000

Du musst dran bleiben. Es hat mindestens 3 entschieden geschriebene Antworten von mir gebraucht bis sich da was gerührt hat. Du darfst gerne auch auf mein Ticket verweisen : #200299

Wir könnten ja offerieren das wir die Anleitung für sie überarbeiten, wenn sie uns versprechen das uns mal der Entwickler anruft. Ich kann gerne ein GoogleMeet aufsetzen

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Wed, 04 Mar 2026 12:02:17 +0000

nicht nur 350€ für die app.

20.000€ für 50kW Speicher…

Das Produktversprechen auf der Homepage lautet

FEMS App Schreibzugriff Heimspeicher
Lokale Kontrolle
Über Modbus/TCP binden Sie Ihren FENECON-Speicher direkt in Ihre Haussteuerung ein. So steuern Sie Lade- und Entladevorgänge präzise vor Ort – zuverlässig und unabhängig vom Internet.
Mit REST/JSON integrieren Sie Ihren Speicher in webbasierte oder cloudgestützte Anwendungen. So erweitern Sie Ihr Energiemanagement um intelligente Automatisierungen und vernetzte Funktionen.

Das war mein Entscheidungsgrund für das Produkt. Naja… hab jetzt auch ein Supportticket aufgemacht. Mal sehen was sie sagen…

p.s. Lokale Kontrolle Modbus… Hab ich auch schon probiert. Ist das gleicher Ergebnis wie bei REST

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@bkumio Mario — Wed, 04 Mar 2026 11:49:34 +0000

Sehe ich ähnlich. Wenn man schon 350EUR für so eine App, die laut Feature Beschreibung genau das kann anbietet, verkauft sollte man das auch unterstützen.

Die Person die mich angerufen hat war aber kein Entwickler sondern ein Helpdesk mitarbeiter der dann am Ende des Tages auch nur in seine Datenbank geschaut hat. Vielleicht (hoffentlich gibts da noch mehr)

was wir brauchen sind mal Fakten zum Verhalten unter bestimmten Bedingungen.

Vielleicht gibt es in der Community jemand, der jemand kennt der das Fachlich beantworten kann?

Mann hat mir gesagt das ein eingreifen/überschreiben bei den Commercial systemen auch völlig normal ist. Wenn unsere Wüsche zum schreiben nicht funktionieren würden wäre da bstimmt schon jemand auf den Barikaden.

Endkunden stehen da scheinbar leider hinten an…. . Ich hatte mich auch schon gefreut den Verbrauch mal genauer auf meine Anforderungen zu setzen…..

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Wed, 04 Mar 2026 11:03:28 +0000

Außerdem wird einem suggeriert das man die Wahl hat. Und da es auf der Homepage beworben wird ist es ein Produktfeature. Sich danach raus zureden dass es nicht gewollt ist, gilt nicht.

Die App dynamischer Stromtarif kann in meinem Scenario niemals so gut sein wie ich.

Ich habe die Daten um auf die kWh genau zu berechnen was ich morgen brauche. Genau diese Menge würde ich gerne in der Nacht zum günstigen Strom laden. Das schafft keine KI da es nicht wiederkehrend ist.

Irgendwie bricht gerade mein komplett geplantes Scenario zusammen. Unter den Gesichtspunkten hätte ich mir den 50kW Akku sparen können.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@bkumio Mario — Wed, 04 Mar 2026 10:37:24 +0000

Hallo Holger,

du bist schon 2 Schritte weiter wie ich. Vor ein paar Tagen hab ich auch schon mal in dem Post : https://community.openems.io/t/bedeutung-datenpunkte-rest-schreibzugriff-fenecon/10170 meine Fragen gestellt.

Parallel hatte ich ein Ticket bei Fenecon eröffnet. Zuerst die Standardantwort: Zur Parametrierung geben wir keine Auskunft. Nachdem ich dann insistiert hab hatte mich tatsächlich mal jemand zurückgerufen.

Dies wurde mir gesagt:

Eigentlich will man gar nicht das wir eingreifen. Aber warum dann eine WriteAPI angeboten wird ist mir schleierhaft. Es wurde zugegeben, dass die Dynamische Stromtarif App nicht “aggressiv” genug ist und noch Fehler macht. Aber in Zukunft sollten auch “Events” vorgesehen werden so dass ich sagen kann :”um 14:00 möchte ich mein Auto mit 15kwh beladen” oder kaufe mir 8kwh Strom um 09:00h” . Aber wann das passiert … keine Ahnung.

Das Beladen wird mit negativen Werten erreicht. Minus -2000 = Beladen aus dem Netz mit 2kwh . Das Verhalten vom System, falls doch noch Solar Erträge kommen ist die Beladung definitv additiv! Sprich wenn zur gleichen Zeit 1500Watt Solar produziert, werden lädt der Speicher mit 3500Watt total. Deckt sich ein bisschen mit deiner Erfahrung

Netzdienliche Beladung und die Dynamische Stromtarif app und andere sind System apps und haben immer höhere Priorität. Sprich falls wir mit -2000Watt Strom «kaufen», 1500Watt Solar produziert wird und die Netzdienliche Ladung mit 1000Watt einspeisen will, wird wohl unser Speicher mit 2500 Watt beladen werden. —> Wobei ich das auch erst glaube, wenn ich es sehe…

Es sieht aber zumindest so aus das die Priorität des Balancing umzuschreiben nicht wirklich vorgesehen/gewünscht ist.

Alles in allem unbefriedigend. Ich möchte aber auch den App kaufen und dann müssen wir das Verhalten re-engineeren. Mann müsse mal den Entwickler der des Moduls an die Strippe bekommen. Der könnte in 5Min Licht ins Dunkel bringen. Die Docu von Fenecon ist in der Hinsicht überhaupt nicht zu gebrauchen.

Alles in allem wie du schreibst : unbefriedigend….

New IntelliJ Setup Using Gradle

@alex.belke Alex — Wed, 04 Mar 2026 07:55:05 +0000

Hi everyone,

the IntelliJ + Gradle setup guide is finally released.

It explains how to set up the development environment step by step and should make onboarding and daily development easier.

Feedback and improvements are very welcome!

Best regards,
Alex

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Wed, 04 Mar 2026 07:45:50 +0000

Mittlerweile konnte ich etwas mehr Licht ins dunkel bringen.

Wenn ich ess0/SetActivePowerLessOrEquals auf -1000 setze, sollte die Batterie mit exakt 1kw beladen werden. Was aber passiert ist:

Batterie wird mit mindestens 1kW aus dem Grid geladen plus den kompletten PV Ertrag
Der aktuelle Verbrauch wird komplett aus dem Grid bedient

Erwartet hätte ich das die Batterie mit 1kW geladen wird. Je nach Verfügbarkeit aus PV oder Grid. Überschüssiger PV Ertrag wird entweder direkt verbraucht oder eingespeist.

Wenn ich ess0/SetActivePowerLessOrEquals auf 0 setze, sollte nur die Entladung verhindern werden. Was aber passiert ist:

Batterie wird mit dem kompletten PV Ertrag geladen
und der aktuelle Verbrauch wird komplett aus dem Grid bedient

Erwartet hätte ich das der aktuelle Verbrauch wahlweise aus PV oder Grid bedient wird. Überschüssiger PV Ertrag in die Batterie geht. Und fehlender Strom aus dem Grid gezogen wird, falls PV nicht ausreicht. (Batterie eben nicht entladen wird)

bei ess0/SetActivePowerGreaterOrEquals konnte ich noch keinen Effekt feststellen.

Auf jeden Fall scheint die Doku irreführend zu sein und mein komplettes Ladekonzept wird damit über den Haufen geworfen.

Eventuell verstehe ich auch nur etwas falsch.

Der Grund warum ich die Write API gekauft habe war, damit ich meine Batterie be- und Entladung steuern kann.

Ich würde gerne sagen können mit wie viel kW die Batterie beladen werden soll
Ich würde gerne eine Entladung der Batterie zu bestimmten Zeiten verhindern.
Ich würde gerne steuern können mit wie viel kW maximal die Batterie beladen werden soll.

Punkt 1 und 2 dachte ich mit “ess0/SetActivePowerLessOrEquals” steuern zu können und Punkt 3 über “ess0/SetActivePowerGreaterOrEquals”

Hierbei sollte meine Einstellung über die REST API absolute Priorität haben. Alles andere sollte danach ausbalanciert werden.

Kann mir irgendjemand einen Tip geben ob das irgendwie geht? Irgendwo habe ich gelesen das man dazu die Reihenfolge der Balancer ändern muss. Kann das jemand bestätigen?

—-

Auch diesen Thread habe ich gelesen ohne wirklich zu wissen was jetzt die Lösung wäre

Option 1: CtrlEssBalancing komplett deaktivieren (enabled=false) wenn Sie via REST steuern
kann nicht die Lösung sein. Ich will ja nicht das komplette Balancing aushebeln.

Option 2: Scheduler-Reihenfolge ändern - CtrlEssBalancing VOR ctrlApiRest0 setzen, damit die REST-Constraint Vorrang hat
scheint auch dort zu einem merkwürdigen Balancing zu führen

Option 3: Statt SetActivePowerLessOrEquals=0 den Balancing Controller via REST steuern:
kann nicht die Lösung sein. Ich will ja nicht das komplette Balancing aushebeln.

—-

Gibt es aktuell keine Möglichkeit die Min/Max/Exakte Beladung/Entladung der Batterie zu steuern ohne das Balancing “davor” durcheinander zu bringen?

Ich habe mir die 50kW Batterie extra gekauft um damit genau das zu machen.

ess0/SetActivePowerGreaterOrEquals scheint keinen effekt zu haben

@HolgerHees Holger Hees — Tue, 03 Mar 2026 16:40:38 +0000

Hallo,

Vorweg. Bei mir läuft ein Home 10 mit 19KW peak und 50kwh akku.

ich habe ziemlich viel in diesem Forum zu besagtem Thema gelesen, trotzdem funktioniert es nicht.

Ich möchte die maximal zulässige Beladung der Batterie steuern.

Hierzu setze ich z.B. ess0/SetActivePowerGreaterOrEquals auf “-500”. Jetzt würde ich erwarten das die Batterie mit maximal 0.5kW geladen wird und der Rest ausbalanciert wird. d.h. ist weniger PV vorhanden, wird mit weniger geladen. Ist mehr PV vorhanden, wird mit maximal 0,5kW geladen und der Rest geht ins Netz/Grid

Das Verhalten von “ess0/SetActivePowerLessOrEquals” habe ich so verstanden. “0” verhindert eine Entladung der Batterie und “-500” erzwingt eine Beladung mit 0,5kw.

Kurzum, bei mir tut sich aber nichts.

Fangen wir mit dem ersten an… Ich setze ess0/SetActivePowerGreaterOrEquals auf “-500”.

Im log sehe ich

```
[ctrlApiRest1] Set Channel [ess0/SetActivePowerGreaterOrEquals] to Value [-500]
```

aber meine aktuelle Beladung sieht so aus

Unter Anlagenprofil unter Speichersystem Steuerung taucht es auch nicht auf

Aufgeführt ist es aber unter Externe Schnittstellen

How to Reset a Modbus Value

@Sn0w3y Sn0w3y — Mon, 02 Mar 2026 09:59:42 +0000

Happy to create a PR if wanted !

github.com/OpenEMS/openems

[EDGE] Handle UNDEFINED_VALUE as null in ModbusRecordChannel (#3601)

develop ← Sn0w3y:null-modbus-fix

opened 10:17AM - 02 Mar 26 UTC

Sn0w3y

+21 -6

This commit updates the ModbusRecordChannel to interpret UNDEFINED_VALUE as null… for numeric types (FLOAT64, FLOAT32, UINT16, UINT32, UINT64). This change ensures that when a Modbus record contains a value that is designated as undefined or not applicable, it is correctly handled as a null value in the system, rather than being processed as a valid numeric value. This is crucial for avoiding incorrect data interpretation and ensuring data integrity in applications that rely on Modbus communication.

How to Reset a Modbus Value

@stefan.feilmeier Stefan Feilmeier — Mon, 02 Mar 2026 09:30:01 +0000

The problem here is, that Modbus is not able to handle null values. What’s missing here is a specific handling in the Modbus-Write-API that interpretes UNDEFINED_VALUE as null. This way Modbus would behave like JSON/REST.

Example UNDEFINED_VALUE for UINT16: openems/io.openems.edge.common/src/io/openems/edge/common/modbusslave/ModbusRecordUint16.java at develop · OpenEMS/openems · GitHub
Possible location: openems/io.openems.edge.common/src/io/openems/edge/common/modbusslave/ModbusRecordChannel.java at develop · OpenEMS/openems · GitHub

Lambda Wärmepumpe Support

@enzensbs Enzensbs — Sun, 01 Mar 2026 22:43:01 +0000

Hallo Munkustrap, würde mich auch für Deine Einbindung der Lamda interessieren. Wie ist es Dir weiter ergangen? Gibt es Neuigkeiten? Kann ich den aktuellen Stand der Software bekommen?
Viele Grüße
Stefan

Release 2026.3.0 · OpenEMS/openems

@stefan.feilmeier Stefan Feilmeier — Sun, 01 Mar 2026 13:47:42 +0000

How to Reset a Modbus Value

@Sn0w3y Sn0w3y — Sat, 28 Feb 2026 04:00:19 +0000

ah sorry, i missed this - okay

How to Reset a Modbus Value

@HolgerHees Holger Hees — Fri, 27 Feb 2026 15:26:51 +0000

thanks for the explanation!

currently I’m using the modbus write app. But modbus does not allow null values

so I will change my app “modbus write” to “rest write” and with rest, it should be possible. I already wrote the support, and I hope they can convert the app license key.

How to Reset a Modbus Value

@Sn0w3y Sn0w3y — Fri, 27 Feb 2026 10:49:13 +0000

Hey,

i looked into the code to give you a proper answer on this.

The write values from the API are managed by the ApiWorker class. Important thing to understand: all your API write values are stored in a shared queue (ApiWorker.values map), and the watchdog timer resets on every new write - not per channel, but for the entire queue.

So heres the problem: when you write SetActivePowerGreaterOrEquals every 30 seconds, you also reset the watchdog timer for SetActivePowerLessOrEquals. It will never timeout as long as you keep writing anything through the API. The default timeout is 10 seconds btw, not 60.

To remove a single constraint while keeping the other, you can set the value to null via the API. The ApiWorker has this logic:

github.com/OpenEMS/openems

io.openems.edge.controller.api.common/src/io/openems/edge/controller/api/common/ApiWorker.java

ea2f2b778


      
          	 * Adds a value to the write-pipeline. The values are then set in the next
          	 * execution of {@link #run()}, until the timeout is reached.
          	 *
          	 * @param channel     the {@link WriteChannel}
          	 * @param writeObject the {@link WriteObject}
          	 */
          	public void addValue(WriteChannel channel, WriteObject writeObject) {
          		this.resetTimeout();
          		synchronized (this.values) {
          			if (writeObject.isNull()) {
          				// set null -> remove write-value
          				OpenemsComponent.logInfo(this.parent, this.log,
          						"Set [" + channel.address() + "] to [" + writeObject.valueToString() + "] via API");
          				this.values.remove(channel);
          			} else {
          				// set write-value
          				OpenemsComponent.logInfo(this.parent, this.log, "Set [" + channel.address() + "] to ["
          						+ writeObject.valueToString() + "] via API. Timeout is [" + this.timeoutSeconds + "s]");
          				this.values.put(channel, writeObject);
          			}
          		}

So your flow should be:

Keep writing SetActivePowerGreaterOrEquals = 1000 every 30s as usual
When you want to reset SetActivePowerLessOrEquals, send a write request with value null for that channel

This will remove only that one constraint from the queue while your GreaterOrEquals constraint stays active.

Hope that clears things up

How to Reset a Modbus Value

@HolgerHees Holger Hees — Fri, 27 Feb 2026 10:34:06 +0000

Hello,

I’m using a fenecon home 10 with a 50kw battery.

I’m setting SetActivePowerGreaterOrEquals to 1000 and SetActivePowerLessOrEquals to 0 every 30 seconds to avoid the watchdock timer.

Now I try to reset/fallback SetActivePowerLessOrEquals to their default. Normaly I would expect that If I don’t write this value for > 60 seconds. The watchdog timer will reset this value. But this is not the case.

My question is, how can I reset/fallback one value but still keep a different value at the same time.

Windows Message: Filename too long

@JackyFlint Jacky Flint — Fri, 27 Feb 2026 10:31:45 +0000

LongPathTool worked well for shortening deep paths before trying file operations

[Gelöst] FEMS - Schreiben eines Wertes rückgängig machen

@HolgerHees Holger Hees — Thu, 26 Feb 2026 14:21:45 +0000

Weiss jemand wie man das bei Modbus macht.

mit dem Watchdog fallback scheint nur zu gehen wenn man keinerlei Werte per modbus setzt. Wenn ich aber nur einen Wert zurücksetzen will, reicht es nicht diesen Wert einfach nicht mehr zu schreiben. Er bleibt so lange erhalten bis ich aufhöre auch die anderen zu schreiben.

keine aktuellen Messwerte

@cgn-nv — Wed, 25 Feb 2026 20:52:38 +0000

Update zur Problematik:

Ich habe mir den Java-Code des Treibers angeschaut und die abgerufenen Registeradressen mit den Herstellerangaben abgeglichen.

Man sieht, dass die 3P-Wirkleistung über das FC3(Holding)-Register mit der Adresse “19026” abgerufen wird. Dies ist laut Herstellerangaben ein Durchschnittswert, sofern es als FC3 abgerufen wird. Wenn man es allerdings als FC4 abruft handelt es sich beim selben Register um einen 200ms-IST-Wert.

Ich denke das ist die Ursache für das untypische Verhalten der Wirkleistung im Dashboard. Mir stellt sich nun die Frage, wie ich das möglichst effizient anpassen kann. Kann ich so eine Änderung bei OpenEMS Edge Apache vornehmen oder muss dafür der Code angepasst werden?
Falls Code angepasst werden muss:
Ersetze ich einfach in Zeile 122 “FC3ReadRegistersTask” durch “FC4ReadInputRegistersTask” und kompiliere das ganze, oder gäbe es da mehr zu beachten?