MatzeTF

Weißt du, ob der BMW das an einer Grenze von 16 A festmacht, oder vermutest du das? Meine Vermutung wäre eher, dass „Langsamladen“ einphasig und „Schnellladen“ dreiphasig bedeutet und man somit unterschiedliche Ladeströme für einphasiges und dreiphasiges Laden vorgeben kann. Ladesäulen und Wallboxen bieten in Europa üblicherweise dreiphasiges Laden an und „Ladeziegel“ für zuhause nur einphasiges Laden.

Die WARP2 unterstützt eine sogenannte CP-Trennung, die ein vollständiges Abstecken des Fahrzeuges simuliert. Während die Control Pilot-Leitung (CP) des Typ 2 Steckers getrennt ist, kann man problemlos die Phasen umschalten. Das macht auch der Energy Manager: Ladung stoppen per Ladestrom auf 0, warten bis die Wallbox 0 meldet, CP trennen, warten bis die Wallbox getrennt meldet, Phasen umschalten, CP verbinden und Ladestrom wieder freigeben. Es ist möglich, die Phasenumschaltung selbst zu implementieren, da die CP-Trennung der WARP2 auch per API genutzt werden kann. Das sicher in Loxone zu implementieren wäre dann dir überlassen.

Das hört sich an wie ein bekanntes Problem aus der vorletzten Firmware-Version. Hast du schon Firmware Version 2.1.2 vom 14.04.2023 drauf?

Es gibt in der Firmware-Version auf deinem ESP32 Ethernet Brick noch das Problem, dass bei schlechter WLAN-Verbindung oder bei einem Neustart des Bricks anschließend die Login-Seite angezeigt wird, obwohl kein Passwort eingestellt ist. In dem Fall kann man einfach wieder auf die Startseite des Webinterface wechseln und muss kein Passwort eingeben. F5 hilt nicht, weil dann nur die Login-Seite neu geladen wird. 😉 Wann es ein neues Firmware-Release geben wird, weiß ich aktuell nicht. Falls du das Problem häufiger hast und etwas experimentierfreudig bist, kannst du die angehängte bleeding-edge Firmware einspielen. Damit ist auch das von photron beschriebene andere Problem gefixt. esp32_ethernet_firmware_2_0_2_beta_645b5a60.bin

Sorry, hatte nicht dazugeschrieben, dass ich das bei einem WARP2 Charger ausprobiert hatte. Bei einem WARP(1) Charger könnte der Berührschutz ein Problem sein.

Theoretisch ist bei einem WARP2 Charger zwischen ESP32-Board und Deckel gerade so ausreichend Platz, dass das passen könnte. Bei einem WARP2 Charger Smart könnte auch beim 230V-Klemmblock Platz sein, allerdings würde ich den Piezo 2.0 lieber bei der Kleinspannung statt bei der Netzspannung installieren. Eine offizielle Unterstützung für den Piezo-Speaker ist aktuell nicht geplant und jemand aus der Community müsste das basteln.

Kein Problem. Für Code ist da noch mehr als genug Platz.

Ich glaube, das Problem ist weniger, dass ein bestimmtes Fahrzeugmodell Schuld ist, sondern eher, dass die meisten Hersteller die Toleranzen sehr konservativ auslegen und lieber im Normalfall nicht die komplette Leistung ausreizen, als dass sie riskieren wollen, bei schlechten Wallboxen oder Störungen auf dem Kabel die maximale Leistung zu überschreiten und eine Sicherung rauszuwerfen.

Neben CCS ist auch die Frage: Gibt es die Quasar2 fürs europäische 400-V-Drehstromnetz? Laut den technischen Daten, die ich finden konnte, ist die Quasar2 nur für das amerikanische Einphasen-Dreileiternetz geeignet, wo sie 11,5 kW mit 240 V und 48 A bereitstellt (einphasig bzw. split-phase).

Wenn du lieber direkt benachrichtigt werden möchtest, solltest du MQTT benutzen. Sobald sich irgendein Zustand in der Wallbox ändert, wird ein Update gesendet, auf das du warten kannst.

Du kannst bereits jetzt mit einem WEM zwei (oder auch mehr) WARP Charger steuern. Dabei kannst du auch Phasenumschaltung nutzen, indem du einfach beide Wallboxen hinter das Schütz hängst. Das Problem dabei ist nur, dass du dann eine starke Schieflast im Stromnetz erzeugen kannst, weil beide Wallboxen an der selben Phase hängen. Theoretisch ist es natürlich auch möglich, zwei Schütze an einen WEM anzuschließen, und damit beide Wallboxen im einphasigen Betrieb an unterschiedlichen Phasen hängen zu haben. Ein zusammenschalten von mehreren WEM ist nicht möglich. Du kannst nur einen WEM verwenden, der dann die Gesamtleistung aller angeschlossenen Wallboxen überwacht.

Für dein Problem mit der Namesauflösung über DNS sollten wir eine Lösung haben. Du kannst bei Gelegenheit die angehängte Beta-Firmware testen. Es sollte ausreichen, sie nur auf die Wallbox einzuspielen, die als Lastmanager fungiert. Das würde natürlich bedeuten, dass es noch ein anderes Problem gibt, dessen Ursache uns bisher nicht bekannt ist. 😒 Bitte melde dich wieder, falls das Problem mit der Beta-Firmware weiterhin auftritt. warp2_firmware_2_1_2_643fb258_b968db50121f21e_beta.bin

Wir kümmern uns drum. Anscheinend hängen die nicht aufgelösten Hostnamen und die Nicht-Erreichbarkeit zusammen am selben Problem.

Das ist leider nicht möglich, da der in den Wallboxen verbaute RFID-Leser nur Forum Typ 1-4 + Mifare Classic unterstützt. Wenn ich das richtig sehe, kommunizieren Tokens auf Basis des EM4102 über 125 kHz, wohingegen RFID-Tags nach Forum Typ 1-4 und Mifare-Standard über 13,56 MHz kommunizieren. Sie sind also schon hardwareseitig komplett inkompatibel. Theoretisch sollte es so sein, dass fertig geladene Fahrzeuge mit niedriger Priorität geführt werden und nur dann wieder Strom zugeteilt bekommen, wenn noch was frei ist. Alternativ würden fertig geladene Fahrzeuge auf den Minimalstrom reduziert und der restliche Strom auf andere Wallboxen verteilt. So der Plan. Ist leider noch nicht fertig.

Das ist ein bekanntes Problem, das noch auf unserer Todo-Liste steht. Ist damit gemeint, dass die RFID-Karten ebenfalls bei den Wallboxen eingerichtet werden können, oder dass die Wallboxen in das vorhandene System zur Zugangskontrolle integriert werden sollten?

Was du beschreibst, ist auch das, was wir unter dynamischem Lastmanagement verstehen. Es soll dann für jede Phase einzeln der Strom gemessen werden und nur bei tatsächlicher drohender Überlast auf einer Phase runtergeregelt werden. Wenn sich die erlaubten 33 kW auf die Gesamtleistung beziehen und nicht auf 48 A Phasenstrom, dann würde standardmäßig auch bei Schieflast bis zu 33 kW freigegeben werden, also z.B. auf zwei Phasen je 15 kW und auf der dritten Phase 0 kW. Ist das vom Energieversorger nicht erlaubt, müsste man im WEM den maximalen Phasenstrom auf 48 A stellen und bei Schieflast würden die 33 kW nicht erreicht werden, da mit zwei Phasen zu je 48 A nur maximal 22 kW drin wären. Statisches Lastmanagement bedeutet bei uns, dass man komplett ohne Zähler auskommt, damit man es auch mit den WARP Charger Smart und ohne Zähler am Hausanschluss verwenden kann. Es gibt dann keine Möglichkeit herauszufinden, wie viele Phasen ein angeschlossenes Fahrzeug tatsächlich benutzt.

Da ist leider die Fehlermeldung irreführend. Gemeint sind 16 Benutzer inklusive dem unbekannten Benutzer. Somit können nur 15 Benutzer mit Namen angelegt werden. Edit: Ab der nächsten Firmwareversion wird korrekt gemeldet, dass maximal 15 zusätzliche Benutzer angelegt werden können.

Darauf wird es möglicherweise hinauslaufen. Welche Ladeeinstellungen wären das? Eigentlich muss die Wallbox nicht speziell für ein Fahrzeug eingestellt werden. Aktuell kann auf jeden Fall nur der maximale Ladestrom pro Benutzer eingestellt werden.

Die in WARP2 Charger und WEM verwendete ESP32-Platform hat leider nur sehr begrenzte Ressourcen, weshalb die Anzahl der Benutzer und RFID-Tags auf der WARP2 auf 16 begrenzt ist. Der WEM hat einige der Funktionen der WARP2 nicht (z.B. OCPP, was ein großer Speicherfresser ist), sodass dort mehr Ressourcen frei sind, um in Zukunft mehr Benutzer und RFID-Tags zu verwalten. Aktuell nicht. Es wird im Moment nicht zwischen Statusseite und Rest des Web-Interface unterschieden. Außerdem können über die Statusseite auch Einstellungen geändert werden, nämlich Ladestrom und Starten/Stoppen eines Ladevorganges. Schauen wir uns an.

Das ist aktuell nicht geplant, allerdings achten wir schon darauf, dass die Kombination ESP32 Ethernet + WARP1 kompatibel bleibt und Bug-Reports von poohnet bearbeiten wir natürlich wie alle anderen Bug-Reports auch, damit es auch wirklich kompatibel bleibt. Firmware-Releases gibt es also nur inoffiziell in diesem Thread. Wir hoffen, dass poohnet noch eine Weile Interesse an dem Projekt hat und seine selbstgebauten Firmwares hier weiter zur Verfügung stellt.

rtrbt ist aktuell im Urlaub. So oder so gibt noch keine Updates.

In Zukunft wahrscheinlich ja, aktuell ändert sich die Funktionalität des WEM noch zu häufig.

Was mich sehr wundert, sind die dutzenden von MQTT-Fehlern auf _update- und _reset-Topics. Das sieht für mich so aus, als würde irgendwas versuchen, über MQTT sämtliche Einstellungen und Werte zu überschreiben. Insbesondere sehe ich dort den Versuch, meter/values und meter/all_values zu setzen. Die hin- und her-springenden Zählerwerte ließen sich dadurch erklären, dass die Werte abwechselnd korrekt aus dem Zähler gelesen oder von extern falsch überschrieben werden. Deaktiviere doch mal MQTT und schau nach, ob die Werte dann stabil bleiben.

Die Bezeichnung „object_id“ wird auch schon als Komponente des MQTT-Topic verwendet, allerdings wird der Wert nicht zum Generieren der Entity ID verwendet. <discovery_prefix>/<component>/[<node_id>/]<object_id>/config Mit dem object_id-Feld im Payload kann man aber wie gewünscht die Entity ID setzen. Hätte man vielleicht eindeutiger benennen können. Demnächst wird das Feld object_id gesetzt, und zwar auf genau den gleichen Wert wie die Unique ID. Warum Home Assistant nicht gleich die bereits vorhandene Unique ID verwendet, um die notwendigerweise eindeutige Entity ID zu generieren, sei mal dahingestellt. Alt: button.ladevorgang_beenden Neu: button.warp2_abc_stopcharge Entweder wartet ihr auf das nächste Firmware-Release, kompiliert euch die Firmware von Github selbst, oder traut euch an die angehängte Firmware in Daily-Snapshot-Qualität. 😉 Edit: Gerade gesehen, dass floho anscheinend eine WARP1 hat und mit der WARP2-Firmware nichts anfangen kann. warp2_firmware_2_1_1_6421ad85_599febcb6a60600_merged.bin warp_firmware_2_1_1_6421b132_599febcb6a60600_merged.bin

Das Problem ist, dass die Namen der Entitäten aus der lesbaren Benennung generiert werden. Wenn der Button „Ladevorgang beenden“ heißt, macht HA daraus halt „button.ladevorgang_beenden“. Wenn man stattdessen „button.warp1_ladevorgang_beenden“ haben möchte, geht das nur, wenn man die Beschriftung des Buttons auf „WARP1 Ladevorgang beenden“ ändert. Das würde dann bedeuten, dass alle Buttons/Felder/etc ein „WARP1“ davor stehen hätten. Wenn das gewünscht ist, können wir das einbauen. Eine bessere Möglichkeit sehe ich aufgrund der Einschränkungen der Auto Discovery nicht. Wenn jemand weiß, wie man die Auto Discovery doch dazu überreden kann, dass HA bessere Entitätsnamen generiert, immer her damit. 🙂