poohnet

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

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