poohnet

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 🙂

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