Rangliste

Dein Bug ist ein „Feature“, das für „schlaue“ Fahrzeuge nötig ist. Bei einigen neueren Fahrzeugen (z. B. von VW) kann man einstellen, dass der Akku zu einer bestimmten Abfahrtszeit voll sein soll und das Fahrzeug berechnet dann den Startpunkt der Ladung aus der Stromfreigabe der Wallbox. Offensichtlich wurde das Feature (zumindest bei VW) nur für den Fall einer dummen Wallbox mit statischer Stromfreigabe geplant. An Lastmanagement oder PV-Überschussladen hat wohl niemand gedacht. Das führt dazu, dass wenn das Fahrzeug nicht laden will und die Wallbox deswegen nur den Minimalstrom freigibt, das Auto auf einmal Panik bekommt und sofort laden will, weil es ja mit dem Minimalstrom sonst nicht rechtzeitig fertig wird. Daraufhin regelt die Wallbox bis zum fairen Strom bzw. gerade aktuellen PV-Überschuss hoch. Mit dem vielen Strom glaubt das Fahrzeug dann aber, dass es sich ja noch Zeit lassen kann, und hört wieder auf zu laden. Daraufhin gibt die Wallbox dem ladeunwilligen Fahrzeug wieder nur den Minimalstrom und das Spielchen wiederholt sich. Das „schlaue“ Feature ist somit offensichtlich ziemlich dumm implementiert. Da die Fahrzeughersteller natürlich keinen Cent investieren wollen, ihr tolles Feature mit mehr als einem Use-Case kompatibel zu machen, ist aktuell unsere Lösung, einem ladeunwilligen Fahrzeug mehr als den Minimalstrom zu geben. Dass das „schlaue“ Feature kaputt ist, sieht man auch sofort, wenn man PV-Überschussladen nutzen möchte: Sobald viel PV-Überschuss da ist und die Stromfreigabe erhöht wird, hört das Fahrzeug auf zu laden. Ist die Sonne dann weg, fängt das Fahrzeug wieder an zu laden, wird dann aber nicht rechtzeitig fertig oder man muss vorher auf Schnellladen stellen und Strom aus dem Netz kaufen, nachdem man vorher seinen PV-Überschuss verschenkt hat. Top Feature. 👍 Da dein Fahrzeug offensichtlich längere Zeit ladeunwillig an der Wallbox hängt, trifft dich das und führt zu dem von dir beobachteten unsinnigen Verhalten. Wir haben mal weiter oben auf die Todo-Liste gesetzt, eine bessere Lösung für das Problem zu finden. Ansonsten darfst du dich gerne bei VW beschweren, dass die mal ihr Schrott-Feature fixen sollen. 🤢 Wenn ich so drüber nachdenke, wäre es nicht mal kompliziert, das auf Fahrzeugseite zu fixen. Wenn sich die Stromfreigabe der Wallbox ändert, muss das Auto davon ausgehen, dass sie das jederzeit wieder tun kann. Entweder muss dann sofort mit voller Leistung voll geladen werden, da die Freigabe jederzeit wieder auf das Minimum sinken könnte (sichere Variante), oder es wird mit reduzierter Leistung der geplante Abfahrtszeitpunkt angepeilt, also bei einer Abfahrt in 8 Stunden und 40 kWh zu laden wird nur mit 5 kW geladen.

Aktuell unterstützen wir nur die API von forecast.solar. Für die dynamischen Strompreise ist es geplant dass man anstatt die Strompreise von api.warp-charger.com zu pullen, diese auch per MQTT oder HTTP API rein-pushen kann. Würde sich sicher anbieten das für die PV-Ertragsprognose auch so anzubieten.

Hallo, ich würde gebeten meine Lösung hier mal kurz zu beschreiben. Ich nutze: 2x WARP3 Pro Cupra Tavascan VZ Seat Mii Electric 2x WiCAN OBD2-CAN Adapter von MeatPi (WICAN-OBD-C3) Auf einem Ubuntu Server läuft die aktuelle evcc Version und ein Mosquitto Broker. Das WiCAN Modul hat die Firmware v4.12-102-ge1d0a09. Hier die Config vom WiCAN für den Mii: Hier die Config vom WiCAN für den Tavascan: Beim Tavascan gibt es aktuell mit der Firmware und mit den Einstellungen auch keinen Alarm, wenn der PKW abgeschlossen ist... In evcc ist die Konfiguration dann wie folgt, als Benutzerdefiniertes Gerät: title: Seat Mii icon: car capacity: 32 phases: 2 soc: source: mqtt topic: mii/soc range: source: mqtt topic: mii/range odometer: source: mqtt topic: mii/odometer features: - welcomecharge onIdentify: mode: pvUnd gleiches für den Tavascan: title: Cupra Tavascan icon: car capacity: 77 phases: 3 soc: source: mqtt topic: tavascan/soc range: source: mqtt topic: tavascan/range odometer: source: mqtt topic: tavascan/odometer features: - welcomecharge onIdentify: mode: pvAlso der Mosquitto Broker, der auf dem Unbuntu Server läuft, ist der Zentrale Datenaustauschpunkt. Dieser wird sowohl von den Wallboxen, WiCAN Modulen und vom evcc verwendet um die entsprechenden Infos auszutauschen. In evcc ist bei den Wallboxen ein Standard Fahrzeug hinterlegt und das Update Verhalten steht auf "immer", das Update-Intervall auf 1 Minute und das interpolieren ist deaktiviert. In der Garage ist ein Access Point und sobald eines der Autos in diese Reichweite gelangt wird der SoC an den MQTT Broker gesendet, evcc bekommt die Informationen und zeigt diese an. Ist der PKW nicht in Reichweite, dann zeigt evcc nur die zuletzt erhaltenen Werte an. Also das funktioniert hier so wirklich super... Viele Grüße Stefan

Hi, websocket läuft sehr unproblematisch und ist wesentlich einfacher als MQTT, da hier nun kein extra MQTT Broker mehr nötig ist. Probiere es aus, das Thema mit den Anmeldedaten ist nun auch behoben - bei mir funktioniert es gut. Phasenumschaltung wird weiterhin unterstützt und durchgeführt. Ich selbst habe eine WARP 3 Smart.

„Leistung verfügbar“ ist eine Altlast, die aktuell nicht funktioniert. Im Nachhinein haben wir festgestellt, dass die Vorbedingungen für das Kriterium nicht sinnvoll waren. Wenn uns nichts besseres dafür einfällt, wird das irgendwann einfach entfernt. „Netzbezug“ bezieht sich einfach nur auf den momentanen Wert am Netzanschluss. Das hat nichts mit V2G/V2H zu tun und kann nur auf dem Lastmanager genutzt werden, weshalb es bei deiner Wallbox deaktiviert ist. „Netzbezug“ ist auch nur bedingt nützlich, da das Ereignis bei gut ausgeregeltem Netzbezug nahe Null im Sekundentakt ausgelöst werden kann. Damit könnte man z. B. eine Anzeige steuern, damit man weiß, wann man „grün“ und unabhängig fühlen kann. Einen Verbraucher sollte man damit nicht steuern.

Jo, kann ich reproduzieren. Wenn ich über den Browser auf dem Handy die gleiche Seite aufrufe funktioniert es. Die App zeigt ja technisch auch die Webseite an, sehr komisch. Die App bekommt aber in Kürze ein Update wo auch alle Abhängigkeiten und die SDK-Version und so erhöht wird. Ich hoffe dass es das einfach fixt (werde das mit der neuen Version aber nochmal testen vorher).

Okay, danke. Scheinbar bist du der Erste, der die App nutzt um sich zu registrieren 👀 Der Funktionsaufruf für den Download der Datei innerhalb der App fehlt nämlich einfach... (Ich habs verbrochen) Kommt mit der anderen Änderung zusammen.

Brickv 2.4.27 is released

Preis < 6 ¢ und SOC ≤ 50 % Preis < 8 ¢ und SOC ≤ 30 % Wenn du diese beiden Regeln hast, ist die Reihenfolge sogar egal. 😉 Umsortieren der Regeln steht auf der Todo-Liste und ist aktuell leider noch nicht möglich.

Ich habe gerade eingebaut, dass beim PV-Überschussladen nur noch Zähler mit dem Messort „Netzanschluss“ ausgewählt werden können. Damit kommt man hoffentlich sofort auf die richtige Lösung, wenn man versehentlich den falschen Zähler angelegt hat.

Naja, ist ja auch der Zähler für den Wechselrichter und ein Wechselrichter kann nur Energie einspeisen. Möchtest du vielleicht den virtuellen Zähler auf „Netzbezug“ ändern, bzw. einen weiteren Zähler dafür anlegen, falls du beide Werte gleichzeitig sehen willst? Mit dem Netzbezugszähler klappt’s dann auch mit PV-Überschussladen.

Die Wallboxleistung ist in der Tat ein Durchschnittswert über die letzten fünf Minuten. Da der Energy Manager nur diese Durchschnittswerte speichert, steht an der Stelle auch nicht die Momentanleistung zur Verfügung. Wir setzen deine Anregung mal auf die Todo-Liste.

Moin, Anbei der Export meiner Konfiguration der Batteriesteuerung (json) sowie 3 screenshots zu den Einstellungen in der Web-Oberfläche der WARP3: Mein Kostal setzt die Register nach 60 s zurück, daher habe ich das Wiederholraster auf 55 s gesetzt. Hatte in der Beta Phase auch mal 58 s eingestellt, ging auch. Um erst mal zu sehen, was im Normalbetrieb in den Registern steht, habe ich GModBus benutzt. Damit kann man auch Werte testweise schreiben um zu sehen, wie das System reagiert. Da der Plenticore physikalische Vorgaben will (zB Register 1040 in W), braucht es dann noch eine Umrechung von float nach hex. Im obigen Fall "Entladeleistung 0 W" ist das einfach, für andere Werte hilft google "float to hex" ... Batteriespeicher-Konfiguration-Modbus-TCP-Kostal_Plenticore+10_20260214.json Wer aus sowas wie ein *.py wie im referenzierten git macht, ist mir nicht bekannt. hth VinciSC71

Das wäre toll! Auf HomeAssistant gibt es ein Projekt eine lokale PV-Ertragsprognose mittels lokaler KI bereitzustellen: Solar-Forecast-ML Forum dazu

Die Wallbox-Elektronik der WARP4 wird als Ersatzteil verfügbar sein, wie auch schon bei allen vorigen Generationen. Damit kann man dann aus einer WARP3 eine WARP4 machen. Die WARP3-Elektronik ist dann aber über, sodass es eher ein „Umrüsten“ als ein „Nachrüsten“ ist. Da ISO15118 zusätzliche Hardware erfordert, reicht ein Softwareupdate nicht aus.

Falls ihr die ISO erfolgreich implementieren könnt, wird es ein "Nachrüst-Kit" für den WARP3 geben oder reicht ggf. sogar Softwareupdate? Ich wollte meine bestehende Wallbox eigentlich gegen eine von euch tauschen, bin jetzt aber etwas verunsichert, ob ich mit dem Invest nicht lieber warten sollte. dein Link führt wahrscheinlich auf deine "Adminseite" - bei mir kommt jedenfalls irgendein Fehler. Hier der Share-Link, der mir nach Unterzeichnung angezeigt wird: https://c.org/PjrZjx5BRh

Die Batteriesteuerung ist jetzt in den aktuellen Firmwares für alle Produkte mit enthalten. Der Beta-Test ist damit beendet. Danke für eure Unterstützung. Die Entwicklung der Batteriesteuerung ist aber noch nicht angeschlossen. Es wird ähnlich wie bei den Stromzähler noch Unterstützung für weitere Hersteller hinzugefügt werden.

Einfach nur nach WICAN-OBD-C3 in Google suchen und den ersten nicht gesponserten Link zum Mouser Shop. Das "welcomecharge" ist z.B. bei E-Autos der MEB Plattform wichtig, damit da beim anstecken nicht die rote LED an geht. Dadurch wird sofort beim anstecken mit dem beladen begonnen und wenn keine Sonne da ist, nach dem Abschalt-Timer gleich wieder beendet. Wenn beim anstecken kein Strom anliegt, dann leuchtet die LED an PKW nach dem weiß blinken nach einem Moment rot... Also ich habe bei mir die ID.Serie Settings genutzt, daher denke ich, dass der Elroq sicherlich auch funktioniert. Hier gibt es auch noch umfangreiche Infos: https://github.com/meatpiHQ/wican-fw

Wir müssen echt irgendwo einen großen, roten Banner platzieren, dass wir keinen Support für KI-generierten Code bieten. ☠️

Firmware: WARP1 2.9.0, WARP2 2.9.0, WARP3 2.9.0, WARP Energy Manager 2.5.0, WARP Energy Manager 2.0 1.4.0 Batteriesteuerung hinzugefügt Übersetztes SunSpec-Scanprotokoll hinzugefügt (Nur WARP1, WARP2, WARP3) Sprachauswahl zum Download des Ladelogs hinzugefügt (Nur WARP1, WARP2, WARP3) Behoben, dass Standardname des unbekannten Benutzers nicht korrekt im Ladelog angezeigt wurde (Nur WARP1, WARP2, WARP3) Kodierung von nicht-CP-1252-Zeichen im CSV-Ladelog repariert Konfiguration des virtuellen Zählers von Carlo Gavazzi EM270 und EM280-Zählern repariert (Nur WARP Energy Manager 2.0) Hinzugefügt, dass Heizungsmodul deaktiviert wird, wenn SG-Ready-Ausgänge durch Automatisierungsregeln kontrolliert werden (Nur WARP Energy Manager) Konfiguration von Relais-Aktionen im Webinterface repariert Übersetzungen verbessert Download: WARP1 2.9.0 bzw. WARP2 2.9.0 bzw. WARP3 2.9.0 bzw. WARP Energy Manager 2.5.0 bzw. WARP Energy Manager 2.0 1.4.0

man war das eine schwerer Geburt (wenn man wenig Ahnung von Servern/Zertifikaten usw. hat). Aber dank AI läuft eigener Python-Preis-Server auf einem RasPi. Python Script # -*- coding: utf-8 -*- # wapr_prices_server.py (Python 2.7 kompatibel) from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer import time import json # Konstante Preise (Octopus Go): 2 Tage = 192 Werte # 0:00-4:59 → 18890 (20×), 5:00-23:59 → 28890 (76×) → wiederholt für Tag 2 PRICES = ( [18890] * 20 + [28890] * 76 + # Tag 1 [18890] * 20 + [28890] * 76 # Tag 2 ) assert len(PRICES) == 192, "Preis-Array muss genau 192 Eintraege haben" START_TIMESTAMP = 1768258800 EPOCH_DAY_SECONDS = 86400 class PriceHandler(BaseHTTPRequestHandler): def do_GET(self): if self.path != '/v1/day_ahead_prices/de/15min': self.send_error(404, "Not Found") return now = int(time.time()) days_passed = (now - START_TIMESTAMP) // EPOCH_DAY_SECONDS current_first = START_TIMESTAMP + days_passed * EPOCH_DAY_SECONDS current_next = current_first + EPOCH_DAY_SECONDS data = { "first_date": current_first, "prices": PRICES, "next_date": current_next } self.send_response(200) self.send_header("Content-type", "application/json") self.send_header("Access-Control-Allow-Origin", "*") self.end_headers() # Kompakte JSON (spart Bandbreite) json_str = json.dumps(data, separators=(',', ':')) self.wfile.write(json_str) if __name__ == '__main__': server_address = ('', 1234) httpd = HTTPServer(server_address, PriceHandler) print "Fake Strompreis-Server laeuft auf http://0.0.0.0:1234/v1/day_ahead_prices/de/15min" print "Beispiel: curl http://raspberry:1234/v1/day_ahead_prices/de/15min" httpd.serve_forever()und wenn man noch Modul 3 drauf legt (N-Ergie) dann wird es noch ein Tick spannender:

Ja(ein), da geht, allerdings nicht mit einer statischen Datei. Man kann den API-Server, von dem die dynamischen Strompreise angefordert werden, gegen einen eigenen Server austauschen und dann mit einem relativ einfachen PHP- oder Python-Script die Preise für den heutigen und morgigen Tag ausgeben lassen. Das Format der Datei könnt ihr euch hier ansehen: https://api.warp-charger.com/v1/day_ahead_prices/de/15min Das sind 192 Viertelstundenpreise für zwei Tage. Der erste Wert gilt ab dem Zeitpunkt "first_date". "next_date" ist die Anweisung an die Wallbox, wann sie neue Daten abrufen soll. Statt 15min man auch 60min benutzen und dann halt 48 Werte reinschreiben. Den API-Server könnt ihr bei der Wallbox über die API http://warp3-2abc.local/day_ahead_prices/config ändern. Doku dazu hier. { "enable":true, "api_url":"https://api.warp-charger.com/", "region":0, "resolution":0,"cert_id":-1, "vat":0, "grid_costs_and_taxes":0, "supplier_markup":0, "supplier_base_fee":0 }Einfach die api_url auf euren Server umbiegen. Die anderen Werte müsste ihr natürlich eurer aktuellen Config entnehmen. Wenn ihr ein selbstsigniertes Zertifikat verwendet, müsst ihr das erst unter System → Zertifikate hochladen und dann dessen Nummer in der Config angeben. Viel Spaß beim Basteln.

Mahlzeit zusammen, in den letzten Wochen haben wir an einer zentralen Nutzerverwaltung und einem zentralen Ladetracker gearbeitet. Damit besteht die Möglichkeit, Benutzer und NFC-Tags zentral auf dem Lastmanager anzulegen, Ladevorgänge per Tag beim Lastmanager zu autorisieren, sowie Ladevorgänge zentral auf dem Lastmanager zu tracken. Außerdem haben wir die Latenz des Lastmanagements deutlich gedrückt, wenn ein Auto angeschlossen wird. Konfiguriert werden kann es über die Lastmanager-Konfiguration. Die Nutzer und NFC-Tags werden wie gewohnt (aber nur noch auf dem Lastmanager) hinzugefügt. Bekannte Probleme sind: Die lokale Benutzerfreigabe muss deaktiviert werden Gelöschte Wallboxen mit getrackten Ladungen haben keinen Namen Beim Neustart des Lastmanagers werden alle laufenden Ladungen abgebrochen Der Email-Versand von großen Ladelogs funktioniert unter Umständen nicht Exportierte Ladelogs verraten noch nicht von welcher Wallbox die Ladung stammt Das UI ist noch nicht voll ausgereift Beide Features sind vorerst nur für WARP2 und WARP3 verfügbar. Auf dem Energy Manager werden wir beide Features zeitnah nachreichen. Für WARP1 ist das noch unklar, da gerade das Tracken der Ladevorgänge für mehrere Wallboxen und die damit verbundene Generiung von PDF- und CSV-Ladelogs recht RAM-Intensiv ist. Wir freuen uns auf euer Feedback und wünschen frohe Weihnachten! warp2_firmware_2_8_16_69495ab3_4a571754474b8b8_feature-central-user-management-6_merged.bin warp3_firmware_2_8_16_694959d6_4a571754474b8b8_feature-central-user-management-6_merged.bin

Ja, das kenne ich, sowas blödes. Mir war das auch zuerst nicht bewusst und habe das Auto beim Kollegen abgestellt mit dem ich ne Fahrgemeinschaft habe und dann einige Minuten später hat die Nachbarin vom Kollegen angerufen, dass da permanent der Alarm los geht. Man kann das Auto dann ja aus der Ferne öffnen, und damit dem Alarm abstellen, aber wird die Tür dann nicht physisch geöffnet, dann schließt er wieder ab und das ganze geht von vorn los. Also mussten wir umkehren...