e3DC Entladesperrzeiten nutzen

[veiter555]

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.

[mdkeil]

scheint über evcc aktuell nicht implementierbar zu sein. Einen Workaround über Homeassistent gibt es aber.

10836

[andig]

Es gibt keine Bibliothek für rscp. Das müsste also erstmal jemand entwickeln.

[mdkeil]

Wurde zumindest mal begonnen.. https://github.com/spali/go-rscp

[andig]

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?

[docolli]

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 site/bufferSoc mit "Batterieentladung durch Wallbox" synchronisieren. Realisiert über eine HomeAutomation (FHEM), in die sowohl evcc als auch das E3DC System per MQTT eingebunden sind.

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. 😉 Siehe auch meinen Wiki-Beitrag: https://github.com/evcc-io/evcc/wiki/docolli:-E3DC-S10E-Hauskraftwerk-&-Easy-Connect-Wallbox-11kW,-FHEM,-rscp2mqtt,-MyStrom-Wifi-Switch,-Nissan-Leaf-ZE1#wallbox

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. 😎

[mdkeil]

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.

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.

Mit dieser Einstellung kommt NUR die Wallboxladung aus dem Netz, der Hausverbrauch kommt weiterhin aus der E3DC Batterie. 😎

Das kann ich mir nicht vorstellen, außer man verwendet die E3DC-eigene Wallbox.

[spali]

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 What an honor. Feel free to integrate it. It was kind of a learning project for go from the need of my father who has this battery. I tried to make it as reusable as possible also as library, but currently I only use it as command line utility for home assistant to control the battery. Don't know if anyone is using it as library, currently only know from the issues and discussions that the cmd utility is used.

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 don't have much time currently due to the family.

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.

[andig]

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.

[docolli]

Grid: EMS_POWER_GRID PV: EMS_POWER_PV Battery: EMS_POWER_BAT Home: EMS_POWER_HOME Battery Soc: EMS_BAT_SOC

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

[andig]

Please give it a try

[docolli]

Compilation is running... How should a minimal config look like?

[veiter555]

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. I even would think to increase my sponsorship if this would be provided from your development community.

Veiter

[docolli]

Damn, I am running into compilation errors. My system: Linux modbusproxy 6.1.60-0-virt #1-Alpine SMP PREEMPT_DYNAMIC Wed, 25 Oct 2023 15:45:31 +0000 i686 Linux

I am using the following command: env GOOS=linux GOARCH=386 make

But I am running into the following error:

npm run build

> build
> vite build

/root/evcc/node_modules/rollup/dist/native.js:38
        throw new Error(
              ^

Error: Your current platform "linux" and architecture "ia32" combination is not yet supported by the native Rollup build. Please use the WASM build "@rollup/wasm-node" instead.

The following platform-architecture combinations are supported:
android-arm
android-arm64
darwin-arm64
darwin-x64
linux-arm
linux-arm64
linux-arm64 (musl)
linux-riscv64
linux-x64
linux-x64 (musl)
win32-arm64
win32-ia32
win32-x64

If this is important to you, please consider supporting Rollup to make a native build for your platform and architecture available.
    at Object.<anonymous> (/root/evcc/node_modules/rollup/dist/native.js:38:8)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:169:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

Any quick idea? I am getting the same error if I use env GOOS=linux GOARCH=x64 make

[andig]

Cross-compile from a different system. ia32- was ist das denn für ein Gruß aus der Vergangenheit?

[docolli]

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. Ich habe vorhin das evcc Quellcode Verzeichniss komplett gelöscht und frisch geklont. Muss ich da noch wieder was installieren?

modbusproxy:~/evcc# go version
go version go1.22.2 linux/386

modbusproxy:~/evcc# apk list nodejs
nodejs-20.12.1-r0 x86 {nodejs} (MIT) [installed]

Liegt wohl daran, dass evcc 32bit Linux nicht mehr unterstützt, meine VM läuft aber auf einem kleinen 32bit Synology NAS... Egal, baue evcc jetzt direkt auf meinem Windows Laptop. Ich habe jetzt eine evcc.exe zum Testen ! 😎

[andig]

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. 😎

@docolli guter Strom schlechter Strom? Wie soll das denn gehen?

[andig]

Liegt wohl daran, dass evcc 32bit Linux nicht mehr unterstützt

Fehlermeldung lesen. Mir evcc hat das rein gar nichts zu tun.

[docolli]

@docolli guter Strom schlechter Strom? Wie soll das denn gehen?

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. 🤣 Spaß beiseite: So kann man (zumindest bilanziell) den Hausverbrauch weiterhin aus der Batterie (also PV-Strom) decken während die Wallboxladung läuft, schont den Hausakku. Und der Hausverbrauch während der Wallboxladung kommt nicht auch aus dem Netz, erhöht also den Eigenverbrauch.

[docolli]

Liegt wohl daran, dass evcc 32bit Linux nicht mehr unterstützt

Fehlermeldung lesen. Mir evcc hat das rein gar nichts zu tun.

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:

meters:
- type: template
  template: e3dc-2
  usage: grid
  address: 192.168.1.121
  port: 5033
  username: xxx
  password: xxx
  key: xxx
  name: grid1

[main ] FATAL 2024/04/12 21:58:17 cannot create meter 'grid1': cannot create meter type 'template': template not found: e3dc-2

[docolli]

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 kWh

ime="2024-04-12T22:13:30+02:00" level=info msg="Connecting to 192.168.1.121:5033"
time="2024-04-12T22:13:30+02:00" level=info msg="successfully connected to 192.168.1.121:5033"
time="2024-04-12T22:13:30+02:00" level=info msg="hiding auth request for security, use debug >= 99 to debug authentication"
time="2024-04-12T22:13:30+02:00" level=info msg="successfully authenticated (level: AUTH_LEVEL_USER)"
[site  ] ERROR 2024/04/12 22:13:30 pv 1 power: message at index 0: EMS_POWER_PV: tag is not a request tag
time="2024-04-12T22:13:30+02:00" level=info msg="Connecting to 192.168.1.121:5033"
time="2024-04-12T22:13:30+02:00" level=info msg="successfully connected to 192.168.1.121:5033"
time="2024-04-12T22:13:30+02:00" level=info msg="hiding auth request for security, use debug >= 99 to debug authentication"
time="2024-04-12T22:13:30+02:00" level=info msg="successfully authenticated (level: AUTH_LEVEL_USER)"
[site  ] ERROR 2024/04/12 22:13:31 battery 1 power: message at index 0: EMS_POWER_BAT: tag is not a request tag

Das klappt so nicht mit diesen Tags! Aber das kann ich selber im Code ändern und testen. Morgen dann, jetzt ist Feierabend!

[docolli]

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:

[site  ] DEBUG 2024/04/12 22:21:22 pv power: 0W
[site  ] DEBUG 2024/04/12 22:21:22 battery soc: 59%
[site  ] DEBUG 2024/04/12 22:21:22 battery power: -402W
[site  ] DEBUG 2024/04/12 22:21:22 grid meter: 2W
[site  ] DEBUG 2024/04/12 22:21:22 site power: -300W

[andig]

Welche? Alle falschrum?

[andig]

@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?

[docolli]

Zumindest den Batteriewert sieht er als Ladung an, obwohl jetzt um diese Zeit natürlich entladen wird. Auch Netzbezug (grid) ist falschherum, wenn ich das mit dem evcc mit Modbusanbindung vergleiche.

[docolli]

Hinweis: Die verbaute Batteriekapazität könnte man auch per RSCP abfragen. Müsste dann nicht mehr in die config.yaml rein. TAG_BAT_SPECIFICATION, TAG_BAT_SPECIFIED_CAPACITY Rückgabewert in Wh (!)

@spali Ich sehe gerade, dass dieser TAG noch nicht bei Dir eingebaut ist. TAG_BAT_SPECIFIED_CAPACITY 0x03800125 Siehe: https://github.com/pvtom/rscp2mqtt/blob/main/RscpTags.h

[spali]

@andig

@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?

Bin nicht 100% sicher, aber es müsste möglich sein den globalen Logger von logrus zu konfigurieren. Ein import vom logger und dann gemäss Doku den Output anpassen.

@spali Ich sehe gerade, dass dieser TAG noch nicht bei Dir eingebaut ist. TAG_BAT_SPECIFIED_CAPACITY 0x03800125 Siehe: https://github.com/pvtom/rscp2mqtt/blob/main/RscpTags.h

Kurzfristig sollte direkt mit der Nummer auch gehen anstatt den TAG "Alias".

Benötigt es ev. alle von:

#define TAG_BAT_REQ_SPECIFICATION                               0x03000043
#define TAG_BAT_SPECIFICATION                                   0x03800043
#define TAG_BAT_SPECIFIED_CAPACITY                              0x03800125
#define TAG_BAT_SPECIFIED_DSCHARGE_POWER                        0x03800126
#define TAG_BAT_SPECIFIED_CHARGE_POWER                          0x03800127
#define TAG_BAT_SPECIFIED_MAX_DCB_COUNT                         0x03800128
#define TAG_BAT_ROLE                                            0x03800129

Das Gefühl sagt mir TAG_BAT_REQ_SPECIFICATION ist ein Container Request mit den anderen Tags als Werte darin. Kann das jemand bestätigen... bei meiner Doku ist keiner der Tags enthalten....

[andig]

Wie müsste dann bei dem Request die Verarbeitung aussehen um die Kapa rauszufischen? Der Container Request scheint dann ja mehrere Werte zurück zu geben, oder wie funktioniert das?

[spali]

Beispiel für BAT_REQ_DATA (welches ein Container Type ist): Request:

[
    ["BAT_REQ_DATA",
        [
            ["BAT_INDEX",0],
            ["BAT_REQ_INFO"],
            ["BAT_REQ_DCB_INFO", 0],
            ["BAT_REQ_DCB_INFO", 1]
        ]
    ]
]

Resultat:

{
  "BAT_DATA": {
    "BAT_INDEX": 0,
    "BAT_INFO": {
      "BAT_RSOC": 55.844955,
      "BAT_MODULE_VOLTAGE": 51.9,
      "BAT_CURRENT": -0.3,
      "BAT_STATUS_CODE": 0,
      "BAT_ERROR_CODE": 0,
      "BAT_MAX_DCB_CELL_CURRENT": 0
    },
    "BAT_DCB_INFO": [
      {
        "BAT_DCB_INDEX": 0,
        "BAT_DCB_LAST_MESSAGE_TIMESTAMP": 1713002538338,
        "BAT_DCB_MAX_CHARGE_VOLTAGE": 58.8,
        "BAT_DCB_MAX_CHARGE_CURRENT": 63,
        "BAT_DCB_END_OF_DISCHARGE": 44.5,
        "BAT_DCB_MAX_DISCHARGE_CURRENT": 63,
        "BAT_DCB_FULL_CHARGE_CAPACITY": 126,
        "BAT_DCB_REMAINING_CAPACITY": 69.1,
        "BAT_DCB_SOC": 54.8,
        "BAT_DCB_SOH": 91.9,
        "BAT_DCB_CYCLE_COUNT": 671,
        "BAT_DCB_CURRENT": 0,
        "BAT_DCB_VOLTAGE": 51.9,
        "BAT_DCB_CURRENT_AVG_30S": 0,
        "BAT_DCB_VOLTAGE_AVG_30S": 51.9,
        "BAT_DCB_DESIGN_CAPACITY": 126,
        "BAT_DCB_DESIGN_VOLTAGE": 51.8,
        "BAT_DCB_CHARGE_LOW_TEMPERATURE": -10,
        "BAT_DCB_CHARGE_HIGH_TEMPERATURE": 45,
        "BAT_DCB_MANUFACTURE_DATE": 0,
        "BAT_DCB_SERIALNO": 2004240070,
        "BAT_DCB_PROTOCOL_VERSION": 21,
        "BAT_DCB_FW_VERSION": 260,
        "BAT_DCB_DATA_TABLE_VERSION": 7,
        "BAT_DCB_PCB_VERSION": 8,
        "BAT_DCB_NR_SERIES_CELL": 0,
        "BAT_DCB_NR_PARALLEL_CELL": 0,
        "BAT_DCB_MANUFACTURE_NAME": "LG",
        "BAT_DCB_DEVICE_NAME": "EM048126P3S",
        "BAT_DCB_SERIALCODE": "2004240070",
        "BAT_DCB_NR_SENSOR": 2,
        "BAT_DCB_STATUS": 96,
        "BAT_DCB_WARNING": 0,
        "BAT_DCB_ALARM": 0,
        "BAT_DCB_ERROR": 0
      },
      {
        "BAT_DCB_INDEX": 1,
        "BAT_DCB_LAST_MESSAGE_TIMESTAMP": 1713002537538,
        "BAT_DCB_MAX_CHARGE_VOLTAGE": 58.8,
        "BAT_DCB_MAX_CHARGE_CURRENT": 63,
        "BAT_DCB_END_OF_DISCHARGE": 44.5,
        "BAT_DCB_MAX_DISCHARGE_CURRENT": 63,
        "BAT_DCB_FULL_CHARGE_CAPACITY": 126,
        "BAT_DCB_REMAINING_CAPACITY": 69.4,
        "BAT_DCB_SOC": 55.1,
        "BAT_DCB_SOH": 91.6,
        "BAT_DCB_CYCLE_COUNT": 671,
        "BAT_DCB_CURRENT": -0.1,
        "BAT_DCB_VOLTAGE": 52,
        "BAT_DCB_CURRENT_AVG_30S": -0.098618805,
        "BAT_DCB_VOLTAGE_AVG_30S": 51.983055,
        "BAT_DCB_DESIGN_CAPACITY": 126,
        "BAT_DCB_DESIGN_VOLTAGE": 51.8,
        "BAT_DCB_CHARGE_LOW_TEMPERATURE": -10,
        "BAT_DCB_CHARGE_HIGH_TEMPERATURE": 45,
        "BAT_DCB_MANUFACTURE_DATE": 0,
        "BAT_DCB_SERIALNO": 2004240284,
        "BAT_DCB_PROTOCOL_VERSION": 21,
        "BAT_DCB_FW_VERSION": 260,
        "BAT_DCB_DATA_TABLE_VERSION": 7,
        "BAT_DCB_PCB_VERSION": 8,
        "BAT_DCB_NR_SERIES_CELL": 0,
        "BAT_DCB_NR_PARALLEL_CELL": 0,
        "BAT_DCB_MANUFACTURE_NAME": "LG",
        "BAT_DCB_DEVICE_NAME": "EM048126P3S",
        "BAT_DCB_SERIALCODE": "2004240284",
        "BAT_DCB_NR_SENSOR": 2,
        "BAT_DCB_STATUS": 96,
        "BAT_DCB_WARNING": 0,
        "BAT_DCB_ALARM": 0,
        "BAT_DCB_ERROR": 0
      }
    ]
  }
}

Zusammengefasst ist ein Container ein Array mit weiteren Requests, wo man sagen kann welche Infos man will, entweder mit nur einem Request Tag (Type: None) oder einem Request Tag (Type: index) wo man noch spezifisch sagen kann wenn man wie in dem Fall von der Batterie den Index mit angeben will.

[andig]

Hast Du ein Codebeispiel das request/response mal für die Batteriekapazität zeigen würde? Mir ist nicht irchtig klar wie ich das zusammen bauen müsste.

[spali]

Korrektur... glaube habe falsch vermutet. Mag mich erinnern... die 8 an zweiter stelle deutet auf Antwort tag hin. Für die Tags

#define TAG_BAT_REQ_SPECIFICATION                               0x03000043
#define TAG_BAT_SPECIFICATION                                   0x03800043
#define TAG_BAT_SPECIFIED_CAPACITY                              0x03800125
#define TAG_BAT_SPECIFIED_DSCHARGE_POWER                        0x03800126
#define TAG_BAT_SPECIFIED_CHARGE_POWER                          0x03800127
#define TAG_BAT_SPECIFIED_MAX_DCB_COUNT                         0x03800128
#define TAG_BAT_ROLE                                            0x03800129

würde ich also vermuten, das mit nur der Anfrage des Tags TAG_BAT_REQ_SPECIFICATION ein Container zurück kommt (sprich einzelner Tag anfragen wie bei einem Wert... aber vermutlich mit antwort:

{
  "TAG_BAT_SPECIFICATION": {
    "TAG_BAT_SPECIFIED_CAPACITY": ??,
    "TAG_BAT_SPECIFIED_DSCHARGE_POWER": ??,
    ...
  }
}

Als Erklärung json zu "realer" Msg im Code... Für commandline interface habe ich eine optionale vereinfachte notation der Requests... wo nur die Tags im Array geschrieben werden müssen und sofern der Tag bekannt ist, kann er den Type selber herausfinden.

folgender einfacher json Request

["INFO_REQ_MAC_ADDRESS]

entspricht im eigentlichen Protocol:

[["INFO_REQ_MAC_ADDRESS","None",""]]

Jeder Tag ist ein Tuple bestehend aus [Tag Id, Type, Wert] Bei Type Container, kann der Wert ein Array sein von "Sub"-Werten.

Nachtrag... da der Tag und somit der Type der library nicht bekannt ist... müsstes du definitiv das Tuple ausschreiben... Wobei ein Request Tag der nicht ein Container ist immer "None" type hat und kein Wert. Die Antwort müsste ein Container mit den "Unter"-Werten" sein.

[andig]

Ich versteh nur Bhf. Was bedeutet das in Code?

[docolli]

Die ersten 8 Bit sind der NAMESPACE, hier 0x03 = BAT Das höchstwertige Bit der nächsten 24 Bit sind 0=Request / 1=Response ("Die 0 bzw. 8 an zweiter Stelle") Die restlichen 23 Bit sind individuell für den Befehl

[docolli]

@spali Ich habe dein Projekt als Windows Exe kompiliert, schaffe aber die Übergabe eines Wertes als Array nicht:

C:\Daten\SW-Entwicklung\go-rscp\go-rscp\cmd\e3dc>e3dc.exe '[["EMS_REQ_START_MANUAL_CHARGE",0]]'
error: request input has always to be an in an array

Kannst du mir da mit der Syntax aushelfen?

[docolli]

@andig Korrektur zu gestern: Die Auswertung des Grid-Wertes passt. Aktuell wird eingespeist und auch korrekt angezeigt:

[site  ] DEBUG 2024/04/13 12:39:09 pv power: 7707W
[site  ] DEBUG 2024/04/13 12:39:09 battery soc: 100%
[site  ] DEBUG 2024/04/13 12:39:09 battery power: 0W
[site  ] DEBUG 2024/04/13 12:39:09 grid meter: -7163W
[site  ] DEBUG 2024/04/13 12:39:09 site power: -7063W

Damit muss nur das Vorzeichen von Battery Power umgedreht werden.

[spali]

@docolli

@spali Ich habe dein Projekt als Windows Exe kompiliert, schaffe aber die Übergabe eines Wertes als Array nicht:

C:\Daten\SW-Entwicklung\go-rscp\go-rscp\cmd\e3dc>e3dc.exe '[["EMS_REQ_START_MANUAL_CHARGE",0]]'
error: request input has always to be an in an array

Kannst du mir da mit der Syntax aushelfen?

öööö Ihr bringt mich ins Schleudern... ist schon ein weilchen her und wie es scheint waren die Fehlermeldungen ned ideal 😉 Exakt dein Request nutzt mein Vater sogar aktiv im Homeassistant als shell_command. Hast du mal mit -debug 6 versuchtob was zu erkennen ist? Falls es bei der Authentifizierung ist.. kannst du auch mal mit-debug 100` schauen... aber dann bitte das log nicht hier posten... da mit >= 99 nicht nur die Antwort sondern auch dein Passwort etc. im Log landet.

[docolli]

@spali Danke Dir, ich dachte du hättest das vielleicht schon mal unter Windows am Laufen gehabt. Ist vermutlich irgendein Syntax Problem in der Windows Shell, der die Linux Array Eingabekonstruktion nicht kennt.... PS: Selbst bei -debug 100 kommt im Prinzip der gleiche Fehler.

Egal, habe es mir jetzt für mein Linux System gebaut und es läuft. Jetzt kann ich hier wieder mit realen Daten zu TAG-Anfragen und Antworten helfen. Das war mein Ziel.

modbusproxy:~/go-rscp/go-rscp/cmd/e3dc# ./e3dc '[["EMS_REQ_START_MANUAL_CHARGE",0]]'
{"EMS_START_MANUAL_CHARGE":true}

Wie würde ich jetzt mal zum Testen BAT_REQ_DATA abfragen, oder direkt die 0x03800125? Hast du da ein Beispiel für einen Kommandozeilen-Aufruf?

[docolli]

Ich werde nicht schlau, wie ich einen Wert aus einem Container abfrage. 😟 Ich versuche z.B. den Wert BAT_REQ_RSOC aus dem Container "BAT_REQ_DATA" abzufragen:

./e3dc -debug 6 '[["BAT_REQ_DATA","Container",["BAT_REQ_RSOC"] ]]'
INFO[0000] Connecting to 192.168.1.121:5033
INFO[0000] successfully connected to 192.168.1.121:5033
INFO[0000] hiding auth request for security, use debug >= 99 to debug authentication
TRAC[0000] read plain []byte{0xe3, 0xdc, 0x0, 0x11, 0x1a, 0x77, 0x1a, 0x66, 0x0, 0x0, 0x0, 0x0, 0x30, 0x6c, 0x9f, 0x5, 0x8, 0x0, 0x1, 0x0, 0x80, 0x0, 0x3, 0x1, 0x0, 0xa, 0x8c, 0x59, 0x77, 0x1b}
TRAC[0000] read [{ RSCP_AUTHENTICATION UChar8 10 }]
INFO[0000] successfully authenticated (level: AUTH_LEVEL_USER)
DEBU[0000] write [{ BAT_REQ_DATA Container [{ BAT_REQ_RSOC None <nil> }] }]
TRAC[0000] write plain []byte{0xe3, 0xdc, 0x0, 0x11, 0xdf, 0x6d, 0x1a, 0x66, 0x0, 0x0, 0x0, 0x0, 0x78, 0x10, 0xf5, 0x12, 0xe, 0x0, 0x0, 0x0, 0x4, 0x3, 0xe, 0x7, 0x0, 0x1, 0x0, 0x0, 0x3, 0x0, 0x0, 0x0, 0xc4, 0x1b, 0x67, 0xaa}
TRAC[0000] write crypt []byte{0xf1, 0xae, 0x3a, 0x89, 0xda, 0x4b, 0xf1, 0x4e, 0xd, 0x8d, 0x2e, 0x95, 0xaa, 0x9f, 0x16, 0xbe, 0x42, 0x74, 0x23, 0x75, 0xe, 0x7d, 0xe1, 0x31, 0xc, 0xde, 0xf5, 0x5, 0xc0, 0xde, 0xb1, 0x5, 0x52, 0x3c, 0xfe, 0x27, 0xf2, 0xee, 0x3c, 0xe9, 0x82, 0x96, 0xc8, 0x34, 0xa4, 0x73, 0x72, 0xb2, 0x6b, 0x27, 0x6d, 0xeb, 0xff, 0xd5, 0x4f, 0xb, 0x21, 0xaa, 0xb0, 0xea, 0x12, 0x7, 0xbc, 0xc5}
TRAC[0000] read plain []byte{0xe3, 0xdc, 0x0, 0x11, 0x1a, 0x77, 0x1a, 0x66, 0x0, 0x0, 0x0, 0x0, 0x60, 0x2f, 0x10, 0x6, 0xb, 0x0, 0x0, 0x0, 0x84, 0x3, 0xff, 0x4, 0x0, 0x6, 0x0, 0x0, 0x0, 0x54, 0xa, 0x5b, 0x8f}
TRAC[0000] read [{ BAT_DATA Error ERR_NOT_AVAILABLE }]
INFO[0000] disconnected
{"BAT_DATA":"ERR_NOT_AVAILABLE"}

[spali]

@spali Danke Dir, ich dachte du hättest das vielleicht schon mal unter Windows am Laufen gehabt. Ist vermutlich irgendein Syntax Problem in der Windows Shell, der die Linux Array Eingabekonstruktion nicht kennt.... PS: Selbst bei -debug 100 kommt im Prinzip der gleiche Fehler.

Nein, aber ich vermutlich hast du Recht mit Powershell Escaping.

Wie würde ich jetzt mal zum Testen BAT_REQ_DATA abfragen, oder direkt die 0x03800125? Hast du da ein Beispiel für einen Kommandozeilen-Aufruf?

Das mit den nummern direkt geht leider über json noch nicht... heisst kannst du nur über go mit der library. Ich wollte das aber sowieso mal einbauen als Fallback, da scheinbar einige Tags auch Modelspezifisch sind. Baue ich.... kann nur nicht versprechen, dass es heute fertig wird.

Ich werde nicht schlau, wie ich einen Wert aus einem Container abfrage. 😟 Ich versuche z.B. den Wert BAT_REQ_RSOC aus dem Container "BAT_REQ_DATA" abzufragen:

Bei BAT_REQ_DATA musst du noch zwingen den BAT_INDEX mitgeben:

[
    ["BAT_REQ_DATA",
        [
            ["BAT_INDEX",0],
            ["BAT_REQ_INFO"],
            ["BAT_REQ_DCB_INFO", 0],
            ["BAT_REQ_DCB_INFO", 1]
        ]
    ]
]

[docolli]

Oh Mann, alle die hier mitlesen habens wahrscheinlich schon kapiert, nur ich nicht... 🙈 Jetzt ist endlich der Groschen gefallen, wie ich den CMD Aufruf für einen Container machen muss:

./e3dc '[["BAT_REQ_DATA",[["BAT_INDEX",0],["BAT_REQ_INFO"],["BAT_REQ_DCB_INFO", 0],["BAT_REQ_DCB_INFO", 1]]]]'

Übrigens: Unter Windows müssen die inneren Anführungszeichen so escaped werden:

e3dc "[\"INFO_REQ_MAC_ADDRESS\"]"

Das mit den nummern direkt geht leider über json noch nicht... heisst kannst du nur über go mit der library. Ich wollte das aber sowieso mal einbauen als Fallback, da scheinbar einige Tags auch Modelspezifisch sind. Baue ich.... kann nur nicht versprechen, dass es heute fertig wird.

Keine Eile! Danke erstmal für die Unterstützung. Melde Dich, wenn es eingebaut ist, dann teste ich gerne.

[docolli]

Die Infos sind hierarchisch gegliedert. Jedes Batteriesystem hat einen BAT_INDEX (Man könnte ja mehrere Speicher aufstellen und als einheitlichen Batteriespeicher ansehen). Dann hat jeder Speicher noch einzelne Batteriemodule, die über den BAT_DCB_INDEX einzeln ansprechbar sind. Start der Zählung ist bei "0".

Hier die Werte meines 4. Batteriemoduls:

./e3dc '[["BAT_REQ_DATA",[["BAT_INDEX",0],["BAT_REQ_DCB_INFO",3] ]]]' | jq
{
  "BAT_DATA": {
    "BAT_INDEX": 0,
    "BAT_DCB_INFO": {
      "BAT_DCB_INDEX": 3,
      "BAT_DCB_LAST_MESSAGE_TIMESTAMP": 1713018950948,
      "BAT_DCB_MAX_CHARGE_VOLTAGE": 56.8,
      "BAT_DCB_MAX_CHARGE_CURRENT": 0,
      "BAT_DCB_END_OF_DISCHARGE": 47,
      "BAT_DCB_MAX_DISCHARGE_CURRENT": 42,
      "BAT_DCB_FULL_CHARGE_CAPACITY": 58.7,
      "BAT_DCB_REMAINING_CAPACITY": 58.7,
      "BAT_DCB_SOC": 100,
      "BAT_DCB_SOH": 99.8,
      "BAT_DCB_CYCLE_COUNT": 351,
      "BAT_DCB_CURRENT": 0,
      "BAT_DCB_VOLTAGE": 53.2,
      "BAT_DCB_CURRENT_AVG_30S": -0,
      "BAT_DCB_VOLTAGE_AVG_30S": 53.2,
      "BAT_DCB_DESIGN_CAPACITY": 64,
      "BAT_DCB_DESIGN_VOLTAGE": 51.2,
      "BAT_DCB_CHARGE_LOW_TEMPERATURE": -10,
      "BAT_DCB_CHARGE_HIGH_TEMPERATURE": 45,
      "BAT_DCB_MANUFACTURE_DATE": 2262,
      "BAT_DCB_SERIALNO": 375,
      "BAT_DCB_PROTOCOL_VERSION": 0,
      "BAT_DCB_FW_VERSION": 17694720,
      "BAT_DCB_DATA_TABLE_VERSION": 0,
      "BAT_DCB_PCB_VERSION": 772,
      "BAT_DCB_NR_SERIES_CELL": 0,
      "BAT_DCB_NR_PARALLEL_CELL": 0,
      "BAT_DCB_MANUFACTURE_NAME": "ATL",
      "BAT_DCB_DEVICE_NAME": "ATL3_3",
      "BAT_DCB_SERIALCODE": "202203020177",
      "BAT_DCB_NR_SENSOR": 2,
      "BAT_DCB_STATUS": 97,
      "BAT_DCB_WARNING": 0,
      "BAT_DCB_ALARM": 4096,
      "BAT_DCB_ERROR": 0
    }
  }
}

Wäre es jetzt noch möglich in der Abfrage nur 1 dieser Werte abzufragen, z.B. BAT_DCB_SOH? Oder muss man das selber durch JSON Parsing machen?

[docolli]

Für die Leistungswerte für PV, Netz und Batterie haben wir bereits die passenden Tags im Zweig feat/e3dc. Die Logik für die Interpretation der Batteriewerte muss jedoch noch an die evcc Logik angepasst werden.

Netz:     -> Einspeisung = negative Werte / Bezug = positive Werte
Batterie: -> Entladen = negative Werte / Laden = positive Werte

Wenn nötig, kann man folgendermaßen Spannung und Strom abfragen. Auch hier muss der Index des Wechselrichters mitgegeben werden und die abzufragende Phase L1/L2/L3 als 0/1/2 spezifiziert werden.

#Bsp: Abfrage für Spannung Wechselrichter (#0) und Phase L3(#2):
./e3dc '[["PVI_REQ_DATA",[["PVI_INDEX",0],["PVI_REQ_AC_VOLTAGE",2]]]]' | jq
{
  "PVI_DATA": {
    "PVI_INDEX": 0,
    "PVI_AC_VOLTAGE": {
      "PVI_INDEX": 2,
      "PVI_VALUE": 232.1
    }
  }
}

#Bsp: Abfrage für Strom Wechselrichter (#0) und Phase L1(#0):
./e3dc '[["PVI_REQ_DATA",[["PVI_INDEX",0],["PVI_REQ_AC_CURRENT",0]]]]' | jq
{
  "PVI_DATA": {
    "PVI_INDEX": 0,
    "PVI_AC_CURRENT": {
      "PVI_INDEX": 0,
      "PVI_VALUE": 9.2
    }
  }
}

Es gibt auch noch diese Tags laut E3DC Doku: Die scheinen wiederum Teil des PM_DATA Containers zu sein, ich schaffe es jedoch aktuell keine funktionierende Anfrage zu erstellen.🙈 Das hier scheitert: ./e3dc '[["PM_REQ_DATA",[["PM_INDEX",0],["PM_POWER_L1",0]]]]' | jq

Eine Einbindung einer E3DC Wallbox per RSCP würde ich nicht empfehlen, da über RSCP keine mA genaue Ansteuerung möglich ist.

Cool wäre, wenn evcc den eingestellten bufferSoc per RSCP mit dem E3DC System synchron halten würde. @spali Hierzu bräuchten wir dann noch Zugriff auf diese Tags:

TAG_EMS_GET_WB_DISCHARGE_BAT_UNTIL                      0x0180027D
TAG_EMS_REQ_GET_WB_DISCHARGE_BAT_UNTIL                  0x0100027D
TAG_EMS_SET_WB_DISCHARGE_BAT_UNTIL                      0x0180027C
TAG_EMS_REQ_SET_WB_DISCHARGE_BAT_UNTIL                  0x0100027C

[spali]

@docolli Ich sollte die Tags leider nicht wild hinzufügen... da ich nicht das gleiche Model habe zum testen und es ev. Konflikte gibt zwischen den Tags. Könntest du zufällig die Doku (Excel im Example download von E3DC) mir zur Verfügung stellen? Ev. ist deine vollständiger da ich nur die kastrierte Quattroporte habe ;).

Ich arbeite daran, dass die Tags nicht Strings, sondern auch Nummern sein können, sowie, das man für die Datentypen Notfalls bestehende Tag/Datentyp-Definitionen überschreiben kann. Dann ist man nicht mehr davon abhängig, dass ich alle Tags zwingend definiere im Code.

@andig Für die Library-Nutzung, müsste das schon möglich sein, in dem du anstatt NewMessage einfach direkt ein Message struct erstellst:

rscp.Message{Tag: 0x00000000, DataType: rscp.None, Value: nil}

[spali]

Habe eine neue Version als Beta released, welche nun auch für das Kommandozeilen-Tool e3dc erlaubt Tag's und Datentypen zu überschreiben, bzw. nicht definierte zu benutzen. Das dürfte es für euch euch einfacher machen zu testen was das entsprechende Model hergibt oder wie es abgefragt werden muss. https://github.com/spali/go-rscp/releases/tag/v0.2.0-beta2

Kleiner Wermutstropfen... benötigt eine Tag Nummer als dezimale Zahl, da JSON Standard keine 0x0 Schreibweise unterstütz. Also immer brav mit dem Windows-Rechner umrechnen 😉

Updated: Link zu beta2 angepasst.

[docolli]

@spali Kann ich Dir die Dateien persönlich zukommen lassen? Ich möchte die E3DC Doku hier nicht öffentlich machen, es gibt auch noch eine andere gute Quelle bei E3DC 😁.

Die Beta werden ich heute Abend mal testen, vielen Dank dafür!

[spali]

Kann ich Dir die Dateien persönlich zukommen lassen? Ich möchte die E3DC Doku hier nicht öffentlich machen, es gibt auch noch eine andere gute Quelle bei E3DC 😁.

Meine mail ist in den Commits (du hast das Repo ja schon geklonnt. Oder einfach mein Usernamen hier bei github vor und nach dem @ und ein .ch dahinter 😉

es gibt auch noch eine andere gute Quelle bei E3DC 😁.

Wäre ich auch an Infos interessiert... kenne nur den Download der E3DC für die ich ein Login habe.

[spali]

Neues beta release mit ein paar tausend mehr Tags (Dank an @docolli ) 😉 https://github.com/spali/go-rscp/releases/tag/v0.2.0-beta3

[docolli]

@andig

Um die im E3DC System vorhandene Begrenzung der Batterieunterstützung bei Wallboxladung (mit einer E3DC Wallbox) nutzen zu können muss man das System mit diesen Befehlen folgendermaßen konfigurieren:

./e3dc '[["EMS_REQ_SET_BATTERY_BEFORE_CAR_MODE","UChar8",0]]'
{"EMS_SET_BATTERY_BEFORE_CAR_MODE":0}

Mit dem Wert "0" wird definiert, dass die Wallbox vor der Batterie Überschußstrom bekommt.

./e3dc '[["EMS_REQ_SET_BATTERY_TO_CAR_MODE","UChar8",1]]'
{"EMS_SET_BATTERY_TO_CAR_MODE":1}

Der Wert 1 schaltet die Batterieunterstützung der Wallboxladung ein.

./e3dc '[["EMS_REQ_SET_WALLBOX_ENFORCE_POWER_ASSIGNMENT","Bool",1]]'
{"EMS_SET_WALLBOX_ENFORCE_POWER_ASSIGNMENT":true}

Dies unterbindet die Batterieentladung durch Wallbox im Mischmodus und während Haltezeit und Zeitfunktion

Mit dieser "Grundkonfiguration" kann man nun den Soc Wert bis zu dem die Batterie durch die Wallbox entladen werden darf setzen. Der Wert muss als Type "UChar8" übertragen werden.

./e3dc '[["EMS_REQ_SET_WB_DISCHARGE_BAT_UNTIL","UChar8",75]]'
{"EMS_SET_WB_DISCHARGE_BAT_UNTIL":true}

Es kann auch gelesen werden:

./e3dc '[["EMS_REQ_GET_WB_DISCHARGE_BAT_UNTIL","UChar8",0]]'
{"EMS_GET_WB_DISCHARGE_BAT_UNTIL":75}

Wenn dieser Wert synchron zu bufferSoc laufen könnte wäre es genial! Also wenn ich in evcc im GUI den `bufferSoc´ ändere, den rscp-Befehl absetzen und das E3DC System ist passend konfiguriert.

Umgekehrt wird schwieriger, hier müsste evcc den Wert zyklisch per rscp pollen und seinen bufferSoc entsprechend setzen.

---

Hier die Zuordnung der Tags zum E3DC Display:

1. Lade-Priorität

   Dies ist der Tag BATTERY_BEFORE_CAR_MODE. 0 = erst Wallbox 1 = erst Batterie

Nur wenn dieser Tag 0 ist, dann kann man die folgenden Tags benutzen.

2. Im Sonnenmodus

   Dies ist das Tag BATTERY_TO_CAR_MODE. 0 = unterbunden 1= erlaubt Wenn dieses auf 1 ist, dann kann man WB_DISCHARGE_BAT_UNTIL verwenden

3. Bis SOC

   Dies ist das Tag WB_DISCHARGE_BAT_UNTIL. xx = Prozentwert

4. Im Mischmodus und während Haltezeit und Zeitfunktion Dies ist das Tag WALLBOX_ENFORCE_POWER_ASSIGNMENT. true = unterbunden false = erlaubt.

Hinweis: Wird BATTERY_BEFORE_CAR_MODE auf 1 gesetzt, dann werden vom E3DC System automatisch die Tags BATTERY_TO_CAR_MODE = 0 und WALLBOX_ENFORCE_POWER_ASSIGNMENT = 0 gesetzt.

[docolli]

Ich vermute mit diesen Tags würde man die Entladeleistung irgendwie limitieren können:

./e3dc '[["EMS_REQ_GET_POWER_SETTINGS","UChar8",1]]' | jq
{
  "EMS_GET_POWER_SETTINGS": {
    "EMS_POWER_LIMITS_USED": false,
    "EMS_MAX_CHARGE_POWER": 1500,
    "EMS_MAX_DISCHARGE_POWER": 1500,
    "EMS_DISCHARGE_START_POWER": 65,
    "EMS_POWERSAVE_ENABLED": true,
    "EMS_WEATHER_REGULATED_CHARGE_ENABLED": false,
    "EMS_WEATHER_FORECAST_MODE": 0
  }
}

Vermutlich müsste man EMS_MAX_CHARGE_POWER bzw. EMS_MAX_DISCHARGE_POWER setzen und dann mit EMS_POWER_LIMITS_USED aktivieren. Vielleicht kann @spali hier helfen und weiß genaueres. An meinem System möchte ich ungern einfach rumspielen und dann was wichtiges verstellen.

[spali]

Ich nutze diese Einstellungen per RSCP.... Übrigens zumindestens bei meiner im Web-GUI auch bedienbar unter Smart-Funktionen -> Betriebsbereich (hab ja die "billige" ohne Display):

{
  "EMS_GET_POWER_SETTINGS": {
    "EMS_POWER_LIMITS_USED": false,   // Betriebsbereich (false = Automatisch, true = manuell) -> bei manuell gelten die unteren Limitts
    "EMS_MAX_CHARGE_POWER": 1500, // Maximale Ladeleistung [W] -> kann ich zwischen 0 und 4500 setzen (weiss nicht ob es je nach Typ unterschiede gibt)
    "EMS_MAX_DISCHARGE_POWER": 1500, // Maximale Entladeleistung [W] -> kann ich zwischen 0 und 4500 setzen (weiss nicht ob es je nach Typ unterschiede gibt)
    "EMS_DISCHARGE_START_POWER": 65, // Untere Entladeschwelle [W] -> habe ich nie ganz verstanden... denke ab wann erst die Entladung wirklich beginnt.. vermutlich ab dann wird der Inverter eingestellt... ist aber nur Theorie... hab ich auf 60 was bei mir der Default ist.... kann man vermutlich komplett ignorieren
  }
}

Habe bis jetzt nie Probleme durch die Benutzung bekommen... einzig... das die Werte sich ab und an selber zurück zu stellen scheinen....

Update: setzen natürlich mittels EMS_REQ_SET_POWER_SETTINGS Container und nur die Werte darin übertragen die man ändern möchte. PS: EMS_POWERSAVE_ENABLED habe ich Zweck ebenfalls nie verstanden, aber auch kein nutzen.

[MrIngenieur]

Hi, falls das hilft: Ich habe die Entladesperre über die EVCC-iobroker Integration und die E3DC-iobroker Integration am Laufen. Aber das ist natürlich ein Notbehelf, wenns in EVCC direkt geht ist besser. Daher sind die benutzten Befehle vielleicht für euch hilfreich, zumal ich das sowohl für das Thema Batterieentladung als auch die Tibber-EVCC-Ladung programmiert habe (sonst zieht‘s einem die Batterie wieder leer, wenn EVCC Tibberladen macht, weil der Status weiterhin z.B. auf PV stehen bleibt und nicht auf Schnell/Now geht.):

async function Entladeleistung_berechnen() {
  if (((getState('evcc.0.loadpoint.1.status.mode').val == 'pv' || getState('evcc.0.loadpoint.1.status.mode').val == 'minpv' || getState('evcc.0.loadpoint.1.status.mode').val == 'off') && !getState('evcc.0.loadpoint.1.status.smartCostActive').val)) {
    setState('e3dc-rscp.0.EMS.MAX_DISCHARGE_POWER' /* Maximale Batterie-Entladeleistung (Betrag) */, 4500);
    setState('e3dc-rscp.0.EMS.POWER_LIMITS_USED' /* Leistungs-Limits aktiviert */, false);
  } else {
    setState('e3dc-rscp.0.EMS.MAX_DISCHARGE_POWER' /* Maximale Batterie-Entladeleistung (Betrag) */, 0);
    setState('e3dc-rscp.0.EMS.POWER_LIMITS_USED' /* Leistungs-Limits aktiviert */, true);
  }
}

Im wesentlichen nutze ich den Lademodus von EVCC (PV, Min+PV, etc), smartCostActive von EVCC (Tibber) und bei E3DC MAX_DISCHARGE_POWER und POWER_LIMITS_USED. MAX_DISCHARGE_POWER schalte ich auf Wert 0W, wenn keine Entladung stattfinden soll. MAX_DISCHARGE_POWER schalte ich auf Wert 4500W, wenn ich zurück in den Normalbetrieb gehen will, also auch Entladung erlaubt sein soll. 4500W ist hier spezifisch für mein System und entspricht dem max. Möglichen Entladeleistungswert. Kann bei anderen Systemen höher/niedriger sein. EMS.POWER_LIMITS_USED sollte man immer begleitend mit setzen, sonst übernimmt der E3DC-Speicher die neuen werte nicht, oder geht nicht zurück in den normalbetrieb.

Update Intervall E3DC ist bei mir auf 5 min eingestellt. An den Sperrzeiten habe ich nicht rumgestellt. Die Nutzung der Wallbox-Steuerung aus dem E3DC-System habe ich bisher nicht umgesetzt, da ich das lieber zentral über EVCC mache, bevor da noch ein System (E3DC) mit eigener Logik mit eingreift und dann komische Zustandskombinationen generiert. Die Funktion wird aufgerufen, d.h. Entladeleistung neu evaluiert, wenn

• EVCC-Modus loadpoint.1.status.mode geändert wurde,
• oder EVCC- loadpoint.1.status.smartCostActive geändert wurde
• oder EVCC- loadpoint.1.status.charging geändert wurde.