Add Delta chargers

[mirgonet]

Fixes #10864

Tested with tcpip converter. Should also work with direct RS485 connection but I cant test it. Will try to improve the plugin by using additional registers that I was not aware of until today.

[premultiply]

@mirgonet Kannst du bitte mal die Quelle der Registerbeschreibung teilen?
Ich hab da nur eine Powerpoint wo nur ein Bruchteil der Register drauf zu finden ist.

[mirgonet]

@mirgonet Kannst du bitte mal die Quelle der Registerbeschreibung teilen? Ich hab da nur eine Powerpoint wo nur ein Bruchteil der Register drauf zu finden ist.

@premultiply Klar, kein Problem. Die Originalquelle ist mir nicht bekannt, habe folgendes PDF im PV-Forum gefunden:

https://www.photovoltaikforum.com/core/attachment/408989-evcs-modbus-register-table-v1-1-working-1-pdf/

[premultiply]

Ich hab mal ein paar kleine Änderungen vorgenommen. Bitte mal testen.

[premultiply]

Kannst du auch mal bitte interessehalber evcc charger --log trace --diagnose laufen lassen?

Klappt das ansonsten funktioniell so alles wie erwartet?

[premultiply]

@andig Ich bin mir bei dem ganzen Mutex locking/unlocking immer etwas unsicher. Schau dir das mal bitte näher an.

[andig]

Das ist wie ein Stack. Jedes Lock dass du drauf legst muss genau einmal wieder abgeräumt werden.

[premultiply]

Das ist schon klar, die Frage zielt eher darauf ab ob es das hier überall so braucht?

[andig]

curr und enabled werden asynchron verwendet. Beide sind gegen lesen/schreiben aus der anderen Goroutine gelocked. Sieht alles richtig aus.

[mirgonet]

Kannst du auch mal bitte interessehalber evcc charger --log trace --diagnose laufen lassen?

@premultiply Klar, kein Problem:

./evcc charger --log trace --diagnose
[main  ] INFO 2023/12/24 13:35:19 evcc 1fea2863 (1fea2863)
[main  ] INFO 2023/12/24 13:35:19 using config file: /home/mirko/evcc/evcc.yaml
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 01 00 00 00 06 01 03 00 ca 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 01 00 00 00 05 01 03 02 02 58
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 02 00 00 00 06 01 04 03 ed 00 02
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 02 00 00 00 07 01 04 04 00 00 00 00
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 03 00 00 00 06 01 04 03 f9 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 03 00 00 00 05 01 04 02 00 00
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 04 00 00 00 06 01 04 03 e9 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 04 00 00 00 05 01 04 02 00 02
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 05 00 00 00 06 01 03 06 40 00 02
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 05 00 00 00 07 01 03 04 00 00 1a f4
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 06 00 00 00 06 01 04 03 fb 00 02
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 06 00 00 00 07 01 04 04 00 00 00 00
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 07 00 00 00 06 01 04 04 4c 00 06
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 07 00 00 00 0f 01 04 0c 00 00 00 00 00 00 00 00 00 00 00 00
Power:         0W
Soc:           0%
Charge status: B
Enabled:       true
Charged:       0.0kWh
Identifier:    <none>
Diagnostic dump:
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 08 00 00 00 06 01 04 00 64 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 08 00 00 00 05 01 04 02 00 01
        State:  1
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 09 00 00 00 06 01 04 00 65 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 09 00 00 00 05 01 04 02 05 14
        Version:        1300
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 0a 00 00 00 06 01 04 00 66 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 0a 00 00 00 05 01 04 02 00 01
        EVSE Count:     1
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 0b 00 00 00 06 01 04 00 67 00 01
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 0b 00 00 00 05 01 04 02 00 00
        Error:  0
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 0c 00 00 00 06 01 04 00 6e 00 14
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 0c 00 00 00 2b 01 04 28 4a 56 34 32 31 34 35 30 34 36 34 34 57 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        Serial: JV4214504644WE
[delta ] TRACE 2023/12/24 13:35:19 modbus: send 00 0d 00 00 00 06 01 04 00 82 00 14
[delta ] TRACE 2023/12/24 13:35:19 modbus: recv 00 0d 00 00 00 2b 01 04 28 45 49 41 57 2d 45 31 31 4b 54 42 45 35 41 30 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        Model:  EIAW-E11KTBE5A02

Klappt das ansonsten funktioniell so alles wie erwartet?

Es gibt jedenfalls keine Probleme mehr mit dem sync. Leider funktioniert das VW Connect Zeugs gerade nicht und daher konnte ich noch nicht probieren wie sich der Code beim Laden verhält.

[mirgonet]

Leider funktioniert der SOC von meinem Auto gerade nicht, daher ist das Testen weiter schwierig. Mir sind aber noch folgende Punkte aufgefallen:

• Wenn das Auto weniger Phasen als der Loadpoint unterstützt wurde die Ladeleistung nicht korrekt reduziert. Habe ich mit c4802d6 gefixt, so das die Phasen des vehicles berücksichtigt werden. Gerne mal drüberschauen, bei mir funktioniert es so (Loadpoint 3p, Auto 2p).

• Die ChargedEnergy war immer 0. Ich habe die Reihenfolge von Cast und Division und den Cast-Typ geändert. Funktioniert jetzt (1e3e7de).

• Im "Min + PV" Modus tauchen im Log komische Einträge auf, die ich nicht richtig einordnen kann: [lp-1 ] DEBUG 2023/12/24 14:53:18 pv charge current: 0A = 6A + -6.45A (2968W @ 2p) Eigentlich macht doch die Watt-Angabe hier gar keinen Sinn oder? PV ist 0 und er Lädt danach mit 6A wie er soll. Die 2968W müssten ja eigentlich -2968W (als möglicher Beitrag der PV) sein oder verstehe ich das falsch?

• Das Setzen des maximalen Ladestroms in der GUI hat keine Auswirkungen (experimentelles Feature)

[premultiply]

Wenn das Auto weniger Phasen als der Loadpoint unterstützt wurde die Ladeleistung nicht korrekt reduziert. Habe ich mit c4802d6 gefixt. Gerne mal drüberschauen, bei mir funktioniert es so (Loadpoint 3p, Auto 2p).

Diese Berechnungen gibt es eigentlich alle schon im LP. /cc @andig vgl. Huawei

[andig]

Stimmt. Tatsächlich gibt GetPhases() die Konfiguration des Loadpoints zurück. Die tatsächlich aktiven Phasen kennt activePhases(), das ist momentan nicht extern erreichbar. Sollten wir das raus reichen?

[premultiply]

Würde imho Sinn machen. Alternativ direkt eine Leistungsvorgabe analog MaxCurrent().
Hatten wir da nicht schon mal irgendwas angefangen gehabt?

[andig]

Das sollte mal #7338 werden.

[premultiply]

@andig Im Prinzip fehlt hier jetzt nur noch der Zugriff auf lp.activePhases() als ToDo

[premultiply]

Das war für mich ein bisschen schnell gemerged.

• SoC raus ist unnötig, das kann man über eine Condition abfangen. Notfalls mit Wert > 0.0 oder Modbus-Fehler. Für DC-Charger erforderlich. Die Doku ist dazu übrigens nicht eindeutig.
• Da gehört dann auch der im Template hinterlegte ISO-Support dazu.
• Default-Baud im Template nun falsch? 19200 statt 115200?

Ich erstelle einen Fix-PR.

[andig]

Unterstrützen wir DC Charger und gibt es irgendjemanden der das testen könnte? Sonst wäre das für mich auch ok so zu lassen.

[mirgonet]

* SoC raus ist unnötig, das kann man über eine Condition abfangen. Notfalls mit Wert > 0.0 oder Modbus-Fehler. Für DC-Charger erforderlich. Die Doku ist dazu übrigens nicht eindeutig.

* Da gehört dann auch der im Template hinterlegte ISO-Support dazu.

@premultiply Ich habe das mit dem SoC jetzt nochmal ausprobiert. Das Problem ist einfach, dass die WB immer SoC 0 meldet (keinen Modbus Fehler) und damit den korrekten Wert der vom vehicle kommt überschreibt. Habe da erst lange gesucht, weil ich dachte es wäre ein Problem mit dem id Plugin oder der VW API, aber evcc --vehicle gibt den richtigen SoC aus. Im Betrieb ist der SoC dann immer 0 (km Stand etc stimmen aber). Somit wäre das Plugin mit dem SoC Feature aktuell nicht an AC Wallboxen nutzbar. Im Datenblatt steht ja auch State of Charge (not available for AC).

Mir fallen spontan folgende Lösungsansätze ein:

• Der Loadpoint ignoriert den SoC von 0% und verwendet einfach den Wert vom vehicle. Was ist dann aber wenn das vehicle wirklich mal leer ist und 0% meldet?
• Das Plugin gibt für die AC Wallboxen als SoC nil, -1 oder eine magic number zurück andem der Loadpoint erkennt, dass das Plugin mit der aktuellen WB gar keinen SoC unterstützt. Hierzu müsste das Plugin die Wallbox erkennen können (wäre anhand des deltaRegModel möglich, aber wir kennen nicht alle Versionstrings.

Beide "Lösungen" sind meiner Meinung nach eher Workarounds und erzeugen Komplexität mit einem sehr geringen Mehrwert. Ich habe nur mit AC MAX Basic getestet und hoffe das bald noch jemand mit der AC MAX Smart testen kann. Glaube nicht das wir wen finden der DC Charger von Delta bestitz und das testen will. Daher habe ich den SoC Support entfernt, weil es für mich die sinnvollste Lösung mit überschaubarem Nachteil ist.

Wenn aber wirklich ein Support für die DC Charger von Delta sinnvoll und nötig ist würde ich persönlich zwei Plugins draus machen. Funktionell könnten diese dann identisch sein, nur das DeltaDC zusätzlich noch das SoC Interface implementiert.

Je nachdem wie entschieden wird müssten der "SLIM Charger" und der "Ultra Fast Charger" noch aus dem Delta Template raus.

* Default-Baud im Template nun falsch? 19200 statt 115200?

Laut Datenblatt hat ModbusRTU 115200, bei OCPP sind für ModbusRTU dann 19200 angegeben. Wenn ich mich richtig erinnere war meine Basic von Werk auf 115200 und nach FW Update dann 19200. Nehme die Tage noch eine weitere in Betrieb, da werde ich nochmal genau drauf achten. Aktuell würde ich sagen das 115200 konform zum Datenblatt ist.

[premultiply]

Bei Wert 0.0 oder Lesefehler wird dann "Fehler, nicht implementiert" zurückgegeben. Vgl. EEBUS.

[mirgonet]

Ok, hab ich auch mal ausprobiert. Wenn man ErrNotAvailable mit dem SoC 0% zurückgibt scheint es zu funktionieren. Einfach nur bei SoC == 0.0 dann den Error zurückzugeben finde ich aber keine sinnvolle Lösung. SoC 0% ist ja ein valider Wert. Wenn dann müsste man schon eine Erkennung des WB Modells oder zumindest eine Option in der Konfiguration vorsehen und danach steuern ob der SoC abgefragt wird (wir bei EEBUS ja scheinbar auch so gemacht !socSupported).

Auch wenn ich der Meinung bin, dass wir hier zusätzliche Fehlerquellen einbauen um eine Funktion abzubilden die wir weder Testen können noch nutzen werden habe ich mich mal an eine Modellerkennung gemacht:

func (wb *Delta) isSocSupported() (bool, error) {
	b, err := wb.conn.ReadInputRegisters(deltaRegModel, 2)
	if err != nil {
		return false, api.ErrNotAvailable
	}

	chargerModel := bytesAsString(b)
	// SoC not supported by Delta AC chargers
	// EIAW - AC MAX (Basic & Smart)
	// EVPT - AC Charger (CSN interface)
	// EVPE - AC Charger (Type1/2 interface)
	if chargerModel == "EIAW" || chargerModel == "EVPT" || chargerModel == "EVPE" {
		return false, nil
	}
	return true, nil
}

Die Modelltypen stammen aus Google, mit meiner AC MAX Basic scheints zu funktionieren. Mir wäre es auch lieber die DC Charger auf eine Whitelist zu setzen, aber das kann ich wieder nicht testen und mir liegt keine vollständige Liste vor.

Wie machen wir hier jetzt weiter @premultiply / @andig ? Soll ich einen neuen PR öffnen oder lassen wir den SoC raus?

[andig]

Charger Modell reicht nicht. Es muss ermittelt werden, ob eine ISO Kommunikation stattfindet. Zumindest die OpenWB rückt diese Information raus.

[premultiply]

Machs doch nicht so kompliziert.

SoC 0.0% kommt in der Praxis quasi nie vor.
Und wenn der Charger DANN mal kurz keinen SoC liefert ist das auch nicht schlimm. Wenige Augenblicke später wären es schon wieder 0.1% oder eher viel mehr.