mattsches

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.

Oh, cool - habe gar nicht gewusst, dass GitHub auch als Buildserver genutzt werden kann. Aber vielleicht bin ich diesbezüglich auch zu sehr Noob. Probiere ich aus, wenn ich wieder an die Box gehe. Zur Zeit ruht das Projekt wegen anderer Themen. Aber danke für den Tipp!

Kurzes Update: @deepflyer911 hat mich auf ein Problem bei der Schützüberwachung aufmerksam gemacht, bei laufendem Ladevorgang wurde das Ereignislog mit sinnlosen Einträgen geflutet. Zudem war bei dem zuvor verlinkten Stand noch der Debug-Modus aktiv, was zu weiteren Logeinträgen geführt hat. Anbei ein Stand, in dem das gefixt ist. warp_firmware_2_0_7_644ff009_merged.bin

Um das kurz zu präzisieren (sorry für die Erbsenzählerei): Der Ladestrom wird bei Typ 2 nicht über einen Widerstandswert übertragen, sondern über ein puls-Weiten-moduliertes Signal an CP. Die Widerstände kommen zum Einsatz, um den Maximalstrom des Kabels zu signalisieren (zwischen PP und PE) und den Status des Autos (angesteckt, ladebereit etc., zwischen CP und PE). Die bei EVCC erwähnte Erkennung des Autos über das Kabel bezieht sich auf die ISO15118, die bislang nur vereinzelt unterstützt wird. Daher liest man in der EVCC-Doku auch: Bei dir wird ziemlich sicher die Erkennung über den Ladestatus aktiv sein: Ich würde mir mal die MQTT-Kommunikation zwischen den beiden Boxen und EVCC genauer anschauen (wenn das denn geht, ich nutze EVCC nicht). Vielleicht lässt sich da ja ein Unterschied feststellen, der das abweichende Verhalten erklärt.

Was EVCC ja macht. Oder meine gepimpte Warp1 auch direkt. Allerdings nur für Fiat, hilft dir also nix. Die Ladevorgabe in kWh oder Zeit wäre natürlich leicht umzusetzen. Allerdings heißt das, bei jedem Ladevorgang die Webseite der Box zu öffnen und die Vorgabe abhängig vom aktuellen Ladestand anzupassen. Wobei dieser in unserem Auto wiederum nur in Prozent angezeigt wird, es wäre also Kopfrechnen angesagt. Kein wirklich komfortables Setting. Wenn man es komfortabler haben aber sich nicht so spinnert tief in die Warp Firmware reingraben möchte wie ich (das sei als Warnung zu verstehen, ein echtes Zeitgrab), dann ist EVCC auf einem Raspi sicher eine gute Option. Wobei die Beschaffung von letzterem zur Zeit eine Herausforderung darstellt.

Stellt sich iebFrage, ob hier der richtige Ort dafür ist oder ob das nicht eher ins EVCC-Forum gehört. Scheint ja eher ein allgemeines Problem mit der Konfig zu sein denn Warm-spezifisch. Oder?

@poohnet Wieder was gelernt, sehr interessant! Cool, was die Box doch alles kann bzw. was Erik und Kollegen da schon alles rein gebaut haben. @SRHA Für dich zur Info, weil ich es gerade greifbar habe (hatte mich interessiert): https://www.warp-charger.com/api.html?v=2#reference-meter

Das unterstützt die Firmware meine Wissens nicht. Aber EVCC hat laut https://github.com/evcc-io/evcc/pull/4162 ein eigenes Ladelog. Ist es da nicht ein wenig um die Ecke gedacht, der Box dann den in EVCC schon bekannten Zählerstand unterzuschieben, damit die ihn dann loggt?

Die Schütze passen grundsätzlich (2 Schließer). Du sagst ja, dass nur auf den Meldekontakten (Klemme 4) Spannung (also 12 V?) anliegt, nicht aber an den Klemmen 2. Auch das spricht gegen ein Verkleben der Kontakte, auf 3 und 4 ist ja keine nennenswerte Last. Sehr seltsam. Im komplett ausgebauten Zustand ist die Verbindung 2-4 also jeweils geschlossen? Das würde wirklich auf einen Defekt hindeuten.

Die Überwachung der Schütze ist recht simpel: Wenn ein Schütz angesteuert wird, muss innerhalb von zwei Sekunden die Rückmeldung anliegen, dass es angesteuert ist. Und umgekehrt. Die Rückmeldung für das erste Schütz wird wie vor dem Umbau durch das EVSE-Bricklet geleistet. Hier wird L1 ausgangsseitig ausgewertet, ich hole mir den Zustand zyklisch über das API des EVSE-Bricklets. Die Rückmeldungen für das zweite und das dritte Schütz werden über die jeweils zweiten Kontakte der Schütze geliefert, die auf das Industrial In-Bricklet verdrahtet sind. Angesteuert wird Schütz 1, wenn das EVSE-Bricklet seinen für das ursprünglich verbaute Schütz gedachten Ausgang setzt (evse/low_level_state.gpio[3], siehe hier). Schütz 2 und 3 nur dann, wenn mit zwei oder drei Phasen geladen werden soll. In deinem Log sieht man, dass sofort die Schützüberwachung für L2 und L3 anspricht. Der Zustand der betreffenden Eingänge passte also nicht zu den Ausgängen. Etwas unschön ist, dass die Meldung zyklisch ausgegeben wird, das spamt das Ereignislog zu. Ich habe das in der angehängten FW mal dahingehend geändert, dass nur bei kommendem und gehendem Fehler Logeinträge geschrieben werden. Mich wundert, dass bei dir die Schütze kaputt gegangen sein sollen. Es kann schon sein, dass Kontakte von Schützen hängen bleiben (man spricht von Verkleben). Aber das passiert üblicherweise, wenn die Ströme zu groß sind und unter Last (also bei Stromfluss) geschaltet wird. Beides ist in der WARP nicht der Fall. Der Strom wird - durch entsprechende Vorgabe ans Auto - erst hochgeregelt, wenn die Schütze geschaltet haben. Und beim Beenden der Ladung umgekehrt. Poste doch mal hier die genauen Typbezeichnungen deiner drei Schütze. Wenn sie (genau!) identisch sein sollten, reicht natürlich eine. warp_firmware_2_0_7_63fe5aa3_merged.bin

Zuletzt habe ich November noch was gefixt, der Stand war hier noch nicht gepostet. Im Anhang findet ihr daher den aktuellsten Build vom 14.11.22 (die Commit Messages könnt ihr natürlich auch auf Github sehen). Aufgefallen ist mir kürzlich noch, dass das Schnellladen über Taster nicht getan hat und dass bei einem Ladestopp durch das Auto (mache ich selten, ich stoppe i. d. R. über mein SOC-Modul in der Box) der Fehlerspeicher mit Meldungen geflutet wurde (Endlosschleife). Aber letzteres war nach Abstecken des Autos erldigt und das Schnellladen ließ sich glaub durch manuellen Start über die Weboberfläche anschmeißen. Insgesamt waren mir die Bugs nicht gravierend genug, um mich sofort dranzusetzen. Ich bin gerade an einem anderen Thema und möchte - wenn ich den Warp wieder angreife - gleich auf Eriks aktuellen Entwicklungsstand gehen. Das wird durch seine Umbauten allerdings eine größere Sache, fürchte ich. In der Vergangenheit habe ich diese Erfahrung zumindest schon gemacht. warp_firmware_2_0_7_637181f3_merged.bin

Du könntest das Defekte Schutz mit einem der beiden anderen tauschen, am defekten abgangsseitig das Kabel abgeklemmt lassen und dann einphasig laden, bis der Ersatz da ist.

Jo, dann ist das Schütz wohl hin. Von der Software kann es nicht kommen, die kann verklebte Kontakte auch nicht heilen. Mich wundert es aber, du hast dich auch die Finder Schütze drin, oder? Und es wird ja noch nicht einmal unter Last geschaltet, so dass es zu einem Lichtbogen kommen könnte. Den richtigen Typ hast du? Also zwei Schließer. Muss ja eigentlich so sein, du hattest ja geschrieben, dass die Box eine ganze Weile getan hat... Ich würde das Schütz reklamieren, ist ja noch nicht alt.

Ach, und falls du dich über die nicht funktionierende Ladestandsabfrage wundern solltest (ich habe gesehen, dass du deine FIN eingetragen hattest): Die geht nur mit Fiat. Das liegt daran, dass auf die Daten der Fiat-Cloud zugegriffen werden. Mit Fahrzeugen anderer Hersteller kann das natürlich nicht gehen. In EVCC gibt es m. W. aber für verschiedene Fabrikate Softwaremodule.

Das klingt tatsächlich so, als ob zumindest eines der Schütze Mucken macht. Wenn die Ausgänge alle abgesteuert sind (Auto abgesteckt, LEDs aus), am Kanal 2 des Digital In-Bricklets aber die LED leuchtet, dann dürfte das Schütz der Phase 3 noch geschlossen sein. Das würde ich mal nachmessen, sowohl am 12 V- wie auch am 230 V-Kontakt. Nicht schlüssig ist für mich, dass ein Kontaktfehler auf Phase 1 und 2 gemeldet wurden. Alles wie gesagt in der Annahme, dass das Auto abgesteckt ist. Testweise würde ich die Box mal stromlos machen und dann neu starten. Wobei ich nicht von einem Softwareproblem ausgehe. Denn du hast ja schon geschrieben, dass du eine ganze Zeitlang keine Probleme hattest. Übrigens: Schütz = starkes Relais = elektrisch angesteuertes Schaltelement Schutzschalter hast du im Zählerschrank (LS = Leitungsschutzschalter), nicht aber in der Wallbox.

Hi Erik, danke für die Info! Dann behalte ich das mal im Hinterkopf und beobachte eure Commits weiter.

Das Sollverhalten ist so: * Einstecken bei ausreichend Leistung: Ladung startet sofort * Einstecken ohne ausreichend Leistung: Der Ladecontroller geht in "Warte auf Freigabe" und die Phasenumschaltung auf "Standby". Sobald die Mindestleistung (230 V * 6 A = 1380 W) ununterbrochen für die eingestellte Verzögerungszeit überschritten wurde, startet der Ladevorgang automatisch. Das alles gilt, wenn der automatische Ladestart (Funktion der Standard-FW) aktiv ist. Bei zu wenig Leistung wird nach Ablauf der Verzögerung unterbrochen und später wieder automatisch gestartet. Die Freigabe der externen Steuerung ist eine Funktion der Standard API, die z. B. von EVCC genutzt werden kann (https://www.warp-charger.com/api.html?v=2#evse_slots). Damit lässt sich der Ladestrom von außen vorgeben. Ich nutze das für die Vorgabe durch die Phasenumschaltung, du kannst aber natürlich auch von außen darauf schreiben. Mein Ziel ist aber, dass das von dir beobachtete Verhalten gar nicht erst auftritt. Mit der Version von gestern sollte das auch gefixt sein.

HI @rtrbt, in letzter Zeit hast du das Frontend ja auf Preact umgestellt. Muss ich das mit meinen Modulen so nachturnen, wenn ich auf den aktuellen Stand gehe, oder funktionieren meine Frontend-Seiten weiter wie bisher? Danke & Gruß, Matthias

Ja, der Fehler ist mir bekannt. Wenn man bei ausreichender Ladung (und Ablauf der Verzögerungszeiten) erst einsteckt und Autostart aktiv hat, dann startet das EVSE nicht durch, weil ich ihm Sollwert 0 A als Vorgabe schicke ("Externe Steuerung"). Ich hatte das schon gefixt, aber das hatte andere unschöne Seiteneffekte. Ich habe das nun nochmal überarbeitet, kannst du bitte mit der angehängten Version nochmal testen, ob es nun besser ist? Ich bin morgens unterwegs und kann daher die Kiste mittags nicht anstecken, wenn was vom Dach kommt. Danke! warp_firmware_2_0_7_6369622d_merged.bin