rtrbt

Sorry, den Post hatte ich übersehen. max_current_configured war der Wert, den du im Webinterface setzen kannst. Das ist jetzt evse/global_current.

Moin, EVCC kann Ladungen derzeit noch nicht Nutzern zuordnen, Gedanken zur Implementierung gibt es aber bereits: https://github.com/evcc-io/evcc/discussions/3190 Die Nutzerzuordnung läuft aber derzeit nur über NFC (bzw. über gefakte NFC-Tags über die API, das benutzt EVCC dann auch). Da die WARP1 Smart kein NFC-Bricklet hat (du kannst dir aber eins nachrüsten ;) ), kannst du erstmal keine Ladungen zu Nutzern zuordnen. Da wird es künftig aber sicherlich irgendeine Lösung geben. Habe dafür mal ein Issue aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/133

Hm da liest man seine eigenen Posts und merkt dass man Schwachsinn geschrieben hat. Bei WARP1 kann man das Bricklet schlecht an die Seitenwand kleben, da ist der Berührschutz im Weg. Wenn das Bricklet hinter dem Deckel ist, z.B. oben oder unten links, dann kann es ganz gut NFC-Tags lesen, die von oben bzw. unten an die Wallbox gehalten werden. Am besten machst du das Bricklet erst einmal temporär fest und probierst, ob die Tags gefunden werden. Das geht nach einem Neustart der Wallbox ohne Konfiguration, die LED in der Frontplatte blinkt mit dem "Tag nicht bekannt"-Muster wenn du irgendwelche Tags dranhältst.

Moin, Der Rückstellzeitpunkt wird jetzt gespeichert: https://github.com/Tinkerforge/esp32-firmware/commit/5656fc9bfa52740fb69c54cccfb0f5f485d2eed3 Die Funktion wird mit der nächsten Firmware-Version kommen. Du kannst dann auf meter/last_reset den Zeitpunkt (als Unix-Timestamp) abfragen.

Das ist bisher so. Der SDM72(V1) benutzt andere Register als der SDM630 und der SDM72V2. Möglicherweise baue ich den SDM630-Support aber noch ein. Ich melde mich Montag nochmal.

Das stimmt die Platte gibt es im Shop (noch?) nicht. Wenn du keine Lust auf Sägen hast kannst du, falls du Zähler und Bricklet bei uns bestellst, Bescheid sagen, dann legen wir dir eine Platte mit ins Paket.

Ja. Zähler und Kabel verkaufen wir beide als Ersatzteile: https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/stromzaehler-sdm630.html https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/jst-cable-for-sdm630.html Im Stromlaufplan steht, wie du das (RS485/JST)-Kabel anschließen musst: https://www.warp-charger.com/documents/WARP2_Stromlaufplan.pdf

Da hat dein Golf von sich aus entschieden, wieder zu laden. Alle Freigaben die die Wallbox macht (also z.B. Lastmanagement, NFC, Auto-Start usw.) bleiben freigegeben, bis entweder das Auto abgezogen wird oder die Freigabe widerrufen wird. D.h. wenn du händisch PV-Überschussladen machst, dann musst du auch händisch wenn die Sonne nicht mehr scheint die Freigabe wieder wegnehmen, eben durch Tag nochmal an die Box halten, im Webinterface auf Stop klicken, über die API usw. Sieh dir mal EVCC an, damit kannst du PV-Überschussladen automatisieren.

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.