rtrbt

Für den Port auf die API 2.0.0 sollte der Blogpost, den wir gerade veröffentlicht haben hilfreich sein: https://www.tinkerforge.com/de/blog/new-features-and-changes-in-warp2-firmware-200/ Für die Steuerung würde es sich dann anbieten, wenn du z.B. evse/external_current_update verwendest. Dann funktioniert die Steuerung über ioBroker auch zusammen mit anderen Steuerungsmöglichkeiten (Webinterface, Lastmanager, NFC usw.)

Ah, ja Handys machen da Probleme, da z.B. bei Android die NFC-ID rotiert wird. Siehe z.B. hier: Weißt du was für einen Tag-Typen dein Handy emuliert? Bekommst du über den 8266 immer die selbe ID? Falls ja würde mich der Code bzw das genaue NFC-Modul interessieren, dass du da einsetzt, vielleicht könnte man sich für die Wallbox da abschauen wie man stabile IDs ausliest.

Firmware: WARP 2.0.1 und WARP2 2.0.1 Modifikation bestehender Benutzer repariert Löschen konfigurierter Benutzer ohne aufgezeichnete Ladungen bei Konfigurations-Reset repariert Konfigurierbarkeit der Webinterface-Anmeldung bei Vergabe eines Passworts an einen bestehenden Benutzer repariert Download: WARP 2.0.1 bzw. WARP2 2.0.1

Kurzes Update dazu: Die automatische Ladefreigabe ist seit Firmware 2.0.0 persistent (de)aktivierbar.

Ups nein, das ist nur verquer formuliert. Bisher war es so, dass wenn du auf der WiFi-Verbindungsseite bereits eine Verbindung konfiguriert hattest und dann eine andere konfiguriert hast, in jedem Fall eine Passphrase eingegeben werden musste. Die Änderung ist, dass wenn die alte und neue SSID gleich sind (du also z.B. zu einem anderen AP/Repeater des selben Netzes wechselst) du jetzt nicht mehr die Passphrase neu eingeben musst.

D.h. mit diesem Gerät bekommst du immer 01:02 usw.? Was ist das denn für ein Gerät?

Moin, Wo liest du die ID genau ab? Ist das im Webinterface oder benutzt du z.B. die API bzw. MQTT? Kannst du das gezielt reproduzieren oder passiert das nur sporadisch? Spontan haben wir im Code keine Stelle gefunden die das Muster 01:02:03 usw. erzeugen kann.

Firmware: WARP 2.0.0 und WARP2 2.0.0 Blogpost mit Details zu den umfangreichen Änderungen API-Änderungen; möglicherweise sind Anpassungen an Software die mit der Wallbox interagiert notwendig! Ladetracker hinzugefügt; ordnet Ladevorgänge Benutzern zu und zeichnet diese persistent auf Download eines Logs der aufgezeichneten Ladungen hinzugefügt Benutzerverwaltung hinzugefügt; NFC-Tags werden jetzt Benutzern zugeordnet Netzwerk-Zeitsynchronisierung hinzugefügt Ladestromgrenzen aufgeteilt um NFC und andere Steuerungsmöglichkeiten zu entkoppeln (durch Update auf Ladecontroller-Firmware 2.1.0 (WARP) bzw. 2.1.2 (WARP2)) Netzwerk-Abschnitt hinzugefügt; alle Netzwerk-Interfaces verwenden jetzt den selben Hostnamen Konfigurierbares Sendeintervall für MQTT hinzugefügt Editierbaren Wallboxnamen hinzugefügt Unterstützung des Browser-Verlaufs hinzugefügt Eingabefeld des Ladestroms verbessert Übersetzungen verbessert Webinterface-Details verbessert Warnung hinzugefügt, wenn WLAN-Access-Point deaktiviert werden soll Hinweis zu Lastmanager-Watchdog hinzugefügt WebSocket-Verbindungsverlust durch falsches Ping-Frame-Handling repariert Browser-Caching repariert Anzeige der Ladecontroller-Version repariert WebSocket-Verbindungen durch SSL-Proxies repariert Logik der Fehleranzeige im Webinterface repariert Repariert, dass Passphrase bei Verbindung zu anderem Access Point mit selber SSID nicht verlangt wird Sporadisches Fehlen des Ereignis-Logs repariert Download: WARP 2.0.0 bzw. WARP2 2.0.0

Ja die Beta gibt es schon länger, hier die Beschreibung: und hier die aktuelle Beta-Version: PS: Die fertige Version 2.0.0 kommt diese Woche noch.

Ah sorry, ich dachte das wäre ein anderer Timeout. Den Watchdog musst du garnicht aktivieren. Der ist ausschließlich dafür da, dass jemand von außen dem Lastmanager vorgibt, wie viel Strom für den gesamten Verbund an Wallboxen verfügbar ist (z.B. eine große PV-Anlage). Wenn du nicht per API diesen Strom verändern willst, musst du den Watchdog deaktiviert lassen. Ich füge dazu im Webinterface noch einen Hinweis ein, das ist ein beliebter Fallstrick.

Nein, stattdessen musst du unter Ladecontroller die Benutzerautorisierung aktivieren. Dann kann nur noch mit Tag geladen werden.

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.