poohnet

Moin, die WARP Smart hat keinen Stromzähler verbaut, daher kannst du leider weder die aktuelle Leistungsaufnahme noch den Stromverbrauch auslesen. Du kannst aber problemlos einen kompatiblen Stromzähler nachrüsten (und sie damit auf eine WARP Pro aufrüsten), das ist hier im Forum gut dokumentiert… Gruß Thomas

Ich hatte mir letztes Jahr auch einen WICAN-Dongle bestellt und etwas damit „rumgespielt“. Allerdings hatte ich das Problem, dass ein Zugriff auf den CAN-Bus bei abgeschlossenen Wagen reproduzierbar die Alarmanlage meines ID.4 ausgelöst hat - und offen wollte ich ihn nicht rumstehen lassen 🙈 Das funktioniert bei einer „normalen“ AC-Wallbox (also auch WARP 1-3) leider nicht, da es keinerlei Kommunikation mit dem Fahrzeug gibt. Lediglich der maximal erlaubte Ladestrom, den das Fahrzeug ziehen darf, wird per PWM vorgegeben. Aber schau mal hier, die nächste Generation der WARP wird zumindest mit Autos, die (auch) über einen CCS-Anschluss verfügen, „sprechen“ können:

Das habe ich tatsächlich schon mal probiert, leider wurde die Modbus-TCP-Bridge damit überlastet. s. hier: Wenn möglich würde ich den Raspberry Pi in der UV durch den WEM 2.0 ersetzen, um beide Modbus-Zähler auszulesen, die Daten im Netzwerk zur Verfügung zu stellen und meine WARP1-on-Steroids fit für §14 zu machen. Seit ein paar Wochen habe ich jetzt nämlich ein SMGW („leider“ noch ohne Steuerbox, keine Ahnung, wann das eingebaut wird), sodass ich theoretisch in Modul 3 wechseln könnte…

Moin zusammen, aktuell lese ich den SDM630 in der UV per Modbus/TCP-Bridge und Node-RED auf einem Raspberry Pi aus und stelle die Daten dann meinem WARP-Charger per API-Zähler zur Verfügung. Darüber hinaus gibt es noch einen zweiten Zähler, der ebenfalls mit am Bus hängt und vom SMA Data Manager per TCP/IP ausgelesen wird. Besteht prinzipiell die Möglichkeit, die RS485-Schnittstelle im WARP Energy Manager 2.0 als Modbus/TCP-Bridge zu verwenden - oder alternativ zumindest den WARP API-Zähler zu füttern? Besten Dank und Gruß Thomas

Genau, einfach mal machen und zum Bohrer greifen - oder freundlich bei Tinkerforge anfragen, ob sie das Loch vor dem Versand ggf. bohren können…

Das Verhalten habe ich auch schon festgestellt, allerdings habe ich mich damit abgefunden, beim Fahrzeugwechsel einfach etwas zu warten. Ich würde aber sagen, dass das Problem eher bei evcc zu suchen ist, da die CP-Trennung definitiv eine direkte MQTT-Nachricht verursacht (s. o.). Fun Fact: Auch die Fahrzeugerkennung, die bei evcc i. d. R. ja über die Cloud des Fahrzeugherstellers geht, lässt sich "aus dem Tritt" bringen. Wenn ich beispielsweise im Büro lade und meine Frau ihr Auto zu Hause verbindet, dann wird der Ladevorgang meistens mir zugeordnet... 🙃

Ich denke, evcc könnte den gewünschten Anwendungsfall abdecken: https://docs.evcc.io/docs/features/battery evcc muss zwar parallel installiert werden (und benötigt auch eine gewisse Einarbeitung), harmoniert aber perfekt mit WARP 1/2/3, wenngleich mittlerweile auch viele Funktionen direkt in WARP verfügbar sind… Gruß Thomas

Beides wird in der Konfigurationsdatei (evcc.yaml) eingestellt. Die 15s auf oberster Ebene # open evcc at http://evcc.local:7070 network: schema: http host: evcc.local # .local suffix announces the hostname on MDNS port: 7070 log: info levels: cache: error interval: 15s # control cycle interval und der minimale/maximale Ladestrom beim Fahrzeug vehicles: - name: ev1 title: VW ID.4 type: template template: vw user: xxx password: xxx capacity: 77 phases: 3 mode: off mincurrent: 6 maxcurrent: 16 - name: ev2 title: Renault Zoe type: template template: renault user: xxx password: xxx capacity: 50 phases: 3 mode: pv mincurrent: 8 maxCurrent: 16 Gruß Thomas

Das kann ich bestätigen: Ich hatte bereits einen passenden Zähler in der UV und versorge meine WARP1 seit „Anbeginn der Zeitrechnung“ per MQTT mit den Daten. Das funktioniert 1a…

WARP1/2 hat ein 4-poliges Schütz, WARP3 zwei 2-polige inkl. der Hilfskontakte zur (potentialfreien?) Schützüberwachung. @seppl2025 Warum hast du deine WARP3 komplett auseinander genommen? Wolltest du nicht nur den Stromzähler nachrüsten?

Sehr gerne - es freut mich, wenn man hin und wieder auch mal etwas zurückgeben kann. Schließlich werde ich als „Firmware-Hacker“ von euch allen ja schon seit Jahren jederzeit erstklassig unterstützt! … und wenn ich mir die diversen Entwicklungsbranches anschaue, dann freue ich mich schon darauf, bald noch mehr testen zu können 🙃

Vielen Dank für die detaillierte Analyse und Rückmeldung, @MatzeTF. Wieder ein kleines „Krabbeltierchen“ eliminiert… 😂

Ok, das sind definitiv alles valide Argumente, die vermutlich auf fast jedes IoT-Device zutreffen. UniFi hat übrigens einen extra „IoT-Modus“, in dem u. a. das entsprechende WLAN nur im 2.4 GHz-Band ausgestrahlt wird, vielleicht teste ich die diversen Settings auch mal…

Tja, wenn ich das wüsste… Ich bin auf jeden Fall gespannt, was eure Tests ergeben. Sollte sich das Problem nicht reproduzieren lassen, dann hätte ich auch kein Problem damit, den jetzigen Fix nur in meinem Fork vorzunehmen. Nur aus Neugier: Welches ursprüngliche Problem löst(e) das explizite Setzen auf HT20? Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

Im Log steht immer noch HT20, mein UniFi AP hat im 2.4 GHz Band aber auch nur 20 MHz Kanäle aktiv. EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…