rtrbt

Korrekt, die externe Steuerung kann zwar z.B. 28 Ampere vorgeben, aber wenn du in der GUI 12 Ampere eingestellt hast, dann ist das das Maximum. Wenn die externe Steuerung jetzt aber 10 Ampere vorgibt, dann wird auch nur mit 10 geladen. Eben immer das Minimum aus allen aktiven Ladegrenzen.

Also an Sonderzeichen liegt es vermutlich nicht: Ich habe hier einen Fritz Repeater 2400, habe bei dem versucht alle möglichen Sonderzeichen in das Passwort zu setzen und dabei gelernt, dass AVM nur bestimmte Zeichen erlaubt. Zitat aus der Online-Hilfe: Ich habe dann alle aus der erlaubten Liste benutzt, das funktioniert mit WARP1 Beta 2 ohne Probleme. Wenn du im Webinterface unter die Netzwerk->WLAN-Verbindung die Netzwerksuche ausführst, taucht den Netzwerk da auf?

Das ist noch nicht gut dokumentiert, funktioniert grundlegend aber wie folgt: Es gibt pro Ladestromgrenze einen Strom und ein Flag das angibt, ob die Grenze aktiv ist. Der Ladecontroller berechnet dann das Minimum aus allen aktiven Grenzen und das ist der Strom mit dem geladen werden kann. Intern ist es so, dass neben den üblichen Strömen von 6000mA bis 32000mA auch 0 gesetzt werden kann, das bedeutet, dass diese Grenze den Ladevorgang blockiert. Ein Beispiel dafür wäre, das wenn das Lastmangement aktiviert ist, immer 0 in der entsprechenden Grenze steht, bis der Lastmanager eine Ladung freigibt. Dann wird entsprechend die Grenze auf das gesetzt, was der Lastmanager vorgibt. Da es einige Grenzen gibt, die nur binär auf entweder 0 mA oder 32000 mA gesetzt werden (auch bei 16 Ampere bzw. 11 kW Wallboxen, da limitieren die Ladestromgrenzen von Zuleitung und Typ-2-Kabel entsprechend), habe ich das so gebaut, dass statt 0 mA "blockiert" angezeigt wird und statt 32000 mA "freigegeben". Die "freigeben"-Buttons rechts neben einigen Grenzen sind dafür da, die entsprechende Grenze komplett aufzuheben, also auf 32000 mA zu setzen. Die Ladestromgrenze "Konfiguration" ist der Wert, den du auf der Statusseite einstellen kannst. Da ist es aber auf der Statusseite so, dass du maximal das Minimum aus Zuleitungs- und Typ-2-Kabel-Grenze setzen kannst (wir hatten schon Benutzer, die verwirrt hat, dass man seine seine 16 Ampere-Box auf z.B. 24 Ampere konfigurieren kann), ist der Knopf die einzige Möglichkeit die Grenze wieder komplett aufzuheben. Bei der externen Steuerung kann es hilfreich sein, die Grenze aufzuheben, ohne die externe Steuerung ansich zu deaktivieren. Z.B. wenn du dir ein Script gehackt hast, dass zu bestimmten Tageszeiten das Laden verbietet, das Script aber gerade nicht läuft, aber die Grenze nicht freigegeben hatte. Dann kannst du, wenn du jetzt sofort laden willst, die Grenze aufheben (und damit ggfalls. eine Ladung freigeben die sonst blockiert wäre) und irgendwann später dein Script wieder starten und es funktioniert wieder alles. Das ist in der Tat seltsam. Auch interessant ist, das eine 11kW-Wallbox bei denen schon Zustimmungspflichtig ist. Bei allen anderen Netzbetreibern die mir so untergekommen sind, liegt die Grenze immer bei > 11kW, nicht bei >= 11 kW. Das ist wirklich seltsam. Ich teste gleich mal ein Passwort mit allen Sonderzeichen die mir so einfallen durch. Weißt du zufällig noch welche Firmware du vor der Beta installiert hastest? Da hatte es ja funktioniert, oder?

Noch nicht, nein. OCPP wird auf jeden Fall kommen, aber bisher hatten andere Features Vorrang. Bei welchem Netzbetreiber bist du? Wäre für uns auf jeden Fall interessant deren genauen Anforderungen zu sehen.

Ah, da ist die API-Dokumentation veraltet, das behebe ich gleich. Du musst in dem Fall (immer wenn du Daten zur Wallbox schickst und sei es nur null) HTTP PUT anstelle von POST o.Ä. als Method verwenden. Edit: gefixt: https://www.warp-charger.com/api_beta.html Support für POST und die anderen HTTP Methods kommt eventuell wieder, da wehrt sich leider die Webserver-Implementierung etwas: https://github.com/Tinkerforge/esp32-firmware/issues/39

EVCC unterstützt noch nicht die Firmware 2.0.0. Hier wird dran gearbeitet: https://github.com/evcc-io/evcc/pull/1700 Ich glaube aber, dass die Änderung damit EVCC mit einem geänderten MQTT-Sende-Intervall umgehen kann noch nicht im Pull-Request sind.

Die Ladevorgänge werden auch ohne Zähler getrackt, nur der Stromverbrauch fehlt dann. Z.B. so: (Das ist meine Entwicklungsbox deshalb waren das auch nur 6 Sekunden Ladezeit) Die Smart hat leider keine Möglichkeit zu messen wie viel Strom gezogen wurde. Je nachdem wie dringend du den Stromverbrauch messen möchtest kannst du den Zähler aber nachrüsten, Details dazu hier:

D.h. das NFC-Tag ist nur das Signal für "Ich möchte jetzt laden, nicht erst heute Nacht"? Da fallen mir zwei Varianten zur Umsetzung ein. Variante 1: Auto-Start an, NFC-Tag angelernt und Nutzer zugeordnet, Ladung nur mit Nutzerfreigabe bzw. Tag Wenn du das Auto ansteckst und dann das Tag dranhältst, wird sofort geladen Wenn du kein Tag dranhältst kann deine MQTT-Steuerung Nachts nachsehen, ob 1. evse/state["charger_state"] == 1 und 2. evse/slots[6]["max_current"] == 0 ist. Das bedeutet, dass du in dem Zustand bist, dass die Box nicht lädt weil kein NFC-Tag gesehen wurde. In diesem Fall machst du ein nfc/inject_tag dann sollte der Ladevorgang beginnen und auf das entsprechende Tag getrackt werden. Da ist noch etwas unschön, dass du evse/slots benutzen musst. Ich füge mal (allein der Vollständigkeit halber) noch ein Topic für den Strom der Benutzerfreigabe hinzu, das gibt es für die anderen Stromslots auch. Variante 2 ist dass du das ganze NFC- und User-System umgehst: Auto-Start aus, NFC-Tag kann angelernt sein, muss aber nicht, Ladung ohne Nutzerfreigabe bzw Tag erlaubt Deine MQTT-Steuerung sieht sich permanent evse/state["charger_state"] und nfc/seen_tags an. Wenn sich in seen_tags der oberste Eintrag ändert (also wenn die Tag-ID wechselt oder die last_seen-Zeit rückwärts springt) hat jemand ein Tag dran gehalten. Dann prüfst du ob die Tag-ID passt und falls ja schickst du evse/start_charging Wenn nachts ein Auto angeschlossen ist (charger_state == 1) schickst du auch evse/start_charging. Wenn du nachts charger_state == 2 siehst heißt das, dass du in dem oberen Fall warst, also per Tag gestartet wurde. Das ist Absicht, ja. Die Benutzerfreigabe gilt immer nur für den "laufenden" Ladevorgang, der definiert ist als der Zeitraum zwischen dem Anstecken und dem Abziehen des Autos.

Das stimmt über den Ladestandard bekommen wir keine Fahrzeug-ID. Du kannst https://www.warp-charger.com/api_beta.html#nfc_inject_tag benutzen um über MQTT eine Ladung auf einen bestimmten User zu starten. Schwierig ist dann in der Tat nur die Zuordnung dazu, welcher Benutzer das ist. Eine Idee dazu: Deine MQTT-Steuerung hat bisher doch entschieden, ob Auto-Start an oder aus ist bzw. Auto-Start war immer aus und über MQTT kam früher oder später ein evse/start_charging-Aufruf. Das kannst du weiterhin so machen, also dass du Auto-Start ausschaltest und die ganze NFC-Tracking-Sache zusätzlich dazu benutzt. Du musst dann nur daran denken, wenn du das Auto ansteckst die entsprechende Karte dranzuhalten, wie bisher. Die Benutzerfreigabe bleibt dann erhalten bis das Auto abgezogen wird, deine MQTT-Steuerung kann also Stunden später erst start_charging aufrufen und das wird funktionieren.

Danke für die Rückmeldung! Die Änderung kommt dann in die nächste offizielle Firmware.

Hm, da war ein Typo in der relevanten Zeile. Teste mal diese Variante. warp2_firmware_1_1_2_622f5066_merged.bin

Das sieht gut aus. Dann würde ich erwarten, dass es mit der Testfirmware funktioniert.

Firmware: WARP 1.9.91 (2.0.0 Beta 2) und WARP2 1.9.92 (2.0.0 Beta 3) Details hier:

tl;dr: WARP1 Beta 2 bzw. WARP2 Beta 3. Viele Bugfixes. Was gibt's neues? Beta 2 (WARP1) bzw. 3 (WARP2) ist größtenteils ein Bugfix-Release. Es gibt aber zwei neue Mini-Features: Die Zeitzone ist jetzt einstellbar und Usernamen (zusätzlich zu Anzeigenamen) werden im Ladelog vermerkt. Größere Bugfixes MQTT sollte wieder alle Nachrichten verschicken Es wird jetzt sichergestellt, dass Usernamen eindeutig sind Die Anmeldung im Webinterface kann nicht aktiviert werden wenn nicht mindestens ein Benutzer ein Passwort gesetzt hat warp_firmware_1_9_91_622f4134_merged.bin warp2_firmware_1_9_92_622f4114_merged.bin

Moin, Deine Mail hat es noch nicht zu mir geschafft. Ich frag gleich mal meine Kollegen. Zum Proxy-Problem: Das klingt so, als ob die Websocket-Verbindung nicht aufgebaut werden kann. Über die Websockets bekommt das Webinterface den Zustand der Wallbox zugeschickt, unter anderem welche Module angezeigt werden sollen. Wenn das fehlt, sieht das Webinterface so kaputt aus wie du es gesehen hast. Die Websocket-Verbindung musst du durch deine SSL-Proxy mit durchführen bzw von ws auf wss (das verhält sich genauso wie http zu https) umstellen. Bei nginx scheint das zum Beispiel so zu gehen: https://nginx.org/en/docs/http/websocket.html Du kannst deine Konfiguration (unabhängig vom Webinterface) z.B. mit websocat testen: https://github.com/vi/websocat z.B. mit websocat wss://url-zum-nginx.de/ws sollte dann eine Verbindung aufgebaut werden und relativ viele JSON-Daten ankommen. Damit das auch mit dem Webinterface funktioniert muss ich eventuell noch eine Änderung vornehmen. Die URL zum Websocket-Server wird sehr naiv gebaut: https://github.com/Tinkerforge/esp32-firmware/blob/2187de47ea45c73f534e68b5c25634f1040f400f/software/web/src/ts/util.ts#L185 und verwendet deshalb immer ws://. Korrekt wäre falls das Webinterface selbst über HTTPS kam wss:// zu verwenden. Ich habe dir eine Firmware angehangen, die dieses Problem beheben sollte. Falls du also per websocat eine Verbindung durch deine SSL-Proxy aufbauen kannst, das Webinterface aber immer noch nicht funktioniert, teste bitte mal die angehangene Firmware. Wenn das Problem dann weg ist würde ich die Änderung direkt übernehmen. warp2_firmware_1_1_2_622712c6_merged.bin

Habe das hier gefunden: https://www.davidbritch.com/2014/08/test-post.html Die PHP-API von curl scheint etwas kompliziert zu sein ;) Das ist interessant. Die Wallbox versucht sich ja zu verbinden aber es klappt nicht. Taucht dein WLAN auf wenn du nach Netzwerken scanst oder musstest du die SSID händisch eintragen? Ah, ich sehe das Problem: Die ganzen Konfigurationsmöglichkeiten (Auto-Start, NFC, usw.) sind nicht mehr so gekoppelt wie es vor der Beta der Fall war. Wenn du willst, dass man eine Ladung mit einem Tag freigeben muss, dann aber sofort geladen wird, ist die korrekte Konfiguration, dass du Auto-Start und unter Ladecontroller die Benutzerautorisierung aktivierst. Das wird perspektivisch in der Doku bzw. der Anleitung stehen. Vermutlich, ja. Gib bitte nochmal Bescheid wenn Beta 3 (poste ich in ein paar Stunden) nicht hilft.

Ah Windows. Da muss es curl -w "%{response_code}" -H "Content-Type: application/json" -X PUT -d "{}" http://123.123.123.123/evse/start_charging sein, sorry. Also mit " um den Payload statt '.

Was bekommst du, wenn du auf der Kommandozeile curl -w "%{response_code}" -H "Content-Type: application/json" -X PUT -d '{}' http://123.123.123.123/evse/start_charging ausführst? (Die Wallbox-IP davor einfügen!)

Zumindest auf der Kommandozeile funktioniert ein äquivalenter curl-Aufruf bei mir. Was gibst du curl_getinfo als zweiten Parameter? CURLINFO_RESPONSE_CODE bzw CURLINFO_HTTP_CODE sollten beide funktionieren. Das sind alles geänderte APIs. Die schon an die Beta angepasste Doku findest du hier: https://www.warp-charger.com/api_beta.html

Das kannst du bedenkenlos machen. Bei der aktuellen Firmware-Version setzt sich bei einem Neustart aber Auto-Start wieder auf an und die im Webinterface eingestellte Ladestromgrenze wird zurückgesetzt. Ab Firmware 2.0.0 werden diese Einstellungen auch gespeichert.

Die Doku https://www.php.net/manual/de/function.curl-exec.php sagt, dass du nach curl_exec mit curl_getinfo https://www.php.net/manual/de/function.curl-getinfo.php den HTTP-Return-Code bekommst.

Du musst zum Aufrufen HTTP-PUT statt HTTP-POST verwenden. In deinem Fall wäre das CURLOPT_PUT statt CURLOPT_POST und entsprechend CURLOPT_PUTFIELDS statt CURLOPT_POSTFIELDS. Danach sollte es z.B. mit "false" funktionieren. Dass "" nicht klappt ergibt Sinn: da kommt bei curl nur ein leerer String an, du musst aber noch eine Stufe tiefer, also als JSON-Payload einen leeren String schicken. Versuche mal curl_setopt($ch, CURLOPT_PUTFIELDS, "\"\""); Ich würde erwarten, dass das klapt.

Hm das konnte ich hier gerade auch reproduzieren. Ist jetzt gefixt: https://github.com/Tinkerforge/esp32-firmware/commit/6cf9077bf73f15b0f411637fad3a5dfbffdd0046 Ich fixe noch ein paar kleinere Bugs, morgen kommt Beta 3.

Das ist nur ein Maximal-Interval. D.h. wenn du keine Wertänderungen hast weil gerade kein Auto lädt, dann werden auch keine Nachrichten auf das Topic geschickt. Das war aber eigentlich schon immer so. Hast du das selbe Problem auf wallbox/warp2/meter/values bzw. wallbox/warp2/meter/phases? Dass die evse/energy_meter...-Topics überhaupt rausgegeben wurden war eher unbedacht und sowohl energy_meter_values und energy_meter_state werden vor der finalen 2.0.0 noch entfernt. Ersatz ist wie gesagt meter/values bzw. meter/phases für evse/energy_meter_values und meter/error_counters for evse/energy_meter_errors.

Fast übersehen, sorry: Hast du nachdem du den User zugeordnet hattest die Wallbox neugestartet? Sonst werden die NFC- und User-Konfigurationen nicht angewandt. Wie verhält es sich denn? Kannst du mit der Konfiguration garnicht mehr laden oder wartet die Wallbox nicht auf ein NFC-Tag? Schick mir mal einen Debug-Report.