rtrbt

Das ist soweit beabsichtigt, ja. Die Ladezeit ist eher die Standzeit. Es könnte ja bzw. ist dir auch passiert, dass dein Fahrzeug Stunden nachdem der Akku voll war sich wieder soweit entladen hat, dass es wieder Strom ziehen wollte. Das wird auf den selben Ladevorgang aufgezeichnet. Deshalb endet der Ladevorgang erst wenn du das Fahrzeug abziehst, oder (falls du die NFC-Freigabe benutzt) wenn du mit dem selben Tag, dass den Ladevorgang erlaubt hat diesen beendest. Analog benutzen wir als Ladestart für die Aufzeichnung entweder den Zeitpunkt an dem das Fahrzeug angesteckt wurde (ohne NFC-Freigabe) bzw. den Zeitpunkt an dem ein Tag den Ladevorgang erlaubt hat (mit NFC-Freigabe).

Gibt noch nichts offizielles, nein. Du brauchst ein NFC-Bricklet, ein 7-Pol-Kabel, am besten 15cm (kannst du auf der Seite gleich dazu bestellen) und zur Befestigung etwas Spiegelklebeband. An der besten Positionierung scheiden sich die Geister, auf jeden Fall solltest du es eher von innen an eine der seitlichen Gehäusewände kleben, die Frontplatte ist geerdet, da geht NFC nicht durch.

Das ist interessant, auch mit den Infos aus diesem Thread. Ich hatte für die 2.0.0 (ohne Beta) und entsprechend auch die 2.0.1 kurzerhand noch WPA3-Unterstützung mit reinkompiliert. Mich wundert vor allem, dass die Unterstützung in den Betas nicht enthalten war, d.h. wenn da etwas klemmt dürfte es eigentlich nicht davor aufgetreten sein. Ich habe aber gestern im privaten Umfeld mitbekommen, dass Fritzboxen wohl Probleme beim WPA2+WPA3-Modus haben. Siehe hier: https://bbs.archlinux.org/viewtopic.php?id=273651 und https://lists.infradead.org/pipermail/hostap/2022-February/040209.html Es ist wohl so, dass die Fritzboxen sich nicht an die Spezifikation halten, laut https://lists.infradead.org/pipermail/hostap/2022-February/040212.html und dass die Probleme teilweise auch im WPA2-Only-Modus auftreten: https://bugzilla.opensuse.org/show_bug.cgi?id=1195395#c40 Wenn ich die aufgelaufenen Sachen aus meiner Urlaubswoche aufgeholt habe teste ich auf jeden Fall nochmal alle Varianten durch. Es bleibt spannend ;)

Theoretisch geht das. Es gibt aber zwei Probleme: 1. Der Platz: Die LAN-Buchse des Ethernet Bricks ist höher, deshalb kannst du ihn nicht auf den Berührschutz in einer WARP1 schrauben, außerdem musst du für das LAN-Kabel ein Loch ins Gehäuse bohren. Je nach persönlichem Anspruch an rumfliegende Platinen ist das eventuell machbar. 2. Die Firmware: Die WARP1-Firmware unterstützt kein Ethernet, die WARP2-Firmware nicht den "alten" Ladecontroller der in der WARP1 verbaut ist. Du kannst dir aber eine Firmware kompilieren, mit der das funktionieren müsste. Dazu musst du dir das Firmware-Git klonen und dann in der platformio.ini das WARP-Environment so ändern, dass du bei den Backend-Modulen statt ESP32 Brick ESP32 Ethernet Brick benutzt und zusätzlich das Ethernet-Backend- und -Frontend-Modul reinbaust. (Das kannst du dir am WARP2 Environment weiter unten abschauen) Das ist alles nicht offiziell unterstützt und auf eigene Gefahr. Falls du dir das aber hacken willst und dabei Firmware-Probleme findest, gib gerne Bescheid.

Wenn du es noch ein paar Mal probierst sollte es klappen. Es gab in der alten Firmware zwei Bugs die verkettet dazu führen, dass fälschlicherweise dieser Fehler ausgegeben wird. In Wirklichkeit bricht nur die Verbindung weg, über die das Update übertragen wird, das ist aber nicht so kritisch wie die Fehlermeldung es vermuten lässt.

Ich verstehe nicht, was du mir damit sagen willst. Ich fürchte etwas mehr Kontext musst du schon bieten, damit man dir helfen kann. Programmierst du gegen die API oder machst du direkt Dinge im Browser, so wie du es in deinem anderen Thread geschrieben hattest? Wenn du ein Programm schreibst in welcher Sprache? Warum weist du Fehlermeldungen der Wallbox auf eine Variable zu?

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: