Docmac

So geht's auch (auch das gleich um Null Gezappel) Kleine Nebenbemerkung (vielleicht für andere auch interessant): Kostal Plenticore als Smart meter und SunSpec -> Port 1502 KSEM über LAN und Sunspec -> Port 502 (mit Port 1502 wird der KSEM nicht gefunden)

Habe jetzt den KSEM über LAN verbunden (IP, Port 1502, Location: Grid) Da in der Auswahl fürs Register Table jedoch kein Kostal oder KSEM zu finden ist habe ich mal den Eastron SDM630 TCP genommen. Damit komme ich nun auf keine negativen Leistungswerte sondern pendel um Null herum - was auch okay ist, da ich weder lade noch Netzbezug habe (die -xxx W von vorher kommen aus der Batterie am Plenticore und decken den Hausverbrauch ab) Nun war im Lastmanagement auch direkt der KSEM ausgewählt. Scheint also so zu gehen. Oder ist der Registersatz des Eastron SDM630 TCP doch irgendwo nicht 100% identisch zu dem des KSEMs ?

Hier das log file By the way, die MQTT Kommunikation habe jetzt abgeschaltet (da der Raspi aktuell nicht läuft) und damit einen Reboot ausgelöst. Das hat aber nichts geändert. warp-SCa-Debug-report-2026-02-06T17-36-17-118.txt

Ich habe gerade versucht den KSEM bzw. den Plenticore+ Wechselrichter (der den KSEM über RS485 ausliest) mit dem Warp Charger zu verbinden. Das hat auch (teilsweise) funktioniert. Add Meter -> SunSpec -> Kostal Plenticore IP Adresse und Port 1502 Beim Scan wird der Wechselrichter unter Device Address 71 gefunden. Es gibt zwei Modelle 103 und 113 wobei der Warp Charger eine Anmerkung dazu liefert, dass der 113 preferred ist. Dementsprechend habe ich diesen ausgewählt. Im Energie chart ist dann auch die aktuellen Leistungswerte der drei Phasen am Netzanschlusspunkt (<- Position des KSEM) ) zu sehen - Minus Werte im Fall von Strombezug aus dem Netz. Wenn ich nun aber aufs dyn. Lastmanagement gehe, ist dort aber im Pulldownmenü für das Energy Meter keine Auswahl möglich (Warp Charger und Kostal Plenticore beide ausgegraut). Ausserdem steht beim Kostal ein Hinweis, dass die Phasenströme fehlen und ein Minus Strombezug nötig ist. FW des Warp Chargers ist aktuell und 2.9.0 - jedoch nicht Warp charger smart oder Warp charger pro??? Irgendeine Idee was hier faul ist?

Ach, dann habe ich das misverstanden. Optimal, dann muss ich gar kein HEMS mehr aufsetzten, wenn die Wallbox das macht. Was müsste denn alles beim Umbau von Warp1 smart auf Warp2 oder 3 smart getauscht werden und bekommt man das?

Danke für die Antwort. Das heißt für den Überlastungschutz des Hausanschlusses muss ich über ein HEMS gehen wenn ich die Leistung max. ausreizen möchte. Ansonsten könnte ich auch ganz simple einen festen Stromwert einstellen von dem ich ausgehen kann, dass dieser zusammen mit den andreren Verbrauchern im Haus unter dem erlaubten Gesamtstrom bleibt. Mal sehen ob der Elektriker oder der Versorger bzgl. der "Bastellösung" zur Steuerung nach $14a über den Schlüsselschalter Bauchschmerzen bekommt. By the way, was müsste ich denn alles tauschen um die Warp1 smart auf Warp3 smart aufzurüsten? Nur das EVSE 3.5 Bricklet oder auch das Warp ESP32 Bricklet?

Hallo, ich habe hierzu nichts gefunden. Bei meiner Installation werkelt ein KSEM (Kostal Smart Energy Meter) am Netzanschlusspunkt und kommuniziert über ModBus mit dem Kostal Plenticore Plus (LAN vom KSEM wäre auch möglich). Dieser KSEM liefert mir die Bezugs und Einspeisewerte. Nun muss ich wegen der zu installierenden Wärmpepumpe die Steuerbarkeit nach $14a auch für die Wallbox implementieren. Gibt es an der Warp 1 smart ein Signaleingang der die Drosselung auf 4.2kW triggert oder geht das nur über ein HEMS, dass mittels MQTT, ... ein entsprechenden Maximalstromwert an die Wallbox schickt? Und ist eine HEMS Opensource Lösung über OpenHAB, evcc, Home assiatant überhaupt seitens der Netzbetreiber erlaubt? Die Wallbox sollte die Priorität 3 hinsichtlich Strom bekommen. Haus und WP entsprechend 1+2. Ein weiterer Punkt wäre, ich vermute eine Hausanschlussüberlastung (z.B. 50A SLS) lässt sich wohl nur über ein HEMS realisieren, da die Wallbox und die WP voneinander nichts wissen. Also ein übergeordnetes System (HEMS) den Geräten mitteilen muss, wer wieviel nutzen darf. Der KSEM muss dann dazu die Werte liefern. Richtig? Hast jemand sowas schon realisiert? Gruss Markus

Okay. Danke. War etwas verunsichert wegen der Bemerkung in der Anleitung. Aber nachdem die RCD/FI Prüfung und der DC Fehlerstromtest ordnungsgemäß funktioniert haben wollte ich nur nochmal sichergehen, dass es es nicht einen anderen triftigen Grund gibt.

Hallo zusammen, In der Anleitung zur Warp2 steht nun explizit aufgeführt, dass beim einphasigen Anschluss auch ein 1-poliger RCD / FI zu verwenden ist. In der alten Warp Betriebsanleitung steht dieser Teil nicht. In meinem Aufbau habe ich einen 3poligen RCD mit nachfolgendem kWh Zähler in Unterverteilung, danach ist eine Phase direkt zur Wallbox verlegt und die beiden anderen Phasen sind über einen Schütz zuschaltbar. Nun habe ich mich gefragt ob sich dadurch etwaige Problem hinsichtlich Abschaltverhalten im Fehlerfall ergeben. Einen RCD Auslösetest (ms Abschaltzeit) hat der Elektriker bei der Inbetriebnahme gemacht. Alles normal und wie es sein soll. Den DC Fehlerstromtest habe ich durchgeführt und dieser löst auch in 1-phasigen Betrieb den 3 poligen RCD aus. Gibt es andere Fehlerfälle bei denen der 1-polige RCD zwingend im 1-phasigen Betrieb nötig ist? Falls dem so ist, hätte das wohl wesentliche Auswirkungen auf eine 1-Phasen/3-Phasen Umschaltung. Gruss Markus

Ist mit "einem Zähler" ein Smart Energy Meter am Netzanschlusspunkt oder der Lademengenzähler der Wallbox? Ich vermute ersteres, da das in der Warp verbaute SDM 72DM keine Einzelphasenspannungen und ströme ausgibt. Das macht soweit ich weiß nur das SDM630. Außerdem müsste das SDM72DM der bestehenden WB (vor den Schütz) umgebaut werden, sonst läuft es ja nicht. Per RS485 Auslesen wäre dann Modbus RTU? Oder ginge auch über WLAN? Ich bin mir nicht sicher ob ich z.B. am KSEM den zweiten RS485 (B) Port (vorkonfiguiert auf Kostal Piko MP; Einstellungen sind aber laut Handbuch änderbar) gleichzeitig mit der ersten RS485 (A) Port betreiben kann. Am ersten hängt nämlich schon der Plenticore+ WR. Diese Frage habe ich mal an Kostal weitergeben.

Ich bin zwar mit meiner Unterverteilung etwas weiter weg - aber über das RS485 Bricklet habe ich in der UV bereits einen Zähler SDM72D-M (rein für die Messung der geladenen kWh) vor dem Phasenumschaltschütz und der scheint auch bei 1phasig zu arbeiten (ich sehe aktuell im Leerlauf am Zähler zwischen 1 und 3 Watt). Falls die Umschaltung über RS485 laufen soll, wäre ich wohl passend vorbereitet? Am Netzanschlusspunkt sitzt ein KSEM für den Kostalwechselrichter, der die PV Überschussdaten generiert. Somit wäre bei mir ev. nur das Modul (ohne Schütz) vermutlich ausreichend?! Zur Info: Mein Schütz ist ein 4-fach Schließer 63A mit 230V Schaltspannung (A1,A2) auf dem 2 Phasen aufliegen.

Hallo, meine eigene Phasenumschaltung bei PV-Überschuss laden (eigenes Raspi Programm aber ohne HMI) funktioniert in Trockenexperiment. Nun hätte ich aber gern auch eine Visu (am liebsten über Browser) und eine händische (z.B. Button in HMI) Umstellmöglichkeit der Phasenanwahl. Das übersteigt aber meine Programmierfähigkeiten. Ich habe gesehen, dass die Warp auch über EVCC gesteuert werden kann und dort auch eine PV Überschussladung implementiert ist. Daher habe ich mir das mal etwas genauer angeschaut. Es gibt darin auch eine Phasenumschaltung - leider aktuell nur für OpenWB und easee; nach Aussage von Andi (EVCC) weil nur diese beiden eine interne Phasenumschaltung (HW) und Status/Fehlerprüfung (SW) haben. Ich habe den Warp Code überflogen, konnte dergleichen hier nicht finden. Ist das vom Design her nicht möglich (im Schaltplan ist als Phasenüberwachung nur die Ph1 eingeschleift; ansonsten sehe ich keine weitere Überprüfung der Phasen bzw. Phasenanzahl) oder liegt das an unterschiedlichen Controllern bei den verschiedenen WBs? Rein software-seitig sollte sich doch so eine Abfrage der Phasen bzw. auch eine Fehlerbehandlung realisieren lassen. EVCC erwartet, soweit ich das verstanden habe, dass die Phasen und entsprechende Fehler in der WB behandelt werden und berechnet dann anhand der erhaltenen WB Daten und der PV Überschussleistung den erlaubten Strom aus. Scheint somit für eine Warp mit EVCC und Phasenumschaltung per PV Überschuss nicht so einfach zu sein?

Habe den Fehler gefunden: Ich habe statt der internen Terminierung des RS485 Bricklets, selbst einen 120 Ohm Widerstand parallel an die Brickleteingang geklemmt (das hätte ev. auch noch funktioniert) aber das Hauptproblem war, ich hatte die DIP switches am Bricklet noch auf Vollduplex stehen, aber keine weitere Teilnehmer angeschlossen. Nachdem ich jetzt auf Halbduplex und interne 120Ohm Terminierung umgestellt habe geht es jetzt und mir wird auch ein Trendgraph min 1~2W im Idle angezeigt.

Hallo Tinkerforge-Team, leider klebt bei mir (und vermutlich allen anderen) der WARP Typenaufkleber unten auf der Gehäuseseite zwischen der Eingangs- und der Ladekabelverschraubung. Da ich ja meinem im Zählerkasten (wegen 1-polig / 3-poling Umschaltung) verbauten SDM 630 an meiner WARP Smart mit ergänztem RS485 Bricklet betreiben will, geht mir der Aufkleber etwas im Weg um. Ich wollte mit der RS485 Leitung auch von unten in die Box gehen und da ist das der einzige Platz. Lässt sich der Aufkleber abziehen ohne kaputt zu gehen oder löst er sich in seine Bestandteile auf o.ä., sprich hat er entweder eine extrem guten Kleber oder ein Sicherheitsfeature? Ich nehme an ein nicht beschädigtes Typenschild ist für den Elektriker / die Abnahme und Einreichung der Unterlagen bei der KFW notwendig? Oder reicht das Typenschild das in die Betriebsanleitung geklebt ist? Falls ich da nicht ran sollte, kann man alternativ auch seitlich in die Box (linke Seite beim Anschlussblock) gehen oder ist das wegen IP54 nicht machbar? Entsprechende metrische Verschraubung für das verwendete RS485 Kabel / LAN Kabel ist vorhanden. Die Lösung von unten her würde mir aber besser gefallen. Da die WARP Smart bei mir in der Garage montiert ist, spielt die Schutzklasse hinsichtlich Wasser keine große Rolle für mich. Wäre super, wenn ihr hierzu etwas sagen könntet. Gruss Markus

So, habe weiter (ohne e-Auto) getestet... Mit beidseitig 120Ohm terminiertem RS485 wird zwar weiterhin der Leistungsgraph in der Web Application Status Übersicht und im Stromzählerunterpunkt eingeblendet - aber im Leerlauf der Box (also ohne angestecktem Auto) wird kein Trendchart (blaue Linie bei 0W) bei z.B. Live Modus angezeigt. Kann ev. jemand mal nachschauen ob ohne angestecktem Auto bei einer Warp Pro ein blauer 0W Trendgraph in der Web Application angezeigt wird oder nicht? Dann ist hoffenlich klarer ob ich noch irgendwo in meiner HW Verdrahtung (RS485 Bricklet, RS485 Kabel & Abschirmung, Terminierung) oder am SDM Energiezähler einen Fehler habe oder das Ganze nur dann geht wenn wirklich Leistung vom Energiemeter gemessen wird (ev. sendet der ja nichts wenn 0W anliegt? Gruss Markus

Hmm.... Das liest sich so als würde ein Stop Laden, Phasemumschaltung, Start Laden seitens der Wallbox bei kontinuierlich angestecktem Auto nicht ausreichen ? Sondern man muss manuell oder elektronisch (CP/PP Trennung) eine Ladekabeltrennung durchführen. Ich hoffe hier kann jemand was gegenteiliges berichten. Wenn das nicht nur bei der Zoe so ist, dann würde meine selbst gestrickte Rapi PV Überschussregelung nicht komplett funktionieren und ich müsste mich auf entweder 1ph oder 3ph fix festlegen :-(

Hallo Hoich, ja der SDM72 kann keine Einzelleistung jeder Phase messen. Was aber eigentlich gehen müsste, ist wenn er 3 phasig versorgt wird aber am Ausgang nur über eine Phase Leistung abgenommen wird diese Leistung als Gesamtleistung anzuzeigen. So zumindest mein Verständnis der Betriebsanleitung des SDM72. @all: Leider zeigt mein SDM aktuell über RS485 immer noch kein Ladekurvendiagramm (also keine blaue Linie; auch nicht mit 0W) in der Web Applikation an. Die RS485 Einstellungen entsprechen den oben erwähnten Werte (Einstellung zum Stoppbit kann ich aber am SDM nirgends finden) Ich denke, das liegt wohl an der aktuell fehlenden Terminierung der RS485 Verbindung ?! Soweit ich gelesen habe muss man auf beiden Seiten mit extra 120Ohm terminieren. Oder ist die Terminierung im SDM630/72 und/oder im RS485 Bricklet bereits verbaut? Weiters habe ich gefunden, dass teils noch zusätzlich zwischen A und +5V und B und GND noch 390Ohm geklemmt werden sollten. Da beim SDM und RS485 aber keine 5V Klemme vorhanden ist, nehme ich an dass das hier nicht notwendig ist. Es ist ja auch nur ein zwei Teilnehmerstrang.

So ich habe jetzt alles verdrahtet und angeschlossen. Leider habe ich nirgends gefunden welche Modbus Verbindungseinstellungen ich am meinem vorgelagerten SDM630 einstellen muss. Sind die Standardeinstellungen des SDM630 korrekt oder was muss dort eingestellt werden damit das RS485 Bricklet mit der SDM630 kommuniziert. Da ich kein e-Auto zum Testen da habe ich dann aber vermutlich immer noch nicht viel sehen (ausser ev. eine Null-Linie ;-)) aber zumindest müsste das dann ja im Stromzählerbereich der Warp graphisch dargestellt werden?! Danke schon mal im Voraus.

Hallo rtrbt, danke für die Rückmeldung. Gut dass man sich den Reset sparen kann. Korrekt, Autostart ist aus. Eine Stop, Warten für x sec (bis das Umschalten per Schütz fertig ist), Gegenprüfung des Schützzustands, Neustart der Ladung Sequenz ist programmiert und läuft auch nur im Fall von angeschlossenem ladenden Auto In allen anderen Fällen wird nichts gesendet - auch keine PV Leistung. Wenn ich Dich aber richtig verstehe, sollte ich lieber statt dem Topic vehicle state das Topic iec61851_state für den Ladeaktivitätsprüfung nutzen, richtig? Das müsste ich dann nochmal kurz abändern. Bzgl. Warte und Schaltzeiten muss ich dann eben noch warten bis mal ein Bekannter mit e-Auto zum Testen vorbeikommen kann ;-)

So nun habe ich eine in der Testumgebung laufende Version für die Bestimmung der PV Überschussleistung und der Kommunikation mit der Wallbox über MQTT fertig. Das Ganze ist jetzt doch nicht in Node-red sondern komplett in Phython geschrieben. Es läuft auf einem Raspberry Pi ZeroW mit RS485 Modul für eine eventuell später zu implementierende WB Leistungszählermessung und einem Doppel-Relaismodul für das 1ph<->2ph Schützschalten sowie den Prüfloop ob der Schütz in richtiger Stellung steht. Jetzt fehlt dann nur noch die Wallbox (und ein E-Auto) um die Sache real zu testen. Offene Fragen (an die Spezialisten / Tinkerforge): Aktuell ist es so implementiert, das nur im error_state ungleich Null mein Programm überhaupt über MQTT sendet und sonst nichts tut. Ausserdem sende ich nur das Current_limit Topic sowie Start/Stop charging. Der WB Vehicle & Error State wird nur ausgelesen. Daher sollte das ganze sicher sein, da die WB generell noch die Führung im Fehlerfall hat, richtig? Muss ich noch einen WB Reset o.ä. einbauen, wenn ein Umschalten der Phasen erfolgt? Im Fall Vehicle_state = 0 oder 1 wird dann einfach nur der mögliche Überschussladestrom als current_limit gesendet, da aber nicht geladen wird, wird auch kein Start oder Stopp Signal geschickt. Das verursacht Traffic und könnte auch generell rausgenommen werden. Im Fall Vehicle_state = 2 (Fahrzeug lädt) wird der Überschussladestrom regelmäßig (Takt noch genauer zu spefizieren siehe unten) gesendet, dabei aber noch geprüft ob im Vergleich zum letzten Datenpaket eine Änderung im Phasenumschalten auftritt und dann entsprechend das Laden gestoppt, der "Phasen-Schütz" entsprechend geschaltet, 1~2s gewartet, dass der "Phasen-Schütz" auch fertig ist, dann der neue Wert geschickt und dann das Laden wieder gestartet. Ansonsten wird nur der neue Überschussladestrom gesendet. Bzgl. der Taktung bin ich noch nicht Klaren: Welche Taktung ist in Hinblick auf WB, Kommunikation mit dem Auto, dem Phasen-Schütz und PV Anlage sinnvoll? Theoretisch könnte ich ja groß jede 2s (Puffer für die Schützschaltgeschwindigkeit) abfragen und agieren. Da hier aber hintendran dann auch noch die Kommunikation mit dem Auto (wegen Ladestart/Stopp) hängt ist das ev. zu knapp bemessen und könnte meiner Meinung nach zu Zustandsfehlern führen. Ist die Taktung zu lang, könnte die reale Leitung schon wieder niedriger sein und ich nutze für diese Zeit dann teilweise Netzstrom. Gibt es hier ev. Erfahrungswerte wie lange so ein Austausch zwischen Auto und WB bzgl. Ladestart und Stopp Freigabe sowie Laden dauert. Wahrscheinlich ist es am besten, einfach nur für den Phasenwechsel eine längere Taktung / Wartezeit einzubauen und sonst im 1~2s Takt Daten auszutauschen ?

Ja, für "fast" charging mit 3 Phasen würde ich erwarten dass man schon so um die 7kW recht konstant über den Tag liefern können muss. Sonst hangelt man sich immer an der Umschaltgrenze entlang. Meine aktuelle Anlage schafft aber nur max. 5.5kW, somit ist es bei mir AKTUELL ziemlich sicher, dass ich eigentlich nur 1-phasig PV Überschuss laden werden kann. Die paar Mal bei denen ich über die 4.3kW komme sind an einer Hand abzuzählen. Wenn ich mir ein E-Auto kaufe, dann pack ich das Garagedach voll und komme dann basiered auf der aktuellen Anlage auf ca. 12kW max. Leistung April ~ September Das sollte dann auch für 3-phasig Laden passen. Die Fall-back Lademethode mit Netzstrom muss logischerweise mit 11kW gehen bzw. das was das Auto packt. Ich bin ursprünglich auch von einen simplen Schützansteuerung gekommen. Ganz am Anfang dachte ich sogar einfach daran meinen Schaltausgang vom Wechselrichter für den Schütz zu verwenden - der lässt sich bei definierbarer Leistung schalten. Dann wäre aber so erstmal keine Korrelation mit dem Autostatus (z.B. lädt gerade) gegeben und man müsste auch parallel über MQTT nicht nur die Ladeleistung bzw. Ladestrom schicken sondern auch noch Stopp kurz bevor der WR den Schaltausgang schaltet und dann Reset+Re-Start mit neu berechnetem Ladestrom (entsprechend der aktiven Phasen. Das erschien mir recht heikel / ev. fehleranfällig. Da ich aktuell weder mit dem ESP32 noch mit den Bricklets oder einem ESP8266 gemacht habe, bin ich hier unschlüssig ob es hier eine beste/am einfachsten zu realisierende Lösung gibt. Da ich wie gesagt, die Daten vom WR / Smart Energy Meter via Raspi Zero W ziehe und verschicke ist das als partiell separate Methode zur Schützsteuerung auch machbar. Ein Automation HAT mini scheint alle notwendigen Features (24 V in/out + 24V 2A Relais) zu haben und wäre daher ganz gut. Je nachdem wo ich den Schütz verbaue habe ich 2m bzw. 15m Steuerleitung vom Raspi zum Schütz; sprich der Spannungsabfall im Control loop (hin + zurück dann 4 bzw. 30m CAT 6 Kabel) wird dann bei 5V ev. zu groß und nicht stabil funktioneren. Nur ein 5V Relais board (für 230V Steuerspannung schalten am Schütz) + den Control loop über 5V und einen GPIO wird wohl nicht reichen? Wenn das doch geht wäre es zwar auch nicht optimal da keine Fehlermeldungen an WARP geschickt werden. Aber funktioneren müsste das auch. Ev. probier ich das mal - bei den paar € die da zum Testen investiert werden kann man auch einen Fehlschlag riskieren ;-)

Hallo Batti, sorry, das hatte ich nicht genauer beschrieben. Ich bin auch davon ausgegangen, dass der Schütz nicht in die WARP passt und daher in einem kleinem, separatem Kleinverteiler vor der WARP in der Zuleitung sitzt. Deine Aussage bedeutet dann wohl auch ich müsste wahrscheinlich die 3 Bricklets (Relais + Digital In + Digital Out) dann mittels Bricklet Kabeln auch in den Kleinverteiler auslagern Vermutlich muss man dann diese Leitungen gegen EMV nochmal extra schirmen (laufen ja parallel zum 11kW / 22kW Zuleitung)? Ich dachte den Quellcode der WARP mit den entsprechenden Routinen zur Ansteuerung des Schützes und der Abfrage des Control Loops zu ergänzen. Anfänglich dachte ich es ist praktikabler alles innerhalb der WARP SW zu erledigen. Wenn ich drüber nachdenke ist die Lösung mittels Raspi aber auch denkbar - den hätte ich sowieso auch am Laufen wegen der Bestimmung der PV Überschussleistung und deren Info an. Was ich aktuell nicht weiß gibt die WARP über MQTT alle notwendigen Statusinfos zum Laden aus und nimmt diese auch an damit ich das Abschalten und Reseten der Ladeverbindung steuern kann. Problematisch sehe ich den Fehlerfall, Schützfehler wären dann nur separat im Raspi abgehandelt. Die anderen Fehler in der WARP. Geht wahrscheinlich auch aber alle Fehler in der WARP zusammenzufassen (also im WARP Quellcode zu implementieren) scheint mir sicherer?!

Hallo zusammen, ich habe mir weiter Gedanken gemacht wie eine sichere Phasenumschaltung realisiert werden kann. Erste Ansätze und Diskussionen gibt es ja schon im PV Überschussladen Thread. Manuell mit Lasttrennschalter für 2 Phasen ist klar aber wie kann eine automatische sichere Lösung aussehen. Die WARP wird ja über einen ESP32 Brick gesteuert. Für die meisten privaten PV Anlagen denke ich ist es sinnvoll als standard 1 phasig zu laden und bei hoher Leistung die anderen beiden Phase zu zuschalten. Bei der zu erwartenden Umschalthäufigkeit von wenigen Malen pro Stunde scheint mir ein überdimensionierter Schütz (z.B. 32A bzw. 63A bei 11kW bzw. 22kW Ladeleistung - Wallbox hauptsächlich ohmsche Last --> Schütz: AC1 bzw. AC7a) für das Zuschalten der Phasen ausreichend (Lebensdauer mehrere Jahre) - eine Auslegung mittels Solid State Relais übertrieben. Die etwas größeren Verluste durch den Betrieb mittels Schütz liegen im Promillebereich. Die Ansteuerung des Schützes sollte aus der WARP mittels Dual Relais Bricklet und separater 230V (oder auch 24V) Steuerspannung erfolgen. Durch die Verwendung eines 3 oder 4 poligen Schützes ließe sich auch neben den zwei Phasenschalten auch ein Control Loop realisieren, der anzeigt ob der Schütz richtig geschaltet hat oder klebt. Der Ablauf wäre dann: Berechnung des Ladestroms im Minutenbereich gemittelt Prüfung Control Loop = offen / keine Spannung dann OK sonst Fehlermeldung PV Ladeleistung fällt unter 4.3kW -> kein Anziehen des Schützes / kein Aufsteuern des Relais Bricklets Prüfung Control Loop = offen / keine Spannung dann OK sonst Fehlermeldung -> 1phasig laden - Ladestrom aus MQTT mit (PV Überschuss / 230V) -> Ampere Hier müsste man sinnigerweise auch eine Hystere einbauen, damit bei Werten um 4.3kW nicht ständig Phasen zu und weg geschaltet werden --> führt natürlich dazu, dass etwas Netzleistung zugeführt wird oder etwas PV Leistung ungenutzt bleibt PV Ladeleistung steigt über 4.3kW -> Stoppen im Fall einer laufenden Ladung -> ev. Reset der Verbindung zum Auto -> Anziehen des Schützes durch Aufsteuern des Relais Bricklets -> Prüfung Control Loop = geschlossen / Spannung dann OK sonst Fehlermeldung -> 3phasig laden - Ladestrom aus MQTT mit (PV Überschuss / 400V /1.73) -> Ampere Damit ließe sich mit Tinkerforge Bordmittel auch eine sichere Phasen-Umschaltung realisieren. Offen sind folgende Fragen: 1) Lassen sich neben dem RS485 Bricklet auch noch ein Relais Bricklet sowie ein Control Loop Eingang mittels Digital Out & In Bricklets mit dem ESP32 Brick verbinden? Sowohl platztechnisch in der WARP als auch steckverbindertechnisch? 2) Unterstützt ihr mich bei Fragen bzgl. der bestehenden SW Code und der Einbindung dieser Anpassung. Ich würde selbst coden.

Okay. ZOE und wohl auch E-Niro lassen sich problemloser mit wenig PV Überschuss laden. Bleiben wir aber bei den anderen Autos mit 3 phasigem Lader. Dann wäre doch zwei bzw. drei "manuelle" Methoden denkbar: 1) 2 verschiedene Ladekabel: ein Ladekabel 1phasig (PV Überschuss bis 4.2kW bzw. 7.4kW) das andere 3phasig (Netzstromladung bis 22kW) 2a) Lastrennschalter für 2 Phasen zwischen Wallbox und Ladekabel 2b) Lastrennschalter für 2 Phasen zwischen Hausverteilung und Wallbox Wenn ich die anderen Threads richtig verstehe macht dem SDM 630 Drehstromzähler das Fehlen von Phasen nicht und er funktioniert und zählt trotzdem richtig? Dann könnte er sogar nicht nur vor dem Lasttrennschalter (bspw. 2b) verbaut werden sondern auch danach. Eine smarte (gesteuerte) Lösung wäre dann: Mittels 2 (bzw. 3 oder 4) poligem Schütz entsprechend 2 Phasen zu- oder wegschalten. Eine Phase wird fix durchgeschleift fürs 1phasige Laden - Einbau wäre dann entsprechend 2b) Lasttrennschalter. Zum Zu- bzw. Wegschalten müsste man dann noch irgendwie aus dem PV Überschusssignal (<4.2kW bzw. >4.2kW) ein Steuersignal (230V oder DC) für den Schütz generieren. Lasst sich das über die Red Brick (ist das überhaupt in der Wallbox verbaut?) oder das ESP32 Brick (das habe gar nichts gefunden) und ein Industrial Dual Relay Bricklet realisieren? Die direkte Verwendung des Industrial Solid State Relay Bricklets + bei Euch bestellbarem SSR scheidet bei 22kW wegen der zu geringen Stromtragfähigkeit von 25A wohl aus. Sonst wäre das wohl auch eine schöne Lösung. Aber nun ist mir aufgefallen, dass das SSR Bricklet wohl ein Normmaß hat und somit auch SSRs anderer Hersteller mit entsprechend großem Bemessungsstrom (32A ~ 50A) passen müssten. Wäre in der Smart (dort wo bei der Pro der Drehstromzähler sitzt) noch genügend Platz für ein entsprechendes SSR mit SSR Bricklet? Dann würde ich den SDM630 in der Unterverteilung belassen und nicht dort die Phasenumschaltung per Schütz realisieren sondern eher über SSR + SSR Bricklet in der Wallbox gehen. Ein MQTT Signal zur Phasenab/zuschaltung sollte sich ja in der Wallbox (Red Brick bzw. ESP32) wohl an das SSR Bricklet weitergeben lassen?! Zwei Phasen parallel zu/wegschalten sollte ja mit dem SSR genauso gut und sicher gehen wie mit einem Standardschütz?! Preislich sieht es aber so aus als wäre die SSR Lösung teurer - aber nicer ;-) Eine generelle Frage, die ich mir selbst nach längerem Nachforschen nur zu 99% sicher beantworten konnte: Soweit ich herausfinden konnte sind liegen Wallboxen / Gleichrichter nahe cos phi 1 und sind somit hauptsächlich ohmsche bzw. schwach induktive Lasten. Damit müsste die Dimensionierung des Schützes nach Gebrauchskategorie AC-1 oder AC-7a erfolgen. Da in der WARP ein ETEK EKMF6340 mit Gebrauchskategorie AC-7a 63A verbaut ist, denke ich 32A bzw. eine Stufe drüber oder eben 63A für lange Lebensdauer bei AC-7a bzw. AC-1 sollte hier passen. Sehe ich das korrekt?

Hallo rtrbt, ich habe am Wochenende eine Smart bestellt (weil die Problematik mit PV Überschussladen und 1/3phasigen Betrieb des SDM72D). Wenn das mit dem externen SDM630 und dem RS485 Brick geht wäre das für mich auch interessant. Was meinst Du mit "...könnte man da aber eventuell was machen"? Pro Gehäuse verwenden oder entsprechend Löcher für das RS485 vorbohren lassen?