Ich weiß nicht, ob es ein openEMS oder reines Fenecon Thema ist, aber ich versuchs mal:
Ich hab ein Fenecon Home 10, eine Wallbox Keba P30 c-series und die App für die Wallbox. Dazu leider nur eine PV mit 8,4kwp ost/west, so dass ich fast nie über 4,2 beladung komme und so nicht rein aus PV laden kann und die minumale Beladung auf 4,2 einstellen muss und den rest aus dem netzt beziehe. Das wäre auch für mich ok, aber leider wird nicht aus dem netz gezogen, solange der speicher voll ist. So wird nachts zb der ganze speicher leer gesaugt durf die wallbox. Laden des Autos über den Speicher ist aber total ineffizent. Gibt es irgendeine möglichkeit, die wallbox nur aus dem netz und durch PV zu beladen und NIE aus dem Speicher? Finde keine passende einstellung.
Nein gibt es nicht, ich kann mich daran erinnern so eine Diskussion bereits irgendwo mal gelesen zu haben im openEMS.
Du kannst auch mal einen PR machen und den Code vorschlagen, der das umsetzt, dann würden wir auch sehen, wie wir das in Code umsetzen könnten
Grüße !
Leider ist mir das programmieren am openEMS zu komplex und dass, obwohl ich senior software entwickler bin hatte mir das mal kurz wegen einem widget angeguckt.
Vom Gedanken her versuch ich morgen mal einen Trick, den man natürlich auch programatisch umsetzen könnte. Der Speicher gibt ja nur Strom ab, weil angeschlossene Verbraucher Strom benötigten. Jetzt könnte ja ein Ofen und das Auto angeschlossen sein. Beides würde ja momentan aus dem speicher gezogen werden, egal ob das Sinn macht (Ofen) oder nicht (Auto) wegen Verlusten. Kann das System ja wahrscheinlich nicht unterscheiden.
Wenn ich jetzt in die UI gehen, bevor ich das Auto lade, und die Notstromreserve auf 100% stelle, dann dürfte er ja nix aus dem Speicher ziehen und würde alles aus dem Netz holen, oder? Würd ich morgen auf jeden Fall mal testen.
Per Code könnte man ja zumindest einen Schslter einbauen „wenn Auto geladen wird, dann speicher entladung blockieren“. Der könnte dann ähnlich der Notstromreserve solange nix aus dem Speicher raus lassen, nur rein zu beladen, falls was von der PV über bleibt.
Sowas ähnliches wäre ja eh nötig, wenn man an die dynamischen Stromtarife denkt. Wenn Netzstrom gerade günstig ist, dann will man ja auch nicht aus dem Speicher laden, sondern aus dem Netz. Ist ja genau das gleiche, nur jetzt erstmal manuell einstellbar
Prinzipiell sollte meines erachtens strom für ein auto nie aus dem speicher kommen.
Moin,
Ja, die Diskussion gab es. Hab es auf die Schnelle aber auch nicht gefunden.
Stefan hatte mir einen simulierten Speicher empfohlen - fand ich aber nicht sehr praktikabel.
In meinem Repo ist eine Version, die keinen Speicher für den Betrieb der Wallbox braucht. Das ist zumindest mal ein Ansatz.
Grund: Ich privat hatte zu dieser Zeit keinen Speicher. Auf der Firma haben wir ebenfalls keinen, aber wollen die dynamischen Möglichkeiten nutzen.
Hatte auch mal einen PR dazu gemacht. Liegt seit etlichen Monaten auf Eis…
Gruß,
klinki
Interessant. Ich hatte genau das mal bei Fenecon (oder sogar hier im Forum?) angefragt. Rückmeldung von Fenecon direkt: meine „alte“ Fenecon-Hardware (damals noch mit Kaco-Wechselrichter) gibt das regelungstechnisch nicht her. Sowas könnte nur die neue, Fenecon-eigene, Hardware. Und jetzt sagst du, selbst mit der funktioniert es nicht. Passt irgendwie sehr gut in die Reihe an leeren Versprechungen, die ich über die Jahre von Fenecon bekommen habe.
„Zum Glück“ ist der Kaco jetzt nach nicht mal 5 Jahren über den Jordan gegangen. Das gibt mir die Möglichkeit mich endlich von Fenecon zu lösen.
Hi,
ich sehe das auch eher als steuertechnisches Problem.
ich denke am Einfachsten wäre das zu lösen, wenn man nicht den “realen” Grid-Zähler verwendet zum Laden/steuern der Batterie, sondern einen virtuellen.
d.h. virtueller Zähler = realer Zähler - E-Autozähler.
damit würde das EMS den Auto-strom nicht bewerten. hätte aber auch den Nachteil, dass PV primär in die Batterie geladen wird und nicht ins Auto.
das könnte man vermeiden, wenn man beim virtuellen Zähler keine negativen Werte schickt.
d.h. z.B.
Autostrom = 4kW
virtueller Zähler = -2kW → setze virtuellen Zähler auf 0kw
virtueller Zähler =-6kw → setze virtuellen Zähler auf -2kW
Dann ist natürlich der Nachteil, dass viele Werte /Statistik in OpenEMS nicht stimmt. oder man müsste eben 2 OpenEMs parallel betreiben, was auch nicht optimal wäre.
Also hab manuell mach ich das im Moment so, wenn ich das Auto laden will:
- Speicher Notstrom reserve auf aktuellen Ladestand des Speichers stellen (verhindert, dass nun aus dem Speicher gesaugt wird)
- E-Auto Anschließen und Laden (PV und ggf. Netz beladen das Auto)
- warten bis Auto den gewünschten Stand hat
- E Auto laden beenden
- Speicher wieder zurückstellen auf vorherige Notstromreserve.
Als Logik wäre es für mich wie folgt denkbar:
Wenn Wallbox Strom > 0, dann Speicherentladung deaktivieren, wenn Wallbox Strom = 0, dann wieder aktivieren.
Beladen werden, darf der Speicher immer, falls noch PV Strom über ist, oder durch dyn Stromtarife beladen werden soll. Ein Entladung, die ggf. nur zu Stande kommt, weil Wallbox lädt, würde ich nicht zulassen und dann eher in kauf nehmen, dass auch mein Hausstrom solange aus dem Netz kommt.
Mit einem Schalter „Speicherentladung währen E-Auto Ladevorgang deaktivieren“ könnte sogar jeder selbst entscheiden, ob er dieses Verhalten möchte.
ich habe mir für meine Umgebung ein Python script erstellt, das mittels Modbus TCP Daten aus dem fenecon System mit der Wallbox (Power James) abgleicht und die Wallbox entspr. steuert.
klappt schon ganz gut.
wenn ich das Auto priorisiere, lädt mein Programm nur den überschüssigen Strom (Produktion - Verbrauch) ins Auto, dann geht nichts in den Fenecon Speicher.
ansonsten lade ich den Strom, der am Smartmeter ankommt (Grid), dann wird der Speicher zuerst geladen.
Als Rentner kann ich das so machen und tagsüber laden, wenn die Sonne scheint.
Hallo. Möchte gerne das Thema nochmals aufgreifen. Gibt es hier bereits Lösungen ? Meine Anfrage an den Fenecon Support war wie zu erwarten nicht gerade zufriedenstellend.
Meine System:
Fenecon Homespeicher BJ. 2023
Go-e Charger
Überschussladen über evcc auf Raspberry
Vielen Dank euch
Gruß Philipp
Woher soll das OpenEMS in deinem Usecase wissen, dass nun geladen wird, wenn du evcc nebeneinander nutzt?
Denke evcc sollte hier keine Rolle spielen. Der Go-e Charger weiß ja wann geladen wird. Die Wallbox müsste halt mit FEMS komunizieren.
Moin zusammen,
Bin bei meinem Tests auch über dieses Thema nach einer Google Suche gestolpert. Auch ein Ticket beim Support ist bisher unbeantwortet, daher noch ein weiterer Punkt zum Thema FEMS+Wallbox:
Sollte ein starker Stromverbraucher eingeschaltet werden (Durchlauferhitzer bei mir) und dann wieder abgeschaltet werden, reagiert das FEMS zu langsam und sendet Strom ins Netz. Das wird dann als “Überschuss” angesehen und die Wallbox aktiviert sich. Nach ein paar Minuten schaltet sich alles wieder ab, da in Wirklichkeit ja kein Überschuss vorhanden ist.
Und ja, jede Aktion der Wallbox wird erst einmal aus der Batterie bedient! Da ich auch meine Batterie-Zyklen lieber in sinnvolle Hausnutzung des Strom legen will, habe ich mir mir ein wenig python und Home Assistant beholfen.
Lizenz besorgt um die “REST/API Schreibend” zu aktivieren (restart von FEMS notwendig bei mir). Per Dokumentation den mir passenden Channel rausgesucht und RESTful command in HA gebaut. Dies setzt jetzt bei Aktivierung der Wallbox auf eine Entladeleistung von 0 Watt. Wen es interessiert, mit diesen 2 CURL commandos kann man diese Leistung auch schnell selber einmal setzen:
# Disable battery discharge
curl --header "Content-Type: application/json" --request POST --data '{ "value": 0}' http://x:owner@<FEMS_IP>/rest/channel/ess0/SetActivePowerLessOrEquals
# Enable battery discharge
curl --header "Content-Type: application/json" --request POST --data '{ "value": 11059}' http://x:owner@<FEMS_IP>/rest/channel/ess0/SetActivePowerLessOrEquals
Mir ist dabei unverständlich, warum FEMS selbst dies nicht als Konfigurationsoption im EV Charger Panel mitbringen kann. Ein simples “Batterie nicht nutzen” mit einer Checkbox würde dafür ausreichen, intern dann ähnlich gelöst wie mit den beiden Kommandos?
Ich habe jetzt jedenfalls ein System das funktioniert und zumindest die Batterie nicht unnötig nutzt.
EDIT: Kurz zur Erläuterung: Die Kommandos müssen innerhalb von 60s erneut geschickt werden, sonst fällt FEMS zum default zurück. Per Automation in Home Assistant und Python script aber genau so implementiert.
EDIT2: Bin vom Python script auf Home Assistant RESTful commands umgestiegen, da es damit auch prima funktioniert:
fenecon_battery_discharge_disable:
url: http://<FEMS_IP>/rest/channel/ess0/SetActivePowerLessOrEquals
method: POST
username: x
password: !secret fems_rest_password
payload: '{"value": 0}'
content_type: 'application/json; charset=utf-8'
EDIT3: Last but not least … nachdem ich begriffen habe wie man die Werte setzen sollte, hier die fertige Version für Home Assistant:
configuration.yaml
Setze die Power auf den Wert, dem wir and Payload übergeben. <FEMS_IP> mit der IP vom FEMS system ersetzen.
rest_command:
fenecon_battery_power:
url: http://<FEMS_IP>/rest/channel/ess0/SetActivePowerEquals
method: POST
username: x
password: !secret fems_rest_password
payload: '{"value": {{power}}}'
content_type: 'application/json; charset=utf-8'
Action Call Beispiel
So können wir die Leistung manuell einstellen, in diesem Fall: nutze das, was aus der Solarproduktion kommt (wichtig, da wir den Strom ja weiterhin nutzen wollen).
action: rest_command.fenecon_battery_power
data: {power: "{{ states('sensor.fems_production_active_power') | int }}" }
Automation
Wir können damit per automation diesen call ausführen (bei mir: alle 2 Sekunden, wenn die Ladestation lädt). Hier der YAML code für die Action, damit man nicht suchen muss wie das gemacht wird. Sobald die Ladestation aktiviert wird, setzt die Automation alle 2 Sekunden die ActivePower auf das, was PV produziert. Batterie entlädt sich nicht, wird aber auch nicht mit 100% aus Solar aufgeladen - genau das, was ich erreichen wollte.
action: rest_command.fenecon_battery_power
metadata: {}
data: {
power: "{{ states('sensor.fems_production_active_power') | int }}"
}
Damit dann auch direkt der Lösungsansatz für FEMS/OpenEMS: Wenn der User nicht die batterie nutzen will, setze die ESS0 ActivePower nicht auf den Gesamtverbrauch sondern einfach auf das, was aus Solar geliefert wird. Hier liegt im Moment noch das Problem, soweit ich das mit /rest/channel/ess0/DebugSetActivePower
beurteilen konnte.