FEMS App Dynamischer Stromtarif

OpenEMS distributions FEMS
21

Hallo Forum!
Die App dynamischer Stromtarif läuft nun bei uns auch endlich und vervollständigt unsere Fenecon-Anlage. Soweit ich das beurteilen kann funktioniert die App auch wunderbar.
Unser Stromtarif (SpotMyEnergy) wird derzeit noch nicht unterstützt. Ich nutze daher die ENTSO-E App.
SpotMyEnergy schlägt, wie wahrscheinlich viele andere Anbieter auch, einfach einen bestimmten (ortsabhängigen) Nettobetrag auf den Börsenpreis auf. In meinem Fall 17 Ct/kWh. Dazu kommt dann noch 19% MwSt.

Meine Frage bzw. mein Wunsch: Könnte man nicht in der ENTSO-E App eine Option einfügen, bei der man einem “statischen” Nettobetrag und den Mehrwertsteuersatzes eingeben kann um dadurch den Bruttopreis zu ermitteln?

Es könnten viele weitere Anbieter über diesen “Umweg” durch den Endnutzer selber integriert werden. Es versteht sich von selbst, dass der Endnutzer in diesem Fall für die Richtigkeit der Preise selber verantwortlich ist.
Ich habe das derzeit über einen zeitvariables Netzentgelt von 17 Ct/kWh “simuliert”, erhalte dadurch aber natürlich nur fiktive Nettopreise.

22

Hallo @Bedoubleyou,

es freut mich zu hören, dass die App “wunderbar” funktioniert :+1:

Am liebsten optimieren wir immer auf den tatsächlichen Brutto-Preis, deshalb sind mir native APIs, wie die von Tibber am liebsten. Die Realität ist aber, dass die meisten Anbieter das (noch) nicht haben. Gleichzeitig soll es so einfach wie möglich sein, die Preise zu konfigurieren - nicht jeder User möchte den Aufwand betreiben eine “Berechnungsformel” einzugeben und viele können damit leben, wenn die Preise nur ungefähr stimmen.

Die Berechnung des Bruttopreises ist aber so komplex (in Deutschland - noch viel mehr in anderen Ländern). Ich überlege deshalb, ob wir für “Power-User” einfach ein Textfeld anbieten sollten, in dem dann die Formel eingetragen werden kann (z. B. (x + 3) * 1.19). x wäre in diesem Fall der 15-Minuten-Börsenpreis der EPEX SPOT.

Ich würde dazu eine Bibliothek für mathematische Ausdrücke nutzen → GitHub - fathzer/javaluator: A java infix evaluator based on "Shunting Yard" algorithm.

Was hältst du davon?

23

Hallo @stefan.feilmeier ,
vielen Dank für die schnelle Antwort!
Ich halte natürlich sehr viel von dieser Idee! :grinning_face:
Viele technikaffine “Power-User”, von denen es unter den Fenecon-Nutzern naturgemäß wahrscheinlich einige gibt, erkennen sicher schnell den Nutzen dieser Funktion.

Gruß
Benjamin

24

Hallo @stefan.feilmeier ,

Ich fahre mit meiner Solaranalage ca 7 Monate im Jahr autark. In den verliebenen Monaten werden ca 90% des vom Netz bezogenen Stroms von Wallbox und Wärmepumpe bezogen.

Wenn ich es recht verstehe, optimiert die App Dynamischer Stromtarif aktuell durch gezieltes Laden des Speichers zu Zeiten geringer Stromkosten. Noch interessanter ist aus meiner Sicht aber die aktive Verlagerung des Verbrauchs in diese Zeiten.

Hier ein paar Anforderungsbeschreibungen :smiley: ,als Anreiz für eure Produktmanager:

  • Wallbox: Gegeben die zu ladende Energie und maximale Ladegeschwindigkeit (somit die Ladedauer):
    • Lade das Auto in einem vom Nutzer festgelegten Zeitraum (zB kommende 12 Stunde), zu minimalen Kosten
    • Lade, sobald der Strompreis unter einen bestimmten Schwellwert fällt (Nutzereigabe oder Durchschnittswert der kommenden 24h)
  • Wärmepumpe: Gegeben die Durchschnittstemperatur der kommenden 12 Stunden (Wetterapp), definiere einen optimierten “Wärmepumplen-Fahrplan” (Sperre, Normal, Empfehlung) so dass die Wärmepumpe zu n der kommenden 12 Stunden arbeiten kann (wobei n durch eine Funktion in Abhängigkeit der Aussentemperatur sein sollte. Höchstwahrscheinlich muss diese vom Nutzer beeinflussbar sein).
    12 Stunden als Zeitraum für die Optimierung ist mein aktuelles Bauchgefühl, basierend auf Erfahrungen meines Eigenheims. Idee: Maximal 6 Stunden ohne Heizen verträgt meine Fussbodenheizung auch an kalten Tagen, ohne dass man etwas mitbekommt. Für reine FBH Häuser, wie meins ist das Heizungssystem hier ausreichend träge. Bei Häusern mit Heizkörpern ist der Zeitraum mit Sicherheit deutlich zu lang. Dann gibt es aber auch wieder Häuser mit Pufferspeicher für die Heizung, die den möglichen Zeitraum wiederum verlängern.

Beides sind reine Winterfunktionen, die potentiell in Konflikt mit der Optimierung basierend auf der Solarproduktion stehen (weil es unterschiedliche Optimierungsziele sind) und somit ggf durch Nutzer oder kalenderbasiert deaktiviert werden könnten.

Für Wallboxen also ein überschaubar komplexes Optimierungsziel. Für Wärmepumpen sieht das Bild deutlich komplexer aus.

Daher die offensichtliche Frage: Plant ihr zeitnah in einer oder gar beiden Richtungen der optimierten Verbrauchersteuerung funktionen zu realisieren, oder fokussiert ihr euch mittelfristig ausschließlich auf die erweiterte Nutzung des Speichers als Puffer um die zeitlich nicht-optimierten Lasten auszugleichen?

25

I have observed several times that the FEMS Dynamic Electricity Tariff app does not seem to execute the charging power calculated in its own schedule, resulting in the actual SoC falling behind the scheduled SoC.

I documented one occurrence today (28 Sep 2026) in some detail.

System

  • FENECON battery: 22.4 kWh

  • Maximum grid power for battery charging configured in the app: 12 kW (previously 15 kW)

  • Much higher charging power is technically possible: when charging is forced manually via the emergency reserve setting, I observe up to approx. 10 kW battery charging power.

  • FEMS version: 2026.9.3

Schedule
The FEMS schedule predicted approximately:

  • 13:00: 24% SoC

  • 13:15: 27% SoC

  • 13:30: 34% SoC

For the 13:15–13:30 CHARGE_GRID interval, the schedule specified approximately 6.7 kW charging power.

Actual behaviour
At 13:00 the actual SoC was 23%, i.e. almost exactly on schedule.

At 13:16, during the scheduled CHARGE_GRID interval:

  • SoC: 26% (already below schedule)

  • PV production: 2.9 kW

  • House consumption: 0.8 kW

  • Grid import: 2.1 kW

  • Actual battery charging power: 4.2 kW

  • Scheduled battery charging power: ~6.7 kW

The energy balance is consistent:

2.9 kW PV + 2.1 kW grid − 0.8 kW consumption = 4.2 kW battery charging.

Therefore, this does not appear to be a display issue. FEMS actually requested only about 2.1 kW from the grid, resulting in ~4.2 kW total battery charging instead of the scheduled ~6.7 kW.

At 13:30:

  • scheduled SoC: 34%

  • actual SoC: 31%

  • FEMS nevertheless ended CHARGE_GRID as scheduled.

The resulting ~3 percentage-point SoC deficit corresponds to approximately 0.67 kWh for a 22.4 kWh battery.

Interestingly, the discrepancy can almost completely be explained by the lower charging power during the 15-minute interval:

(6.7 − 4.2) kW × 0.25 h = 0.625 kWh

There was also more PV production than FEMS had forecast, not less. This should have made reaching the scheduled SoC easier and should, if anything, have reduced the required grid import while maintaining the scheduled battery charging/SoC trajectory.

I have seen substantially larger discrepancies on other days (several kWh, in one case >10 kWh), but did not have screenshots of the schedule at the time.

My question:
Is it expected behaviour that the actual CHARGE_GRID power can be substantially lower than the charging power calculated in the schedule, even when the actual SoC is already below the scheduled SoC?

If so, what determines the actual charging-power request, and why does the controller not increase charging power or extend the charging interval to catch up with the scheduled SoC?

I have screenshots of the schedule/cockpit and the corresponding 15-minute FEMS export if these would be useful.