poohnet

Hi Erik, leider ist das Problem nach etwas mehr als 24 Stunden nun wieder aufgetreten 🙁 So sah das Webinterface bis heute Vormittag noch aus: Jetzt ist wieder alles weg und auch wenn man die einzelnen Module direkt in der URL angibt (z. B. /#meter, /#evse etc.), dann sieht man nur das leere Framework: Im Eventlog ist war bislang eigentlich (fast) nichts auffälliges erkennbar - außer vielleicht die "httpd_ws_recv_frame failed" Fehler: 0,035 **** TINKERFORGE WARP CHARGER V2.0.1-626f869d **** 0,036 320K RAM SYSTEM 271776 HEAP BYTES FREE 0,046 READY. 0,098 Mounted data partition. 53248 of 3538944 bytes (1.5 %) used 0,187 WARP Charger config version: 2.0.0 0,188 ESP32 Brick UID: SMH 0,539 Set timezone to Europe/Berlin 0,805 No NFC Bricklet found. Disabling NFC support. 0,826 Found 1 records. First is 1, last is 1 0,849 Last charge record size is 112 (112, 0) 1,047 mDNS responder started 1,083 MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE? 1,106 Had to configure soft AP IP address 1 times. 1,106 Wifi soft AP started 1,107 SSID: warp-SMH 1,434 MAC address: 40:F5:20:5B:38:15 1,435 IP address: 10.0.0.1 1,448 Wifi connecting to HMW-IoT 1,462 This is warp-SMH (warp-SMH), a WARP Charger Smart 11kW 4,259 Wifi connected to HMW-IoT 4,333 Wifi MAC address: 40:F5:20:5B:38:14 4,335 Wifi got IP address: 192.168.110.150. Connected to BSSID E4:5F:01:04:D4:08 4,346 Network connected. Stopping soft AP 4,392 MQTT: Connected to broker. 4,626 MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE? 2022-05-02 10:34:47,004 NTP synchronized at 18,000! 2022-05-02 10:35:30,467 This is warp-SMH (warp-SMH), a WARP Charger Pro 11kW 2022-05-02 10:48:51,773 httpd_ws_recv_frame failed with -1 2022-05-02 10:52:07,789 httpd_ws_recv_frame failed to get frame len with 259 2022-05-02 11:25:26,664 httpd_ws_recv_frame failed to get frame len with 259 2022-05-02 14:47:26,432 httpd_ws_recv_frame failed with -1 2022-05-02 14:59:53,592 httpd_ws_recv_frame failed to get frame len with 259 2022-05-02 15:31:38,721 Charger state changed from 0 to 1 2022-05-02 15:31:42,722 Charger state changed from 1 to 2 2022-05-02 15:31:42,764 Tracked start of charge. 2022-05-02 15:31:43,768 Charger state changed from 2 to 3 2022-05-02 16:01:13,910 Charger state changed from 3 to 2 2022-05-02 16:01:15,924 Charger state changed from 2 to 0 2022-05-02 16:01:15,966 Tracked end of charge. 2022-05-02 16:35:27,065 Charger state changed from 0 to 1 2022-05-02 16:36:12,109 Charger state changed from 1 to 2 2022-05-02 16:36:12,156 Tracked start of charge. 2022-05-02 16:36:13,160 Charger state changed from 2 to 3 2022-05-02 17:04:46,414 Charger state changed from 3 to 2 2022-05-02 17:04:48,434 Charger state changed from 2 to 0 2022-05-02 17:04:48,488 Tracked end of charge. 2022-05-03 08:26:53,531 httpd_ws_recv_frame failed to get frame len with 259 Kann das etwas damit zu tun haben, dass ich in meinem Build ein paar Änderungen in den Modulen vorgenommen habe? Das Modul "Modbus Reader" habe ich rausgenommen, da eh nicht verbaut. MQTT habe ich unter "Netzwerk" einsortiert. Anstelle des "Hidden Proxy" verwende ich den "Proxy", sodass ich die Bricklets sehe. Sofern das hilft kann ich gerne auch erstmal mit dem "Originalcode" aus eurem Repository weitertesten... Besten Dank & Gruß Thomas

Hi Erik, vielen Dank für die schnelle Antwort. Ich dachte eigentlich, ich hätte gegen den letzten Stand von Freitagnachmittag gebaut, aber der Commit fehlte mir tatsächlich noch. Ich teste weiter... 🙃 Gruß Thomas

Moin Erik, nachdem ich die neue Firmware ja nun seit ein paar Tagen "richtig" auf meiner WARP1 nutze und die Zählerdaten alle 10 Sekunden per NodeRED bereitstelle, ist mir ein seltsamer Bug aufgefallen. "meter/values_update" und "meter/phases_update" funktionieren problemlos, sobald ich aber auch "meter/all_values_update" sende, dann geht das Webinterface (leider erst nach ein paar Stunden) kaputt und es erscheint der gelbe "Verbindung zur Wallbox verloren!"-Balken: Das Fahrzeug lädt weiter, die aktuellen Daten werden sauber per MQTT bereitgestellt und die Box reagiert auch weiterhin auf die externe Steuerung durch EVCC. Nur das Webinterface ist komplett kaputt und lässt sich nur durch einen Reboot des ESP32-Bricks wiederbeleben. Hast du vielleicht eine Idee, woran das liegen könnte bzw. wie wir den Bug eingrenzen können? Besten Dank & Gruß Thomas

Danke Erik, ich habe den Fix (ddb0655) gerade gefunden und kann bestätigen, dass dieser den Crash behebt! Jetzt traue ich mich auch, die neue Firmware auch auf meinen WARP1 zu flashen... 🙃 Viele Grüße und ein schönes Wochenende Thomas

Moin @rtrbt, erstmal vielen Dank, dass ihr die Anregung aus meinem Fork aufgegriffen habt, d. h. die Daten eines externen Zählers jetzt auch standardmäßig angezeigt werden können 🙂 Prinzipiell funktioniert das sehr gut - zumindest solange zunächst ein "state_update" gesendet und dieses auch verarbeitet wurde (dann erst ist nämlich auch der Punkt "Stromzähler" im Menü vorhanden). Schickt mein NodeRED nach einem Neustart des Bricks aber zuerst ein "all_values_update", dann gibt's im Log die Fehlermeldung "Config index 0 out of range!" gefolgt von einem Crash in "EnergyMeter::updateMeterAllValues()" 🔥 0x400f8416: EnergyMeter::updateMeterAllValues(int, float) at /home/poohnet/esp32-firmware/software/src/modules/energy_meter/energy_meter.cpp:110 0x400d2aa3: std::function<void ()>::operator()() const at /home/.platformio/packages/toolchain-xtensa-esp32/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687 0x40104be8: std::_Function_handler<void (), Mqtt::addCommand(unsigned int, CommandRegistration const&)::{lambda(char*, unsigned int)#1}::operator()(char*, unsigned int) const::{lambda()#1}>::_M_invoke(std::_Any_data const&) at /home/poohnet/esp32-firmware/software/.pio/libdeps/poohnet_warp_eth/strict_variant/src/strict_variant/variant_dispatch.hpp:158 (inlined by) _M_invoke at /home/.platformio/packages/toolchain-xtensa-esp32/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:297 0x400d2aa3: std::function<void ()>::operator()() const at /home/.platformio/packages/toolchain-xtensa-esp32/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687 0x4011def9: TaskScheduler::loop() at /home/poohnet/esp32-firmware/software/src/task_scheduler.cpp:69 0x400e83d4: loop() at /home/poohnet/esp32-firmware/software/src/main.cpp:282 0x4012802d: loopTask(void*) at /home/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50 Vielleicht könnt ihr da bei Gelegenheit ja mal einen Blick drauf werfen... Besten Dank & Gruß Thomas

Da bislang ja anscheinend noch niemand das OLED-Bricklet am ESP32-Brick betreibt, habe ich mal angefangen, eine Implementierung auf Basis der Adafruit GFX Library vorzunehmen...

Danke @rtrbt, das sieht jetzt in der Tat sehr gut aus 👍 Ich erhalte zwar die von dir genannte Warnung, da sich die meisten übertragenen Werte aber eher im ein- bis dreistelligen Bereich bewegen (und ich die Anzahl der Nachkommastellen in Node-RED ja ggf. auch noch begrenzen kann), passt das m. E. so... Gruß Thomas P. S. Soll ich mich bei solchen Themen weiterhin im Forum melden oder lieber per GitHub-Issue?

Moin @rtrbt, besten Dank. Ja, das Problem ist tatsächlich gelöst, d. h. die drei Floats kommen jetzt korrekt an. Dafür gibt es aber einen neuen Bug 🙃 MQTT: Recv buf is 2048 bytes. meter/set_all_values requires 3656. Bump MQTT_RECV_BUFFER_SIZE! Not subscribing!

Guten Abend zusammen, ich würde gerne ein ConfigRoot-Objekt per MQTT setzen und habe dies wie folgt implementiert: ConfigRoot values; values = Config::Object({ {"power", Config::Float(0.0)}, {"energy_rel", Config::Float(0.0)}, {"energy_abs", Config::Float(0.0)} }); ... api.addCommand("meter/set_values", &values, {}, [this]() {}, true); Allerdings erhalte ich im Log des ESP32-Ethernet-Bricks folgende Fehlermeldung, wenn ich das Topic per Node-RED sende: 2022-03-19 19:31:54,741 MQTT: Ignoring message with payload length 51 for topic warp2/XSS/meter/set_values. Maximum length allowed is 48. Anscheinend spielt hier die Anzahl der übertragenen Nachkommastellen eine Rolle, denn wenn ich diese verändere, dann verändert sich auch die Payload-Length in der Meldung entsprechend und mit lediglich einer Nachkommastelle funktioniert das Ganze dann richtig. Als Workaround habe ich jetzt erstmal einen Dummywert in das Objekt aufgenommen, dann klappt's auch mit der gewünschten Anzahl Nachkommastellen. Vielleicht könnt ihr das bei Gelegenheit ja mal prüfen... Besten Dank und Gruß Thomas

Hallo zusammen, ich muss das Topic für die aktuelle Beta-Software leider nochmal aufmachen. Wenn man diese auf einen ESP32-(Ethernet)-Brick flashed, ohne dass das EVSE-Modul angeschlossen ist, dann wird zunächst zwar korrekt "No EVSE Bricklet found. Disabling EVSE support." protokolliert, in der Methode "DeviceName::updateDisplayType()" wird anschließend aber trotzdem ungeprüft per "api.getState()" auf "evse/hardware_configuration" zugegriffen, was in der Folge dann wieder zu einem Crash führt. 🔥 Kurz zuvor wird noch die folgende Fehlermeldung protokolliert: 5,200 Key evse/hardware_configuration not found. Contents are: 5,200 info/version, 5,200 info/modules, 5,211 info/features, 5,211 network/config, ... Klar, das Szenario betrifft jetzt vielleicht nicht soooo viele User, da das EVSE-Bricklet im WARP-Charger ja eigentlich immer vorhanden sein sollte. Wenn man aber (so wie ich) einen separaten ESP32-(Ethernet)-Brick für Entwicklung und Tests verwendet, dann ist das etwas "unschön"... Besten Dank & Gruß Thomas EDIT: Idee für Codeanpassung: void DeviceName::updateDisplayType() { #if defined BUILD_NAME_WARP || defined BUILD_NAME_WARP2 String display_type = "WARP"; if (api.hasFeature("evse")) { if (api.getState("evse/hardware_configuration")->get("evse_version")->asUint() >= 20) { display_type += "2"; } display_type += " Charger "; display_type += api.hasFeature("meter") ? "Pro " : "Smart "; display_type += api.getState("evse/slots")->get(1)->get("max_current")->asUint() <= 20000 ? "11" : "22"; display_type += "kW"; } else { display_type += " Charger w/o EVSE Module"; } if (api.hasFeature("nfc")) { display_type += " +NFC"; } if (api.hasFeature("rtc")) { display_type += " +RTC"; } #elif defined BUILD_NAME_ESP32 String display_type = "ESP32 Brick"; #elif defined BUILD_NAME_ESP32_ETHERNET String display_type = "ESP32 Ethernet Brick"; #endif if (name.get("display_type")->updateString(display_type)) { logger.printfln("This is %s (%s), a %s", display_name.get("display_name")->asCStr(), name.get("name")->asCStr(), name.get("display_type")->asCStr()); } }

Super, vielen Dank. Mit dem jetzigen Softwarestand kann ich die WARP-Firmware auch wieder bauen 🙂 Gibt's mit der neuen Version schon ein Update bzgl. der Kompatibilität zu EVCC?

Moin, das Menü ist nur dann sichtbar, wenn der WARP-Charger auch einen Stromzähler erkannt hat:

Kein Problem, anbei der Flow "WARP SDM630" Kurz zur Erläuterung: Mein SDM630 hängt in der UV und wird über eine Modbus <-> TCP/IP-Bridge angesprochen (Raspberry Pi 4 mit RS485-Hat). Node-RED liest alle 10 Sekunden 5x40 Parameter (das Maximum, das der Zähler lt. Dokumentation hergibt) en bloc aus, bringt die Pakete in die richtige Reihenfolge (da die Bridge die parallelen Anfragen u. U. puffert) und kopiert diese dann in einen großen Buffer. Der Parser erzeugt aus dem Buffer ein Float-Array mit den jeweiligen Werten, die dann per MQTT an den WARP Charger gesendet werden. Parallel werte ich noch die von EVCC (per MQTT zur Verfügung gestellte) geladene Energiemenge aus, sodass "Stromverbrauch seit dem letzten Zurücksetzen" automatisch immer den letzten Ladevorgang anzeigt. Die Anzeige von "Verbundene Phasen" bzw. "Aktive Phasen" ist durch das Anliegen einer Spannung > 200V respektive einen Stromfluss > 1A realisiert. Auch diese Daten werden dann wieder per MQTT an den WARP Charger gesendet. Bei weiteren Fragen gerne melden... 🙃 Gruß Thomas warp_sdm630.json

Alles klar, dann warte ich erstmal noch etwas ab. Mergekonflikte zu beheben macht auf Dauer ja auch keinen Spaß... 🙃 Gruß Thomas

Moin zusammen, seit dem Commit 0b2c2459dc85a8419c64bdfeb354d36cea2f59c2 im Modul "cm_networking" lässt sich die Firmware leider nicht mehr für WARP1 kompilieren 🙁 src/modules/evse/evse.cpp: In lambda function: src/modules/evse/evse.cpp:183:9: error: no matching function for call to 'CMNetworking::send_client_update(const uint32_t&, const uint32_t&, const uint32_t&, const uint32_t&, const uint32_t&, const uint32_t&, const uint32_t&, const unsigned int&, const bool&)' ); ^ In file included from src/modules.h:15, from src/modules/evse/evse.cpp:29: src/modules/cm_networking/cm_networking.h:97:10: note: candidate: 'bool CMNetworking::send_client_update(uint8_t, uint8_t, uint8_t, uint32_t, uint32_t, uint16_t, uint16_t, bool)' bool send_client_update(uint8_t iec61851_state, ^~~~~~~~~~~~~~~~~~ src/modules/cm_networking/cm_networking.h:97:10: note: candidate expects 8 arguments, 9 provided Könnt ihr da bei Gelegenheit bitte mal nach schauen? Anscheinend ist "charge_release" entfallen, ich kann aber leider nicht abschätzen, ob im Modul "evse" evtl. noch weitere Anpassungen erforderlich sind... Besten Dank & Gruß Thomas

@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 🙂