poohnet

Ich hatte diese Informationen bei pyPLC gefunden: https://github.com/uhi22/pyPLC/blob/master/doc/EvseMode.md Hat ein CCS-Stecker da evtl. einen 1K5-Widerstand integriert?

Das ist sehr gut, wenn das demnächst standardisiert wird. Ich habe auch einen dynamischen Stromtarif von Tibber und habe mir die Firmware daher so aufgebohrt, dass ich den aktuellen Preis per MQTT bereitstellen kann und dieser dann beim Start der Ladung gespeichert und im Ladelog ausgewiesen wird. Größter Nachteil dieser Lösung ist aber, dass dieser Preis am Ende u. U. herzlich wenig mit den tatsächlichen Kosten zu tun hat - z. B. weil sich der Preis zwischenzeitlich deutlich geändert hat, der meiste Strom aus PV-Überschuss gekommen ist etc.

Kaum hat man angefangen, sich mit dem Thema zu beschäftigen, sind schon wieder ein paar Stunden rum… 🙃 Letztendlich wird da sicherlich noch eine Menge „Jugend forscht“ nötig sein, aber sooooo kompliziert sieht das aber eigentlich auch nicht aus. Wenn ich das richtig verstanden habe, dann muss der Widerstand zwischen PP und PE 1,5k betragen der EVSE auf CP ein PWM-Signal mit 5% anlegen damit das Auto auf digitale Kommunikation wechselt, die dann über ein paralleles PLC-Modem stattfindet. Zumindest die ersten beiden Punkte sollten WARP-seitig ja relativ einfach umsetzbar sein, allerdings wird damit ja ein 13A-Kabel codiert und mit 5% PWM findet erstmal überhaupt keine Ladung statt. Somit müsste WARP dann nicht nur Daten abfragen, sondern auch die Ladung darüber steuern. Allerdings scheint AC-Laden über ISO 15118 auch nicht allgemeingültig zu funktionieren, sodass die Ansätze z. T. dahin gehen, nur die Fahrzeugparameter (wie z. B. SOC) abzufragen und danach wieder auf die klassische PWM-Vorgabe zurückzuwechseln. Wenn es aber funktioniert, dann sind sogar Ladeströme deutlich unter 6A möglich, was ein weiterer großer Pluspunkt für das Überschussladen wäre. Bitte korrigiert (oder ergänzt) mich, falls ich das nicht richtig zusammengefasst haben sollte…

Ah ok, das ist in der Tat dann etwas komplizierter. Habt ihr denn schon eine grobe Idee bzw. eine halbwegs konkrete „Vorauswahl“ an Hard- und/oder Software? Vielleicht hat ja der ein oder andere hier aus dem Forum Interesse zu unterstützen. 😉

Benötigt man denn zwingend ein solches (propietäres) Modul oder würde hierfür prinzipiell auch der XMC1400 ausreichen? Für das Protokoll an sich gibt es ja bereits Open-Source-Implementierungen (z. B. hier https://github.com/SwitchEV/iso15118)…

Danke auch dir, Matthias! Habe gerade nochmal nachgeschaut: In der UV ist ein 3-poliger C16 verbaut, das stand meine ich damals auch so in der Installationsanleitung für die WARP1. Die 11 kW sind definitiv ausreichend und eigentlich reichen auch die effektiven knapp 10 kW, denn ob die Schnellladung jetzt 2:20 oder 2:40 Stunden dauert, macht letztendlich keinen wirklichen Unterschied. Mit voller Leistung wird ja sowieso nur dann geladen, wenn der Strompreis gerade günstig ist (und der SOC das hergibt), ansonsten tröpfeln da eher einphasig um die 2 kW rein. Letztendlich war das somit auch eher eine Verständnisfrage als ein echtes Problem, d. h. ich wollte eigentlich nur ausschließen, dass das etwas mit meiner CP-Trennung mittels Solid-State-Relais zu tun hat. Andererseits habe ich jetzt, wo die Phasenumschaltung problemlos funktioniert, mit der EVSE-Firmware wieder einen neuen "Spielplatz". Eine 14 kW-Wallbox werde ich aber definitiv nicht draus machen... 🙃

DAS wäre definitiv der Worst-Case, denn dann kriege ich Ärger mit meiner Tochter 😂 Spaß beiseite, ich werde mich mal vorsichtig rantasten und versuchen, einen guten Kompromiss zu finden. Ggf. melde ich mich hierzu dann nochmal... Nochmals besten Dank und Gruß Thomas

Danke Erik, dann bin ich erstmal froh, dass das Verhalten scheinbar nichts mit meinen sonstigen Basteleien zu tun hat 🙃 Dass ihr WARP nur gemäß Spezifikation ausliefern könnt, ist absolut verständlich, aber welche Gefahr würde denn bestehen, wenn ich tatsächlich 17A vorgebe? Der ID.4 hat ja eh nur einen 11 kW-Lader und wenn vielleicht irgendwann einmal ein Gastfahrzeug laden sollte (was in den letzten drei Jahren nur ein einziges Mal vorgekommen ist) und dieses dann auch noch einen 22 kW hätte, würden im schlimmsten Fall diese 17A fließen. Die Zuleitung ist in 6mm² ausgeführt, das 2,5mm² Ladekabel ist mit 20A belastbar und auch der 16A LSS sollte nicht (sofort) auslösen. Oder habe ich einen Denkfehler?

Hallo zusammen, seit ein paar Monaten fährt meine Frau nun auch elektrisch. Ich weiß, die Zoe ist als "Ladezicke" bekannt, d. h. mit 6A oder 7A lädt sie nicht richtig (schon gar nicht dreiphasig) und selbst mit 10A gibt's noch einen recht hohen Blindstromanteil. Auffällig ist aber, dass ich auch bei einer Vorgabe von 16A trotz aktiviertem Boost-Modus nur auf knapp unter 10 kW Ladeleistung komme - und zwar relativ unabhängig von Akkustand und Temperatur. Mein ID.4 lädt mit gleicher Einstellung mit ca. 10,8 kW, daher denke ich, dass das wahrscheinlich nichts mit meiner zwischengeschalteten CP-Trennung zu tun haben kann (zum Beispiel durch eine "Verfälschung" des PWM-Signals), oder? Habt ihr hierzu evtl. eine Idee oder einen Tipp? Klar, letztendlich entscheidet das Auto selbst, wieviel Strom es wirklich zieht, die Diskrepanz "Soll <-> Ist" ist gerade über unterschiedliche SOCs aber schon auffällig. Ansonsten würde ich mal versuchen, den Boost-Modus firmwareseitig vorsichtig zu erhöhen, zumal die Zoe ja bis 22 kW kann... Besten Dank und Gruß Thomas

Hmm, ich habe zwar nur den kleinen 2.5 kW Wechselrichter, aber die Modbus-Schnittstelle ist komplett unabhängig vom Sunny Home Manager 2.0 bzw. dem Sunny Portal konfigurierbar.

😂 Sorry, da fehlte ein @Mannitwi im Angebot... 😂 Das ihr das nicht ohne eigene Testmöglichkeit übernehmen/veröffentlichen könnt, ist klar. Außerdem ist das ja auch eine propietäre Lösung speziell für SMA.

Das ist tatsächlich ein Punkt, die Modbus-Schnittstelle ist standardmäßig nicht aktiv, d. h. die musst du im Webinterface des WR aktivieren. Ich kann aber leider nicht sagen, ob dies mit dem Benutzer-Login funktioniert oder ob dafür das Installateurs-Passwort erforderlich ist. Soweit ich weiß stellt der Sunny Home Manager 2.0 eh keine Daten per Modbus und/oder SunSpec bereit (zumindest habe ich es nicht geschafft, irgendwelche Daten abzurufen), sondern spricht per Speedwire über LAN mit den übrigen SMA-Komponenten (PV-WR, Batterie-WR etc.). Aus diesem Grund habe ich die Firmware des WEM ja angepasst und ein eigenes Zählermodul für den Home Manager implementiert. Wenn du magst, dann kann ich dir gerne mal eine Version der Firmware schicken. Wahrscheinlich solltest du aber auch SunSpec weiterkommen...

Moin Manni, viele Fragen auf einmal, vielleicht versuchen wir erstmal, den WARP Energy Manager richtig zu konfigurieren... 🙃 Kannst du einmal versuchen einen Sunspec-Zähler hinzuzufügen, dort die IP-Adresse deines Wechselrichters (nicht die des SMA Home Managers!) einzutragen und anschließend auf "Suche starten" klicken? Gruß Thomas

Stimmt, das wäre wohl auch eine Option. Mal schauen, ob irgendjemand mal ein neues WARP-Template für EVCC baut…

Moin, ich vermittele mal kurz zwischen Tinkerforge und evcc 🙃 Hier kam die Frage auf, ob evcc WARP3 auch per Modbus TCP steuern kann, sodass man keinen MQTT-Broker benötigt: https://github.com/evcc-io/evcc/issues/13215 Grundsätzlich sollte da ja nichts gegen sprechen (falls jemand ein entsprechendes Template für evcc entwickelt), aber soweit ich das sehe, gibt es noch keine Möglichkeit, die Phasenumschaltung per Modbus zu triggern. Ist das geplant? Danke und Gruß Thomas

Überschreiben nicht, aber Löschen und die null als API-Zähler neu anlegen funktioniert auch 🙃 Grundsätzlich würde ich @MatzeTF aber zustimmen, d. h. wenn ich das jetzt neu implementieren würde (was ich ja vielleicht irgendwann mal muss), dann mit der "richtigen" API...

Doch, funktioniert weiterhin problemlos 🙂

Hallo Gerd, ich stelle die Daten tatsächlich noch über die alte API bereit (d. h. "warp2/XSS/meter/all_values_update"), damit musste ich nur minimale Anpassungen am Node-RED-Flow machen. Das funktioniert absolut problemlos und wenn ich das richtig im Kopf habe, dann bleibt dieser Weg auch weiterhin bestehen. Für den Stromzähler habe ich die SDM630-Vorlage genommen und die Werte für die Einspeisung rausgelöscht: Gruß Thomas

Das ist in der Tat eine stolze Summe. 💰 Letztendlich geht es dabei m. E. dann aber nicht mehr darum, ob sich das irgendwann vielleicht mal rechnet, sondern eher, ob man das als Hobby betrachtet und einem das der Spaß am Umbauen Wert ist. Durch das modulare Konzept der Bricks/Bricklets stehen auf jeden Fall viele Möglichkeiten offen. Ich für meinen Teil bin mit meiner getunten WARP1 jedenfalls weiterhin sehr zufrieden - und solange der Ladecontroller mitspielt, kann ich vielleicht noch das ein oder andere kommende Feature nachziehen…

Ich denke, das ist das kleinste Problem, wenn du einmal auf den Geschmack gekommen bist. Ich baue die Firmware für meine „WARP1 on Steroids Reloaded“ seit mittlerweile drei Jahren selbst und erweitere die Box auch hardwaremäßig immer wieder (erst Umbau auf den ESP32-Ethernet-Brick, dann Nachrüstung der CP-Trennung für die Phasenumschaltung durch WEM und kürzlich der Umbau auf die zwei zweipoligen Schütze für die integrierte Phasenumschaltung). Solange es keine „Breaking Changes“ gibt (und du selbst keine weiteren Anpassungen machen möchtest), kannst du deinen Fork auch über das GitHub-Webinterface synchronisieren und die Firmware über GitHub Actions erstellen lassen. Die Entwicklungsumgebung brauchst du dann nur in Ausnahmefällen…

Den Punkt findest du im Webinterface unter System - Firmwareaktualisierung. Aber Achtung: Danach sind ALLE Einstellungen inkl. der WLAN-Zugangsdaten weg, d. h. du musst dich dann erst wieder mit dem Accesspoint, den der Brick dann aufspannt, verbinden (10.0.0.1), dein WLAN suchen und die Zugangsdaten neu eintragen.

n‘ Abend, du kannst die ESP32-Firmware über den USB-Anschluss z. B. mit PlatformIO flashen. pio run -e esp32 -t upload -t monitor Gruß Thomas

Moin, wenn du eh vor hast, die Zähler selbst auszulesen und die Daten anschließend weiterzuverarbeiten bzw. zu visualisieren, dann kannst du in der WARP auch einen API-Zähler anlegen und die Daten aktiv bereitstellen. So mache ich das über Node-RED. WARP3 kombiniert die Funktionen der WARP2 und des WEM (WARP Energy Manager) in einem Gerät, d. h. PV-Überschussladen inkl. Umschaltung zwischen ein- und dreiphasigem Laden funktionieren out-of-the-box. Wenn du aber weitere Parameter (wie z. B. SOC des Fahrzeugs, aktuellen Strompreis, Hausbatterie, …) in die Ladesteuerung mit einbeziehen möchtest, dann kommst du um EVCC (oder eine eigene Implementierung) aktuell noch nicht herum. Gruß Thomas

Alles klar, besten Dank. Dann werde ich das mal weiter testen (auf dem aktuellen master bin ich momentan eh unterwegs). Insbesondere der low_level_State wäre wichtig, da die neue Logik in EVCC hier ansetzt. Der PR ist übrigens durch, d. h. meine Anpassung wird bald im Nightly-Build verfügbar sein. 😀 Dann könnt ihr die Phasensynchronisation evtl. auch in eurer Umgebung - insbesondere mit der WARP3 - testen. Durch die Anpassung gleicht EVCC den internen Zustand nun immer mit WARP/WEM ab und aktualisiert diesen bei Unterschieden. Somit sollte zukünftig (hoffentlich) immer mit der richtigen Anzahl Phasen geladen werden…

@MatzeTF, gehe ich recht in der Annahme, dass die folgenden Topics sowohl für WEM als auch WARP3 zutreffend sind power_manager/state: config_error_flags u. external_control power_manager/low_level_state: is_3phase und dass power_manager/external_control_update: phases_wanted weiterhin funktionieren wird? Oder sind hier evtl. noch Änderungen geplant, die Auswirkungen auf die Implementierung in EVCC haben könnten?