poohnet

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

Moin, kein Problem, besten Dank für die Rückmeldung. Da mein WARP Charger letzte Woche auch angekommen ist, probiere ich das mal aus 😀 Ich nehme an, dass man nach dem Build die "warp_firmware_xxx_merged.bin" flashen muss, oder? Gruß Thomas

Hallo batti, da mein WARP-Charger Smart bald ankommen sollte, habe ich mich in den letzten Wochen schon mal etwas mit dem Quellcode der Software beschäftigt. Wenn ich das richtig sehe, dann wird die RS485/ Modbus-Verbindung zum Zähler (zumindest aktuell) ja nur für das Webinterface benötigt, oder? Weitere Steuerungsmöglichkeiten habe ich zumindest nicht gefunden und die angesprochenen Modbus-Register sind sehr überschaubar. Hintergrund: Ich hatte ja ursprünglich geplant, meinen bereits in der UV verhandenen SDM630 für die Wallbox zu verwenden und ein separates Netzwerkkabel zwischen Zähler und Bricklet zu verlegen. Da ich den RS485-Bus aber sowieso bereits auf Modbus-TCP „konvertiere“ (über einen ESP32-Mini mit eModbus-Library), könnte ich diese Bibliothek doch auch in die WARP-Firmware einbauen und die relevanten Stellen beim direkten Zugriff auf das Bricklet durch entsprechende eModbus-Calls ersetzen, sodass eine vollständig drahtlose Kommunikation stattfindet. Was haltet ihr davon? Spricht da aus eurer Sicht etwas dagegen (außer vielleicht, dass ich diese Anpassung mit jeder neuen Firmware-Version erneut machen müsste)? Vielen Dank & Gruß Thomas

Perfekt, jetzt konnte ich die Firmware erfolgreich bauen 🙂 Vielen Dank für die schnelle Unterstützung. Ich freue mich schon auf den WARP Charger und das, was da demnächst noch alles kommt... Gruß Thomas

Danke Erik, jetzt bin ich einen Schritt weiter, erhalte aber leider immer noch einen Compile-Fehler: Dependency Graph |-- <ESP Async WebServer> 1.2.3+sha.0c365d8 | |-- <AsyncTCP> 1.1.1 | |-- <ArduinoJson> 6.17.2+sha.1360b6a | |-- <FS> 1.0 | |-- <WiFi> 1.0 |-- <ArduinoJson> 6.17.2+sha.1360b6a |-- <strict_variant> 1.0.0+sha.1112078 |-- <Pangolin MQTT Client> 1.0.0+sha.ceeeddc | |-- <AsyncTCP> 1.1.1 |-- <esp32-lib> 1.0.3+sha.cd031ee | |-- <ESP Async WebServer> 1.2.3+sha.0c365d8 | | |-- <AsyncTCP> 1.1.1 | | |-- <ArduinoJson> 6.17.2+sha.1360b6a | | |-- <FS> 1.0 | | |-- <WiFi> 1.0 | |-- <ArduinoJson> 6.17.2+sha.1360b6a | |-- <FS> 1.0 | |-- <strict_variant> 1.0.0+sha.1112078 | |-- <SPIFFS> 1.0 | | |-- <FS> 1.0 | |-- <SPI> 1.0 |-- <SPIFFS> 1.0 | |-- <FS> 1.0 |-- <WiFi> 1.0 |-- <Update> 1.0 |-- <ESPmDNS> 1.0 | |-- <WiFi> 1.0 Building in release mode Compiling .pio/build/warp/src/main.cpp.o Compiling .pio/build/warp/src/modules/authentication/authentication.cpp.o Compiling .pio/build/warp/src/modules/evse/evse.cpp.o Compiling .pio/build/warp/src/modules/firmware_update/firmware_update.cpp.o src/modules/authentication/authentication.cpp: In member function 'void Authentication::setup()': src/modules/authentication/authentication.cpp:36:16: error: 'class AsyncWebServer' has no member named 'setAuthentication' server.setAuthentication(user.c_str(), pass.c_str()); ^ *** [.pio/build/warp/src/modules/authentication/authentication.cpp.o] Error 1 ================================================================= [FAILED] Took 23.18 seconds ================================================================= Macht euch deswegen aber bitte keinen Stress, ich kann mir vorstellen, dass ihr sowieso gerade genug mit den WARPs um die Ohren habt. Jedenfalls gibt es in den Repositories ja aktuell eine Menge Änderungen... 🙃 Gruß Thomas

Guten Morgen, da ich ja bald meinen WARP-Charger erhalte, wollte ich mich schon mal etwas mit der Software beschäftigen. Leider lässt sich das Projekt "esp32-brick" z. Z. nicht übersetzen, da hier die letzten Änderungen in der Klasse "API" aus dem Projekt "esp32-lib" anscheinend noch nicht nachgezogen wurden: ... Building in debug mode Compiling .pio/build/esp32dev/src/main.cpp.o Compiling .pio/build/esp32dev/src/modules/firmware_update/firmware_update.cpp.o Compiling .pio/build/esp32dev/src/modules/proxy/proxy.cpp.o Compiling .pio/build/esp32dev/src/modules/wifi/wifi.cpp.o src/main.cpp:41:25: error: no matching function for call to 'API::API(<brace-enclosed initializer list>)' API api{true, true, true}; ^ In file included from src/main.cpp:23:0: .pio/libdeps/esp32dev/esp32-lib/src/api.h:57:5: note: candidate: API::API() API() {} ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:57:5: note: candidate expects 0 arguments, 3 provided .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate: API::API(const API&) class API { ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate expects 1 argument, 3 provided .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate: API::API(API&&) .pio/libdeps/esp32dev/esp32-lib/src/api.h:55:7: note: candidate expects 1 argument, 3 provided src/main.cpp: In function 'void register_default_urls()': src/main.cpp:122:26: error: no matching function for call to 'API::registerDebugUrl()' api.registerDebugUrl(); ^ In file included from src/main.cpp:23:0: .pio/libdeps/esp32dev/esp32-lib/src/api.h:67:10: note: candidate: void API::registerDebugUrl(AsyncWebServer*) void registerDebugUrl(AsyncWebServer *server); ^ .pio/libdeps/esp32dev/esp32-lib/src/api.h:67:10: note: candidate expects 1 argument, 0 provided src/main.cpp: In lambda function: src/main.cpp:187:13: error: 'class API' has no member named 'onEventConnect' api.onEventConnect(client); ^ *** [.pio/build/esp32dev/src/main.cpp.o] Error 1 ================================================================= [FAILED] Took 50.93 seconds ================================================================= Wann wird hierzu eine Korrektur erfolgen bzw. ist diese vielleicht schon erfolgt und ich habe nur den falschen Branch? Vielen Dank & Gruß Thomas

Die Frage wollte ich gerade auch stellen, insbesondere wie das dann mit der Bestellung funktioniert 🙃 Am einfachsten wäre es doch, wenn man die Pro bestellt und ihr den SDM72D weglasst, oder?

n‘ Abend, besten Dank für die Rückmeldung, das hatte ich gehofft. Mein Plan wäre, den in der Verteilung vorhandenen SDM630 für die Wallbox zu verwenden und parallel zum Strom- auch ein CAT-Kabel für das RS485-Bricklet zu verlegen. Was müsste denn an der Verkabelung der Box geändert werden? Oder bezog sich die Aussage auf den Einbau des SDM630 in die Box? Vielen Dank 🙂

Hallo, ist es möglich, den WARP Charger Pro mit einem SDM630 Modbus-Zähler (anstelle des SDM72D) zu bestellen bzw. könnte der WARP Charger Smart auch mit einem (bereits vorhandenen) SDM630 kommunizieren? Ein Vorteil wäre dann u. a. ja auch, dass nicht ständig alle drei Phasen anliegen müssen, auch wenn nur einphasig geladen wird. Vielen Dank und Gruß Thomas