e3DC Entladesperrzeiten nutzen #13403
Comments
|
scheint über evcc aktuell nicht implementierbar zu sein. Einen Workaround über Homeassistent gibt es aber. |
|
Es gibt keine Bibliothek für rscp. Das müsste also erstmal jemand entwickeln. |
|
Wurde zumindest mal begonnen.. |
|
Oh, thats nice. Not sure why I didn‘t find that. Would anybody be interested in integrating it? Maybe contact @spali in eschange for evcc token? |
andig
added
enhancement
|
Ich nutze aktuell dieses Projekt auf meinem Raspi, um das E3DC per MQTT ansprechen zu können: https://github.com/pvtom/rscp2mqtt Damit lässt sich Man kann aber im E3DC System wie im Bild gezeigt auch einfach manuell einen Wert eintragen, das E3DC System bringt die Funktionalität, dass die Batterie durch die Wallbox nur bis zu einem definierten Soc entladen wird, bereits mit. 😉 Wenn man Sperrzeiten nutzt, dann würde während der Wallboxladung die Batterie gar nichts mehr liefern, damit also auch der Hausverbrauch aus dem Netz kommen. Mit dieser Einstellung kommt NUR die Wallboxladung aus dem Netz, der Hausverbrauch kommt weiterhin aus der E3DC Batterie. 😎 |
Das wäre natürlich der elegantere Weg und würde sich mit den bereits implementierten Umsetzungen anderer Hersteller decken.. denn sobald dieser Wert auf den aktuellen SOC gesetzt wird, entspricht dies ja "hold battery". Ggfs ist dies ja bereits in go-rscp realisiert bzw. einfach zu erweitern, um in evcc ohne Umweg die Funktionalität umzusetzen.
Das kann ich mir nicht vorstellen, außer man verwendet die E3DC-eigene Wallbox. |
@andig The main problem is, that I could only implement and test on one battery model (Quattroporte). And had only the documentation of it (which is also not really up to date). It seems to have some differences of the "tags" (kind of register addressing) depending on the model. That's a point that should be worked on to support this in a clean way. I would be happy if it would be used and even better if it would be enhanced. I can also add you as a member to the project if it goes to slow for some potential changes/fixes needed to integrate it. I love the broad device support that evcc has. I only use it as a kind of api. i.e. to get the stats of my Fiat 500e. I abuse evcc just as a command line utility to parse the output. I know, evcc is meant as full blown control solution, but I would love to have it more easy to use it just to talk to my devices trough evcc without the controlling part (kind as a bridge). If this would be possible I could also imagine to hand the project over completely if it helps both projects. |
|
Thanks @spali! Before we start anything complicated- I have no real clue how to test the library. What would be the minimal code to read grid, pv, battery power and battery soc? I'm lost how to use the Tags or which ones. If I have a basic understanding I could do a quick prototype, maybe to be continued by you. |
|
Grid: EMS_POWER_GRID I have a E3DC S10E for testing and I am happy to help integrate RSCP into evcc. Check this file: https://github.com/spali/go-rscp/blob/master/rscp/tag.go |
|
Please give it a try |
|
Compilation is running... |
|
Thank you all for picking up my request. Even got an idea to improve one step more but please don't enhance the mvp right away. If i got it right, than the max power of the E3/DC battery could be set dynamicaly. So the enhancement of my idea would be to set the max battery power dynamically to household consumption - pv power. Therefore the whole charging energy would not come from the battery but household power need still would be provided from the battery. Thank you so much for working on my idea. Veiter |
|
Damn, I am running into compilation errors. I am using the following command: But I am running into the following error: Any quick idea? |
|
Cross-compile from a different system. ia32- was ist das denn für ein Gruß aus der Vergangenheit? |
|
Ich hatte evcc aber im Herbst auf genau diesem System bereits erfolgreich für 386 bzw. auch für arm (für meinen Raspi) kompiliert. Keine Ahnung, warum er jetzt meint für ia32 kompilieren zu müssen. Liegt wohl daran, dass evcc 32bit Linux nicht mehr unterstützt, meine VM läuft aber auf einem kleinen 32bit Synology NAS... |
@docolli guter Strom schlechter Strom? Wie soll das denn gehen? |
Fehlermeldung lesen. Mir evcc hat das rein gar nichts zu tun. |
Die guten grünen Elektronen fürs Haus kommen aus der Batterie und die bösen schwarzen Elektronen für die Wallbox kommen aus dem Netz. 🤣 |
Schon klar! Habe inzwischen evcc unter Windows am laufen, wie muss denn die config.yaml für die meters aussehen, damit ich die RSCP Verbindung testen kann? So klappts leider nicht:
|
|
So, jetzt habe ich das verstanden, so klappt die Verbindung: meters:
- type: e3dc-2
usage: grid
address: 192.168.1.121
port: 5033
username: xxx
password: xxx
key: xxx
name: grid1
- type: e3dc-2
usage: pv
address: 192.168.1.121
port: 5033
username: xxx
password: xxx
key: xxx
name: pv1
- type: e3dc-2
usage: battery
address: 192.168.1.121
port: 5033
username: xxx
password: xxx
key: xxx
name: battery1
capacity: 13.1 # in kWhDas klappt so nicht mit diesen Tags! Aber das kann ich selber im Code ändern und testen. Morgen dann, jetzt ist Feierabend! |
|
War leicht im Code zu sehen, du musst REQ ergänzen: switch m.usage {
case templates.UsageGrid:
tag = rscp.EMS_REQ_POWER_GRID
case templates.UsagePV:
tag = rscp.EMS_REQ_POWER_PV
case templates.UsageBattery:
tag = rscp.EMS_REQ_POWER_BAT
default:
return 0, api.ErrNotAvailable
}Jetzt kommen Werte, aber das GUI passt noch nicht, vermutlich weil die negativ sind:
|
|
Welche? Alle falschrum? |
|
@spali können wir das Logging einfangen? Logger als Interface? Ich hab spontan im Code nix gefunden. Und wird da wirklich bei jedem einzelnen Request eine Connection aufgemacht a 3 Log lines? |
|
|
|
Muss das bei normal/hold resettet werden? Wie- einfach auf 0 stellen? |
|
Wann läuft denn evcc in Charge rein? Wann löst evcc eine Ladung der Hausbatterie aus? Ich verstehe den Sinn des Zustands noch nicht so ganz. |
|
Spielt doch für die Frage keine Rolle? Aktuell nur über die Kommandozeile oder wenn Du mit #10814 spielen willst. |
|
Ich möchte schon einigermaßen verstehen was das Ziel ist, dann kann ich versuchen spezifischere Infos zu geben. 😉 Zurück zu deiner Frage mit Reset des Zustands: |
|
Ich verstehe nur Bahnhof. Sichergestellt sein muss, dass bei Charge -> Normal das Zwangsladen beendet wird. Wäre vllt. gut das zu testen ;) |
|
Ja sorry, habs ja selber kaum verstanden mit Ladelimit / Entladelimit usw. und wann welches Limit aktiv ist und wieder auf den Default Wert vom System gesetzt wird... 😂 Ich schau mal, wie ich das Zwangsladen bei E3DC unterbrechen kann. Geht aber erst morgen Abend wieder, für heute darf ich keine Ladung mehr starten. |
|
Testung Unterbrechung der manuellen Ladung.
./e3dc '[["EMS_REQ_SET_POWER_SETTINGS",[["EMS_POWER_LIMITS_USED","Bool",1],["EMS_MAX_DISCHARGE_POWER","Int8",500],["EMS_MAX_CHARGE_POWER","Int8",750]]]]'
{"EMS_SET_POWER_SETTINGS":{"EMS_RES_POWER_LIMITS_USED":0,"EMS_RES_MAX_CHARGE_POWER":1,"EMS_RES_MAX_DISCHARGE_POWER":1}}
./e3dc '[["EMS_REQ_GET_POWER_SETTINGS","None","Nil"]]' | jq
{
"EMS_GET_POWER_SETTINGS": {
"EMS_POWER_LIMITS_USED": true,
"EMS_MAX_CHARGE_POWER": 750,
"EMS_MAX_DISCHARGE_POWER": 500,
"EMS_DISCHARGE_START_POWER": 65,
"EMS_POWERSAVE_ENABLED": true,
"EMS_WEATHER_REGULATED_CHARGE_ENABLED": false,
"EMS_WEATHER_FORECAST_MODE": 0
}
}
./e3dc '[["EMS_REQ_START_MANUAL_CHARGE","UInt32",1000]]' | jq
{
"EMS_START_MANUAL_CHARGE": true
}-> Es wird geladen mit ~750W.
./e3dc '[["EMS_REQ_GET_MANUAL_CHARGE","None","Nil"]]' | jq
{
"EMS_GET_MANUAL_CHARGE": {
"16777278": 1000,
"EMS_MANUAL_CHARGE_START_COUNTER": 1713979605597,
"EMS_MANUAL_CHARGE_ACTIVE": true,
"EMS_MANUAL_CHARGE_ENERGY_COUNTER": 0.1222253535,
"EMS_MANUAL_CHARGE_LASTSTART": "2024-04-24T17:26:45.597996Z"
}
}-> Der Tag 16777278 gibt die manuell zu ladende Energiemenge in Wh an, der Tag EMS_MANUAL_CHARGE_ENERGY_COUNTER hat wieder bei 0 angefangen und gibt somit die aktuell manuell geladene Energiemenge an.
./e3dc '[["EMS_REQ_START_MANUAL_CHARGE","UInt32",0]]' | jq
{
"EMS_START_MANUAL_CHARGE": true
}
./e3dc '[["EMS_REQ_GET_MANUAL_CHARGE","None","Nil"]]' | jq
{
"EMS_GET_MANUAL_CHARGE": {
"16777278": 0,
"EMS_MANUAL_CHARGE_START_COUNTER": 1713979605597,
"EMS_MANUAL_CHARGE_ACTIVE": false,
"EMS_MANUAL_CHARGE_ENERGY_COUNTER": 8.225446666666663,
"EMS_MANUAL_CHARGE_LASTSTART": "2024-04-24T17:26:45.597996Z"
}
}
./e3dc '[["EMS_REQ_START_MANUAL_CHARGE","UInt32",500]]' | jq
{
"EMS_START_MANUAL_CHARGE": false
}PS: Das Entladelimit von 500W greift auch: PPS: den Tag 16777278 würde ich "EMS_MANUAL_CHARGE_ENERGY" benennen, aber ich bin nicht E3DC😉 |
|
Supi. Also müssen wir bei Normal/Hold zusätzlich |
Achtung "Nil" heisst für dich in dem Fall Und wenn wir schon dabei sind... zumindestens nach meinen Tests (siehe Kommentar): EMS_MAX_CHARGE_POWER: Uint32, // documented as Int32, but requires Uint32
EMS_MAX_DISCHARGE_POWER: Uint32, // documented as Int32, but requires Uint32E3DC frisst es zu mindestens in meinem Fall nur mit |
|
BatteryCharge ist jetzt auch drin und könnte mittels getestet werden. Die Werte werden jetzt einfach immer gesetzt und nicht abgefragt. |
v0.2.0-beta5 kenn nun auch diesen Tag mit deinem Namen. |
Nachdem die E3DC RSCP Implementation endlich läuft und wir die Batterieentladung kontrollieren können (aktuell setzt du die auf 0), möchte ich hierauf wieder zurück kommen. Können wir die Powerlimits konfigurierbar machen? 😉😎 |
|
Welche Limits willst du denn konfigurieren? Es wird doch gar keins verwendet?! |
|
Das Entladelimit wird auf 0W gesetzt, das könnte man z. B. auch auf 500W setzen, so würde die Batterie weiterhin entladen werden und so den mittleren Hausverbrauch unterstützen. So könnte man erreichen, dass die Batterie am nächsten Morgen ziemlich leer ist und wieder genügend PV Überschuss aufnehmen kann. |
|
Geht das auch, dass das Entladelimit dynamisch angepasst wird? Auf (Haushaltsverbrauch - PV Leistung) natürlich nur während ein Fahrzeug geladen wird und das alle 20 - 60 sec. anzupassen? (Dann wird quasi die Wallboxladung mit einer gewissen Unschärfe ausgeblendet bei der Batterieentladung. Das wäre aber absolut akzeptabel. PS: geht ja nicht um jedes Elektron sondern am Ende um kWh 😉 |
|
Was ist der Unterschied zwischen gutem und schlechtem Strom? Warum braucht die Batteriesteuerung wenn man so ein Enladelimit such einfach fix extern setzen könnte? Ich denke nicht, dass wir das tun wollen. |
|
Es gibt 2 Gründe dafür:
Ich hoffe die Use Case Erläuterung verdeutlicht den Anwendungsfall etwas besser bzgl. Trennung zwischen Lade Energiemenge und Haushaltsverbrauch. Es geht hier also nicht um grüne und schwarze Elektronen sondern um Energiemengen und wie die abgerechnet werden. |
|
Ich habs nicht verstanden. Da da saber auch nix mit e3dc zu tun hat gerne neues Issue dazu. |
|
@andig genau das war die initiale Idee E3DC beim Laden des Fahrzeugs zu sperren, dass die Batterie nicht durch das Fahrzeug entladen wird. Eine Einstellung der maximalen Entladeleistung E3DC (Hausverbrauch minus PV Erzeugung) und dynamische Nachführung alle 30sec. Würde genau das sicher stellen. Also keine neue Idee sonder nur Konkretisierung des Kundennutzens. Ihr habt da die letzten beiden Wochen einen echt super job gemacht und mit dem was ich gelesen habe ist es denk ich möglich das so umsetzen zu können. Vielen Dank Euch allen! |
|
Ich denke hier ist in evcc einfach für versch. Batteriesysteme der "kleinste gemeinsame Nenner" implementiert worden und das ist die Entladesperre. Vermutlich bieten einige Systeme nur an per true/false diese zu setzen, ein Entladelimit ist nicht vorgesehen. Um konsistent zu bleiben, muss unser E3DC sich dieser Implementierung beugen, auch wenn es an dieser Stelle mehr Funktionalität bieten würde. ./e3dc '[["EMS_REQ_SET_WB_DISCHARGE_BAT_UNTIL","Int32",80]]' | jq
{
"EMS_SET_WB_DISCHARGE_BAT_UNTIL": true
}
./e3dc '[["EMS_REQ_GET_WB_DISCHARGE_BAT_UNTIL","None","Nil"]]' | jq
{
"EMS_GET_WB_DISCHARGE_BAT_UNTIL": 80
}Aber dass kann man, wenn man mag, auch über eine externe Lösung implementieren. Als Kompromiss, würde ich vorschlagen, dass man bei BatteryHold das Entladelimit nicht fix im Code auf "0" setzt, sondern einen Parameter einführt, über den der Nutzer vorgeben kann, wieviel Leistung die Batterie bei einem WB Ladevorgang (wenn die Batterie von evcc gesperrt wird) noch abgeben darf. Gerne darf der Default-Wert hier "0" sein, dann haben wir die Entladesperre wie bei anderen Systemen, wenn der Nutzer den Parameter nicht konfiguriert hat. |
|
Ziehe ich meine reine "evcc User mit E3DC System und E3DC Wallbox" Brille auf und denke nicht an andere Batteriesysteme, würde ich in e3dc.go bei BatteryHold folgende Befehle ans E3DC System schicken, damit es in den dynamischen Entladelimitmodus wechselt und bis ./e3dc '[["EMS_REQ_SET_BATTERY_BEFORE_CAR_MODE","UInt8",0]]' | jq
{
"EMS_SET_BATTERY_BEFORE_CAR_MODE": 0
}
./e3dc '[["EMS_REQ_SET_BATTERY_TO_CAR_MODE","UInt8",1]]' | jq
{
"EMS_SET_BATTERY_TO_CAR_MODE": 1
}
./e3dc '[["EMS_REQ_SET_WALLBOX_ENFORCE_POWER_ASSIGNMENT","Bool",true]]' | jq
{
"EMS_SET_WALLBOX_ENFORCE_POWER_ASSIGNMENT": true
}
./e3dc '[["EMS_REQ_SET_WB_DISCHARGE_BAT_UNTIL","UChar8",80]]' | jq
{
"EMS_SET_WB_DISCHARGE_BAT_UNTIL": true
}Aber das kann sich jeder E3DC User selbst im HKW so einrichten und die Entladesperre in evcc einfach nicht aktivieren. @veiter555 Edit: Aber dann MUSS die Wallbox über den evcc Modbusproxy eingebunden werden. Man könnte das wiederum von evcc aus prüfen, aber um die IP-Adresse der Wallbox im HKW abzufragen benötigt man wieder den Index der Wallbox im RSCP Universum, welches der User konfigurieren muss.... Ein konfigurierbares Entladelimit ist hier das Beste, was mit vertretbarem Aufwand erreichbar ist. |
|
Vielen Danke Euch, dass ist nachvollziehbar. Vielen Dank für die Implementierung der Entladesperre, dass hilft sehr viel. VG Veiter |
|
Zunächst ein herzliches Dankeschön für die Umsetzung dieses Features! Ich hatte mir zwischenzeitlich auch mit dem von EVCC gesetzten MQTT Flag und eigener Automatisierung beholfen aber so ist es natürlich deutlich komfortabler! Eine Frage habe ich noch zu dem "battery" Parameter, dieser löst bei mir eine Fehlermeldung aus wenn ich ihn setze: Hier die Konfiguration: Hintergrund: |
|
Wir sind dran, die Abfrage umzubauen, vielleicht passt das dann auch besser für dich. @andig Sollten wir |
|
@docolli Beim S10X sieht es in meinem Beispiel wie folgt aus: Den "capacity" Parameter habe ich hier im Thread schon gesehen und dachte er wäre vielleicht in "battery" umbenannt worden. Schön wäre es natürlich einen solchen Parameter zu haben aber letztlich natürlich auch eine Frage wie oft er überhaupt genutzt würde. Ich hänge mich vielleicht mal in den #13687 Thread rein denn am schönsten wäre es die aktuell von E3DC errechnete netto Kapazität angezeigt zu bekommen. Die schwankt nämlich ziemlich :-) |
|
Wo siehst du die von E3DC berechnete Netto Kapazität? Im Web Portal? Ich kenne bei mir nur die 13,1kWh. |
|
@docolli Wie man an diesen "echten" netto Wert via RSCP rankommt habe ich noch nicht geschaut. Ich muss mal sämtliche Werte in RSCPGui durchforsten, eventuell findet sich da was.
|
|
Bei mir sind es aktuell 1105Wh. Über RSCP2MQTT bekomme ich aus dem System verschiedenste Werte. Setze ich design und usable capacity ins Verhältnis komme ich auf 84,3%. Multipliziere ich das mit specified, so komme ich auf 13107 Wh*0,843 = 11049 Wh. Das passt zum Wert beim 10% Knopf. Das System kalibriert sich, wenn möglich, 1x Woche (Entladen auf 0%). Passiert meistens im Winter, wenn man mal so viel verbraucht dass der Soc unterhalb der Notstromreserve fällt. Dann wird wohl usable_capacity neu berechnet. |
|
@docolli Dass EVCC den Wert nur einmal beim Start ausliest ist ein gute Info, dann macht es tatsächlich keinen Sinn dort auf schwankende netto Werte zu reagieren. Vielleicht wäre der "capacity" Parameter doch wieder interessant. Zur Kalibrierung, die Hochvoltsysteme (wie das S10X) machen das nicht mehr automatisch. Das Ganze ist mit den Eisen Phosphat Akkus wohl auch nicht so einfach bzw. deren Kapazität anhand der Spannung zu bestimmen. Die usable_capacity ändert sich bei mir mehrfach täglich ebenso wie die 10% Anzeige direkt am Hauskraftwerk (letztere sogar teilweise wenn man auf die Anzeige schaut). |
Describe the solution you'd like
Ich möchte im Schnelllademodus nicht, dass meine E3/DC Batterie entladen wird.
Anwendungsfall Bsp.: PHEV kommt um 19 Uhr Heim und muss schnell geladen werden da bis zum nächsten Morgen kein PV Überschuss vorhanden sein wird.
Allerdings möchte ich keine Energie aus der Haus-Batterie dafür verwenden (Batterieentladen sperren) oder die Batterienutzung nur bis zu einem bestimmten SOC zulassen (Rest der Batterieladung sollte das Haus später versorgen)
Zusätzlich wird die Batterie geschont durch Reduzierung der Tiefentladezyklen.
Über RSCP können Sperrzeiten übermittelt werden.
Es wäre super wenn EVCC das dynamisch anwenden könnte. Bsp. Fahrzeug läd - Min. Entlade SOC der E3/DC Batterie ist erreicht, der nicht durch Fahrzeug unterschritten werden soll. - Entladen der E3/DC Batterie wird gesperrt bis Fahrzeug fertig geladen ist und anschließend automatisch wieder entsperrt um die Batterie für die Hausversorgung wieder freizugeben.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: