Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add E3DC native implementation #13413

Merged
merged 39 commits into from
Apr 27, 2024
Merged

Add E3DC native implementation #13413

merged 39 commits into from
Apr 27, 2024

Conversation

andig
Copy link
Member

@andig andig commented Apr 12, 2024

Fix #13403

@andig andig added the devices Specific device support label Apr 12, 2024
@andig andig marked this pull request as draft April 12, 2024 18:51
meter/e3dc.go Outdated Show resolved Hide resolved
@docolli
Copy link
Contributor

docolli commented Apr 20, 2024

bbc0f77 läuft auch nach dem Einbau von SendMultiple.

[main  ] INFO 2024/04/20 09:47:09 evcc 0.125.0 (bbc0f774)
[main  ] INFO 2024/04/20 09:47:09 using config file: c:\Daten\SW-Entwicklung\evcc\system\evcc\evcc.yaml
[main  ] INFO 2024/04/20 09:47:09 starting ui and api at :7070
[db    ] INFO 2024/04/20 09:47:09 using sqlite database: C:\Daten\SW-Entwicklung\evcc\system\evcc\evcc.db
time="2024-04-20T09:47:09+02:00" level=info msg="Connecting to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully connected to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="hiding auth request for security, use debug >= 99 to debug authentication"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully authenticated (level: AUTH_LEVEL_USER)"
[site  ] INFO 2024/04/20 09:47:09 site config:
[site  ] INFO 2024/04/20 09:47:09   meters:      grid ✓ pv ✓ battery ✓
[site  ] INFO 2024/04/20 09:47:09     grid:      power ✓ energy ✗ currents ✗
[site  ] INFO 2024/04/20 09:47:09     pv 1:      power ✓ energy ✗ currents ✗
[site  ] INFO 2024/04/20 09:47:09     battery 1: power ✓ energy ✗ currents ✗ soc ✓ capacity ✓
[lp-1  ] INFO 2024/04/20 09:47:09 loadpoint 1:
[lp-1  ] INFO 2024/04/20 09:47:09   mode:        off
[lp-1  ] INFO 2024/04/20 09:47:09   charger:     power ✓ energy ✗ currents ✗ phases ✗ wakeup ✗
[lp-1  ] INFO 2024/04/20 09:47:09   meters:      charge ✓
[lp-1  ] INFO 2024/04/20 09:47:09     charge:    power ✓ energy ✗ currents ✗
[site  ] WARN 2024/04/20 09:47:09 interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
time="2024-04-20T09:47:09+02:00" level=info msg="Connecting to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully connected to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="hiding auth request for security, use debug >= 99 to debug authentication"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully authenticated (level: AUTH_LEVEL_USER)"
time="2024-04-20T09:47:09+02:00" level=info msg="Connecting to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully connected to 192.168.1.121:5033"
time="2024-04-20T09:47:09+02:00" level=info msg="hiding auth request for security, use debug >= 99 to debug authentication"
time="2024-04-20T09:47:09+02:00" level=info msg="successfully authenticated (level: AUTH_LEVEL_USER)"
[lp-1  ] INFO 2024/04/20 09:47:09 car disconnected

Wie soll es weiter gehen? Kann/soll ich noch was testen?

@andig
Copy link
Member Author

andig commented Apr 25, 2024

Danke für den Hinweis- jetzt wird DEBUG gesetzt. Ich wundere mich allerdings weiterhin, dass im Nachhinein die rscp Library wieder etwas an den Logleveln ändert. Das ist zumindest ungewöhnlich.

@spali
Copy link

spali commented Apr 25, 2024

Ich wundere mich allerdings weiterhin, dass im Nachhinein die rscp Library wieder etwas an den Logleveln ändert. Das ist zumindest ungewöhnlich.

Das ist, dass die unteren Layers nichts vom Auth Request verstehen müssen... sprich ich setzte temporär das LogLevel auf INFO bevor ich den Auth Request absetze und direkt danach wieder zurück auf das original. Damit stelle ich sicher, dass der Auth Request mit Login-Infos nicht im Log landet auch wenn ich ein TRACE logging mache. Ansonsten müsste ich der "unteren" Schicht ja ein Flag oder so mitgeben bis runter wo ich die bytes des requests logge... Da finde ich es einfacher dies kurz im client zu überschreiben. Dies kann man nur explizit ausser kraft setzen wenn man das LogLevel auf 99 setzt. Du weisst ja wie schnell einem Nutzer das passieren kann.... hat ein Problem und klatscht das ganze log ins Issue und gut ist 😜 Man sieht ja den Bytes nicht auf Anhieb an, dass da Login infos drin sind. Und in dem Fall ist es ein Login das im Online Portal nutzbar ist, nicht nur Lokal.

@andig andig marked this pull request as ready for review April 25, 2024 14:48
@andig
Copy link
Member Author

andig commented Apr 25, 2024

Man sieht ja den Bytes nicht auf Anhieb an, dass da Login infos drin sind. Und in dem Fall ist es ein Login das im Online Portal nutzbar ist, nicht nur Lokal.

Good point. Bei evcc gibts das einfach nur gegen Passwort. Wer TRACE will und nutzt muss damit umgehen können.

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

Immer noch der data type mismatch Fehler:

evcc 0.125.0 (c3cdbef9)
[site  ] ERROR 2024/04/26 07:38:06 battery mode: message at index 1: expected *uint32 got int : value does not match data type

@andig
Copy link
Member Author

andig commented Apr 26, 2024

@spali ich habe jetzt durchgängig auf NewMessage umgestellt und verwende damit die Tags die automatisch abgeleitet werden. Wie wird mit den Typen in value umgegangen- die müssen passen? Wäre es sonst denkbar, dass z.B. ein int übergeben würde, der dann aber je nach Tag bei NewMessage mit etwas Magie (cast.ToUint32E) in den Wunschtyp verwandelt würde? Es gibt sonst keine Möglichkeit, die Information extern programmatisch abzugreifen, oder?

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

evcc 0.125.0 (9e12027)
[site ] ERROR 2024/04/26 08:44:50 battery mode: message at index 1: expected *uint32 got int : value does not match data type
🤔

@andig
Copy link
Member Author

andig commented Apr 26, 2024

Ich denke es geht um diese Änderung:

// alt

		container = append(container, rscp.Message{
			Tag:      rscp.EMS_MAX_DISCHARGE_POWER,
			DataType: rscp.Uint32,
			Value:    limit,
		})

// neu
		contents = append(contents, *rscp.NewMessage(rscp.EMS_MAX_DISCHARGE_POWER, limit))

Mir ist völlig unklar, warum ein uint32 jetzt hier ein Problem sein sollte?

@docolli magst Du das bitte nochmal mit --log trace machen, vielleicht wirds dann ja klarer?

Ansonsten hilft nur, mal mit dem Debugger durchzugehen und/oder info@evcc.io SSH Zugang zu geben.

@spali
Copy link

spali commented Apr 26, 2024

@spali ich habe jetzt durchgängig auf NewMessage umgestellt und verwende damit die Tags die automatisch abgeleitet werden. Wie wird mit den Typen in value umgegangen- die müssen passen? Wäre es sonst denkbar, dass z.B. ein int übergeben würde, der dann aber je nach Tag bei NewMessage mit etwas Magie (cast.ToUint32E) in den Wunschtyp verwandelt würde? Es gibt sonst keine Möglichkeit, die Information extern programmatisch abzugreifen, oder?

Denke @docolli hat dir die Antwort schon gegeben 😉
Leider nein, das habe ich nicht umgesetzt für NewMessage.
Ich mache im Prinzip für das commandline utility bereits so was ähnliches, da json da ja kein Unterschied macht.
Da erstelle ich mittels ein Pointer Interface auf den korrekten Typ basierend auf dem DataType und lasse go casten. https://github.com/spali/go-rscp/blob/9ee4bc6c03c13167b1f0eb30e9ffc5c009346285/rscp/datatype_new.go#L42C5-L42C12
Das funktioniert natürlich nur für einfachen Types... bei komplexeren Types fange ich dies vorher ab. Darum hab ich diese Funktion auch nicht "öffentlich" gemacht. Darfst aber gerne den Code kopieren und verwenden.

Mir ist völlig unklar, warum ein uint32 jetzt hier ein Problem sein sollte?

Index in der Fehlermeldung referenziert den Index im Message Array... sprich geht um die 2. Message. Wenn ich das richtig gesehen habe auf die schnelle, betrifft dies EMS_REQ_START_MANUAL_CHARGE welcher du mit amount als int übergibst anstatt uint32. Bei EMS_MAX_DISCHARGE_POWER sieht es korrekt aus.

@andig
Copy link
Member Author

andig commented Apr 26, 2024

Ich mache im Prinzip für das commandline utility bereits so was ähnliches

Ahhh, nice- genau das meinte ich. Danke für den Hinweis!

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

Die Fehlermeldung ist weg, aber es ändert sich nichts im Zustand des E3DC Systems. Hier --log trace:

time="2024-04-26T16:55:41+02:00" level=debug msg="
write [{ EMS_REQ_SET_POWER_SETTINGS Container [{ EMS_POWER_LIMITS_USED Bool false }] } { EMS_REQ_START_MANUAL_CHARGE Uint32 0 }]"

Da stimmt doch die Verschachtelung der Befehle nicht, oder? Hier vom go-rscp CMD Tool:
write [{ EMS_REQ_SET_POWER_SETTINGS Container [{ EMS_POWER_LIMITS_USED Bool false } { EMS_MAX_DISCHARGE_POWER Uint32 500 }] }]

@andig
Copy link
Member Author

andig commented Apr 26, 2024

Was sollte das denn ändern?

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

Sorry, stimmt schon so. 🙈
Ich musste nur vorher im E3DC System das Limit auf true setzen, dann setzt evcc das wieder zurück.

Vor Aktivierung Battery Control:

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

Nach Aktivierung BatteryControl in evcc:

msg="write [{ EMS_REQ_SET_POWER_SETTINGS Container [{ EMS_POWER_LIMITS_USED Bool false }] } { EMS_REQ_START_MANUAL_CHARGE Uint32 0 }]"
set battery mode: normal
./e3dc '[["EMS_REQ_GET_POWER_SETTINGS","None","Nil"]]' | jq
{
  "EMS_GET_POWER_SETTINGS": {
    "EMS_POWER_LIMITS_USED": false,
    "EMS_MAX_CHARGE_POWER": 4500,
    "EMS_MAX_DISCHARGE_POWER": 4500,
    "EMS_DISCHARGE_START_POWER": 65,
    "EMS_POWERSAVE_ENABLED": true,
    "EMS_WEATHER_REGULATED_CHARGE_ENABLED": false,
    "EMS_WEATHER_FORECAST_MODE": 0
  }
}

Aktuell ist das Auto unterwegs, kann also Wallboxladung mit/ohne BatteryControl noch nicht testen.

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

Auto ist da, Laden "Schnell" mit BatterieControl:

write [{ EMS_REQ_SET_POWER_SETTINGS Container [{ EMS_POWER_LIMITS_USED Bool true } { EMS_MAX_DISCHARGE_POWER Uint32 0 }] } { EMS_REQ_START_MANUAL_CHARGE Uint32 0 }]"
[site  ] DEBUG 2024/04/26 18:02:50 set battery mode: hold

Ja, Discharge Limit ist gesetzt auf "0" und aktiv!

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

@docolli
Copy link
Contributor

docolli commented Apr 26, 2024

BatteryControl in evcc deaktiviert.

write [{ EMS_REQ_SET_POWER_SETTINGS Container [{ EMS_POWER_LIMITS_USED Bool false }] } { EMS_REQ_START_MANUAL_CHARGE Uint32 0 }]"
[site  ] DEBUG 2024/04/26 18:06:12 set battery mode: normal

Klappt auch!

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

@andig andig merged commit ce97c63 into master Apr 27, 2024
7 checks passed
@andig andig deleted the feat/e3dc branch April 27, 2024 08:28
@docolli
Copy link
Contributor

docolli commented Apr 27, 2024

Testung manuelles Laden mit master:

 ./e3dc '[["EMS_REQ_GET_MANUAL_CHARGE","None","Nil"]]' | jq
{
  "EMS_GET_MANUAL_CHARGE": {
    "EMS_MANUAL_CHARGE_ENERGY": 10000,
    "EMS_MANUAL_CHARGE_START_COUNTER": 1714207146087,
    "EMS_MANUAL_CHARGE_ACTIVE": true,
    "EMS_MANUAL_CHARGE_ENERGY_COUNTER": 158.24878416666684,
    "EMS_MANUAL_CHARGE_LASTSTART": "2024-04-27T08:39:06.087112Z"
  }
}

Sieht auch gut aus, er hat die fix im Code hinterlegten 10kWh gesetzt und lädt.

@andig
Copy link
Member Author

andig commented Apr 27, 2024

Vmtl. müssen wir noch den Fehler auswerten falls das 2x pro Nacht passieren sollte, aber erstmal Erfahrungen sammeln. Tausend Dank an @docolli und @spali!

@andig
Copy link
Member Author

andig commented May 2, 2024

@spali release has been published.

@spali
Copy link

spali commented May 2, 2024

@andig pushed also the final v2.0.0 if you want to switch the tag by next chance. only additional commit to beta5 is regarding a github workflow, so no go changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devices Specific device support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

e3DC Entladesperrzeiten nutzen
4 participants