poohnet

@rtrbt, seid ihr bei solchen Erweiterungen eigentlich daran interessiert, diese ggf. in den master zu übernehmen, oder ist das zu speziell? 🙃

Du kannst gerne mal einen Blick in meinen Fork "poohnet/esp32-firmware" des Repositories auf GitHub werfen...

Perfekt, besten Dank 🙂

Moin zusammen, kurze Frage: Warum verhindert ihr standardmäßig eigentlich die Übernahme eines Integerwertes in ein ConfFloat-Objekt? Wenn ich Gleitkommawerte per MQTT an WARP bzw. den ESP32-Brick schicke, dann erhalte ich die Fehlermeldung JSON node was an integer. Please use f.e. 123.0 to set a float node to an integer value. wenn einer der Werte zufälligerweise mal keine Nachkommastellen hat. In meinem Fork des esp32-firmware Repositories habe ich das jetzt einfach mal auskommentiert, dadurch wird das ganze Handling in Node-RED deutlich einfacher. Probleme o. ä. habe ich bislang noch nicht festgestellt... Besten Dank & Gruß Thomas

Ich meine auf einem großen Display sogar schon mal 30 kW als Obergrenze gesehen zu haben, da sieht man die 1,5 kW Ladeleistung dann nicht mehr wirklich. Evtl. hängt die Skalierung auf der Übersichtsseite also von der Displayauflösung ab und nicht vom max. Ladestrom. Ich schließe mich hiermit aber dem Featurewunsch an, das Diagramm auf der Übersichtsseite genauso zu skalieren wie auf der Zählerseite… 😉

Das hatte ich ursprünglich auch vorgehabt, letztendlich habe ich mich dann aber dafür entschieden, den SDM630 in der UV per Node-RED auszulesen und die Daten per MQTT an den WARP Charger zu senden. Falls Interesse besteht, so kann ich die notwendigen Codeanpassungen (hauptsächlich ein neues Modul namens "sdm630_mqtt" in einem eigenen Build-Target) sowie den Node-RED-Flow gerne hier zur Verfügung stellen... Gruß Thomas

Hallo dasfuu, bei einer "normalen" Wallbox gibt es keine bidirektionale Kommunikation, daher ist dies erstmal nicht möglich (die Wallbox signalisiert dem Ladegerät im Auto einfach nur, wieviel Strom zur Verfügung steht). Schau dir aber mal das Projekt evcc.io an, das erfüllt genau deine Wünsche, indem über herstellerspezifische Schnittstellen online der Ladezustand des Autos abgefragt und die Wallbox entsprechend gesteuert wird. Das funktioniert perfekt mit vielen Wallboxen und auch dem WARP-Charger (den ich selbst jederzeit wieder kaufen würde)... Gruß Thomas

Das Verhalten konnte ich auch bei meiner "besonderen" Installation beobachten, bei der der Zähler (SDM630v2) in der UV montiert ist, die Daten per Node-RED ausgelesen und per MQTT an den WARP Charger gesendet werden. Ich habe die Logik für "verbunden/aktiv" im State-Objekt in Node-RED daher einfach auf Spannung > 200V und Strom > 1A gesetzt, dann ist Ruhe... :-) In der Gesamtübersicht sieht man übrigens sehr schön, dass sich die fehlerhaften Werte mit der Zeit immer weiter aufsummieren. Mein Hybrid lädt definitiv nur einphasig über L1, trotzdem gibt es Import und (interessanterweise auch) Export auf L2 und L3: Gruß Thomas

Moin zusammen, gibt es bereits eine Grafikbibliothek für das OLED-Bricklet, die auf dem ESP32 läuft (ähnlich u8g2, Adafruit, ...)? Die in den Beispielen verwendete C++-Bibliothek "libgd" ist (anscheinend) leider nicht kompatibel. Besten Dank & Gruß Thomas

Jepp, das hat funktioniert, jetzt werden alle Bricklets sauber erkannt 🙂

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... 👍