poohnet

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

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

Klar, kein Problem. Einfach in dem von dir zitierten Post die "2" durch "1" ersetzen: Damit solltest du den Zählertyp fix auf den SDM72 festnageln. Vielleicht hat @rtrbt noch eine Idee, ansonsten würde ich dir mal eine Firmware nur aus den Standardmodulen (d. h. ohne meine Anpassungen) bauen...

Hmm, seltsam. Ich habe zwar den Charge Tracker erweitert, aber keine Anpassungen an den Zählermodulen gemacht. Irgendwie scheint der Zähler nicht richtig erkannt (bzw. das Modul nicht richtig initialisiert) zu werden. Hast du im Log irgendwelche Fehlermeldungen? Kannst du das o. g. Update mal mit “payload“:“1“ testen?

Das ist das EVSE-Bricklet. Keine Ahnung, warum das als "unbekanntes Gerät" aufgeführt wird, ist aber bei mir auch so 🙃 Sehr gut! Ich habe nur neue Module in die Firmware mit aufgenommen, keine bestehenden entfernt, daher sollte das eigentlich weiterhin funktionieren. Ich meine aber mal über einen Post gestolpert zu sein, wo die automatische Zählererkennung auch mit der Standardfirmware nicht funktioniert hat und man den Zählertyp dann per "update" fix hinterlegt hat. Ich versuche später mal, den wiederzufinden... Gruß Thomas

Du brauchst vermutlich eine noch weiter angepasste Kalibrierung. Wie gesagt, ich hatte mit meinem ID.4 das gleiche Problem und mit der Datei aus o. g. Post funktioniert's jetzt problemlos im gesamten Bereich 6-16A. Vielleicht probierst du die einfach mal aus... Gruß Thomas

Ein ähnliches Verhalten hatte ich mit meinem ID.4 auch, hier hat die Ladung sogar erst bei 9A stabil begonnen. Evtl. testest du einfach mal meine Kalibrierung aus folgendem Post: Gruß Thomas

Wenn du schon einen SMA Home Manager 2.0 (bzw. SMA Energy Meter) hast, kannst du die Daten auch netzwerktechnisch abgreifen und dem WARP Energy Manager per API zur Verfügung stellen. Ist zwar (noch) ein inoffizielles Feature, funktioniert aber 1a 🙂

Details zur „Kommunikation“ zwischen Wallbox und Fahrzeug sind z. B. hier gut beschrieben: https://ladefragen.de/27/

Ganz einfach, es lädt dann nur ein- oder zweiphasig 🙃 Die Wallbox stellt nur eine oder drei Phasen bereit und teilt dem Auto (über die CP-Leitung) mit, wieviel Strom es maximal ziehen darf. Der Ladecontroller im Auto entscheidet dann selbst, wie viele Phasen verwendet und wie viel Strom tatsächlich gezogen wird. Bei meinem Passat GTE waren in der Ladebuchse beispielsweise L2 und L3 gar nicht verbunden... Gruß Thomas