NEWS
[Frage] Realisierung Adapter UDP Keba Wallbox
-
Habe die Version gerade von git gezogen und mit einer kleinen Ladung getestet. Nach erreichen dieser 500Wh, stop die Ladung, aber die Log-Ausgabe das eine Ladvorgang gestartet wird, wird ausgegeben.
2023-12-07 17:56:07.715 - [32minfo[39m: kecontact.0 (989012) change pause status of wallbox from true to false 2023-12-07 17:56:16.864 - [32minfo[39m: kecontact.0 (989012) change of photovoltaics automatic from true to false 2023-12-07 17:56:17.527 - [32minfo[39m: kecontact.0 (989012) updating X2 for switch of phases from 0 to 1... 2023-12-07 17:56:17.527 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 17:57:04.988 - [32minfo[39m: kecontact.0 (989012) vehicle (re)starts to charge 2023-12-07 18:00:19.993 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:00:49.996 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:01:19.979 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:01:49.999 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:02:19.997 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:02:49.984 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:03:00.642 - [32minfo[39m: kecontact.0 (989012) Loglevel changed from "info" to "debug" 2023-12-07 18:03:04.627 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 2' to 10.3.1.28:7090 2023-12-07 18:03:04.628 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "2", "State": 5, "Error1": 0, "Error2": 0, "Plug": 7, "AuthON": 0, "Authreq": 0, "Enable sys": 0, "Enable user": 0, "Max curr": 0, "Max curr %": 1000, "Curr HW": 16000, "Curr user": 16000, "Curr FS": 0, "Tmo FS": 0, "Curr timer": 16000, "Tmo CT": 0, "Setenergy": 5000, "Output": 1, "Input": 0, "X2 phaseSwitch source": 4, "X2 phaseSwitch": 1, "Serial": "21216522", "Sec": 3217680 } ' 2023-12-07 18:03:04.927 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 3' to 10.3.1.28:7090 2023-12-07 18:03:04.928 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "3", "U1": 0, "U2": 0, "U3": 0, "I1": 0, "I2": 0, "I3": 0, "P": 0, "PF": 0, "E pres": 5877, "E total": 53178000, "Serial": "21216522", "Sec": 3217681 } ' 2023-12-07 18:03:04.992 - [34mdebug[39m: kecontact.0 (989012) Available surplus: 0 2023-12-07 18:03:05.227 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 100' to 10.3.1.28:7090 2023-12-07 18:03:05.228 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "100", "Session ID": 451, "Curr HW": 16000, "E start": 53172123, "E pres": 5877, "started[s]": 3217274, "ended[s]": 0, "started": "3217274000", "ended": "0", "reason": 5, "timeQ": 0, "RFID tag": "0000000000000000", "RFID class": "00000000000000000000", "Serial": "21216522", "Sec": 3217681 } ' 2023-12-07 18:03:05.228 - [34mdebug[39m: kecontact.0 (989012) History ID received: 00 2023-12-07 18:03:19.627 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 2' to 10.3.1.28:7090 2023-12-07 18:03:19.629 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "2", "State": 5, "Error1": 0, "Error2": 0, "Plug": 7, "AuthON": 0, "Authreq": 0, "Enable sys": 0, "Enable user": 0, "Max curr": 0, "Max curr %": 1000, "Curr HW": 16000, "Curr user": 16000, "Curr FS": 0, "Tmo FS": 0, "Curr timer": 16000, "Tmo CT": 0, "Setenergy": 5000, "Output": 1, "Input": 0, "X2 phaseSwitch source": 4, "X2 phaseSwitch": 1, "Serial": "21216522", "Sec": 3217695 } ' 2023-12-07 18:03:19.927 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 3' to 10.3.1.28:7090 2023-12-07 18:03:19.929 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "3", "U1": 0, "U2": 0, "U3": 0, "I1": 0, "I2": 0, "I3": 0, "P": 0, "PF": 0, "E pres": 5877, "E total": 53178000, "Serial": "21216522", "Sec": 3217696 } ' 2023-12-07 18:03:19.997 - [34mdebug[39m: kecontact.0 (989012) Available surplus: -2 2023-12-07 18:03:19.997 - [34mdebug[39m: kecontact.0 (989012) wallbox set to charging maximum of 16000 mA 2023-12-07 18:03:19.997 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:03:20.228 - [34mdebug[39m: kecontact.0 (989012) Sent 'currtime 16000 1' to 10.3.1.28:7090 2023-12-07 18:03:20.231 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: 'TCH-OK :done ' 2023-12-07 18:03:20.231 - [34mdebug[39m: kecontact.0 (989012) Received TCH-OK :done 2023-12-07 18:03:20.528 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 100' to 10.3.1.28:7090 2023-12-07 18:03:20.530 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "100", "Session ID": 451, "Curr HW": 16000, "E start": 53172123, "E pres": 5877, "started[s]": 3217274, "ended[s]": 0, "started": "3217274000", "ended": "0", "reason": 5, "timeQ": 0, "RFID tag": "0000000000000000", "RFID class": "00000000000000000000", "Serial": "21216522", "Sec": 3217696 } ' 2023-12-07 18:03:20.530 - [34mdebug[39m: kecontact.0 (989012) History ID received: 00 2023-12-07 18:03:21.304 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Enable sys": 1}' 2023-12-07 18:03:21.305 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Enable sys": 1}' 2023-12-07 18:03:22.235 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Max curr": 16000}' 2023-12-07 18:03:22.235 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Max curr": 16000}' 2023-12-07 18:03:25.893 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Enable sys": 0}' 2023-12-07 18:03:25.894 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Enable sys": 0}' 2023-12-07 18:03:25.997 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Max curr": 0}' 2023-12-07 18:03:25.997 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Max curr": 0}' 2023-12-07 18:03:34.628 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 2' to 10.3.1.28:7090 2023-12-07 18:03:34.629 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "2", "State": 5, "Error1": 0, "Error2": 0, "Plug": 7, "AuthON": 0, "Authreq": 0, "Enable sys": 0, "Enable user": 0, "Max curr": 0, "Max curr %": 1000, "Curr HW": 16000, "Curr user": 16000, "Curr FS": 0, "Tmo FS": 0, "Curr timer": 16000, "Tmo CT": 0, "Setenergy": 5000, "Output": 1, "Input": 0, "X2 phaseSwitch source": 4, "X2 phaseSwitch": 1, "Serial": "21216522", "Sec": 3217710 } ' 2023-12-07 18:03:34.928 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 3' to 10.3.1.28:7090 2023-12-07 18:03:34.930 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "3", "U1": 0, "U2": 0, "U3": 0, "I1": 0, "I2": 0, "I3": 0, "P": 0, "PF": 0, "E pres": 5877, "E total": 53178000, "Serial": "21216522", "Sec": 3217711 } ' 2023-12-07 18:03:35.002 - [34mdebug[39m: kecontact.0 (989012) Available surplus: 0 2023-12-07 18:03:35.229 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 100' to 10.3.1.28:7090 2023-12-07 18:03:35.230 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "100", "Session ID": 451, "Curr HW": 16000, "E start": 53172123, "E pres": 5877, "started[s]": 3217274, "ended[s]": 0, "started": "3217274000", "ended": "0", "reason": 5, "timeQ": 0, "RFID tag": "0000000000000000", "RFID class": "00000000000000000000", "Serial": "21216522", "Sec": 3217711 } ' 2023-12-07 18:03:35.230 - [34mdebug[39m: kecontact.0 (989012) History ID received: 00 2023-12-07 18:03:49.628 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 2' to 10.3.1.28:7090 2023-12-07 18:03:49.629 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "2", "State": 5, "Error1": 0, "Error2": 0, "Plug": 7, "AuthON": 0, "Authreq": 0, "Enable sys": 0, "Enable user": 0, "Max curr": 0, "Max curr %": 1000, "Curr HW": 16000, "Curr user": 16000, "Curr FS": 0, "Tmo FS": 0, "Curr timer": 16000, "Tmo CT": 0, "Setenergy": 5000, "Output": 1, "Input": 0, "X2 phaseSwitch source": 4, "X2 phaseSwitch": 1, "Serial": "21216522", "Sec": 3217725 } ' 2023-12-07 18:03:49.929 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 3' to 10.3.1.28:7090 2023-12-07 18:03:49.930 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "3", "U1": 0, "U2": 0, "U3": 0, "I1": 0, "I2": 0, "I3": 0, "P": 0, "PF": 0, "E pres": 5877, "E total": 53178000, "Serial": "21216522", "Sec": 3217726 } ' 2023-12-07 18:03:50.002 - [34mdebug[39m: kecontact.0 (989012) Available surplus: 0 2023-12-07 18:03:50.002 - [34mdebug[39m: kecontact.0 (989012) wallbox set to charging maximum of 16000 mA 2023-12-07 18:03:50.002 - [32minfo[39m: kecontact.0 (989012) (re)start charging with 16000mA (maxPower) 2023-12-07 18:03:50.229 - [34mdebug[39m: kecontact.0 (989012) Sent 'currtime 16000 1' to 10.3.1.28:7090 2023-12-07 18:03:50.229 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: 'TCH-OK :done ' 2023-12-07 18:03:50.230 - [34mdebug[39m: kecontact.0 (989012) Received TCH-OK :done 2023-12-07 18:03:50.529 - [34mdebug[39m: kecontact.0 (989012) Sent 'report 100' to 10.3.1.28:7090 2023-12-07 18:03:50.530 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{ "ID": "100", "Session ID": 451, "Curr HW": 16000, "E start": 53172123, "E pres": 5877, "started[s]": 3217274, "ended[s]": 0, "started": "3217274000", "ended": "0", "reason": 5, "timeQ": 0, "RFID tag": "0000000000000000", "RFID class": "00000000000000000000", "Serial": "21216522", "Sec": 3217726 } ' 2023-12-07 18:03:50.530 - [34mdebug[39m: kecontact.0 (989012) History ID received: 00 2023-12-07 18:03:51.300 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Enable sys": 1}' 2023-12-07 18:03:51.301 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Enable sys": 1}' 2023-12-07 18:03:52.122 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Max curr": 16000}' 2023-12-07 18:03:52.122 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Max curr": 16000}' 2023-12-07 18:03:55.681 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"State": 2}' 2023-12-07 18:03:55.682 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"State": 2}' 2023-12-07 18:03:55.980 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Enable sys": 0}' 2023-12-07 18:03:55.981 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"State": 5}' 2023-12-07 18:03:55.981 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Enable sys": 0}' 2023-12-07 18:03:55.981 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"State": 5}' 2023-12-07 18:03:56.093 - [34mdebug[39m: kecontact.0 (989012) UDP datagram from 10.3.1.28:7090: '{"Max curr": 0}' 2023-12-07 18:03:56.093 - [34mdebug[39m: kecontact.0 (989012) UDP broadcast datagram from 10.3.1.28:7090: '{"Max curr": 0}'
-
@darkiop Du hast ohne PV-Automatik getestet. Ich hab es nur bei PV-Automatik implementiert.
Dachte zuerst, dass es ohne PV-Automatik keinen Sinn macht. Aber beim BLick in den Code hab ich gemerkt, dass auch ohne PV-Automatik aktiv die Ladeleistung (entweder 0 oder max bzw. max. zulässige Leistung bei Lastbegrenzung) angepasst wird. ICh war gedanklich wohl eher beim passive mode...
Hab's geändert. Jetzt sollte es auch ojne PV-Automatik tun. Version steht wieder auf github bereit.
-
@sneak-l8 Passt jetzt. Danke!!
-
So langsam muss ich auch mal an die Integration meines SMA STP Smart Energy und der BYD HVM angehen
Akutell läuft die Steuerung des WR <> Batterie über den SMA Home Manager 2.0 - das soll auch so bleiben.
Damit ich das Auto (PV optimiert und vom Netz) laden kann, muss ich zuvor über den WR auf manuelle Steuerung umstelen. Denn ohne, lädt das Auto auch mit Strom aus dem Speicher.
Dies geschieht über:
# 802 = manuelle Steuerung setState('modbus.0.holdingRegisters.3.40151_Kommunikation', 802); # 0 = keine Ladung / keine Abgabe setState('modbus.0.holdingRegisters.3.40149_Wirkleistungvorgabe', 0);
Am Ende setze ich den WR wieder auf den gesteuerten Modus mit
setState('modbus.0.holdingRegisters.3.40151_Kommunikation', 803);
Hast du deine Idee wie ich das in zusammen mit deinem Adapter / deiner Batterielogik bringen kann?
Als Plan B, unabhängig vom Adapter könnte ich über ein Skript auch eine eigene Logik bauen, welche die Steuerung deaktiviert, sobald der SoC des Speichers 100% erreicht hat (Aktuell ist mir ist das Laden vom Speicher wichtiger als des Autos).
-
@darkiop So ganz folgen konnte ich Dir noch nicht.
Der SHM (Sunny HomeManger) steuert laut Deiner Beschreibung nur die Batterie. Das sehe ich auch so, dass daran nichts geändert werden soll.
Aber warum musst den WR auf manuelle Steuerung stellen, um das Auto zu laden? Der WR liefert ja einfach die Energie, die vom Dach kommt (wenn er nicht abregeln muss).
Ob das auto Strom aus dem Speicher nimmt, dass sollte ja mit der aktuellen Version des Keba-Adapters regelbar sein.Oder meinst du mir WR den WR der Batterie und nicht den der PV bzw. ist das ein Kombiteil?
Ok, soist es vermutlich gemeint.
Aber ich glaube, auch dafür muss man nichts deaktivieren: Wenn Du die Automatik aktiv lässt, dann würde der Adapter (bei Vorrang für die Batterie) ja nur auf den Überschuss am Übergabepunkt schauen. Und da der SHM die Batterie anweist, möglicht viel zu laden, wäre der Überschuss dann wohl nur noch ein paar Watt über/unter 0. Der Adapter/die Wallbox würde dann nicht laden, außer Du hast so viel PV-Überschuss, dass trotz voller Ladeleistung der Batterie noch genug Leistung übrig ist.Einzig wenn sich die PV-Leistung ändert wird es schwieriger. Wenn der SHM sehr schnell auf PV-Leistungsänderung reagiert, dann dürfte er schneller als der Keba-Adapter sein und immer gleich nachregeln, so dass weiterhin nichts für die Wallbox übrig bleibt und er den vollen Überschuss erhält.
Lässt die Sonne nach und die Batterie würde das Laden des Autos stützen, dann würde im Modus "keine Batteriekapazitäten nutzen, Prio auf Batterie" die aktuelle Abgabeleistung der Batterie vom Überschuss abgezogen, so dass zumindest die Batterie nicht belastet wird. -
@sneak-l8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
Oder meinst du mir WR den WR der Batterie und nicht den der PV bzw. ist das ein Kombiteil?
Genau, ist ein hybrider Wechselrichter.
@sneak-l8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
Aber ich glaube, auch dafür muss man nichts deaktivieren: Wenn Du die Automatik aktiv lässt, dann würde der Adapter (bei Vorrang für die Batterie) ja nur auf den Überschuss am Übergabepunkt schauen. Und da der SHM die Batterie anweist, möglicht viel zu laden, wäre der Überschuss dann wohl nur noch ein paar Watt über/unter 0. Der Adapter/die Wallbox würde dann nicht laden, außer Du hast so viel PV-Überschuss, dass trotz voller Ladeleistung der Batterie noch genug Leistung übrig ist.
Einzig wenn sich die PV-Leistung ändert wird es schwieriger. Wenn der SHM sehr schnell auf PV-Leistungsänderung reagiert, dann dürfte er schneller als der Keba-Adapter sein und immer gleich nachregeln, so dass weiterhin nichts für die Wallbox übrig bleibt und er den vollen Überschuss erhält.
Lässt die Sonne nach und die Batterie würde das Laden des Autos stützen, dann würde im Modus "keine Batteriekapazitäten nutzen, Prio auf Batterie" die aktuelle Abgabeleistung der Batterie vom Überschuss abgezogen, so dass zumindest die Batterie nicht belastet wird.Klingt soweit logisch, Danke Dir. Testen ist aktuell eher schwierig. Ich geh mal mit den folgenden Einstellungen ins Rennen und warte bis die Sonne wieder scheint
Max. Entladeleistung fehlt noch auf dem Screenshot, die beträgt 10200W.
-
@darkiop max power of battery solltest Du noch füllen. Es gibt an, was die Batterie abgeben kann. Für deine Strategie spielt es glaub ich keine Rolle, eher für die Strategie, die Batterie voll einzubinden.
Bin gerade nicht am Rechner, um zu schauen, ob es sonst auch Auswirkungen hat... -
@sneak-l8 Hi, sorry für die lange Sendepause, hatte viel um die Ohren...
Also, ich habe die Keba-ios-App laufen, die auch den Status der Box abfragt, somit "Ja" die erste Frage betreffend.
Mit "Download funktionert" meine ich, dass die Sessions in den Stats landen, also grundsätzlich schon eine Kommunikation zw. der Box und iobroker stattfindet.
Im Log steht nichts... -
@thilo-frank Zwei Systeme, die gleichzeitig die Box abfragen, ist nicht optimal. Die Box absturz immer dem, der zuletzt mit ihr gesprochen hat.
Im debug-log steht auf jeden Fall was. Zumindest das, was an die Box gesendet wird.
-
@sneak-l8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
@darkiop max power of battery solltest Du noch füllen. Es gibt an, was die Batterie abgeben kann. Für deine Strategie spielt es glaub ich keine Rolle, eher für die Strategie, die Batterie voll einzubinden.
Bin gerade nicht am Rechner, um zu schauen, ob es sonst auch Auswirkungen hat...Das hatte ich befüllt - nur nicht für den Screenshot.
Der erste Test, bei dem bisschen Sonne heute, lief auch erfolgreich:
-
@darkiop Ich muste geradde feststellen, dass mit die Wallbox auch einen State 5 zurückliefert, selbst wenn ich weder eine kWH-Limitierung noch eine RFID-Freigabe aktiviert habe. Ich vermute, dass das Auto nach einer Weile auch ein "ich mag nicht mehr" sendet, wenn es zu lange keinen Strom bekommen hat.
Zumidnet schickt mir mein ID.3 immer wieder über die Volkswgen App Push-Benachrichtigungen "Fehler beim Laden". Manchmal blickt die LED am Ladeport langsam weiß, wenn sie auf Strom von der Wallbox wartet und manchmal geht sie auf rot. Und letzteres führt vermutlich dazu, dass der State der Wallbox auf 5 springt. Und dann fängt das Auto nicht mehr zu laden an ...
Mir fällt jetzt nur ein, einen Timer zu nutzen und zu schauen, wann ich das letzte Mal einen Versuch unternommen hab, das Laden zu starten. Und bei State 5 würde ich es dann z.B. 1 Stunde lang nicht mehr versuchen und dann doch nmal wieder.
Oder es immer einmal versuchen und wenn der Status auf 5 bleibt, erstmal ne Stunde warten oder so.
Sonst hab ich Pech, wenn das Auto lange steckt und lnage auf Sonne wartet .... -
Guten Morgen, habe ähnliches beobachtet, Wallbox steht auf 5/7 und MercedesMe meldet einen Ladefehler. Nach abstecken und wieder anstecken ist der Fehler weg und bei ausreichend Überschuss startet auch die Ladung.
-
@darkiop oder nach Wechsel auf ne ältere Version
Ich denke, ich versuche immer nur einen Ladeversuch mit state == 5 und dann so lange mit state == 5 nicht mehr, bis ich mal das Laden wegen nicht genügend Überschuss nicht starten würde. -
Ich hab mal ne aktualisierte Version auf github bereitgestellt. Morgen scheint die SOnne, da kann man nochmal testen
-
Bei mir hat es heute mit der neuen Version wieder geklappt, auch wenn der State zunächt auf 5 stand.
-
Hallo zusammen,
ich habe mal eine doofe Frage. Ich habe einen ID.4 wenn PV Überschuss da ist startet das Laden aber immer mit ca. 4,1 kWh. Jetzt haber ich gerade nen Golf GTE als Leihwagen, habe des gerade angestöpselt, der Lädt jetzt gerade mit 1,8 kWh. Nen Phasenswitcher habe ich nicht?
kecontact.0.u1 kecontact.0.u2 und kecontact.0.u3 zeigen auch alle ca. 230 V an, aber nur i1 ist mit 10100 gefüllt, i2 und i3 sind 0, warum ist das sonst nicht der Fall? Habe keinen Phasenswitch -
@malz1902 Du lädst den ID.4 wohl mit 3 Phasen (6A * 230V * 3), den GTE mit nur einer Phase (6A * 230V).
Wenn der GTE nur auf einer Phase lädt, dann ist nur i1 > 0. Da die Wallbox aber auf allen drei Phasen Strom anbietet, sind U1, U2 und U3 = 230V.
Was ist jetzt komisch? Hättest Du erwartet, dass der GTE auch mit 4,2 kW? Wäre den so viel Überschuss da?
-
Hätte eher erwartet, dass der ID.4 auch mit so wenig Laden kann. Aber liegt glaub ich eher am Golf GTE, der kann wohl nur 1-phasig Laden und deswegen passiert das gerade wohl.
Es liegt 3x 230 V an, aber da der Golf nur 1-Phasig kann, wird wohl auch nur ein Phase versorgt -
@malz1902 Dein ID.4 lädt 3-phasig, wenn er drei Phasen bekommt. Deine Wallbox hat drei Phasen, also lädt er auch mit dreien. Mindeststromstärke ist 6A, daher 4,2 kW.
Weniger geht nur, wenn Du Phasen abklemmst (ggf. über Phasenumschalter). -
Verstanden, danke
Liegt wohl daran weil der Golf nur einphasig kann und die WB dann so schlau ist und das dann macht.