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.

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.

38 minutes ago, Lenny said:

Mit dem einen ist es jedoch reproduzierbar. Die Freigabe zum Laden funktioniert auch.

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.

16 minutes ago, jensstark said:

Muss die Anmeldung des Benutzers enabled sein?

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.

14 hours ago, elektron said:

Hast Du auf dem AP beide Frequenzbereiche aktiviert? Also 2,4 und 5 GHz?

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 ;)

On 3/29/2022 at 3:50 PM, michael99 said:

Bisher konnte ich im Browser das als http senden und auch kontrollieren.

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.

On 4/1/2022 at 3:06 PM, gintonicgamer said:

Ich bekomme die WLAN Verbindung nicht gelöst ... noch jemand eine idee?

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:

On 4/2/2022 at 4:59 PM, elektron said:

2022-04-02 16:47:45,828      stage 0: Can't reach EVSE of Wallbox2 (192.168.2.199): last_update too old.

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.

14 hours ago, alestrix said:

Nein, das habe ich im Log nicht gesehen.

Als ich mit der neuen Beta das gleiche Verhalten gesehen habe, bin ich stutzig geworden. Dann ist mir bewusst geworden, dass das ja nur mit angestecktem Fahrzeug funktioniert. Nach Beseitigung des Layer 8 Fehlers lief es dann wie es soll. Ich möchte es jetzt allerdings mit der alten Beta nicht nochmal nachtesten.

Solange es jetzt funktioniert ;)

14 hours ago, alestrix said:

Mir ist noch folgendes Verhalten aufgefallen: In meiner WARP sind zwei Tags mit unterschiedlichen Stromgrenzen hinterlegt. Ein inject_tag mit dem ersten setzt die Benutzergrenze auf den konfigurierten Wert. Ein nachfolgendes inject_tag mit dem anderen Tag ändert nichts mehr an der Benutzergrenze. Ich muss erst die Benutzerauthorisierung aus- und wieder anschalten, dann nimmt die WARP das zweite Tag an. Ich nehme an, ein Ab- und Anstecken des Fahrzeugs hätte wahrscheinlich den gleichen Effekt gehabt. Ob es sich mit echten Tags am RFID Leser genauso verhält, konnte ich nicht testen.

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.

13 hours ago, alestrix said:

Soll die user_id wirklich der numerische Index sein oder sollte hier nicht eher der Benutzername rein?

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 :)

39 minutes ago, poohnet said:

Soll ich mich bei solchen Themen weiterhin im Forum melden oder lieber per GitHub-Issue?

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 ;)

On 3/19/2022 at 12:07 AM, alestrix said:

Ich hoffe, ich spamme nicht zu viel ins Forum (einfach Bescheid geben), aber ich bin möglicherweise über einen Fehler gestolpert.

Alles gut, Feedback hilft gerade bei den Betas immer.

On 3/19/2022 at 12:07 AM, alestrix said:

Wenn ich nun per

mosquitto_pub -t warp/nfc/inject_tag -m '{"tag_type": 0, "tag_id": "DE:AD:BE:EF"}'

eine Aktivierung per RFID simuliere, bleiben aber weiterhin beide Werte unverändert auf "blockiert" stehen. Der Tag findet sich nach Aufruf des mosquitto Befehls im seen_tags Topic und die Tag-ID habe ich per copy-and-paste aus dem NFC Menüpunkt der WARP kopiert, ein Tippfehler ist also ausgeschlossen.

Ich hätte erwartet, dass ein inject_tag die Begrenzung bei "Benutzer" beeinflusst.

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.

On 3/20/2022 at 7:35 AM, E-t-h said:

Kleines Feedback meinerseits: Ich finde die Box gelungen und mit dem NFC und dem Aufzeichnen der Verbräuche und dem Lastmanagement nun auch für Firmenparkplätze gut geeignet. Und der Support hier ist a class of its own..

Danke! Gebe ich auch mal an den Rest weiter :)

On 3/18/2022 at 2:23 PM, gintonicgamer said:

Ja, ich habe alle 3 probiert. 
der mit dem starken signal ist der fritz repeater im mesh.

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.