Docmac

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?!