mattsches

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

Du meinst, dass du die Schnellladung nicht über das Web Frontend starten kannst? Ja, das ist so. Habe ich mir vor einiger Zeit als Idee aufgeschrieben, aber noch nicht umgesetzt. Oder startet der normale (=nicht schnell/Überschuss-)Ladevorgang nicht trotz Leistungsvorgabe? Dann könntest du mal schauen, ob nach dem Einstecken unter "Ladecontroller" bei "Externe Steuerung" noch "blockiert" steht. Wenn ja, dann bitte mal die Leistungsvorgabe checken (ausreichend?). Wenn ja, dann mal die "Externe Steuerung" freigeben und schauen, ob der Ladevorgang startet. So soll das natürlich nicht sein, ich hatte die Situation auch schon. Zwischenzeitlich nicht mehr, aber der Fix verursachte dann andere Probleme.

Hast du Autostart aktiviert? Dann startet die Ladung automatisch, sobald es die Leistungsvorgabe zulässt (also bei 6 A * 230 V = 1380 W und nach Ablauf der eingestellten Verzögerungszeit). Schnellladen geht durch Drücken des Tasters für >2 Sekunden. Ich habe zwischenzeitlich aber ein paar Änderungen vorgenommen, um das Umschaltverhalten zu verbessern. Ich hänge hier mal meinen aktuellen Entwicklungsstand rein. Der ist allerdings noch ungetestet (war heute nicht zuhause). Wann was nicht tut, einfach wieder auf den alten Stand 633aea44 zurück flashen. warp_firmware_2_0_7_6362e2b2_merged.bin

Anbei mal mein aktueller Entwicklungsstand, wie ich ihn gerade auf Github eingecheckt habe. Ich habe einige Änderungen vorgenommen, um das Umschaltverhalten etwas zu optimieren. Das Ganze gibt es aber wie schon mehrmals erwähnt ohne Gewährleistung und ohne jedes Versprechen auf zukünftige Updates. Die baue ich zwar immer wieder, doch werde mich nicht festlegen, in welcher Frequenz und wie lange ich das mache. Mein Beitrag hier im Forum richtet sich vorrangig an diejenigen, die sich in der Lage sehen, zur Not selbst Hand anzulegen. Daher nochmal ausdrück die Warnung - auch an andere, die hier vielleicht mitlesen: Verwendung auf eigene Gefahr! Und noch ein Hinweis: Wenn der Umbau gemäß meinen Angaben oder der demnächst von @ThomKa erscheinenden, sehr guten Anleitung vorgenommen wurde, kann die Standard-Firmware die Schütze nicht mehr ansteuern. Der Weg zurück ist natürlich nicht verbaut, aber er erfordert den Umbau zurück auf das vierpolige Schütz mit 230 V-Spule. Wen das alles nicht abhält: Die angehängte Firmware lässt sich ganz normal über das Web-Frontend einspielen. Außer Log-Einträgen, dass die Phasenumschaltung und die Ladestandsabfrage (funktioniert nur für Fiat) deaktiviert wurden, wird man jedoch keinen Effekt feststellen, solange der Umbau nicht erfolgt ist. Die entsprechenden Seiten im Frontend sind dann gar nicht erst sichtbar. Denn die Firmware erkennt, wenn die beiden zusätzlichen Bricklets nicht angeschlossen sind, und aktiviert die Softwaremodule erst gar nicht. Noch eine Frage: Du schreibst Welchen Link meinst du denn genau? warp_firmware_2_0_7_633aea44_merged.bin

Nun ja. OCPP wurde beim Kauf nicht als Feature beworben. Open Source heißt m. E. nicht, dass jedes beliebige Feature nachgerüstet werden kann. Und OPCC und seine Auswirkungen auf die benötigten Ressourcen waren bei Tinkerforge möglicherweise gar nicht auf dem Zettel, als die WARP1 entstand. Daraus nun einen Vorwurf zu formulieren, finde ich persönlich (als WARP1-Besitzer) nicht ganz fair. Die Box wurde und wird aus meiner Sicht zu einem sehr fairen Preis verkauft. Bei anderen Anbietern bekommt man entweder eine Black Box, die möglicherweise gar keine Updates erfährt, oder die Kiste ist um ein paar Hunderter teurer. Hier dagegen wird man sogar dabei unterstützt, einen Stromzähler nachzurüsten, die Firmware selbst zu erweiteren oder eine WARP1 auf WARP2 umzubauen. Ganz ohne Eitelkeiten und immer sehr hilfsbereit. Das suche man mal anderswo. Letzteres (Umbau auf WARP2) könnte ja eine Option für dich sein, wenn OPCC für dich essenziell ist. Im Forum gibt es dazu Einträge, einfach mal suchen.

Nur als Denkanstoß, ohne dich von dem Vorhaben abbringen zu wollen: Ich nehme einen dreiphasigen Heizstab und schalte die drei Stäbe einzeln zu. Wenn ich zwei oder gar drei Stäbe in Reihe schalte, komme ich mit der Leistung dann recht weit runter. Beispiel mit 4,5 kW-Stab = 3x1,5 kW: Alle Stäbe in Reihe = 500 W Zwei Stäbe in Reihe (dritter aus) = 750 W Ein Stab an = 1,5 kW Ein Stab plus zwei in Reihe = 2,25 kW Zwei Stäbe parallel = 3 kW Drei Stäbe parallel = 4,5 kW Das ist weniger genau aber ungleich einfacher als eine Schwingungspaketsteuerung. Und hinsichtlich der erforderlichen Komponenten deutlich günstiger. Aber das nur so als Gedanke.

@rtrbt: Vielen Dank für die Erklärung! Ich komme aus der (Maschinen-)Steuerungsprogrammierung. Monoflops kannte ich zwar als Begriff, doch in der Steuerungstechnik sind mir die nie begegnet. Ich werde das mal wie von dir vorgeschlagen einbauen, dann sollte ich das Schalten hoffentlich erledigt haben. Aktuell bin ich noch damit beschäftigt, eure Refactorings nachzuziehen...

@rtrbt: Ich dachte eigentlich, ich hätte das im Sack. Habe aber nun - mit einiger Verspätung - festgestellt, dass bei einem Reboot und auch wenn das Programm an anderer Stelle (HTTPS Request in meinem SOC-Modul) etwas länger braucht, alle vier Ausgänge des Bricklets angesteuert werden. Mein Code sah so aus: void PhaseSwitcher::write_outputs() { static Config *evse_low_level_state = api.getState("evse/low_level_state", false); if (evse_low_level_state == nullptr) return; bool evse_relay_output = evse_low_level_state->get("gpio")->get(3)->asBool(); bool channel_request[4] = {false, false, false, false}; if (evse_relay_output && !contactor_error){ if (enabled){ switch (requested_phases) { case 0: break; case 1: channel_request[1] = true; break; case 2: channel_request[1] = true; channel_request[2] = true; break; default: channel_request[1] = true; channel_request[2] = true; channel_request[3] = true; break; } } else if (!enabled){ channel_request[1] = true; channel_request[2] = true; channel_request[3] = true; } } int retval; for (int channel = 0; channel <= 3; channel++) { retval = tf_industrial_quad_relay_v2_set_monoflop(&quad_relay_bricklet.device, channel, channel_request[channel], 1000); if (retval != TF_E_OK) { logger.printfln("Industrial quad relay set monoflop failed for channel %d (rc %d).", channel, retval); return; } } } Die Ausgänge werden also zyklisch beschrieben mit dem zuvor jeweils ermittelten Wert. channel_request[0] wird nur initialisiert, aber nie beschrieben (Ausgang wird nicht genutzt). Wenn dieser Abschnitt so aktiv ist, gehen wie schon gesagt alle vier Ausgänge des Bricklets beim Reboot auf True und fallen wieder ab, sobald das Programm gestartet ist. Nehme ich die letzte Schleife mit den Monoflop-Aufrufen raus und rufe das Monoflop einmalig in einer Testroutine auf, dann bleibt der Ausgang für die parametrierte Zeit aktiv, fällt dann ab und bleibt auch beim Reboot aus. Irgendwie stehe ich auf dem Schlauch, ich komme nicht drauf, wo mein Denkfehler liegt. Hast du mir vielleicht einen heißen Tipp? Vorübergehend habe ich wieder auf tf_industrial_quad_relay_v2_set_value umgestellt. Aber das Monoflop wäre ja schon besser. Danke & Gruß, Matthias