poohnet

Softwaretechnisch ist das kein Problem, mittlerweile habe ich die Firmware so angepasst, dass der ESP32-Brick das OLED-Bricklet ansteuert :-) Aktuell scheue ich aber noch den hardwaremäßigen Umbau der Frontblende...

Hi mattsches, eine direkte Verbindung zum ESP32-Brick kann ich über den Brick Viewer auch nicht herstellen, die Wiederherstellung der Firmware über den COM-Port funktioniert aber problemlos. Hierzu muss zunächst der richtige USB-Treiber installiert werden, dann taucht im Gerätemanager ein entsprechender COM-Port auf ("Silicon Labs CP210x USB to UART Bridge") und man kann die Firmware über den Button "Updates / Flashing" hochladen: Gruß Thomas P.S. Interessanterweise kann sich der Brick Viewer rudimentär über die IP-Adresse mit dem ESP32-Brick verbinden, aber leider stehen dann nicht alle Funktionen zur Verfügung und es werden anscheinend nicht immer alle Bricklets gefunden (hier fehlt aktuell das NFC-Bricklet):

Hi wolfgam, hast du evtl. noch das Ladekabel am Auto? Sicherheitshalber ist dann nämlich kein Update möglich. Gruß Thomas

Hallo zusammen, mal ne (blöde?) Frage zwischendurch, da ich davon ausgehe, dass der ESP32 auch das OLED-Bricklet ansteuern kann: Habt ihr schon mal darüber nachgedacht, den WARP-Charger mit einem solchen Display auszustatten (z. B. um Ladedaten auch lokal anzuzeigen)? Oder ist dann die Dichtigkeit des Gehäuses ein Problem? Danke und Gruß Thomas

Ich kann übrigens bestätigen, dass das Problem nun behoben ist: ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:976 ho 0 tail 12 room 4 load:0x40078000,len:10124 load:0x40080400,len:5828 entry 0x400806a8 34 **** TINKERFORGE WARP CHARGER V1.3.0-61a63cc5 **** 35 308K RAM SYSTEM 231439 HEAP BYTES FREE 35 READY. 97 Mounted configuration partition. 8192 of 262144 bytes (3.1 %) used 184 WARP Charger SPIFFS version 1.3.0-61a29020 487 efuse error: malformed passphrase! 487 efuse error: malformed passphrase! 488 efuse error: malformed passphrase! 498 efuse error: malformed passphrase! 729 mDNS responder started 788 No EVSE Bricklet found. Disabling EVSE support. 789 No RS485 Bricklet found. Disabling energy meter support. 835 No NFC Bricklet found. Disabling NFC support. 873 Had to configure softAP IP address 1 times. 2874 Soft AP started. 2874 SSID: warp-1 2874 hostname: warp-1 3352 IP: 10.0.0.1 3367 Connecting to HMW-IoT 6387 Connected to HMW-IoT 6442 Got IP address: ... Connected to BSSID ... 6447 Network connected. Stopping soft AP 6487 MQTT: Connected to broker.

Gerne, ich bin immer froh, wenn ich helfen kann 🙂

Moin, vielen Dank für‘s Nachstellen. Letztendlich ist so ein Bug zwar ärgerlich, da man den WARP-Charger auseinandernehmen und den ESP32-Brick ausbauen muss, aber mit so etwas muss man ja immer rechnen, wenn man auf einer Entwicklungsversion unterwegs ist. Die Vorteile eines offenen Systems machen solche „Wehwehchen“ m. E. aber mehr als wett! 👍 Gruß Thomas

Auch ich habe die WARP1 im Einsatz und keinerlei Probleme mit der WLAN-Verbindung. WARP2 bietet zwar zusätzlich einen LAN-Anschluss, der zugrundeliegende Controller (ESP32) ist aber faktisch der gleiche - und die meisten neuen Features funktionieren ja auch mit der „alten“ Version… Gruß Thomas

Hallo zusammen, ich habe mir jetzt mal die "warp4mb"-Version gebaut und manuell via esptool.py auf meinen ESP32 (DevKit V4) geflashed (dann muss ich den WARP-Charger nicht schon wieder auseinanderbauen 🙃). Der Crash lässt sich auch hier reproduzieren, sobald man MQTT aktiviert. ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:976 ho 0 tail 12 room 4 load:0x40078000,len:10124 load:0x40080400,len:5828 entry 0x400806a8 30 **** TINKERFORGE WARP CHARGER V1.3.0-61a4f380 **** 31 278K RAM SYSTEM 232796 HEAP BYTES FREE 32 READY. Checking if spiffs is mountable as SPIFFS. Please ignore following SPIFFS errors E (43) SPIFFS: mount failed, -10025 Checking if coredump is mountable as LittleFS. Please ignore following LittleFS errors ../components/esp_littlefs/src/littlefs/lfs.c:1071:error: Corrupted dir pair at {0x0, 0x1} E (58) esp_littlefs: mount failed, (-84) E (61) esp_littlefs: Failed to initialize LittleFS E (66) esp_littlefs: Partition was never registered. Checking if spiffs is mountable as LittleFS. Please ignore following LittleFS errors 115 Mounted configuration partition. 8192 of 262144 bytes (3.1 %) used 195 WARP Charger SPIFFS version 1.3.0-61a29020 498 efuse error: malformed passphrase! 498 efuse error: malformed passphrase! 499 efuse error: malformed passphrase! 509 efuse error: malformed passphrase! [ 587][E][vfs_api.cpp:102] open(): /spiffs/wifi_ap_config does not exist, no permits for creation [ 593][E][vfs_api.cpp:102] open(): /spiffs/wifi_ap_config.json.tmp does not exist, no permits for creation [ 600][E][vfs_api.cpp:102] open(): /spiffs/wifi_ap_config.json does not exist, no permits for creation 725 Had to configure softAP IP address 1 times. 2726 Soft AP started. 2726 SSID: warp-1 2727 hostname: warp-1 2730 IP: 10.0.0.1 2736 mDNS responder started Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x4008a8e4 PS : 0x00060830 A0 : 0x80089c1d A1 : 0x3ffb1f90 A2 : 0x00006465 A3 : 0x00006461 A4 : 0x000000ff A5 : 0x0000ff00 A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x8008f20c A9 : 0x3ffb1f70 A10 : 0x00000003 A11 : 0x00060823 A12 : 0x00060820 A13 : 0x00000007 A14 : 0x00000005 A15 : 0x00000001 SAR : 0x00000008 EXCCAUSE: 0x0000001c EXCVADDR: 0x00006465 LBEG : 0x400894b9 LEND : 0x400894db LCOUNT : 0xffffffff Backtrace:0x4008a8e1:0x3ffb1f900x40089c1a:0x3ffb1fa0 0x40089c09:0x3ffb1fc0 0x40138dc5:0x3ffb1fe0 0x40139e88:0x3ffb2000 0x4013a67f:0x3ffb2040 0x400f3958:0x3ffb2090 0x400e18bd:0x3ffb21e0 0x40107dee:0x3ffb2820 Und hier jetzt der dekodierte Backtrace: 0x4008a8e1: strlen at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:43 0x40089c09: strdup at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/string/strdup.c:10 0x40138dc5: set_if_config at /esp32-arduino-lib-builder/build/../esp-idf/components/mqtt/esp-mqtt/mqtt_client.c:348 (inlined by) set_if_config at /esp32-arduino-lib-builder/build/../esp-idf/components/mqtt/esp-mqtt/mqtt_client.c:344 0x40139e88: esp_mqtt_set_config at /esp32-arduino-lib-builder/build/../esp-idf/components/mqtt/esp-mqtt/mqtt_client.c:407 (discriminator 2) 0x4013a67f: esp_mqtt_client_init at /esp32-arduino-lib-builder/build/../esp-idf/components/mqtt/esp-mqtt/mqtt_client.c:765 0x400f3958: Mqtt::setup() at /home/pooh/esp32-firmware/software/src/modules/mqtt/mqtt.cpp:278 0x400e18bd: setup() at /home/pooh/esp32-firmware/software/src/main.cpp:148 0x40107dee: loopTask(void*) at /home/pooh/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:38 Im MQTT-Modul wurde ja tatsächlich etwas geändert. Gruß Thomas P. S. Für weitere Tests habe ich mir jetzt mal den neuen ESP32 Ethernet Brick bestellt...

Moin Erik, besten Dank für die schnelle Rückmeldung, das werde ich heute Abend mal ausprobieren. Gestern habe ich übrigens noch herausgefunden, dass der Crash auftritt, sobald man MQTT aktiviert. Vielleicht hilft das vorab schon mal weiter... Gruß Thomas

Hallo zusammen, vorab erstmal ein Lob: Der Umzug des WARP-Repositories in esp32-firmware ist super, damit lässt sich die komplette Buildumgebung ja nun tatsächlich mit wenigen Befehlen aufsetzen. 🙂 Jetzt das ABER: Leider funktioniert die damit erstellte Firmware nicht mehr - zumindest nicht auf meinem WARP1. Nach dem Flashen war der WARP-Charger reproduzierbar nicht mehr per WLAN erreichbar, sodass ich den ESP32 ausbauen und mit Hilfe von Brickv zurücksetzen musste. Mit Hilfe des Serial Monitors konnte ich erkennen, dass es anscheinend ein Problem mit dem SPIFFS gibt, das in Folge dann zu einem "Core 1 panic" führt: ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:976 ho 0 tail 12 room 4 load:0x40078000,len:10124 load:0x40080400,len:5828 entry 0x400806a8 15 **** TINKERFORGE WARP CHARGER V1.3.0-61a119ca **** 16 278K RAM SYSTEM 234296 HEAP BYTES FREE 17 READY. Checking if spiffs is mountable as SPIFFS. Please ignore following SPIFFS errors E (27) SPIFFS: mount failed, -10025 Checking if coredump is mountable as LittleFS. Please ignore following LittleFS errors ../components/esp_littlefs/src/littlefs/lfs.c:1071:error: Corrupted dir pair at {0x0, 0x1} E (43) esp_littlefs: mount failed, (-84) E (46) esp_littlefs: Failed to initialize LittleFS E (51) esp_littlefs: Partition was never registered. Checking if spiffs is mountable as LittleFS. Please ignore following LittleFS errors 90 Mounted configuration partition. 8192 of 3538944 bytes (0.2 %) used 136 WARP Charger SPIFFS version 1.3.0-617bc859 623 mDNS responder started Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x4008a8e4 PS : 0x00060830 A0 : 0x80089c1d A1 : 0x3ffb1f90 A2 : 0x00006465 A3 : 0x00006461 A4 : 0x000000ff A5 : 0x0000ff00 A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x8008f20c A9 : 0x3ffb1f70 A10 : 0x00000003 A11 : 0x00060823 A12 : 0x00060820 A13 : 0x00000000 A14 : 0x00001004 A15 : 0x3ffb6c68 SAR : 0x00000008 EXCCAUSE: 0x0000001c EXCVADDR: 0x00006465 LBEG : 0x400894b9 LEND : 0x400894db LCOUNT : 0xffffffff Backtrace:0x4008a8e1:0x3ffb1f900x40089c1a:0x3ffb1fa0 0x40089c09:0x3ffb1fc0 0x40137329:0x3ffb1fe0 0x401383ec:0x3ffb2000 0x40138be3:0x3ffb2040 0x400f2e00:0x3ffb2090 0x400e0f11:0x3ffb21e0 0x4010627e:0x3ffb2820 ELF file SHA256: 0000000000000000 Rebooting... Zuerst dachte ich noch an einen Programmierfehler meinerseits, das Problem lässt sich aber auch mit dem unveränderten Sourcecode reproduzieren. Verwendet man stattdessen die "alte" Buildumgebung (tag 1.3.0 im warp-charger Repository), dann funktioniert alles einwandfrei. Habt ihr vielleicht eine Idee, woran das liegen könnte? Besten Dank und Gruß Thomas

Moin Frank, ursprünglich hatte ich auch vorgehabt, meinen SDM630 in der Unterverteilung über ein separates Kabel an den WARP-Charger anzuschließen. Letztendlich habe ich mich aber für eine andere Lösung entschieden, d. h. ich greife die Modbus-Daten über Node-RED ab und sende diese dann über MQTT an WARP. Hierfür ist zwar eine kleine Anpassung der Firmware erforderlich, der Vorteil ist aber, dass alle Daten des SDM630 im Netz zur Verfügung stehen... Gruß Thomas

Hallo Docmac, ich greife zwar über Modbus TCP auf den SDM630 zu, im Originalcode sind aber die folgenden Parameter hinterlegt: Modbus-Id 1 9600 Baud 1 Stopbit No parity Gruß Thomas

Danke für die Blumen :-) Nein, das hängt am Anfrageintervall bzw. der Art und Weise, wie ich die Modbus-Register auslese und in die "Config"-Objekte übernehme. Mal wird der eine, mal der andere Wert aktualisiert. Ist z. Z. halt alles noch etwas "gepfuscht" 😇 Leider scheint sich der Verbrauch beim SDM 630 v2 nicht zurücksetzen zu lassen, jedenfalls setzt das Holding-Register 461457 nur diverse Maximalwerte zurück. Dass die Live-Ansicht immer länger wird, ist mir auch schon aufgefallen. Das ist eigentlich nicht beabsichtigt und ist (wahrscheinlich) ebenfalls der aktuellen Abfrageart geschuldet. Allerdings habe ich ja auch keinen echten Vergleich, was da bei einem "richtigen" WARP-Charger Pro angezeigt wird. Leider war die Integration der eModbus-Library dann doch nicht ganz so einfach, da die Callbacks über Function-Pointer abgebildet werden. Diese musste ich erstmal durch std::function ersetzen, um in "sdm72dm.cpp" mit Lambdas arbeiten zu können...

Das funktioniert! Ist aktuell zwar alles noch etwas experimentell, aber grundsätzlich kann ich per Modbus TCP auf den SDM 630 zugreifen 😀 Ich muss sagen, eure Codestruktur gefällt mir sehr gut und macht Erweiterungen wirklich einfach... 👍

Moin, kein Problem, besten Dank für die Rückmeldung. Da mein WARP Charger letzte Woche auch angekommen ist, probiere ich das mal aus 😀 Ich nehme an, dass man nach dem Build die "warp_firmware_xxx_merged.bin" flashen muss, oder? Gruß Thomas

Hallo batti, da mein WARP-Charger Smart bald ankommen sollte, habe ich mich in den letzten Wochen schon mal etwas mit dem Quellcode der Software beschäftigt. Wenn ich das richtig sehe, dann wird die RS485/ Modbus-Verbindung zum Zähler (zumindest aktuell) ja nur für das Webinterface benötigt, oder? Weitere Steuerungsmöglichkeiten habe ich zumindest nicht gefunden und die angesprochenen Modbus-Register sind sehr überschaubar. Hintergrund: Ich hatte ja ursprünglich geplant, meinen bereits in der UV verhandenen SDM630 für die Wallbox zu verwenden und ein separates Netzwerkkabel zwischen Zähler und Bricklet zu verlegen. Da ich den RS485-Bus aber sowieso bereits auf Modbus-TCP „konvertiere“ (über einen ESP32-Mini mit eModbus-Library), könnte ich diese Bibliothek doch auch in die WARP-Firmware einbauen und die relevanten Stellen beim direkten Zugriff auf das Bricklet durch entsprechende eModbus-Calls ersetzen, sodass eine vollständig drahtlose Kommunikation stattfindet. Was haltet ihr davon? Spricht da aus eurer Sicht etwas dagegen (außer vielleicht, dass ich diese Anpassung mit jeder neuen Firmware-Version erneut machen müsste)? Vielen Dank & Gruß Thomas

Perfekt, jetzt konnte ich die Firmware erfolgreich bauen 🙂 Vielen Dank für die schnelle Unterstützung. Ich freue mich schon auf den WARP Charger und das, was da demnächst noch alles kommt... Gruß Thomas

Danke Erik, jetzt bin ich einen Schritt weiter, erhalte aber leider immer noch einen Compile-Fehler: Dependency Graph |-- <ESP Async WebServer> 1.2.3+sha.0c365d8 | |-- <AsyncTCP> 1.1.1 | |-- <ArduinoJson> 6.17.2+sha.1360b6a | |-- <FS> 1.0 | |-- <WiFi> 1.0 |-- <ArduinoJson> 6.17.2+sha.1360b6a |-- <strict_variant> 1.0.0+sha.1112078 |-- <Pangolin MQTT Client> 1.0.0+sha.ceeeddc | |-- <AsyncTCP> 1.1.1 |-- <esp32-lib> 1.0.3+sha.cd031ee | |-- <ESP Async WebServer> 1.2.3+sha.0c365d8 | | |-- <AsyncTCP> 1.1.1 | | |-- <ArduinoJson> 6.17.2+sha.1360b6a | | |-- <FS> 1.0 | | |-- <WiFi> 1.0 | |-- <ArduinoJson> 6.17.2+sha.1360b6a | |-- <FS> 1.0 | |-- <strict_variant> 1.0.0+sha.1112078 | |-- <SPIFFS> 1.0 | | |-- <FS> 1.0 | |-- <SPI> 1.0 |-- <SPIFFS> 1.0 | |-- <FS> 1.0 |-- <WiFi> 1.0 |-- <Update> 1.0 |-- <ESPmDNS> 1.0 | |-- <WiFi> 1.0 Building in release mode Compiling .pio/build/warp/src/main.cpp.o Compiling .pio/build/warp/src/modules/authentication/authentication.cpp.o Compiling .pio/build/warp/src/modules/evse/evse.cpp.o Compiling .pio/build/warp/src/modules/firmware_update/firmware_update.cpp.o src/modules/authentication/authentication.cpp: In member function 'void Authentication::setup()': src/modules/authentication/authentication.cpp:36:16: error: 'class AsyncWebServer' has no member named 'setAuthentication' server.setAuthentication(user.c_str(), pass.c_str()); ^ *** [.pio/build/warp/src/modules/authentication/authentication.cpp.o] Error 1 ================================================================= [FAILED] Took 23.18 seconds ================================================================= Macht euch deswegen aber bitte keinen Stress, ich kann mir vorstellen, dass ihr sowieso gerade genug mit den WARPs um die Ohren habt. Jedenfalls gibt es in den Repositories ja aktuell eine Menge Änderungen... 🙃 Gruß Thomas

Guten Morgen, da ich ja bald meinen WARP-Charger erhalte, wollte ich mich schon mal etwas mit der Software beschäftigen. Leider lässt sich das Projekt "esp32-brick" z. Z. nicht übersetzen, da hier die letzten Änderungen in der Klasse "API" aus dem Projekt "esp32-lib" anscheinend noch nicht nachgezogen wurden: ... Building in debug mode Compiling .pio/build/esp32dev/src/main.cpp.o Compiling .pio/build/esp32dev/src/modules/firmware_update/firmware_update.cpp.o Compiling .pio/build/esp32dev/src/modules/proxy/proxy.cpp.o Compiling .pio/build/esp32dev/src/modules/wifi/wifi.cpp.o src/main.cpp:41:25: error: no matching function for call to 'API::API(<brace-enclosed initializer list>)' API api{true, true, true}; ^ In file included from src/main.cpp:23:0: .pio/libdeps/esp32dev/esp32-lib/src/api.h:57:5: note: candidate: API::API() API() {} ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:57:5: note: candidate expects 0 arguments, 3 provided .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate: API::API(const API&) class API { ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate expects 1 argument, 3 provided .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate: API::API(API&&) .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate expects 1 argument, 3 provided src/main.cpp: In function 'void register_default_urls()': src/main.cpp:122:26: error: no matching function for call to 'API::registerDebugUrl()' api.registerDebugUrl(); ^ In file included from src/main.cpp:23:0: .pio/libdeps/esp32dev/esp32-lib/src/api.h:67:10: note: candidate: void API::registerDebugUrl(AsyncWebServer*) void registerDebugUrl(AsyncWebServer *server); ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:67:10: note: candidate expects 1 argument, 0 provided src/main.cpp: In lambda function: src/main.cpp:187:13: error: 'class API' has no member named 'onEventConnect' api.onEventConnect(client); ^ *** [.pio/build/esp32dev/src/main.cpp.o] Error 1 ================================================================= [FAILED] Took 50.93 seconds ================================================================= Wann wird hierzu eine Korrektur erfolgen bzw. ist diese vielleicht schon erfolgt und ich habe nur den falschen Branch? Vielen Dank & Gruß Thomas

Die Frage wollte ich gerade auch stellen, insbesondere wie das dann mit der Bestellung funktioniert 🙃 Am einfachsten wäre es doch, wenn man die Pro bestellt und ihr den SDM72D weglasst, oder?

n‘ Abend, besten Dank für die Rückmeldung, das hatte ich gehofft. Mein Plan wäre, den in der Verteilung vorhandenen SDM630 für die Wallbox zu verwenden und parallel zum Strom- auch ein CAT-Kabel für das RS485-Bricklet zu verlegen. Was müsste denn an der Verkabelung der Box geändert werden? Oder bezog sich die Aussage auf den Einbau des SDM630 in die Box? Vielen Dank 🙂

Hallo, ist es möglich, den WARP Charger Pro mit einem SDM630 Modbus-Zähler (anstelle des SDM72D) zu bestellen bzw. könnte der WARP Charger Smart auch mit einem (bereits vorhandenen) SDM630 kommunizieren? Ein Vorteil wäre dann u. a. ja auch, dass nicht ständig alle drei Phasen anliegen müssen, auch wenn nur einphasig geladen wird. Vielen Dank und Gruß Thomas