poohnet

Hi @photron, hier das aktuelle Log zur Unit-ID 126. Leider noch nicht wirklich erfolgreich: Using device address 126 Using base address 40000 Reading SunSpec ID SunSpec ID found Reading Common Model Common Model found (block-length: 66) Common Model block has padding, reading data only Could not read Common Model block (error: ILLEGAL_ADDRESS [2]) Using device address 126 Using base address 50000 Reading SunSpec ID No SunSpec ID found (sun-spec-id: ffffffff) Using device address 126 Using base address 0 Reading SunSpec ID No SunSpec ID found (sun-spec-id: ffffffff)

Ich hatte gestern Abend noch ein bisschen getestet, aber leider vergessen zu antworten 🙈 Modbus ist definitiv aktiv, wobei SunSpec bei SMA wohl unter Unit-ID 126 läuft (das passt ja auch zum o. g. Log) und per Node-RED kann ich auch diverse Daten abgreifen. Besten Dank. Gerne kann ich die Firmware auch selbst aus dem Development Branch kompilieren, dann braucht ihr die nicht ständig zu pushen...

Kein Problem, die neue Firmware steht im Topic "WARP on Steroids" zur Verfügung... Gruß Thomas

neue Firmware 2.1.5 für WARP on Steroids Anpassungen s. hier: warp2_firmware_2_1_5_653fc31b_d95071fff65f02e_merged.bin

'n Abend Erik, dann mache ich hier mal den Anfang 🙃 Mein SMA Sunny Boy 2.5 scheint nicht (zumindest nicht auf Anhieb) zu funktionieren: Starting scan Resolving 192.168.xxx.xxx Connecting to 192.168.xxx.xxx:502 Using device address 1 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: ILLEGAL_ADDRESS (2) Using device address 1 Using base address 50000 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 1 Using base address 0 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 2 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: ILLEGAL_ADDRESS (2) Using device address 2 Using base address 50000 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 2 Using base address 0 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 3 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: ILLEGAL_ADDRESS (2) Using device address 3 Using base address 50000 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 3 Using base address 0 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 4 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: DEVICE_FAILED_TO_RESPOND (11) Using device address 5 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: DEVICE_FAILED_TO_RESPOND (11) ... Using device address 125 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: DEVICE_FAILED_TO_RESPOND (11) Using device address 126 Using base address 40000 Reading SunSpec ID SunSpec ID found Reading Common Model Common Model found Could not read Common Model block: ILLEGAL_ADDRESS (2) Using device address 126 Using base address 50000 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 126 Using base address 0 Reading SunSpec ID No SunSpec ID found: ffffffff Using device address 127 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: DEVICE_FAILED_TO_RESPOND (11) ... Using device address 247 Using base address 40000 Reading SunSpec ID Could not read SunSpec ID: DEVICE_FAILED_TO_RESPOND (11) Disconnecting from 192.168.110.195 Scan finished Ich bin mir allerdings auch nicht 100% sicher, ob die "kleinen" Wechselrichter SunSpec unterstützen... Gruß Thomas

Alles klar, dann warte ich noch etwas. Oder gibt es schon einen Development-Branch, den ich mir anschauen könnte?

Danke für den Hinweis, @MatzeTF. Mittelfristig werde ich wohl die Implementierung zum Auslesen des SMA Energy Meters / Home Managers 2.0 in WEM übernehmen... Gruß Thomas

Moin Knut, der wichtigste Wert für die Regelung ist Netzbezug bzw. -einspeisung, nur so kann das Überschussladen (und damit indirekt auch die Phasenumschaltung) korrekt funktionieren. Normalerweise ist daher direkt hinter dem Zähler deines EVU ein weiterer Zähler installiert, der mit den Komponenten der PV-Anlage (d. h. PV- und ggf. Batterie-Wechselrichter) kommuniziert. Wie das bei Goodwe genau aussieht, kann ich leider nicht sagen, aber irgendwie scheinst du ja einige Werte vom Wechselrichter abgreifen zu können. Der Zähler in der Wallbox ist für die Regelung selbst nicht notwendig, allerdings hast du ohne diesen keine Möglichkeit, die aktuelle Ladeleistung aus dem sonstigen Hausverbrauch rauszurechnen. Darüber hinaus geht EVCC ohne Zähler davon aus, dass wenn z. B. mit 11 kW geladen werden soll, das auch tatsächlich der Fall ist. Letztendlich gibt die Wallbox aber nur die max. erlaubte Ladeleistung vor, wieviel das Auto davon letztendlich zieht, bleibt ihm selbst überlassen. Somit können sich "Soll" und "Ist" u. U. signifikant unterscheiden. Wenn du aber eh noch einen Shelly rumliegen hast, dann musst du nicht unbedingt einen neuen Zähler kaufen; mein Zähler (SDM630) ist z. B. in der UV installiert. Die Daten lese ich über einen Raspberry Pi per Modbus aus und stelle diese per MQTT der WARP bereit. Für EVCC macht das keinen Unterschied, denn EVCC greift eh nur auf das Topic der WARP zu, d. h. muss nicht aktiv mit diesen Daten versorgt werden. Letztendlich kommt es somit in erster Linie darauf an, die benötigten Daten irgendwie abgreifen zu können. Sobald sich diese per MQTT bereitstellen lassen, gibt es schon irgendeinen Weg zu WARP/WEM/EVCC 🙃 Gruß Thomas P. S. Hier (https://herrmayr.de/pv-ueberschussladen-mit-goodwe-wechselrichter-home-assisant-und-evcc/) gibt es ein Tutorial für die Konfiguration von EVCC im Zusammenspiel mit HA und Goodwe...

Gerne - Danke für die Blumen 😀

Hallo Knut, wenn du eh vor hast, die Steuerung über EVCC zu realisieren, dann kannst du dich auch direkt mit dem Thema beschäftigen - sooo kompliziert ist die Konfiguration nämlich nicht 🙃 Der Vorteil ist, dass du Phasenumschaltung, min./max. Ladestrom, Batterie und evtl. Berücksichtigung des Börsenstrompreises an einer zentralen Stelle hast. Grundsätzlich brauchst du für die Regelung immer einen Zähler am Hausanschluss, der Netzbezug und -einspeisung messen kann (sowohl für WEM als auch für EVCC), wobei die Daten bspw. auch per MQTT bereitgestellt werden können. Hierzu sind wir ja gerade auch in deinem zweiten Post in Kontakt. Wenn du Leistung und Verbrauch des WARP-Chargers separat messen/aufzeichnen möchtest (was definitiv empfehlenswert ist) dann musst du einen Zähler nachrüsten; die Daten des WEM helfen da nicht weiter… Gruß Thomas

Ah, du übergibst die Werte als String (in Anführungszeichen), es muss aber ein Float oder Integer sein.

Hast du den Stromzähler-Typ auf „Benutzerdefinierter Zähler“ gesetzt?

Ja, richtig - "energy_rel" und "energy_abs" werden nur von WARP, nicht aber von WEM nicht ausgewertet und müssen daher immer vorhanden sein. Den o. g. Codeschnipsel kannst du direkt in eine Node-RED-Function packen, da habe ich den auch rauskopiert ;-) Gruß Thomas

Moin Oliver, in der aktuellen Entwicklungsversion gibt's die Möglichkeit schon. Wenn du magst, dann stelle ich dir den Firmwarestand für WARP on Steroids zur Verfügung... Gruß Thomas

Moin Knut, du schickst dem WEM einfach ein "values_update" (bei mir z. B. "wem/26ue/meter/values_update") mit folgendem Payload: var result = { topic: "values", payload: { power: msg.payload, energy_rel: null, energy_abs: null } }; return result; Es müssen immer alle drei Werte vorhanden sein, ausgewertet wird aber nur "power". Positive Werte sind hier Netzbezug, negative Netzeinspeisung. Gruß Thomas

Das kann ich leider nicht sagen. Ich selbst verwende den SDM630 mit WARP1, wobei der Zähler aber nicht in der Wallbox sondern in der Unterverteilung verbaut ist. Die Daten werden per Raspberry Pi ausgelesen und dann per MQTT bereitgestellt. Gruß Thomas

Genau, das sind die beiden Zähler, die lt. Code von WARP2 (EVSE V2) standardmäßig unterstützt werden: #define METER_TYPE_NONE 0 // Supported by modbus_meter module #define METER_TYPE_SDM72DM 1 // Supported by modbus_meter or evse_v2 module #define METER_TYPE_SDM630 2 #define METER_TYPE_SDM72DMV2 3 // Supported by energy_manager module #define METER_TYPE_SDM72CTM 4 #define METER_TYPE_SDM630MCTV2 5 // Supported by mqtt_meter module #define METER_TYPE_CUSTOM_BASIC 200 #define METER_TYPE_CUSTOM_ALL_VALUES 201 Ansonsten kannst du die Zählerwerte auch per API (MQTT, HTTP) bereitstellen. Gruß Thomas

Danke Erik, das sieht jetzt wieder gut aus 🙂

Guten Morgen zusammen, seit ein paar Tagen bleiben meine Github Actions Builds für WARP und WEM hängen und werden dann irgendwann (nach sechs Stunden) abgebrochen: Lokal konnte ich das Problem zunächst nicht nachvollziehen - bis ich auf die Idee kam, das Repo mal in ein neues/leeres Verzeichnis abzurufen und die Builds dort zu starten. Und siehe da, auch diese bleiben nun reproduzierbar im Schritt "Web interface dependencies are not up-to-date (marker file missing), updating now" hängen 😟 $ pio run -e energy_manager Processing energy_manager (board: esp32_ethernet_brick; platform: platformio/espressif32@^5.4.0; framework: arduino) -------------------------------------------------------------------------------- Verbose mode can be enabled via `-v, --verbose` option Updating packages Clearing arduino-esp32#warp-2.0.2 Clearing arduino-esp32#warp-2.0.7 Clearing arduino-esp32#warp-2.0.7-1 Clearing arduino-esp32#warp-2.0.7-1_5a32cef9d41d229fb071ddb99954134b6e28928b Clearing arduino-esp32#warp-2.0.8_035c8510036bbcd47d3e17c23903b4a9ffaa11d9 Clearing arduino-esp32#warp-2.0.8_532fdfc25add50bd4a58f240bc7765da24627e65 Clearing arduino-esp32#warp-2.0.8_7fb92b0e99a57f5c1aadbe5084ad3fc710cff7b5 Clearing arduino-esp32#warp-2.0.8_f28d3f3005822befe76f8decd052322e41459846 Clearing arduino-esp32#warp-2.1.3_6d324e561b9da599f44212cfb6b8d55d24a1531b Clearing arduino-esp32#warp-2.1.4_c921691ac08faf25fc6c55106846d6698d504f25 Skipping arduino-esp32#warp-2.1.5_49331ac8f553d5e314a97eebd8ba635a27442de3 Clearing arduino-esp32#warp-2.1.5_7566d054c407469983d4e971bd54001b67bc9e7a Clearing arduino-esp32#warp2-2.0.2 Clearing arduino-esp32#warp2-2.0.8 Clearing arduino-esp32#warp2-2.0.8-1 Clearing arduino-esp32#warp2-2.0.8-1_7ee30a65df8e505af2f677ad65184b570009bf03 Clearing arduino-esp32#warp2-2.0.90_ae7cdb0f7fa90f8b2500063f6a2d7081b5f5e2c3 Clearing arduino-esp32#warp2-2.0.9_1d6f5403b0f31fdf4695af28fd65589d2f901c7a Clearing arduino-esp32#warp2-2.0.9_40a69926bf20860224fbe65b6ebc27f8b3d62c09 Clearing arduino-esp32#warp2-2.0.9_9326b6026102e72489017bcf1c8fa08d0084e30f Clearing arduino-esp32#warp2-2.0.9_9b884c39a1c00bf02e47fefac3b3543d4e09e01c Clearing arduino-esp32#warp2-2.1.3_bd9c96d4e26747bcdf4fbcde1cfeef9e0ee9f598 Clearing arduino-esp32#warp2-2.1.4_32458a66419a299083ee70f1372a03453a2aa88d Skipping arduino-esp32#warp2-2.1.5_8f8dfc02ec6fa0ebc08ec906ad71eca2c9e6f171 Clearing arduino-esp32#warp2-2.1.5_d0f25126da68a18cdb1fb0eacd3b171d90714ead Preparing backend module: NTP Preparing backend module: Firmware Update Embedding recovery_html (digest file missing) Preparing backend module: Rtc Bricklet Embedding real_time_clock_v2_bricklet_firmware_bin (digest file missing) Preparing backend module: Energy Manager Embedding warp_energy_manager_bricklet_firmware_bin (digest file missing) Preparing backend module: Pwa Embedding manifest (digest file missing) Generating module_dependencies.h from module.ini Ignoring unused translation override de.charge_tracker Ignoring unused translation override en.charge_tracker Missing hyphenations detected. Add those to hyphenations.py! Donnerstag Donnerstags Gespeicherte Wednesdays akzeptiert setMinutes toLocaleTimeString Checking translation completeness ... Unused placeholders: de.certs.content.add_cert_id de.certs.content.cert_file_muted de.certs.script.reboot_content_changed de.certs.script.save_failed de.charge_tracker.script.csv_header_username de.component.input_password.not_set de.evse.content.active_high de.evse.content.active_low de.evse.content.button_configuration de.evse.content.button_pressed de.evse.content.button_released de.evse.content.gpio_in de.evse.content.gpio_out de.evse.content.gpio_out_high de.evse.content.gpio_out_low de.evse.content.gpio_shutdown de.evse.content.gpio_state de.mqtt.content.no de.mqtt.content.yes de.rtc.content.hour de.rtc.content.minute de.rtc.content.wday en.certs.content.add_cert_id en.certs.content.cert_file_muted en.certs.script.reboot_content_changed en.certs.script.save_failed en.charge_tracker.script.csv_header_username en.component.input_password.not_set en.evse.content.active_high en.evse.content.active_low en.evse.content.button_configuration en.evse.content.button_pressed en.evse.content.button_released en.evse.content.gpio_in en.evse.content.gpio_out en.evse.content.gpio_out_high en.evse.content.gpio_out_low en.evse.content.gpio_shutdown en.evse.content.gpio_state en.mqtt.content.no en.mqtt.content.yes en.rtc.content.hour en.rtc.content.minute en.rtc.content.wday Checking translation override completeness Checking web interface dependencies Web interface dependencies are not up-to-date (marker file missing), updating now Könnt ihr das Problem auch reproduzieren bzw. habt evtl. eine Idee, wie man es lösen kann? Vielen Dank & Gruß Thomas

Sehr gut 👍

Ich bin mir zwar nicht ganz sicher, glaube aber die MQTT-Topics sind case-sensitive. Probier mal in der evcc.yaml „warp/SC9“ zu verwenden, d. h. exakt so, wie es im Log der Box ausgegeben wird.

„fw2: true“ ist outdated, d. h. muss/darf nicht mehr angegeben werden. Hat WARP denn eine Verbindung zu Mosquitto? Vielleicht startest du sicherheitshalber alles nochmal neu… Gruß Thomas

Sehr gut 👍 Richtig. Standardmäßig funktioniert die Phasenumschaltung des WEM nicht mit WARP1, mit meiner o. g. Erweiterung aber schon. Du bräuchtest dann nur das Industrial Quad Relay Bricklet (2.0, nicht 2.1) und meine Firmware-Erweiterung für die CP-Trennung. Das wird @mattsches besser beantworten können, soweit ich das verstanden habe, verwendet er aber auch Industrial Quad Relay Bricklet und hat noch einen Kanal frei, der für die CP-Trennung verwendet werden könnte. Der WEM ist für EVCC nicht direkt sichtbar, vielmehr sieht das so aus, als ob WARP selbst eine Phasenumschaltung hätte.

Hmm, am Wochenende konnte ich das Problem nicht nachvollziehen, der ID.4 hat trotz 85% SOC sowohl ein- als auch dreiphasig anstandslos geladen. Ich werde das mal weiter beobachten…

Keine Sorge, ich habe das nicht als „meckern“ verstanden. Schön, dass das mit dem Trennschalter (erstmal) deinen Anforderungen genügt - aber wie war das? Der Appetit kommt mit dem Essen… 😂 Die Firmware für den ESP32-Brick ist definitiv C++ und NodeJS, nur wenn du die Low-Level-Firmware der Bricklets anpassen möchtest, brauchst du C. Das war zumindest bei mir aber noch nie der Fall, denn auch wenn man neue Bricklets integrieren möchte (wie z. B. das Industrial Quad Relay), dann gibt´s fertige Firmware-Binaries, die man „nur“ noch einbinden muss. Gruß Thomas