poohnet

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

On 10/17/2023 at 8:41 PM, energie2023 said:

Welches der beiden Stromzähler ist den der besser geeignete? Bringt der teurer irgendwelche Vorteile?

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

On 9/20/2023 at 5:54 PM, dkp_cobra said:

EVCC zum PV Überschussladen habe ich testweise zum Laufen bekommen.

Sehr gut 👍 

On 9/20/2023 at 5:54 PM, dkp_cobra said:

Es ist doch richtig, dass ich auch mit dem EnergyManager mit einer Warp1 Pro nicht weiterkomme, weil die Warp 1 keine CP Trennung durchführt und dies auch nicht vom EnergyManager gemacht wird / werden kann.

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.

On 9/20/2023 at 5:54 PM, dkp_cobra said:

Um die Warp 1 umzubauen, müsste ich den 4-poligen Schütz z.B. gegen 2 2-polige Schütze austauschen. Der zweite kann dann die Phase 2 und 3 schalten. Zusätzlich brauche ich dann noch den Industrial Quad Relay 2.0 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.

On 9/20/2023 at 5:54 PM, dkp_cobra said:

Aber wie erfolgt dann die Kommunikation mit EVCC? Die neuen Features werden sicherlich durch die neue Software der MQTT Schnittstelle zur Verfügung gestellt.

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… 😂

On 9/16/2023 at 7:52 PM, dkp_cobra said:

In einem der Threads hatte ich gelesen, da müsse sich noch jemand dazu in C einarbeiten, eine Programmzeile sah für mich aber mehr nach C++ aus.

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

On 9/15/2023 at 5:34 PM, dkp_cobra said:

sieht aber auch nicht nach "Deckel ab, zwei Stecker umstecken, Deckel zu, fertig"

Viel komplizierter ist es aber auch nicht 🙃 Allerdings braucht man eine angepasste Firmware, die die im Ladecontroller der WARP1 nicht vorhandene CP-Trennung durchführt.

Der Umbau von @mattsches ist da sicherlich etwas aufwändiger, kommt dafür aber auch ohne externe Komponenten für die Phasenumschaltung aus.

Letztendlich muss man halt Spaß an derartigen Bastelprojekten haben, d. h. es eher als Hobby sehen, die Box zu tunen. Jedenfalls wird man von den Jungs von TinkerForge hier im Forum (und bei Bedarf auch per PM) bestens unterstützt 💜

Die CP-Trennung habe ich bei meiner WARP1 nachgerüstet und damit die vollständige Kompatibilität mit dem WARP Energy Manager (inkl. Phasenumschaltung) hergestellt:

Gruß Thomas

Alles klar, werde ich morgen machen...

Hallo zusammen,

könntet ihr ggf. nochmal einen Blick auf das angehängte Ladeprotokoll werfen? Ich habe es gestern nämlich nicht geschafft, den ID.4 über 80% zu laden, obwohl ich Battery Care ausgeschaltet und das Ladeziel im Auto auf 90% gesetzt habe.

Die Ladung hat zwei, dreimal kurz begonnen, ist nach wenigen Sekunden aber abgebrochen. Ich habe daraufhin die Box neugestartet und das Ladeprotokoll sowie die Ladung (bewusst nur 3-phasig, 16A) gestartet. Leider ist dann gar nichts mehr passiert, d. h. die Anzeige ging nicht über "Ladebereit" hinaus.

Ich lade heute in der Firma bewusst mal auf 90% um zu schauen, ob dies korrekt funktioniert und (falls ja) ich heute Abend mehr als 80% SOC habe, wenn ich wieder zu Hause ankomme...

Besten Dank & Gruß Thomas

evse-debug-protocol-warp2-XSS-2023-09-10T14-06-15-655.txt

Perfekt! Ich bin froh, dass der Zähler bei dir nun funktioniert und das Problem nicht doch durch irgendeinen Seiteneffekt meiner Firmwareanpassungen verursacht wurde. Vielen Dank Erik auch für deine Unterstützung. Ich hoffe, du hattest einen schönen Urlaub 🙂

Gruß Thomas

Moin Oliver,

das ist jetzt wirklich sehr merkwürdig. Kannst du die Tests bitte nochmal mit der alten Firmware machen, d. h.

• die Zählererkennung zurück auf 255 (automatisch) stellen,
• einen Ladevorgang starten und
• die Kommunikation mit dem BrickViewer prüfen?

Gruß Thomas

Sehr gut! Schön, dass es nun funktioniert 🙂

Wobei ich nicht verstehe, warum a) der Zähler nicht mehr automatisch erkannt wird und b) das "type_override_update" nicht auch in der aktuellen Firmware funktioniert. Vielleicht können @rtrbt und/oder @MatzeTF ja hier etwas Licht ins Dunkle bringen...

Gruß Thomas