Add chargeable battery charger

[andig]

Refs #10379

Experimental

[Hofyyy]

Hast du hier ein config beispiel wie ich das einschalten würde? und könnte es hier ein testing docker geben :-9

[andig]

Mehr Config ists nicht: https://github.com/evcc-io/evcc/pull/10814/files#diff-4feb564f6d486dba3b596f30d97336a633b098ffd574222cbce9f95579c00b5aR31. Einfach den Namen des Akkus angeben. Image kannst Du selber bauen ;)

[mucki12]

Sorry, wahrscheinlich die falsche Frage am falschen Ort:
Kommt das noch zB in die nightly Version zum Testen? Bin leider beim erstellen eigener Versionen vollkommen am Limit meiner Fähigkeiten :-)
Würde das gerne Testen.

[vkr2791]

... Würde das gerne Testen.

Beim Testen wäre ich auch dabei, wenn es ein Docker-Image gäbe ... (Kostal Plenticore, BYD HVS)

[andig]

Ihr könnt evcc/evcc:testing verwenden.

[mucki12]

Vielen Dank für den Test-Docker.

Einfach den Namen des Akkus angeben.

Könntest du mir noch einen Tipp geben an welcher Stelle?

[mucki12]

Ich hätte jetzt vermutet, dass man einen neuen Charger (Template?) + Loadpoint konfigurieren muss?

meters:
  - type: template
    template: huawei-dongle-powersensor 
    id: 1  
    host: 192.168.2.168  
    port: 502  
    usage: battery  
    modbus: tcpip  
    timeout: 15s  
    name: battery1
    capacity: 10

chargers:
- type: template
  template: battery 
  name: battery1

loadpoints:
- title: Luna Test
  charger: battery1

Ergibt folgende Fehlermeldung:
FATAL 2024/03/20 13:26:39 cannot create charger 'battery1': cannot create charger type 'template': template not found: battery

Irgendwo bin ich in der Konfiguration daher falsch abgebogen :-)

[andig]

Der PR enthält kein Template. Also type: battery.

[mucki12]

Danke für den Hinweis, das hatte ich als erstes probiert. Aber name: sollte schon name: vom battery meter entsprechen?
Also so:

meters:
  - type: template
    template: huawei-dongle-powersensor 
    id: 1  
    host: 192.168.2.168  
    port: 502  
    usage: battery  
    modbus: tcpip  
    timeout: 15s  
    name: battery1
    capacity: 10

chargers:
- type: battery
  name: battery1

loadpoints:
- title: Luna Test
  charger: battery1

Ergibt:
FATAL 2024/03/20 15:26:25 cannot create charger 'battery1': cannot create charger type 'battery': not found:

evcc 0.124.10 (a72044b)

[mucki12]

@Hofyyy @vkr2791
Konntet ihr den testing Docker schon mal installieren und das ebenfalls testen? Wenn ja, kommt ihr da weiter?

[vkr2791]

Hi, bis jetzt hatte ich noch keine Zeit, aber auch noch mal zum Verständnis:
Aktuell habe ich evcc quasi im Standard konfiguriert (PV + Batterie + Charger (go-e) + Auto).
Wenn ich das nun richtig verstehe, um die PV-Batterie zu laden (z.B. Nachts) muss man nun einen zusätzlichen Charger einrichten (Type Battery) und das in einem Loadpoint verknüpfen, korrekt?
Mal sehen ob ich heute Abend Zeit dafür habe das auszuprobieren.

[mucki12]

@vkr2791
So hätte ich es zumindest verstanden. Bin gespannt auf deinen Test. Vielleicht habe ich in der Konfiguration einfach einen Fehler gemacht und du kannst dann ja mal deine posten.

[andig]

Schau mal hier: https://github.com/evcc-io/evcc/pull/10814/files#diff-4feb564f6d486dba3b596f30d97336a633b098ffd574222cbce9f95579c00b5aR31. Du musst Deinem battery1 charger auch noch verraten, welche Batterie er den laden soll ;)

[mucki12]

Ich kleines Dummerchen dachte, dass wäre durch den Namen schon erledigt :-)
Umgebaut:

meters:
  - type: template
    template: huawei-dongle-powersensor 
    id: 1  
    host: 192.168.2.168  
    port: 502  
    usage: battery  
    modbus: tcpip  
    timeout: 15s  
    name: battery
    capacity: 10

chargers:
- type: battery
  name: lunacharger
  battery: battery

loadpoints:
- title: LUNA
  charger: lunacharger

Damit komme ich dann schon mal weiter, aber der Container beendet sich:
battery.log

Aber ehrlich gesagt bin ich nicht fit genug um den Code so zu lesen ob nicht doch noch etwas in der Konfiguration fehlt.

[vkr2791]

Hi, ich habe nun auch mal das Image "testing" installiert und bekomme auch ein "Segmentation violation" Error, wenn ich mich recht erinnere sind das doch Pointer-Fehler im Speicher ...
Hier das LOG und das YAML:
panic_log..txt
evcc_anonymisiert.yaml.txt

[andig]

Ist behoben ;)

[andig]

Disclaimer: Also das ganze ist ein (von mir nicht durchdachtes Experiment).

Warnmeldungen: „LUNA: charge power must not be negative:“

Aktueller Build dreht das Vorzeichen nochmal um. Bin allerdings nicht sicher ob das reicht oder richtig ist. Evtl. müssen wir da auch auf 0 cappen.

Wenn man auf Aus wechselt

Schaue ich nochmal an

Die von evcc korrekt gesetzten Parameter (AC-Laden ein / forcible charge an / 2500W / 1 Minute) werden korrekt angenommen, aber der Huawei Luna braucht dann über eine halbe Stunde um aus dem Hibernation Mode aufzuwachen und dann auch wirklich zu reagieren.

Ok, Einzelthema. Evtl. kann man den noch irgendwie anpingen? Dafür dann bitte neues Issue.

[andig]

Ach ja- wenn man das nutzt darf aktuell natürlich nicht Battery Control aktiv sein. Denn der würde beim Laden eines Speichers (mindestens by "now") ja sofort auf hold schalten womit dann genau nicht mehr geladen würde :O.

[mucki12]

Mit meiner Hauptinstallation für evcc lade ich den Speicher mit einem Fake Loadpoint und diversen Automationen im Hintergrund. Hier fange ich eine eventuelle aktive Batteriesteuerung seitens evcc ab und deaktiviere diese bevor der Ladevorgang beginnt über die API. Das Hauptproblem ist hier ebenfalls die Anzeige der Ladeströme.

Das Sleep Problem mit Huawei muss nicht weiter verfolgt werden. Eine Beschleunigung des Aufwachens ist nicht möglich und man muss damit einfach leben ;)

Frage ist halt wo es hingehen soll. Angenommen die Ladeströme können korrekt visualisiert werden… sollte der Loadpoint grundsätzlich anders angezeigt werden? Min+pv ist ja im Prinzip über und pv ist für die Nutzung von ausschließlich smarten Netzladen + Planer auch nicht mehr der richtige Begriff.

Teste die Erweiterungen am nächsten Wochenende.

[vkr2791]

Hi
leider komm ich ja mit dem Kostal Plenticore hier nicht zum Ziel ggf. müsste jemand mit mehr Modbus-Erfahrung ins Testing => vielleicht @deadrabbit87 ???
Grundsätzlich fände ich ein cooles Features die Batterie gesteuert über evcc auch z.B. Nachts mal zu laden, aber dazu sollte sich dann noch einiges an der GUI ändern wie auch schon @mucki12 geschrieben hat.
Das ganze in der YAML so zu konfigurieren finden ich OK, aber der neue Loadpoint ist ja dann schon etwas spezielles und benötigt Extra-Features und sollte dann nicht so dargestellt werden, ggf. sollte er dann irgendwie eingeklappt oder versteckt sein ober über die "Batterieeinstellungen" erreichbar sein.

[andig]

Das ist eh klar. Hier gehts erstmal nur um Machbarkeit. Wir haben nichtmal festgelegt, ob wir das wirklich als Charger machen wollen.

[deadrabbit87]

Ich hab mir das heute mal angesehen. Kostal kann gar nicht funktionieren, weil das laden hier nicht im meter-Template implementiert ist.

Geschrieben wird nur Register 1042 was für den minSoc steht. Wird dieser hochgesetzt, lädt der Kostal nicht.

Eine Möglichkeit den Plenticore zum laden zu bewegen, wäre Register 1028.

Hier kann man %-Werte schreiben. Bei -100% beginnt er mit seiner technisch max. möglichen Leistung aus dem Netz zu laden.

Im Falle meiner BYD 10.2 HVS Battery sind das ~5,2 kW.

Ich kann mich mal dran machen, das template anzupassen... Kann aber nix versprechen, ob ich das auch hin kriege...

[vkr2791]

Ich kann mich mal dran machen, das template anzupassen... Kann aber nix versprechen, ob ich das auch hin kriege...

Das wäre ein Traum, danke :-)

[vkr2791]

@deadrabbit87 : Ich mache meine ersten Gehversuche auf Modbus und versuche gerade mal das Register 1028 anzusprechen. Dabei ist nun selbstverständlich evcc als Modbus-Master deaktiviert, damit es nicht dazwischen funkt.

Mit einem Wert von "10" entlädt die Batterie (BYD 7,7) mit ca. 400 Watt,
mit anderen positiven Werten bekomme ich entsprechend andere Entlade-Leistungen hin:

Wenn ich aber versuche mit negativen Werten zu arbeiten, z.B. "-50" bekomme ich eine Fehlermeldung,
auch ein umstellen des Signed-Flags hilft nicht:

Die weiteren QModMaster-Einstellungen sind noch:

[deadrabbit87]

Du brauchst FC 10 und nicht 6 für single. Dann musst du zwei Register schreiben.

Außerdem ist der Wert float. Siehe auch die Doku von Kostal.

Damit geht es dann.

Problem ist nur, wie man von charge wieder die Kostal interne Regelung aktiviert.

Ich hab festgestellt, wenn man 1028 mit -100 beschreibt, entlädt er solange bis die Batterie leer ist solange noch Modbuskommunikation läuft.

So sähe es mit mbpoll und dem Register für den minSoc aus:

 mbpoll 172.16.10.20 -a 71 -r 1042 -0 -p 1502 -1 -t 4:float
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [71]
                        start reference = 1042, count = 1
Communication.........: 172.16.10.20, port 1502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 32-bit float (little endian), output (holding) register table

-- Polling slave 71...
[1042]:         5

Das schreiben geht dann z.B. so für 10 % minsoc:
mbpoll 172.16.10.20 -a 71 -r 1042 -0 -p 1502 -1 -t 4:float 10

[vkr2791]

Danke für das Oster-Geschenk :-)

Mit dem QModMaster bekomme ich es nun auch hin, dass die Batterie lädt:

Mit mbpoll probiere ich das auch mal aus, das wäre ja dann eine gute Möglichkeit eine kleine Script-Automatisierung zu bauen, solange es evcc noch nicht unterstützen würde.

Aber in der Tat stelle ich auch fest, das wenn man nun die Verbindung zwischen dem Plenticore und dem QModMaster trennt, er fleißig weiter bei der Einstellung z.B. -10% bleibt und auch weiterhin "Ext. Batteriesteuerung aktiv" anzeigt, auch wenn das Timeout für die ext. Batteriesteuerung überschritten ist.
ABER wie ich nun feststellen konnte, lag das daran, das evcc noch im Hintergrund an war und wohl noch eine ModBus-Master-Verbindung zum Plenticore offen hat.

Ich habe nun mein evcc-docker runtergefahren und den gleichen Test noch mal gemacht:
-10% im 1 Sekunden-Intervall gesetzt => Batterie lädt
Verbindung zw. Modbus-Master (KModMaster) und dem Plenticore getrennt
Timeout abgewartet (60s) => interne Batteriesteuerung hat wieder übernommen

Also wäre doch eine Lösung zu deiner Aussage:
> Problem ist nur, wie man von charge wieder die Kostal interne Regelung aktiviert.
einfach für mindestens 60s (max. Plenticore-Timeout für die ext. Batteriesteuerung)
die ModBus-Verbindung zu trennen, dann ist man kurz auf der internen Batteriesteuerung
und kann dann wieder extern weiter steuern.

[deadrabbit87]

Also wäre doch eine Lösung zu deiner Aussage:
> Problem ist nur, wie man von charge wieder die Kostal interne Regelung aktiviert.
einfach für mindestens 60s (max. Plenticore-Timeout für die ext. Batteriesteuerung)
die ModBus-Verbindung zu trennen, dann ist man kurz auf der internen Batteriesteuerung
und kann dann wieder extern weiter steuern.

Ja, aber dazu verstehe ich golang und die templates aktuell noch zu wenig, ob und wie das umzusetzen wäre. Eventuell kann ja @andig einen Tipp geben....

[mucki12]

@andig
Bin wieder da und habe mal die Testing Docker Version neu gezogen (evcc 0.124.10 642b666) und einen Ladevorgang mit "schnell" angestossen.

Log:
battery-4.log

Wie schon zuvor lädt der Hausspeicher jetzt zuverlässig mit dem Modus charge.
" charger logic error: disabled but charging" ist noch teilweise zu sehen. Teilweise werden die "normalen" Ladevorgänge des Hausspeichers auch dem Ladepunkt und dem Hausspeicher zugeordnet (beim tatsächlichen Laden mit evcc ebenso).

Screenshots:

[andig]

charger logic error: disabled but charging

Sollte jetzt behoben sein.

[mucki12]

@andig
Vielen Dank - die Fehlermeldung ist jetzt weg.

Ich weiß natürlich nicht wie/wo/ob es weiter geht, aber hier mal meine 2 cents:

Für die Anzeige der Leistung würde ich mir folgendes wünschen (ohne genau zu wissen, was technisch möglich ist):

• Die Leistung wird „unten“ beim loadpoint nur angezeigt, wenn der Modus charge aktiv ist (wenn irgendwie möglich sogar nur der Teil der Leistung, der aus dem Netz kommt)
• „Oben“ wird die Leistung beim Ladepunkt gar nicht angezeigt (ist ja bei „Batterie laden“ enthalten - damit würde auch wieder das „T-Konto“ passen)

Für die grundsätzliche Nutzung wären aus meiner Sicht die Weiterverfolgung von zwei bereits diskutierten Erweiterungen sinnvoll:

• Möglichkeit der Berücksichtigung der PV-Vorhersage für den nächsten Tag - Add Solcast #9454
• Eventuell Darstellung des Hausspeichers als Mini Loadpoint (allerdings mit SoC)? - Mini Loadpoints (UI Sketch) #7236

Sobald aber erst einmal der grundlegende Umgang mit der Leistung geklärt ist, könnte das meiner Meinung nach gerne in die normalen evcc Versionen. Dürfte ja bei Nichtnutzung erst einmal nicht schaden?

[andig]

Die Leistung wird „unten“ beim loadpoint nur angezeigt, wenn der Modus charge aktiv ist (wenn irgendwie möglich sogar nur der Teil der Leistung, der aus dem Netz kommt)

Das ist prinzipbedingt. Würden wir sie immer ausgäben käme es wieder zu:

charger logic error: disabled but charging