rtrbt

Irgendetwas in die Richtung haben wir geplant, es gab aber noch kein Issue. Jetzt schon: https://github.com/Tinkerforge/esp32-firmware/issues/88

Stimmt, hatte ein Zaunpfahlproblem. Noch ein Grund mehr auf der Ladecontroller-Seite nachzusehen.

Das ist ein Fehler mit dem DC-Schutzmodul. Du kannst die ganzen Fehlerzustände übrigens schöner aufbereitet auf der Ladecontroller-Unterseite sehen.

Hi, How is your extension configured? The methods work for me. Does the attached script print the same messages with your extension? (Remember to change the UID ;) ) $ ruby test.rb LED true Press key to disable LED LED false Press key to enable LED LED true Press key to exit test.rb

Ah sehr gut, das Mosquitto local-only-Problem wäre was ich spontan geraten hätte. Deshalb die Frage nach Broker und Version. Ich füge das mal der FAQ hinzu. https://github.com/Tinkerforge/esp32-firmware/issues/85 Man beachte wann ich das Issue angelegt habe, vor allem in Relation zu meinem Post weiter oben ;)

Über USB kann der Brick in der Tat nur geflasht werden, er ist im Setup-Tab des Brick Viewer nicht als Brick sichtbar und die Bricklets tauchen auch nicht auf. Das ist soweit erwartet. Er sollte aber trotzdem unter Updates / Flashing -> Brick auftauchen, wie @poohnet schon schreibt. Update mal deine Firmware, bzw baue sie gegen den aktuellen Stand des Repos neu. Das Problem mit den fehlenden Bricklets sollte gefixt sein.

Das ist soweit korrekt, die Wallboxen müssen sich über ein Netzwerk erreichen können, damit Lastmanagement funktioniert. Du kannst aber jede Wallbox in das entsprechende WLAN einbinden und dann zwischen den Wallboxen eine LAN-Verbindung ziehen (bei mehr als zwei über einen Switch). Dann musst du für das LAN-Interface jeweils statische IPs konfigurieren, oder einen Router mit dazuhängen ,der IPs per DHCP verteilt, das ist dir überlassen. Ich habe das gerade erfolgreich mit folgendem Aufbau getestet: Fritzbox A <--WLAN A--> Wallbox A <--LAN-Kabel--> Wallbox B <--WLAN B-->Fritzbox B Du musst dann aber darauf achten, dass das Netz zwischen den Wallboxen einen anderen IP-Bereich benutzt als die beiden WLANs.

Das Problem ist vermutlich das hier: Der Ladecontroller geht in einen Fehlerzustand, weil vor dem Schütz keine Spannung ist. Da du schreibst, dass die Box am Strom hängt: Ist sie eventuell falsch herum angeschlossen? Also Neutralleiter und L1 vertauscht? Ich habe bei mir einen Wallboxprototypem mit Schukostecker auf dem Tisch liegen zur Firmware-Entwicklung, wenn ich bei dem den Stecker verdreht in die Steckdose stecke, passiert genau das. Unabhängig davon ist die Prüfung, dass ein Update nur erlaubt ist, wenn der Fahrzeugzustand "kein Fahrzeug angeschlossen" ist, zu aggressiv. Ich entschärfe das mal, damit Updates auch erlaubt sind, wenn die Wallbox in einem Fehlerzustand ist.

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.