borg

Solange du an EVCC nichts änderst und es kein Bug bei uns in den Config-Migrationen gibt wird alles noch so funktionieren. Du musst nichts umbauen. Der Fehler deutet auf ein defektes DC-Schutzmodul hin, ich würde da allerdings nichts austauschen wollen solange wir nicht mit einer neuen Firmware das Problem reproduziert haben, auch wenn du lange keine Probleme hattest.

Bitte einmal auf die neuste Firmware aktualisieren und dann schauen ob die Probleme noch auftreten. Da es ein Fehler mit dem DC-Fehlerstromsensor ist hilft das Update schon alleine weil wir dort die Debug-Ausgaben verbessert haben.

Nach unserer Erfahrung ist die Willkommensladung bei MEB-Platform Autos notwendig. Du könntest eventuell zum Testen das PV-Überschussladen über die WARP4 machen lassen (und EVCC, HA ausstellen). Dann ist sichergestellt das es eine Willkommensladung gibt und du kannst testen ob es die Probleme behebt. Der Fahrzeug-Weckruf bei der WARP4 wird automatisch ausgeführt wenn du von 0A auf >0A wechselst und er besteht aus einem vierstufigen Prozess. Es wird zuerst CP getrennt für 4s, dann 30s gewartet, dann CP getrennt für 30s, dann 30s gewartet, dann wird für 4s state E/F erzwungen, dann 30s gewartet, dann wird für 30s state E/F erzwungen und danach geben wir auf. Für gewöhnlich beginnt die Ladung bereits nach der ersten CP-Trennung. An der Stelle ist wichtig: Wenn du Fahrzeug-Weckruf in der WARP4 aktivierst würde ich nicht zusätzlich noch weitere "Wakeup-Features" bei EVCC oder HA aktivieren. Zwei gleichzeitig laufende Weckrufe die irgendwie undefiniert miteinander interagieren wird nicht robust funktionieren.

Für die Leute bei denen der Passwortmanager beim normalen Browser die Eingabefelder nicht erkennt bitte einmal die Firmware im Anhang testen. Für die Apps braucht es erst ein neues App-Release damit das automatisch funktioniert. Edit: Veraltete Firmware entfernt.

Mittelfristig ist das geplant, allerdings stehen davor noch jede Menge andere Features auf der TODO-Liste, daher kann ich da keine Zeitabschätzung machen oder ein Datum angeben o.ä. Planen müsstet ihr also definitiv erstmal ohne.

@becmar39 Ich hab einen Thread für dich aufgemacht: https://www.tinkerunity.org/topic/13899-sammelthread-autos-die-nach-dem-soc-auslesen-keine-ac-ladung-starten/ Dann können wir das ein bisschen trennen. Das Problem was Hawell hat ist ein anderes (und mit der Firmware oben voraussichtlich bereits behoben).

Da wir neben den Teslas jetzt auch zumindest noch einen Opel mit dem Problem haben, machen ich mal ein extra Thread dafür auf. Anbei eine Firmware welche Konfigurationen zum Testen von unterschiedlichen Optionen zum "Aufwecken" des Autos nach dem auslesen des SoC bereitstellt: Zum Testen müsstet ihr das Auto abstecken, SoC auslesen aktivieren (Autocharge kann ausbleiben), eine experimentellen Konfigurationen wählen, dann speichern, dann das Auto anstecken und dann bitte ~5 Minuten warten um zu sehen ob das Auto anfängt zu laden. Bitte nicht nur ein paar Sekunden warten. Dabei könnt ihr unterschiedliche Kombinationen testen, sinnvoll sind fünf Varianten: Neuverbindung Neuverbindung + Autocharge-Variante Neuverbindung + E/F Reset Neuverbindung + Autocharge-Variante + E/F Reset E/F Reset Wenn ihr nichts aktiviert entspricht es der Release-Firmware. Wenn ihr testen wollt bitte PV-Überschussladen/Lastmanagement/EVCC usw deaktivieren, damit es nicht passieren kann dass das Auto nur nicht lädt weil es von irgendetwas anderem blockiert wird. Wenn ihr "SoC immer lesen" aktiviert, wird die Sonderbehandlung für Teslas rausgenommen. Für die Leute die mit ihrem Tesla auch noch einmal testen wollen. Ziel ist es eine Kombination zu finden die funktioniert. Wenn es diese gibt würde ich Sonderbehandlung für den Onboard-Charger-Typ des Autos einbauen die das entsprechend abbildet (nur für diesen OBC). warp4_firmware-NIGHTLY_2_13_1_6aa41e7e_3ae311b69598585_ota.bin

Von den Logs her sieht es so aus als hättest du Autocharge aktiviert und es dauert ca. 3 Minuten nachdem das Auto erkannt wird bis die Ladung anfängt. Die Ladung wurde sofort freigegeben in dem Fall von der WARP4 und das Auto hat dann etwas gebraucht bis es angefangen hat zu laden. Ich befürchte damit verhält sich der Fiat sogar noch Standardkonform. Nichtsdestotrotz solltest du nochmal mit der Firmware testen die wir voraussichtlich kommende Woche Veröffentlichen (und damit auch nochmal Debug-Report und Ladeprotokoll machen). Wir haben da für das Autocharge noch ein paar Verbesserungen eingebaut, eventuell verhält sich der Fiat dann anders.

Der DSZ16DE wird in einem OEM Produkt (unsere Ladeelektronik in einem Fremdprodukt) eingesetzt und dort baubedingt "falschrum" angeschlossen, daher aktivieren wir das"Messrichtung umkehren"-Register in der Firmware. Das hatte ich im März als ich dir geschrieben hab dass der DSZ16DE funktionieren sollte nicht auf dem Schirm. Du kannst das im Menü im Display zurückstellen, aber beim nächsten Firmware-Update oder wenn die Box das nächste mal aus anderen Gründen neustartet würde unser EVSE das wieder zurücksetzen. D.h. ich befürchte du müsstest das einmal um-verkabeln 🙈.

Wie rum hast du ihn eingebaut?

Keine Angst, wir sind da auf dem laufenden. Hab die ISO 15118-20:2022/Amd1 direkt am Tag der Veröffentlichung gekauft 🙂. Rein vom Ablauf her müssen wir aber zuerst die ISO 15118-20:2022 zertifizieren lassen. Erst mit der Zertifizierung können wir eine Verbindung zum Auto aufbauen (wenn das Auto auch die "-20" unterstützt und zertifiziert ist). Das "Amendment 1" kommt dann oben drauf.

Ich hab es mir aufgeschrieben mir das nochmal anzuschauen wenn wir das nächste mal Änderungen an der App machen. Ich hätte aber eigentlich gedacht dass der normale Password Manager der bei Android integriert ist dort auch funktioniert. Sollte genauso behandelt werden als wenn du im normalen Browser die Webseite besuchst.

Nur für mein Verständnis: Bei der Lösung 2 wären die vier Zähler dann die Zähler der 4 Parteien im Haus, richtig? In dem Fall würde sich Lösung 2 dann eigentlich anbieten da es die Abrechnung so viel einfacher macht. Es wäre dann so dass man dynamisches Lastmanagement für die 63A am Gesamtanschluss konfiguriert und für die einzelnen Anschlüsse müsste man pro Wohneinheit schauen wieviel Strom dort übrig ist für die Vorsicherungen und die jeweilige Wallbox auf diesen Strom als Maximum begrenzen. Wir können leider aktuell kein "hierarchisches dynamisch Lastmanagement" machen wo es einen Hauptzähler gibt auf den man dynamisch regelt und einen Zähler pro Wallbox auf bei den man auf andere Zähler dynamisch regelt.

@Hawell Bitte einmal mit der Firmware im Anhang probiere. Edit: Veraltete Firmware entfernt.

@VanDa: Es ist bei Tesla leider aktuell nicht möglich den SoC auszulesen und danach zu laden. Das fließt beim nächsten Firmware-Release insofern mit ein als dass wir bei Teslas (selbst wenn SoC-auslesen aktiviert ist) diesen nicht auslesen. Ansonsten hoffen wir aktuell auf die ISO 15118-20 (wo SoC auslesen und AC-laden im Standard vorgesehen ist). Wenn die "-20" bei Tesla nicht per Firmware-Update nachgeliefert wird müssen wir schauen ob wir den SoC stattdessen bei Teslas über die Tesla-API holen.

Oh ich vermute die Apps werden das von der Box selbstgewürfelete Zertifikat für https einfach nicht akzeptieren. Nutzt du Android oder iOS?

Wenn du über den Fernzugriff gehst wird das Passwort nicht zusätzlich abgefragt (das einloggen in die App genügt). Wenn du über die App lokal die Seite aufrufst ist es als würdest du sie lokal im Browser aufrufen.

In der Tat hat bisher noch niemand nach belgischen dynamischen Stromtarifen gefragt. Ich hab jetzt "10YBE----------2" als Bidding-Zone für Belgien hinzugefügt (scheint mir die einzige Möglichkeit zu sein für Belgien): https://transparencyplatform.zendesk.com/hc/en-us/articles/15885757676308-Area-List-with-Energy-Identification-Code-EIC https://www.eex-transparency.com/service/glossary Gibt es dann mit dem Firmware Release. Änderungen: https://github.com/Tinkerforge/esp32-firmware/commit/e7fba4393d6787896fdf75d3dd0dfbfe470fd0cd https://github.com/Tinkerforge/warp-charger/commit/abb4211594ba69038caede076782a97af33464e0 https://github.com/Tinkerforge/api.warp-charger.com/commit/6ab16fc28790c9de769bdbb25b654343c630ce15

Ob der ESP prinzipiell funktioniert oder tot ist kannst du ganz einfach testen indem du ihn per USB anschließt. Wenn dann die LED vom ESP anfängt zu leuchten muss es denke ich ein Problem mit der Stromversorgung sein. Die Sicherungen sind bei der WARP1 rechts neben dem 12V Netzteil in diesen schwarzen Hutschienen-Sicherungshaltern (PT 6-HESI):

Doku zu den neuen Funktionen der Apps steht auf meiner TODO-Liste, kommt in Kürze(ish).

Das reicht, sieht im Log tatsächlich nach einem Fehler auf unserer Seite aus (sehe den "SDP Request" vom Auto, aber kein Response von uns). Muss ich mir wieder im Detail anschauen, könnte ein paar Tage dauern bis ich dazu komme.

Bitte nochmal den Debug-Report nachdem es nicht geklappt hat, Danke!

Da können wir aktuell leider nicht viel machen, ändert sich hoffentlich später mit ISO 15118-20. Und VW würde sagen dass ist genau dafür gut damit man zwei unterschiedliche Autos nicht unterschieden kann ...aus Datenschutzgründen. 🙈

Generell gilt: Wenn eine API nicht dokumentiert ist behalten wir uns vor diese in neuen Versionen noch zu ändern. Oft sind es APIs die bei Features genutzt werden welche noch in der Entwicklung sind und wo wir uns noch nicht sicher sind wie eine langfristige stabile API aussehen kann. Die undokumentierte API ist aber nicht Lava. Du kannst jegliche API nutzen wenn du möchtest. Infos zu den nicht-dokumentierten APIs findet Claude sicher am einfachsten im Source: https://github.com/Tinkerforge/esp32-firmware/tree/master/software Könnte nur sein dass du es nach einem Firmware-Update nochmal anpassen musst.

Kannst du einmal unter Wallbox -> Ladestatus -> Ladeprotokoll -> "Start" klicken, dann das Auto anstecken, dann das Problem erzeugen und dann auf Stop. Das Ladeprotokoll dann hier hochladen. Damit können wir dann schauen was in dem Moment wo er die Ladung wieder beendet passiert.