rtrbt

Moin, @stomb@rifmetroid Welchen MQTT-Broker in welcher Version benutzt ihr? Schickt mir außerdem bitte beide einen Debug-Report. @floho Ging das Ereignis-Log so weiter oder hörte es danach auf? Aufgrund der Zeiten sehe ich bei dir folgendes: MQTT hat die Verbindung verloren (bei 232020682), wohlgemerkt durch ein normales schließen der Verbindung, nicht durch Netzwerkprobleme ö.Ä. Dann hat es 8 Versuche gebraucht, die Verbindung wieder aufzubauen (bis 232151062), das entspricht 130 Sekunden (Die Timestamps sind in Millisekunden). Die Verbindung bestand dann 3 Stunden und 40 Minuten (bis 245351725), konnte aber danach wieder nach einer Minute (245412100) wieder aufgebaut werden. Wenn das Log danach nicht so weiter ging, bzw. wieder größere Sprünge in den Zeiten waren sind das eventuell Netzwerkeffekte. Ich habe z.B. schon einmal beobachtet, dass bei einer bestimmten Fritzbox Nachts kurz alle WLAN-Verbindungne getrennt werden. Da hatte man dann einmal am Tag einen MQTT-Reconnect im Log. Wie sind die Wallbox und der Rechner auf dem dein Broker läuft an dein Netz angeschlossen? Häng bitte auch einmal einen Debug-Report an, da steht u.A. die Uptime drin, anhand der wir sehen können, wie lange das her ist.

Gut zu wissen, danke!

Kurzes Update: Ich habe in das Lastmanagement testweise eingebaut, dass wenn Strom übrig ist, dieser an Wallboxen zugeteilt wird, die bereits einmal geladen haben ohne dass danach das Fahrzeug abgezogen wurde. Kannst du bitte kurz mit der angehangenen Firmware testen ob nachdem du deinen Tesla normal auf 70% geladen hast (und nicht abgezogen!) der Ladestart über die App funktioniert bzw die Heizung über Wallbox-Strom? Bis auf diese Änderung ist die Firmware identisch zu 1.1.1. warp2_firmware_1_1_1_61b32328_merged.bin

Das klingt gut! Nur damit ich das richtig verstehe: Das war einer der RJ45-Stecker an deinem LAN-Kabel oder der Stecker in der Wallbox?

Firmware: WARP1 1.3.2 Kritisches Stromzähler-Kommunikationsproblem behoben Leere Client-IDs für MQTT verboten Download: WARP1 1.3.2

Firmware: WARP1 1.3.1 Unnötige Logmeldungen des Logins entfernt Übersetzungen überarbeitet Konfigurationspartition auf robusteres Dateisystem umgestellt Login-Probleme nach Update von Firmwares älter als 1.3.0 behoben Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert Bug der zur Anzeige eines leeren Webinterfaces führt behoben Recovery-Seite hinzugefügt Warnung vor Downgrades hinzugefügt Logmeldungen über mehr Netzwerkereignisse hinzugefügt Download: WARP1 1.3.1

Firmware: WARP2 1.1.1 Unnötige Logmeldungen des Logins entfernt Übersetzungen überarbeitet Konfigurationspartition auf robusteres Dateisystem umgestellt Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert Bug der zur Anzeige eines leeren Webinterfaces führt behoben Watchdog des verfügbaren Lastmanagementstroms zurückgesetzt wenn dieser über die API gesetzt wird. Recovery-Seite hinzugefügt Warnung vor Downgrades hinzugefügt Logmeldungen über mehr Netzwerkereignisse hinzugefügt Detektion aktiver und verbundener Phasen verbessert (durch Update auf Ladecontroller-Firmware 2.0.6) Detektion von Fahrzeugen verbessert, falls beim Start ein Fehler vorliegt (durch Update auf Ladecontroller-Firmware 2.0.6) Download: WARP2 1.1.1

Bisher kenne ich nur den einen anderen Kunden mit LAN-Problemen. Bei ihm ist es auch eine Fritzbox (7362SL) . Auf der anderen Seite haben wir aber extrem viele Kunden, Kollegen und auch die Wallboxen hier in der Firma an Fritzboxen, bei denen die LAN-Verbindung anstandslos funktioniert. In Summe bin ich davon so verwirrt wie du. Das hat sich zerschlagen, statische IPs haben auch nicht geholfen. Als letzte Idee: Hast du getestet? Wenn das nicht hilft wäre der nächste Schritt vermutlich den ESP Ethernet Brick auszutauschen, der in der Wallbox verbaut ist. Als ganz verzweifelte Idee: Besteht die Möglichkeit, dass du ein anderes LAN-Kabel ausprobierst?

Ich habe kurz mit dem Samsung-Handy von einem Kollegen getestet: Scheinbar ist die Websocket-Unterstützung des Samsung Browsers kaputt bzw. unterstützt NUR wss. Ich fürchte, da müsstest du mal den Browser wechseln. Mit Chrome und Firefox funktionierts. Eigentlich sollte sofort wenn du ein LAN-Kabel ansteckst die Verbindung aufgebaut werden. Bei dem anderen Kunden mit dem selben Problem sieht es derzeit aber tatsächlich nach einem DHCP-Problem mit der Fritzbox aus. Ich habe hier ein Testscript laufen, falls ich damit etwas rausfinde melde ich mich nochmal.

Mit der neuen Firmware schon. Unter http://10.0.0.1/recovery gibt es einen Button dafür. Du musst nur erst RESET in die Textbox davor schreiben, damit man das nicht ausversehen auslöst: Dass das Webinterface nicht sinnvoll angezeigt wird ist suspekt. Was für einen Browser benutzt du auf deinem Handy?

Der neue Thread bzw. der Post in den Veröffentlichungen folgt noch. Die neue Firmware findest du hier: http://warp-charger.com/firmwares/warp2_firmware_1_1_1_61aa27dd_merged.bin Auf der Website seibst wird die Firmware erst am Montag sichtbar, man sollte ja nicht große Änderungen Freitag Nachmittags veröffentlichen ;) Die neue Firmware kannst du, wenn du mit dem Access Point der Wallbox verbunden bist unter http://10.0.0.1/update flashen. Teste mit der neuen Firmware dann bitte folgende Dinge: Du hattest geschrieben, dass es nach einem Neustart für ein paar Minuten funktioniert, danach kommst du nur noch per WLAN auf die Wallbox. Lade eine Debug-Report von der Wallbox herunter, wenn die LAN-Verbindung gerade geht Lade noch einen herunter (über WLAN) wenn die LAN-Verbindung nicht mehr geht Du hattest geschrieben, dass wenn es nicht mehr geht, du einen Neustart der Wallbox machen musst. Reicht es dann über WLAN einen Neustart über das Webinterface auszulösen? (System -> Firmware-Aktualisierung) Gehe über WLAN auf IP der Wallbox/recovery, also z.B. http://192.168.178.123/recovery und löse einen Force Reboot aus. Geht das LAN dann wieder für ein paar Minuten? (Auch auf der Recovery-Seite) Wenn das LAN nicht mehr geht und du in die Box unter API folgendes einträgst: {"method": "PUT", "url":"/ethernet/force_reset", "payload":"null"} und auf Call API klickst, funktioniert LAN dann nach ~ 10 Sekunden wieder? Falls du ohne größere Probleme einen Rechner neben die Wallbox bekommst: Konfiguriere auf der Wallbox und auf dem Rechner statische IPs und verbinde beide direkt mit einem LAN-Kabel. Funktioniert das? Was für eine Fritz Box hast du genau?

Sorry, das hat etwas länger gedauert als geplant. Es kamen noch einige Bugfixes dazu. Die Firmware findest du hier: http://warp-charger.com/firmwares/warp2_firmware_1_1_1_61aa27dd_merged.bin Auf der Website seibst wird die Firmware erst am Montag sichtbar, man sollte ja nicht große Änderungen Freitag Nachmittags veröffentlichen ;)

Sorry, war gestern nicht mehr dazu gekommen dir was zu schreiben. Ich baue gerade die Recovery-Seite der Wallbox aus, damit die HTTP-Put-Geschichte einfacher ist (und man darüber den Reset auf Werkszustand auslösen kann). Wenn das fertig ist, kommt es in Firmware 1.1.1, die diese Woche noch erscheint. Mit der finden wir dann hoffentlich raus, warum bei dir (und auch bei mindestens einer anderen Wallbox, siehe hier: ) diese Ethernet-Probleme bestehen.

Sure, please send the log to erik@tinkerforge.com.

https://github.com/Tinkerforge/esp32-firmware/commit/f25ea41db9f65459cf4a27c9d17cd6c212a24954 sollte das Problem gelöst haben. Ich hatte in https://github.com/Tinkerforge/esp32-firmware/commit/3a77faec23b6557dbb4c91a1c0fc062b0f1390b2 alle Designated Initializers aus dem Code geworfen, weil das eher C-Stil ist und die C++-Compiler sich (berechtigterweise) darüber beschweren. Bei der Initialisierung der MQTT-Config fehlten aber die geschweiften Klammern, damit erstmal alles auf 0 (technisch gesehen: auf die jeweiligen defaults) initialisiert wird. Das führte dann dazu, dass esp-mqtt versucht hat die Länge des nicht initialisierten Last-Will-Topics zu bestimmen: https://github.com/espressif/esp-mqtt/blob/89894bd0c611b1392967fe90bb49682eba858383/mqtt_client.c#L407 (einem Wert den wir nicht schreiben, das kommt eventuell noch, siehe https://github.com/Tinkerforge/esp32-firmware/issues/34). Daher dann der Crash. Nochmal danke fürs melden!

Laut Debug-Report sieht das soweit gut aus: Da ich die API falsch im Kopf hatte ist aber im Report kein Event-Log enthalten. Kannst du den bitte auch noch abrufen? Sorry, dass ich nicht gleich daran gedacht habe. Das Eventlog bekommst du unter http://10.0.0.1/event_log Das haben wir aus der Firmware genommen, da viele Elektriker die Box testen, ohne den Deckel wieder anzuschließen. Der Taster ist ein Öffner, das heißt, wenn er nicht angeschlossen ist, denkt die Wallbox, dass er gedrückt ist. Wenn man dann die Box ohne Deckel (und damit ohne Taster) betreibt, geht sie in eine Reset-Schleife. Für einen Reset auf Werkseinstellungen gibt es jetzt noch zwei Möglichkeiten (und bald noch eine dritte, einfacher zu benutzende): Entweder musst du die Box aufschrauben, den ESP ausbauen und an einen PC anschließen, das wird in der aktuellen Anleitung genauer erklärt (https://www.warp-charger.com/documents/WARP2_Betriebsanleitung.pdf?v=2 Seite 12), oder wir müssen entweder das Webinterface wieder zum Laufen bekommen, bzw. du musst einen HTTP-Put-Request absetzen können, das wäre tendenziell mit einem Laptop einfacher.

Dass das Webinterface über den WLAN Access Point nicht geht liegt eventuell daran, dass du deine mobile Datenverbindung aktiviert hast. Viele Handys kommen dann mit dem Routing durcheinander. Wenn du die deaktivierst, würde ich erwarten, dass es funktioniert. Zum LAN-Problem: Ruf, wenn du auf das Webinterface zugreifen kannst mal einen Debug-Report ab (unter System->Ereignis-Log) und poste ihn hier, eventuell sehen wir dann mehr. Falls die Idee von oben nicht hilft, kannst du versuchen den Report händisch abzurufen, indem du auf http://10.0.0.1/debug_report gehst.

Hi, If you can still reach the web interface over WLAN when the LAN connection is interrupted, please download a debug report (System -> Event-Log -> Download debug report and event log) and post it here.

Ich habe dafür ein Issue aufgemacht, das Problem kam ja schon ein paar Mal auf: https://github.com/Tinkerforge/esp32-firmware/issues/77 Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

Ich habe dafür ein Issue aufgemacht, das Problem kam ja schon ein paar Mal auf: https://github.com/Tinkerforge/esp32-firmware/issues/77 Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

Die Pinbelegung ist (von links nach rechts wenn du auf das EVSE siehst) nicht belegt rot (A+; RX+) grün (B-; RX-) schwarz Ground Das Kabel ist (ohne den Teil, der im JST-Stecker verschwindet) etwas über 19cm lang. Ich habe mal ein Bild gemacht:

Moin Thomas, Das sieht im ersten Moment in der Tat so aus, als wäre es ein SPIFFS-Problem, ist es aber vermutlich nicht. Die verwirrenden Meldungen kommen daher, dass wir in letzter Zeit von SPIFFS auf LittleFS umgestellt haben, weil das schneller und vorallem robuster ist. Damit dann bei einem Update von einer SPIFFS auf eine LittleFS-Firmware nicht die Konfiguration verloren geht, macht die (neue) Firmware einen Migrationsschritt, der unter anderem involviert, dass die zunächst geprüft wird, ob die Konfigurationspartition eine SPIFFS-Partition ist, und wenn ja, wird die Migration ausgeführt. Diese Prüfung führt aber noch dazu, dass Meldungen wie angezeigt werden. Das aufzuhübschen ist einer der nächsten Schritte, ich hatte dann als Schnellschuss erstmal die Meldung davor eingebaut: D.h. du kannst das ignorieren. Es hatte erstmal nicht die höchste Priorität, die verwirrenden Meldungen loszuwerden, da man sie ja nur auf der seriellen Konsole sieht. Diese Kombination aus Logmeldungen sagt dann übrigens, dass alles soweit okay ist, die Konfigurationspartition ist ein LittleFS und lies sich erfolgreich mounten. Zu deinem eigentlichen Problem: Da das Mounten klappt, steckt der Fehler wo anders. Am besten decodierst du den Backtrace, der ausgegeben wird, dann siehst du, in welchem Codestück der ESP sich aufhängt: Dazu brauchst du die zugehörige .elf-Datei zu der .bin-Datei, die du geflasht hast (die sollte im build-Verzeichnis liegen und die selbe Versionsnummer haben. Also zu warp2_firmware_1_3_0-61a119ca.bin z.B. die warp2_firmware_1_3_0-61a119ca.elf.). Das Dekodieren kannst du mit xtensa-esp32-elf-addr2line auf der Kommandozeile machen machen, das liegt im Platformio-Ordner (https://docs.platformio.org/en/latest/projectconf/section_platformio.html#directory-options) unter packages/toolchain-xtensa-esp32/bin/ xtensa-esp32-elf-addr2line -pfiaC -e /pfad/zur/warp2_firmware_1_3_0-61a119ca.elf 0x4008a8e1:0x3ffb1f900x40089c1a:0x3ffb1fa0 0x40089c09:0x3ffb1fc0 0x40137329:0x3ffb1fe0 0x401383ec:0x3ffb2000 0x40138be3:0x3ffb2040 0x400f2e00:0x3ffb2090 0x400e0f11:0x3ffb21e0 0x4010627e:0x3ffb2820 Sollte dir dann einen sinnvollen Backtrace ausgeben, mit Dateinamen und Zeilennummern. Den kannst du gerne hier posten, dann werfe ich auch mal einen Blick darauf, vorallem wenn das Problem nicht in deinem Code auftritt. Grüße, Erik

Ah, dass du mit MaxMSP direkt ohne Code und SDK TCP-Pakete schicken/empfangen kannst war mir nicht klar. Das ändert natürlich einiges. Ich bin da beim googlen falsch abgebogen und dachte, dass du mit dem SDK ein C-Modul schreibst. Wenn du das TFP-Protokoll händisch benutzen willst, musst du im Endeffekt nur die Bricklets dazu bringen, dass sie ihre Callbacks aktivieren, lies: dass sie von sich aus Daten zu dir senden. Das RGB LED Button Bricklet macht das automatisch, deshalb funktioniert das einfach so, bei den anderen müsstest die entsprechende Funktion aufrufen (was heißt, das entsprechende TCP-Paket schicken) Um an den Payload zu kommen, kannst du also entweder in der TCP/IP-Dokumentation die einzelnen Paketformate nachschlagen (z.B. hier für die Position des Motorized Linear Poti Bricklets) oder du schneidest den Traffic des Brick Viewers oder eines kleinen Testprogramms mit.

Du hast vollkommen recht, das ist in der Firmware kaputt. Das Problem ist, dass der Lastmanager auf der Wallbox nicht die API benutzt, sondern ein eigenes Protokoll mit den anderen Boxen spricht. Wenn du über die API managed_current aktualisierst, fehlt der Aufruf, der den Watchdog entschärft. Ich habe das im Quellcode gerade gefixt. https://github.com/Tinkerforge/esp32-firmware/commit/d2834cf2af5f8e3f20cff4da682db36afccb10e5 Es kommt diese Woche noch Firmware 1.3.1, der API-Fix wird enthalten sein, eventuell kommt dann auch der Fix für das eigentliche Problem mit dem Lastmanager, das kann ich dir aber noch nicht versprechen. Edit: Firmware 1.1.1, wir reden ja von WARP 2.

Das ist eine gute Erklärung, der Firefox cacht das in der Tat, bis er einmal komplett neustartet. Jain, die Loginseite fragt den Server nur, ob der komplette Satz Login-Daten korrekt ist, die Rückmeldung ist dann aber immer "falsches Passwort". Hm dass ein richtiges Passwort wieder die Anmeldeseite lädt ist interessant: Das heißt, dass Edge scheinbar für jede Unter-URL einen eigenen Cache hat und dann mit der neuen Realm die Login-Daten geprüft hat, aber für die Hauptseite wieder die alte verwendet.