mattsches

Wenn du den Zähler in der Wallbox einbauen willst, würde ich den SDM72DM-V2 nehmen. Er ist deutlich günstiger und liefert ebenfalls phasenbezogene Werte, gegenüber dem 630 hat er das schwächere (nur einzeilige Display. Das ist aber egal, wenn eh die Frontplatte davor hängt. Mit dem 72 V2 (obacht, das V2 ist wichtig) hast du in der Funktion keinen Nachteil gegenüber dem 630.

@ThomKa, du kannst ruhig auf die 2.1.5 gehen. Das war nur ein Merge des aktuellen Standes von TF, der ohnehin irgendwann fällig gewesen wäre. Ist halt nicht das letzte Release, sondern ein Daily Build/Bleeding Edge von deren Seite. Mein Repo lasse ich darauf und mache mit dem Stand weiter. Wenn du updatest, gewinnst du die Statusanzeigen der Phasenumschaltung zurück, die in der 2.1.4 noch gefehlt haben. Hilfreich wäre es für mich, wenn @deepflyer911 noch den 2.1.5er Stand mit SOC-Modul testen könnte. Das bringt euch nichts (habt ja nicht das passende Auto, außerdem fehlt hier die neue GUI noch komplett). Aber für mich wäre es gut zu wissen, ob das SOC-Modul in die Suppe gespuckt hat oder wie von Matze vermutet ioBroker.

Dann hier noch eine Variante ohne das SOC-Modul. Das hat zur Zeit noch kein Frontend (Refactoring noch offen), und du brauchst es ja eh nicht.warp_firmware_2_1_5_6513378a_7f4039330db99e6_merged.bin

Codestand war das 2.1.4er Release, also vom 23.08. Anbei mal ein Stand auf dem aktuellen 2.1.5 Entwicklungsstand (387bd3e318889d16ce866273f92c9f783b91faff). @MatzeTF, die Debug-Seite habt ihr ja kräftig ausgebaut, cool! Bei mir werden jetzt 78 kB freier Heap und 73 kB als größter Block angezeigt. Die Kiste läuft allewarp_firmware_2_1_5_651335e2_7f4039330db99e6_merged.binrdings erst auch seit ein paar Minuten.

Das Debug-Modul ist im letzten hier geposteten Stand aktiv. @deepflyer911, du hattest die Seite ja schon offen. Wie verhält sich der Speicher denn über die Zeit? Bei mir (MQTT aus) läuft die Kiste seit gut 23 Stunden, ca 75 kB Heap Bytes frei, größter freier Block 30 kB. Ich habe keinen MQTT Broker am Start, sonst würde ich testweise mal einschalten. Aber ich fürchte, ohne Gegenstelle wird das nicht viel bringen.

@ThomKa : Nö, aber falls du @MatzeTF meinst, der ist von Tinkerforge und wird vermutlich auch Matthias heißen (in welcher Buchstabenausstattung auch immer). Für mich hört sich das nach Abstürzen aufgrund von Ressourcenmangel an (Speicher voll). Ich hatte das Problem zeitweise mit meinem Ladestandsmodul. Die Phasenumschaltung belegt Speicher für die Charts. Wenn MQTT auch Platz braucht, wenn aktiv, ist das vielleicht zu viel des Guten. Ich könnte testweise eine Variante ohne Charts bauen, um es einzugrenzen. Und vielleicht hat Matze ja noch einen Tipp, wenn er Debug Logs bekommt.

@deepflyer911, welche Version hattest du denn vorher im Einsatz? Das klingt so, als sei das System ziemlich am Anschlag. Habe gerade mal zuhause reingeschaut, da sieht alles gut aus. Uhrzeit ist da, Leistungsvorgabe wird korrekt angezeigt, nichts Auffälliges. Ich nutze allerdings nicht MQTT, sondern die REST API. Sollte aber keinen Unterschied machen.

Hier mal ein Update, basierend auf dem 2.1.4er Release. Ich habe die Statusausgaben wieder eingebaut auf der Konfigurations- und auf der globalen Statusseite. Das Diagramm auf der Konfigurationsseite funktioniert noch nicht ganz, da fehlen noch die Werte für tatsächliche Leistung und Anzahl angefordereter Phasen. warp_firmware_2_1_4_6511ec66_157129f07258805_merged.bin

Noch kurz zu deinen Fragen: In meinem Umbau kommen drei zweipolige Schütze zum Einsatz für die drei Phasen (einzeln), den Neutralleiter und die Schützüberwachung. Das Quad Relay wird für die Ansteuerung der Schütze benötigt, ein Kanal könnte für eine CP-Trennung verwendet werden. Falls dich das interessiert, findest du mehr Details dazu in meinem von Eric (rtbt) oben verlinkten Thread. EVCC habe ich nicht im Einsatz, kenne mich daher damit nicht aus. Was ich weiß, ist dass der Warp Charger standardmäßig die Vorgabe eines Ladestroms unterstützt. Es muss also an anderer Stelle berechnet werden, wie hoch der Strom unter Berücksichtigung der Anzahl der Phasen sein muss, um die gewünschte Ladeleistung zu erhalten. Wie EVCC in deiner manuellen Lösung die Anzahl der Phasen erkennt (wie du ja berichtest), weiß ich nicht. In meiner Lösung habe ich die Stromberechnung in den Warp Charger verlagert. Mein Phasenumschaltungsmodul in der Firmware bekommt von extern (über die API) eine Ladeleistung vorgegeben und entscheidet dann selbständig, wann auf wie viele Phasen umgeschaltet wird. Diese Softwareanpassung gibt es öffentlich in Github und in o. g. Thread. EVCC wird mit dieser Schnittstelle allerdings nichts anfangen können, da sie dort vermutlich niemand implementiert hat. Ich kenne bislang nur zwei Fälle, wo mein Umbau nachgebaut wurde. Wenn du also wie schon gesagt mit der manuellen Umschaltung zufrieden bist, dann passt das ja. Für eine Automatik würde ich dir eher den Energy Manager in Kombination mit @poohnets Umbau empfehlen.

Huiuiui, da hast du ja ganz schon was auf die Beine gestellt. Ich habe nur kurz rein gelesen, aber das hat mich schon beeindruckt. Aber nachdem ich zeitlich nicht einmal dazu komme, meinen Fork endlich auf den aktuellen Stand zu bekommen, die Beckhoff-Steuerung auf den Austausch durch den Raspberry wartet und ich weiß nicht noch was alles, mache ich diese Baustelle glaub' nicht auch noch auf. Aber vielen Dank für die Info!

Das kann ich nur bestätigen. Der Support und die Offenheit sind erstklassig. Immerhin muss man sich vor Augen halten, dass Leute wie @poohnet und ich das Originalprodukt doch spürbar umbauen. Und demgegenüber gibt es keinerlei Vorbehalte, sondern wir bekommen auch noch (schnelle!) Unterstützung bei Fragen. Zur CP-Trennung: Ich habe die in der Tat in meiner Lösung noch nicht drin, weil unser Fiat ganz prima ohne sie lädt. Aber mit etwas Spickeln bei Thomas wäre das sicher kein Hexenwerk. Ein Kanal auf dem Industrial Quad Relay Brick ist ja noch frei. Aber @dkp_cobra, wenn ich deinen Eingangspost so lese, dann brauchst du die CP-Trennung ja gar nicht, sondern wärst mit einem manuellen Schalter und Austausch des Stromzählers gut bedient. Letzteren bekommt man schon hin, ich habe meinen Zähler auch nachträglich eingebaut.

Aber grundsätzlich hat die Frage natürlich schon ihre Berechtigung. Never change a running system. Und wie schon gesagt hat die gepostete Version schon noch Lücken im Webinterface.

Die normale Firmware wird nicht funktionieren, weil die drei nachgerüsteten Schütze über das Digital Out-Bricklet angesteuert werden müssen. Laden geht nach dem Umbau daher mit der Standardfirmware nicht mehr. Thomas, du kannst es aber mal mit der angehängten Firmware probieren. Das ist mein aktueller Arbeitsstand, die Phasenumschaltung ist funktional schon drin, nur in der Weboberfläche fehlen noch Dinge (Statuswerte, Kurven im Diagramm). Laden geht aber zumindest bei mir schon damit, du könntest also testen, ob die Ultrakurz-Ladevorgänge damit weg sind. Der oben verlinkte Fix von Eric ist da jedenfalls drin. warp_firmware_2_1_3_64c2c604_299e3bddd9d2e98_merged.bin

Du kannst ja mal bei Gelegenheit das Verhalten an einer "normalen" Ladesäule beobachten, wenn du AC lädst und der eingestellte SOC erreicht wird. Wenn die Säule dann auch noch "Ladevorgang aktiv anzeigt", dann scheint das das normale (und für mich durchaus nachvollziehbare, siehe oben) Verhalten des Autos zu sein. Von unserem Fiat kenne ich das Verhalten nicht, er unterstützt aber (leider) das Einstellen eines Ziel-SOC auch nicht.

Nach einem verklebten Schütz sieht mir das nicht aus, Phase 1 wurde ja weiterhin angesteuert. Das passt auch zum Status "Ladevorgang aktiv". Vermutlich regelt das Auto bei Erreichen des eingestellten SOC lediglich den Strom auf Null runter, ohne die Ladung an sich zu beenden. Denn das würde m. W. auch dazu führen, dass der Stecker entriegelt wird und jemand das Kabel klauen kann. Im Ladelog wird der Vorgang auch erst als beendet aufgezeichnet, wenn der Stecker abgezogen wird. Dazu gab es schon einige Rückfragen hier im Forum und entsprechende Erklärungen der Jungs von TF. Aus meiner Sicht gibt es hier keinen Grund zur Sorge, scheint mir alles normal zu sein. Das Verhalten hat auch nichts mit der Phasenumschaltung zu tun, insofern driften wir hier etwas Richtung Off Topic.

Also so unkonventionell ist der WARP Charger doch auch nicht. Meiner Erfahrung nach zieren sich die Elis halt häufig, beigestelltes Equipment zu verbauen. Dann fällt halt die Marge beim Material weg, das mögen sie nicht so. Auch wenn man darum bittet, sämtliche Arbeiten nach Aufwand und zu für sie fairem Preis zu berechnen. Bei uns gibt es auf auf der Seite unseres Verteilnetzbetreibers ein Verzeichnis von eingetragenen Elektrikern, die habe ich einfach im Umkreis von x km abtelefoniert. Viele waren ehrenkäsig, einer war dann aber doch dabei, der sich nicht so angestellt hat. Hat sich sogar für den WARP Charger interessiert, da seinerzeit lieferbar. 😄

Ich schiebe immer einen neuen Sollwert rüber, wenn er sich gegenüber dem vorherigen Wert um mindestens 50 W geändert hat. Auf die Unter- und Obergrenzen nehme ich dabei keine Rücksicht, die Schalterei überlasse ich der Phasenumschaltung. Dann sehe ich in der Weboberfläche der Box auch immer, welche Leistung gerade verfügbar wäre, auch wenn sie nicht ausreicht.

Der Mindestladestrom beträgt laut Norm/Standard/Wasauchimmer 6 A. Es wird also von ein- auf dreiphasiges Laden umgeschaltet, wenn die Ladeleistungsvorgabe >= 3 * 6 A * 230 V = 4140 W ist UND die Mindestdauer erreicht ist UND die Leistungsvorgabe ununterbrochen für die Verzögerungszeit über dem Grenzwert lag. Von drei auf eins umgekehrt, sobald die Mindestleistung für dreiphasiges Laden unterschritten wird (und die Verzögerungen abgelaufen sind). Sowohl rechnerisch wie auch real ist die Phasenumschaltung in deinem Fall außen vor, die 7 kW sind noch dick über der Umschaltgrenze, und auf deinem Video sieht man, wie konstant drei Phasen angefordert werden. Warum der Ladevorgang abbricht bei geänderter Leistungsvorgabe, lässt sich nicht sagen. War vielleicht der Sprung zu groß, evtl. ist der Enyaq hier zickig? Hast du mal ins Log geschaut, was da steht? Noch was: Warum 12 kW Ladeleistung? Hast du eine 22 kW-Variante der Warp? Und selbst wenn, dein Auto kann m. W. nur 11 kW AC laden.

Und kannst du in dem Adapter dann den Endpunkt für die Leistungsvorgabe nutzen? Der kommt ja von meinem Modul und wird von der Serien-FW nicht unterstützt.

Hi @ThomKa, nein, tut mir leid. Mit ioBroker kenne mich nicht damit aus, ich nutze den aktuell nicht. Aber hier hat jemand einen Adapter geschrieben, der einen HTTP PUT verwendet. @deepflyer911, mit was steuerst du die Wallbox denn an?

Das kann ich mir auch gut vorstellen, ist bei unserem Fiat auch so. Der geht auf Störung, wenn ich ihm zwei Phasen gebe. Ich fahre daher im 1/3-Phasenbetrieb. Hast du es damit mal probiert?

@ThomKa: HTTP PUT (nicht POST!) auf <IP der Wallbox>/phase_switcher/available_charging_power Body: { "power": 1234 } Im Browser kannst du das m. W. nicht einfach so testen. Ich nehme dazu immer Postman, da geht das sehr gut. Bzgl. Ethernet Brick sehe ich das ähnlich wie deepflyer. OCPP ist nach meiner Kenntnis das einzige Feature, das auf der WARP1 nicht geht. Das dient zur standardisierten Abrechnung, z. B. gegenüber dem Arbeitgebere - brauche ich nicht. Die Phasenumschaltung lässt sich vermutlich minimalinvasiv in poohnets Fork mergen oder umgekehrt. Aber das muss dann jemand machen, der das auch testen kann. Aber ich habe aktuell nicht vor, mir den Brick zu kaufen und die Box umzubauen. Und poohnet wird wiederum seine Box eher nicht für die Phasenumschaltung umbauen. Insofern: Erstmal nicht, zumindest nicht von meiner Seite.

Ich mache die Sollwertvorgabe ganz ähnlich wie von @deepflyer911 beschrieben: AvailableChargingPower := MAX(WallboxData.iPower + REAL_TO_INT(AvailablePower - MAX(PowerFromBattery, 0)), 0); Sollwert Ladeleistung = MAX(aktuelle Ladeleistung + (verfügbare Leistung am Einspeisepunkt - MAX(Leistung von Batterie, 0)), 0) Das Ergebnis glätte ich (gleitender Mittelwert über zehn Werte) und schreibe nur dann einen neuen Wert zum Warp Charger, wenn sich der resultierende Wert um mindestens 50 W geändert hat. Einfach, um das Ganze nicht zu nervös werden zu lassen. Die tatsächliche Ladeleistung liegt bei mir eh meist >100 W unter der Vorgabe, möglicherweise bedingt durch die Netzspannung oder - wahrscheinlicher - der Laderegler im Fiat ist eher defensiv. Schaltzeiten: 300/300/300/30 s. Aber erst seit die Hausbatterie installiert ist, da fange ich Schatten eine gewisse Zeit darüber ab, ohne runter zu schalten. Vorher hatte ich dafür auch 60 s hinterlegt. Mit kürzeren Zeiten waren mir das zu viele Unterbrechungen, und manchmal hat das Auto auch angefangen rumzuzicken und ist ganz auf Störung gegangen. Ich bin übrigens gerade dabei, meinen Fork auf den aktuellen Stand zu bringen. Das Backend habe ich soweit, die Seiten für das Frontend muss ich so gut wie neu bauen. Aber Stück für Stück geht es voran. Melde mich, wenn ich was zum Testen habe.

Das Ladestandsmodul bringt euch nichts, es funktioniert nur mit Fiat. Die Wallbox fragt in einstellbaren Intervallen über das Internet den Ladestand des Autos bei der Fiat-Cloud ab. Ich nutze das, um den Ladevorgang bei Erreichen eines einstellbaren Ladestands abbrechen zu können und nicht immer voll zu laden. Das Ganze war aber ziemlich aufwändig, und in der Rückschau würde ich es vermutlich nicht noch einmal so umsetzen sondern eher EVCC nutzen, das eine große Zahl von Autoherstellern schon unterstützt. Hatte mich halt an dem Thema festgebissen und wollte mich nicht geschlagen geben. Aber wie gesagt, euch bringt das leider nichts, da VW und nicht Fiat.

Hallo ihr beiden, sorry, dass ich so schweigsam bin - irgendwie ist weiterhin viel los, keine Ahnung, wohin meine Zeit verschwindet. Zu den MQTT-Abbrüchen: Dazu kann ich nicht wirklich etwas sagen, da ich MQTT (noch) nicht nutze (ich schiebe den Ladeleistungs-Sollwert per HTTP PUT rüber). Ich hatte während der Entwicklung zeitweise Probleme, dass die ganze Kiste nicht mehr erreichbar war; das hing aber mit den HTTPS-Abfragen im Ladestandsmodul zusammen, das ich mir noch gebaut habe. Bei euch ist das ja gar nicht aktiv, insofern halte ich einen Einfluss von der Seite für sehr unwahrscheinlich. Um sicher zu gehen, kann ich aber bei Gelegenheit mal eine Version auf dem jetzigen Codestand bauen, in der das ganze Modul entfernt ist. Grundsätzlich mache ich am Thema Warp aktuell aus Zeitmangel aber nichts. Meinen Fork mal auf den aktuellen Stand nachzuziehen, habe ich schon länger geplant. Aber Eric und Kollegen haben das Frontend massiv umgebaut, so dass dieser Schritt nicht mal eben gemacht ist, sondern ziemlich Zeit in Anspruch nehmen wird. Deshalb schiebe ich das noch vor mir her.