poohnet

... und am Besten jetzt direkt die aktuellste Firmware installieren. Gruß Thomas

Der Stromzähler (SDM630) ist nicht im WARP-Charger verbaut sondern in der Unterverteilung und wird über eine Modbus TCP/IP-Bridge (Raspberry mit RS485-Hat) im Netzwerk zur Verfügung gestellt. NodeRED liest die Daten aus und überträgt diese per MQTT an WARP. Parallel kann auch der SMA Data Manager Zählerstände, Leistung etc. abfragen und in das Sunny Portal hochladen. Gruß Thomas

Sehr gut 🙃

Ich weiß aktuell nicht, wie der Default ist, aber sollte bei "fw2" nicht ein "true" stehen? Gruß Thomas

Moin Thomas, wie sieht denn deine "chargers"-Definition in der evcc.yaml aus? Ich musste da nach dem letzten Update von EVCC gestern Abend auch nochmal ran. Meine Config sieht so aus und funktioniert mit v0.93 problemlos: chargers: - name: wallbox1 type: template template: tinkerforge-warp fw2: true host: 192.168.100.8 port: 1883 user: xxxxx password: xxxxx topic: warp/SMH timeout: 30s Gruß Thomas

Hallo zusammen, da die einzelnen Ladevorgänge ja jetzt einzeln getracked werden, wäre es möglich ein "Zähler Dashboard" einzubauen, wo die geladenen kWh pro Monat u. Jahr (d. h. über die letzten 48 Stunden hinaus) angezeigt werden? Im Moment lese ich meinen Zähler parallel aus und speichere die Daten im SMA Sunny Portal. Da gibt's dann u. a. folgende Ansicht: Schön wäre es, wenn das auch direkt im WARP so angezeigt werden könnte... 😍 Besten Dank und Gruß Thomas

Moin, ohne das jetzt ausprobiert zu haben, würde ich sagen, dass die beiden Zeilen "csvfile1.close()" und "input("Press key to exit\n") # Use raw_input() in Python 2" getauscht werden müssen. Wenn der Callback aufgerufen wird, ist die Datei ansonsten nämlich schon wieder geschlossen... Gruß Thomas

Ja, ein ähnliches Problem hatte ich auch (s. https://www.tinkerunity.org/topic/7639-webinterface-kaputt-durch-meterall_values_update/), seit dem Update läuft das aber jetzt problemlos. Einfach die Box neustarten und sofort die 2.0.4 installieren... Gruß Thomas

Moin Erik, man soll den Tag zwar nicht vor dem Abend loben, aber das Webinterface läuft nun schon seit fast zwei Tagen stabil 🙂 Vielen Dank für die (wie immer) tolle Unterstützung hier, viele Grüße und ein schönes Wochenende Thomas

So, die Commits sind nachgezogen und die neue Firmware ist drauf. Mal schau'n, was nun passiert 🙃

Bingo! Das sind die letzten Einträge im Log: 2022-05-04 11:32:43,032 keep_alive_fds 55 -1 -1 -1 -1 2022-05-04 11:32:43,033 keep_alive_pongs 72310851 0 0 0 0 2022-05-04 11:32:43,033 queue_len 20 2022-05-04 11:32:43,044 worker_active yes

Hier noch ein (vielleicht hilfreicher) Hinweis: Auch wenn das Webinterface an sich nicht mehr (richtig) reagiert, die Zählergrafik funktioniert weiterhin:

Moin Erik, tja, das hat leider auch nicht geholfen, das Webinterface ist eben schon wieder kaputt gegangen 🙁 Hat das Problem evtl. etwas mit der Fehlermeldung "httpd_ws_recv_frame failed to get frame len with -1" zu tun? Ich bin mir nicht ganz sicher, aber es scheint, dass die auftritt, wenn ich das Webinterface per iPhone oder iPad öffne. Kann ich noch irgendwas testen, bevor ich ein "reboot" per MQTT sende? Vielen Dank & Gruß Thomas

Danke Erik, wieder was gelernt 😇 Ich habe jetzt alle Anpassungen aus eurem Repository nachgezogen und werde die neue Firmware heute Abend bauen und installieren... Gruß Thomas

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?