rtrbt

Do you also get "Verbinde" or "Connecting" as LAN/ethernet status? In this case the problem is usually with the ethernet cable. Also we've had one case where the router that the charger was connected to had a non-working ethernet port. The log message indicates that a WebSocket frame could not be sent, however if you can't load the Webinterface at all, there is no WebSocket connection. So this is likely a message generated when you disconnect from the chargers WiFi access point.

Hm du hast den Lastmanager auf beiden Boxen aktiviert, schalte ihn auf Wallbox2 mal ab, dann sollte es funktionieren. Der Lastmanager ist der Teil, der die anderen Boxen steuert. D.h. der muss nur auf einer Wallbox aktiv sein, alle anderen Wallboxen brauchen nur die Lastmanagement-Einstellung unter Ladecontroller aktiviert. Ich glaube nicht, dass das das Problem ist, mit einer älteren Firmware funktionierte es ja. Prinzipiell kann der ESP32 (und damit die Wallbox) aber in der Tat nur 2,4 GHz.

Ah, ich ging davon aus, dass du versuchst die API mit einem eigenen Skript o.Ä. zu benutzen. Vergiss den Rest ;) Das verstehe ich nicht. Wenn du http://192.168.0.xx/evse/start_charging in die Addresszeile einfügst, sollte eigentlich nichts passieren, weil das eigentlich nicht dafür gedacht ist, "von Hand" benutzt zu werden. Mit welcher Firmware hat das denn funktioniert? Bzw. warum machst du das so und nicht per Web-Interface? Hast du das einfach als Abkürzung als Lesezeichen hinterlegt o.Ä.?

@gintonicgamer Habe dich mal in den richtigen Thread verschoben. Kurz zusammengefasst (korrigiere mich wenn ich falsch liege): Du hast einen AP + zwei Repeater, zu keinem davon (der in Empfangsreichweite liegt) kannst du dich verbinden. Mit Firmware 1.3.3 (die letzte vor der Beta) ging es aber. Neu konfiguriert hast du die Verbindungseinstellungen schon. Es ist kein Sonderzeichen-im-Passwort-Problem (sowas sollte die Firmware auch nicht haben). Ein paar Ideen habe ich noch: Sieh nach ob auf Router und Repeatern jeweils die aktuelle Firmware installiert ist. Aktualisiere auf jeden Fall die Wallbox auf die aktuelle Beta (3), falls du das noch nicht getan hast. Um sicherzugehen, dass nicht noch irgendeine seltsame Konfiguration auf der Wallbox liegt, solltest du danach einen Reset auf Werkszustand machen und dann das WLAN neu konfigurieren. Falls das auch nicht hilft, schick mir danach einen Debug-Report (hier anhängen).

Moin, Du hast glaube ich zweimal das selbe Log gepostet ;) Zieh am besten von beiden Boxen mal einen Debug-Report, dann sehe ich auch gleich die Lastmanagementeinstellungen. Interessant ist diese Zeile: Je nachdem wie lange die Wallbox schon lief heißt das entweder, dass Wallbox2 nicht oder nicht mehr erreicht werden kann.

Das ist genau das Problem wegen dem ich geschrieben hatte, dass man einen Factory-Reset machen muss: Die Beta hat die Konfigurationsmigration, die im Endeffekt eine Konfiguration der Firmware 1.1.2 (und älter) in eine der Firmware 2.0.0 umwandeln kann. Da die älteren Betas aber schon das neue Konfigurationsformat verwenden, aber die Versionsnummer nicht aktualisiert haben, dreht der Migrationscode etwas durch. Die AP-Konfiguration kann dann nicht geladen werden, weshalb die Wallbox die Default-Konfiguration lädt. Wenn du die im Webinterface einmal speicherst sollte das weg sein.

Solange es jetzt funktioniert ;) Das verhält sich bei echten Tags genauso. Wenn du ein Tag an die Box hältst (in echt oder per nfc/inject_tag, das sollte absolut identisch funktionieren), dann übernimmt der entsprechende Nutzer die Ladung. Du kannst dann wechseln indem du dasselbe Tag noch ein zweites Mal an die Box hältst (dann wird die Ladung wieder blockiert) und danach ein anderes Tag. Mit einem Tag die Ladung wieder zu blockieren funktioniert aber nur wenn gerade geladen wird! Der Hintergedanke dabei war, dass es den Nutzer sonst verwirrt, weil er nicht weiß ob er eine ungerade Anzahl oft das Tag an die Box gehalten hat (dann wäre freigegeben) oder eine gerade Anzahl oft (dann wäre wieder blockiert) Es ist aber bei näherer Betrachtung so, dass es da eindeutiges Feedback gibt: Wenn die Ladung freigegeben ist (immer nur bezogen auf den User-Slot), dann leuchtet die LED permanent, wenn die Ladung blockiert ist weil ein Tag 0, 2, 4 usw. mal gesehen wurde, macht die LED das Nerv-Blinken. Es spricht also erstmal nichts dagegen, das auch zu erlauben. Das ist nur die user_id, damit man künftig (falls es einen Autorisierungsmechanismus dafür gibt) auf user_ids laden kann, die nicht als Benutzer registriert sind. Damit kann man das Nutzerhandling extern machen, hat aber trotzdem das Ladetracking direkt auf der Box. user_ids angelernter Nutzer kannst du in users/config nachschlagen.

Firmware: WARP 1.9.92 (2.0.0 Beta 3) und WARP2 1.9.93 (2.0.0 Beta 4) Details hier:

tl;dr: WARP1 Beta 3 bzw. WARP2 Beta 4. Hoffentlich die letzte Beta ;) Viele Bugfixes. Was gibt's neues? Die Betas sind wieder zum Großteil nur ein Bugfix-Release. Die API wurde noch etwas besser auf die Bedürfnisse von EVCC angepasst. Außerdem gibt es jetzt Migrationslogik, sodass die Konfiguration der alten Firmwares (WARP 1.3.3 bzw. WARP2 1.1.2 oder älter) so umgebaut wird, dass sie mit der kommenden 2.0.0 kompatibel ist. ACHTUNG: Updates von älteren Betaversionen auf die hier gepostete werden nur NACH einem Reset auf Werkszustand unterstützt! Updates von Firmwares älter als 1.9.90 sollten aber ohne Probleme funktionieren. Größere Bugfixes WebSocket-Verbindungen können jetzt sauber durch SSL-Proxies durchgeführt werden. Die MQTT-Payload-Längenberechnung funktioniert wieder Die Firmware kann wieder ohne angeschlossenen Ladecontroller gebootet werden Spontane Fehler beim Flashen von Firmwares behoben warp2_firmware_1_9_93_6239e590_merged.bin warp_firmware_1_9_92_6239e52c_merged.bin

Gut zu hören :) Wie es dir passt. Im Forum kann man eher mal eine Textwand schreiben, dafür kann man Issues sinnvoll in den Commit-Messages verlinken. Ich habe da erstmal keine starke Präferenz.

Hm das ergibt Sinn. In dem Commit habe ich ja einen neuen Config-Visitor eingebaut, der abschätzt wie lang bei einem API-Aufruf der Payload (in String-Länge) werden kann. Das brauche ich um zu prüfen, ob der MQTT-Empfangsbuffer groß genug für alle registrierten APIs ist. Wenn das nicht der Fall ist kommt genau die Fehlermeldung die du hast. Floats können sehr lang werden (JSON limitiert das übrigens nicht, aber sinnvollerweise nimmt man nur Gleitkommazahlen die in den Zieltyp passen an). FLT_MAX liegt bei ~ 3*10^38, deshalb habe ich das mit 42 abgeschätzt (für noch das - den . usw.). Ich würde bei näherer Betrachtung aber nicht erwarten, dass jemals jemand absichtlich einen Float mit mehr als ~20 Zeichen Länge überträgt. Das ist nur gefährlich wenn irgendwo nicht darstellbare floats erzeugt werden, z.B: 0.1 + 0.2 ergibt auf vielen Plattformen 0.30000000000000004 und das sind schon 19 Zeichen. meter/set_all_values müsste ja ein Array aus 85 Floats übertragen, 85*42 = 3570, dazu kommen noch die Kommata usw.. Ich werde die Schätzung mal aggressiver machen, z.B. auf 20 statt 42 Zeichen. Das dürfte ein Anwender kaum bei allen 85 Floats ausreizen. https://github.com/Tinkerforge/esp32-firmware/commit/2139d012a06f04854b80d3a99d19be771d71f3b3 Du bekommst nach der Änderung vermutlich noch folgende Warnung: MQTT: Recv buf is 2048 bytes. meter/set_all_values requires 1871. Maybe bump MQTT_RECV_BUFFER_SIZE? Das ist aber nur die abgeschwächte Form, die API funktioniert trotzdem. Du solltest es dann nur nicht mit dem Whitespace übertreiben ;) Langfristig sollte das MQTT-Modul mit fragmentierten Nachrichten umgehen können (https://github.com/Tinkerforge/esp32-firmware/issues/117), dann löst sich das Problem von alleine.

https://github.com/Tinkerforge/esp32-firmware/commit/b063b3bab67e54b956b93907a327126a9997b633 sollte das Problem fixen. Ich komme heute nicht mehr dazu die nächste Beta zu veröffentlichen, aber du baust ja eh aus Source ;)

Alles gut, Feedback hilft gerade bei den Betas immer. Du bekommst im Ereignislog vermutlich MQTT: Ignoring message with payload length 40 for topic warp2/X8A/nfc/inject_tag. Maximum length allowed is 32. (oder ähnlich)? Das ist dieser Bug hier: Ich gebe Bescheid, wenn das gefixt ist. @E-t-h Eine genauere Dokumentation der Slots kommt noch, liegt unfertig auf meiner Platte. Danke! Gebe ich auch mal an den Rest weiter :) Weißt du was das genau für ein Fritz Repeater ist? Hat er ein aktuelles FritzOS installiert? Kannst du eine Verbindung mit dem Router/Repeater aufbauen, der am nächstbesten erreichbar ist? (Der mit der 44:... MAC-Adresse, da musst du die BSSID-Sperre wieder anmachen um zu erzwingen, das der genommen wird.)

Das Problem scheint zu sein, dass die maximal erlaubte Payloadlänge anhand des JSON-Objekts berechnet wird, in das geparst werden soll. Das ergibt aber keinen Sinn, weil die Größe der geparsten Struktur im Speicher etwas anderes ist als die Länge des Strings, der geparst werden soll. Einfachstes Beispiel sind in der Tat Nachkommastellen bei Float: 123.456789 ist geparst ja nur sizeof(float) == 4 groß, als String aber 10 Byte. Der Bug ist bisher nicht aufgetreten, aber seit https://github.com/Tinkerforge/esp32-firmware/commit/2bbae07c68bb581b06edf182765926984b97e639 ist die Größenberechnung aggressiver, deshalb fällt das jetzt auf. Ich muss im MQTT-Modul also konsequenter unterscheiden, was String-Längen und was JSON-Strukturgrößen sind. Ich gebe Bescheid, wenn es wieder funktionieren sollte.

Ah, das ist kaputt. Danke für den Hinweis. Habe es hier gefixt: https://github.com/Tinkerforge/esp32-firmware/commit/b949541eb5af705563bca5abef5657e49dda550e

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.