Rangliste

Leider muss ich diese „Art“ von Anspruchsdenken hier immer wieder lesen. Andere Hersteller brauchen alleine 5 Monate um ihre Anfrage zu beantworten (wenn überhaupt). Hätten sie hier einfach gefragt ob es möglich wäre vor der Montage ein weites Loch zu bohren und eine Durchführung zu montieren wäre zu hundert Prozent ein „Ja“ gekommen. Wahrscheinlich sogar jetzt noch. Stattdessen kommt eine abfällige beleidigte Leberwurst Antwort und „in Deutschland“ Geschwurbel. Was hat die Antwort mit dem Land zu tun? Ich denke ein respektvoller Umgang und ein wenig Verständnis kommen besser an. Warum z.B. sollte ein Hersteller (die Gehäuse werden wahrscheinlich nicht bei TF selbst gefertigt) eine Umstellung eines Gehäuses vornehmen (müssen?) wenn ohnehin eine neues Gehäuses geplant ist. Und das für wahrscheinlich sehr wenige Kunden die das brauchen und nicht selbst hinbekommen?Kostet schließlich auch wieder Geld das der Kunde dann tragen muss. Klar, das ist wohl das alte „der Kunde ist König“-Gefühl. Kann man haben, sollte aber nicht so auftreten ;-) Ich denke das (kleine) Team hier macht mehr Support und Sonderlocken als jede große WB Firma. Aber fragen muss man halt schon noch selbst. Gruß, Flo.

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

Gutes Argument, aber könnt ihr dann nicht einfach zuschauen, wie alles automatisch funktioniert? 😉 Okay, zugegebenermaßen ist die ganze Logik im Lastmanagement inzwischen so komplex, dass wir ein paar Bugs drin hatten, die von den besagten technikbegeisterten Nutzern entdeckt wurden… Die wirklich faszinierende Technik des Lastmanagements kannst du dir zu Hause übrigens gar nicht ansehen. Stell dir einen Ladepark mit 64 Wallboxen vor, mit einer bunten Mischung aus WARP 1, WARP 2 (mit und ohne Phasenumschaltung per Energy Manager) und WARP 3, manche davon mit bekannter, manche mit unbekannter Phasenrotation, der an einer unterdimensionierten Zuleitung hängt, die dynamisches Lastmanagement benötigt, und der zusätzlich auch noch bei gutem Wetter PV-Überschussladen auf allen Wallboxen machen soll und bei schlechtem Wetter die billigsten Stunden eines dynamischen Stromtarifes nutzen soll, und dann am Ende des Tages, wenn alle Mitarbeiter der Firma nach Hause wollen, jedem ungefähr gleich viel Energie ins Auto geschoben haben. Gleichzeitig soll der Anwendungsfall mit nur einer Wallbox zu Hause damit genauso gut funktionieren. Ja, wir hatten im letzten Jahr echt viel Spaß. 🤪

Du brauchst einen Typ-A. Typ-B brauchst du nur, wenn die Wallbox keinen Gleichstrom-Fehlerschutz integriert hat. Hat sie aber, was auch drei Zeilen darüber steht. Von daher verstehe ich auch nicht, woher die Information kommt, dass ein Typ-B gebraucht wird. In der WARP3-Anleitung steht jedenfalls eindeutig, dass nur ein Typ-A gebraucht wird. Wenn du dir nicht sicher bist, was du jetzt glauben sollst, glaube vielleicht besser den Angaben des Herstellers, statt einer von Dritten betriebenen Seite. 😉

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.

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:

Wir haben deinen Wunsch nach variabler Ladeleistung für den Speicher und die Motivation dahinter zur Kenntnis genommen. Aktuell ist die Funktion nicht geplant, da andere Funktionen deutlich wichtiger sind. Bitte frage nicht weiter danach.

@meierchen006 Wie wäre es mal ernsthaft Gedanken zu machen, dass Du Dir mal jemanden suchst, der deine Ideen und Fatasien in DEINER eigene Firmware umsetzt? Die WARP-Firmware liegt bei github zum freien erweitern. Bei OpenWB finden sich ggf. noch weitere, interessante Codeschnipsel. Wir sprechen hier von einer WALLBOX mit begrenztem Ressourcen und einem Entwicklerteam mit ebenfalls begrenzten Ressourcen! Es wurde von den tinkerforge-Admins bereits mehrfach und an diversen Stellen geschrieben, dass es wichtigere Funktionen gibt welche umgesetzt werden müssen! So hartnäckig Du hier versuchst hast, dass jemand eine simples Loch in "Dein" Warp-Gehäuse bohren soll, oder aktuell versuchst dein persönliches BYD-spezifischen Wünsche hier zu platzieren, so findest Du mit dieser Motivation sicherlich jemanden der deine Fantasien eines eilegengenden Wollmilch-Speicher-Pflegesystem mit Wallboxfunktionen im nu umsetzt.

Eine extra Einführung für ein §14a EnWG-Steuerkabel ist für die nächste Hardware-Änderung bereits fest eingeplant. Wir wollen auch die Einführung für das Ethernet-Kabel so groß machen dass man dies direkt mit RJ45-Stecker einführen kann. Zu unserer Verteidigung: Wir haben uns bei der Umstellung von WARP2 auf WARP3 Feedback von den Elektrikern eingeholt die am meisten bei uns kaufen und das Feedback war durch die Bank dass es für die Elektriker normal ist Löcher in Installationsgehäuse zu bohren um Kabel einzuführen, daher hatten wir davon abgesehen.

Abend! ich glaube ich habe das Problem gelöst. 🥳 Mir ist eingefallen, dass es im Born unter der "Einstellung Laden" die Funktion "Wechselstromkabel nach Abschl. des Ladevorgangs freigeben" gibt. Diese Einstellung hatte ich deaktivert. Weil ich nicht will, dass jemand mir den Stecker zieht (also dem Born 😅) nachdem der Ladevorgang beendet ist, ohne dass ich den Born aufschließe. Gerade an öffentlich zugänglichen Ladepunkten ein sinnvolles Setting. Jetzt vermutete ich, dass der Born das cp disconnect Signal ignoriert wenn er selbst die Steckerfreigabe verweigert. Und so scheint es zu sein. Ich habe jetzt mehrere Tage bei doch recht wechselhaftem Wetter mit Phasenwechseln und Ladepausen geladen, ohne dass ich Probleme hatte und den Stecker physikalisch ziehen musste. Finde es zwar unbefriedigend, dass jetzt der Stecker gezogen werden kann wenn die Ladung beendet ist, aber damit muss ich wohl erst mal leben. Versuche den Punkt bei Cupra/VW zwar mal zu adressieren, aber ich zweifle dran, dass das schnell gehen wird. Hoffe, ich kann mit dem Tipp noch jemand anderem behilflich sein.

Welchen Grund sonst könnte es denn geben, die Wallbox von euch zu kaufen, außer faszinierendes Technik Spielzeug zu wollen? Autos aufladen wird völlig überbewertet, die sind nur Mittel zum Zweck, um Phasenumschaltungen und Überschussladen im Detail optimieren zu können... :-)

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

Kommt voraussichtlich mit dem nächsten Firmware-Release.

Ich sag mal so ... wenn Geld keine Rolle spielt, kannst Du das alles so machen. Möglicherweise tendiert man auch zu "alles bisschen größer und aufwendiger", wenn man neu im E-Auto-Thema ist. Nur mal so als Vergleich ... wir haben inzwischem 3 E-Autos und fahren mit denen zusammen ca. 70000 km pro Jahr und kommen nicht nur mit einer einzigen 11kW-Wallbox bestens aus sondern sind noch weit davon entfernt, dass die irgendwie dauernd belegt wäre und wir dadurch einen Engpass hätten. Mit einer 11kW-Box brauchst Du nicht dimmen sondern nur anmelden und hast kein Theater mit komplexer Steuerung. Ich sehe auch nicht, wieso eine 22kW-Box mit 11kW betrieben "länger halten" sollte. Alles was durch 22kW stärker belastet würde, wäre der Schaltschütz und die Dinger lächeln über 16 oder 32A nur.

Hallo @meierchen006 , ich habe nichts in Frage gestellt, ich wollte nur meine Meinung zum Ausdruck bringen, und die ist nun mal so, das ich auf diese - zugegebenermaßen - doch etwas exotische Möglichkeit in einer Wallbox verzichten kann. Klar das Ding hat einen Rechner aber wo fängst du an und wo hörst du auf? Ich bin mir halt auch sicher das die Leute bei Tinkerforge bestimmt eine ganze Menge in der Pipeline haben, und nicht jedem Wunsch gleich hinterher rennen können. Ich finde die machen einen guten Job und reagieren echt fix auf Fragen der User. Vielleicht gibt es ja später - wenn die Batteriespeicher-Steuerung einmal fix und fertig bei den meisten Usern sauber läuft - auf diese Wünsche einzugehen. Letztendlich geht es ja in diesem Thread um das Testen dieser Steuerung (die prinzipielle Funktion mit verschiedenen Setups), der Rest kommt (vielleicht) später. Gruß Steffen

Nachdem ich diesem Thread nun schon eine Weile folge, wollte ich auch meine Meinung dazu geben... Auch ich habe bei mir einen BYD-Speicher, der am Fronius Symo Gen24 hängt im Keller stehen. Ist das Balancing / BMS von BYD schlecht - keine Ahnung, da bin ich nicht wirklich im Thema. Ja, bei hoher Ladeleistung rennt die eine oder andere Zelle nach oben hin weg. Und ja ich kenne den Ellenlangen Thread im PV-Forum über das Laden der BYD-Akkus auch. Deshalb habe ich auch die Ladeleistung bei höherem SOC begrenzt - ob das wirklich zielführend ist sei mal dahingestellt. Das mache ich aber per Script im ioBroker, weil der eh im Keller vor sich hin werkelt. Ich finde aber, dass das (variable) Begrenzen der (Heimspeicher)-Ladeleistung (wie oben im Thread angesprochen) in einer Wallbox nichts zu suchen hat. Klar ein Entladen den Heimspeichers soll (sofern vom Nutzer gewünscht) verhindert werden. Die Wallbox soll schlicht und ergreifend das tun für was sie konzipiert ist, ein E-Auto Laden und das wenn möglich mit PV-Überschuss (sofern vorhanden) oder bei günstigem Strompreis - alles was darüber hinaus geht, gehört meiner Meinung nach in ein (übergeordnetes) System - ioB, HA, etc. Gruß Steffen

Glaubst du wirklich, dass a) das Balancing des BMS von BYD so grottich ist und b) eine Steuerung über eine Wallbox(!) der richtige Ansatz ist, dies in den Griff zu bekommen? Ich würde hier eher als Spielerei über z.B. Home Assistant Automationen ansetzen, wenn ich meinen würde, hier einen brauchbaren Hebel in der Hand zu haben.

Falls du es überlesen hast: Das ist die aktuell bereits mögliche Lösung für Bastler. Das ist nicht unsere geplante Dauerlösung. Wenn du nicht die nötigen Voraussetzungen mitbringst, kannst du diese Möglichkeit halt nicht nutzen und musst warten, bis es eine anwenderfreundliche Lösung gibt.

Ja, das wäre die einfachste Lösung: Download von dynamischen Preisen gegen eigene Datei tauschen. Da könnte man auch die dynamische Netzentgelte bis aufweiteres mitaufnehmen.

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

Das Feature wurde hier im Forum schon gewünscht und wir überlegen, das einzubauen. Ob und wann das kommt, kann ich aber noch nicht sagen.

Ignorier den KI-Schwachsinn. Die hatte offensichtlich keine Ahnung und hat nur deine Frage umformuliert wiederholt. Immer dran denken: Die aktuell aggressiv den Nutzern aufgedrängten KI-„Assistenten“ neigen eigentlich alle dazu, im Zweifelsfall dem Nutzer einfach zuzustimmen und seine initialen Annahmen zu bestätigen. KI-freier Fakt: Kein von uns getestetes Fahrzeugmodell hat jemals von sich aus einphasig angefangen zu laden und dann von sich aus auf dreiphasig hochgeschaltet. Nach unseren Erfahrungen ist es also eine glatte Lüge, ein derartiges Startverhalten als „normal“ zu bezeichnen. Was du beschrieben hast, ist ein bekanntes Problem von alten Firmware-Versionen der WARP3 und sollte in der aktuellen Firmware behoben sein. Mach einfach ein Update.

Wow. Mega. Gleich installiert. Vielen herzlichen Dank. Ihr seid die Referenz, kenne keine Firma mit so einem Support und solchen Reaktionszeiten. Respekt

Im zweiten Screenshot kann man sehen, dass eindeutig dreiphasig geladen wurde. Bis 13:20 wurde die Ladeleistung an die PV-Leistung von knapp 6 kW angepasst. Bis 13:26 fiel die Ladeleistung immer wieder auf 4,1 kW ab. Wahrscheinlich war es da wolkig und evcc hat die Ladeleistung auf das dreiphasige Minimum reduziert, was bei 4,1 kW liegt. Nach 13:26 sieht man die typische abfallende Ladekurve eines fast vollen Elektroautos. Je voller die Batterie ist, um so langsamer wird geladen. Die minimale dreiphasige Leistung, die eine Wallbox freigeben kann, liegt bei 4,1 kW, aber es steht dem Fahrzeug jederzeit frei, weniger Leistung zu nutzen, und genau das sieht man hier. Vermutlich hat das Fahrzeug auch nicht allzu lange nach dem Screenshot die Ladung von sich aus beendet, da die Batterie voll war.

Wir haben PV-Magazine angeschrieben. Dies wird korrigiert.

Ich habe die WARP auch noch recht neu. Bisher habe ich ein Widget in HA um ein paar grundlegende Infos zu sehen, den Lademodus zu wechseln oder den NFC Tag zu setzen. Die beiden letzten Punkte sind Custom Entitäten die ich per Node-Red erstellt habe. Node Red holt sich alle Infos aus der WARP config um es möglichst dynamisch zu halten. (Nutzer und zugehörige NFC Tags) Ich baue mir fürs Energiedashboard auch noch Entitäten die die geladene Energie pro Nutzer tracken. Die WARP gibt grundsätzlich ja die Energiemengen der Ladevorgänge aus inkl. user_id. Immer wenn sich der Wert erhöht addiere das der entsprechenden Entität hinzu. So habe ich quasi Stromzähler pro Nutzer. Ist für uns ganz interessant, da mein Auto ein Dienstwagen ist und der von der Frau privat.

Firmware: WARP1 2.8.9, WARP2 2.8.9, WARP3 2.8.9, WARP Energy Manager 2.4.9, WARP Energy Manager 2.0 1.3.9 Hinzugefügt, dass Teile einer API mit einem URL- oder Topic-Suffix gelesen (nur über HTTP) und geschrieben (HTTP und MQTT) werden können Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: VARTA Element/Flex Batteriespeicher, Chisage ESS Hybrid-Wechselrichter SunSpec: Falsche Phase-zu-Phase-Spannungswerte für WattNode-Stromzähler erneut korrigiert Fortschrittsanzeige des Firmware-Updates verbessert Behoben, dass lastgemanagte Wallboxen nach 49 Tagen fälschlicherweise als "gestört" angezeigt wurden (Nur WARP1, WARP2, WARP3) Behoben, dass Fronttaster-LED-Steuerung per API nicht immer akzeptiert wurde, wenn der letzte Steuerbefehl auch über die API erhalten wurde (Nur WARP2, WARP3) Behoben, dass eine CP-Trennung manchmal dazu führte, dass das Fahrzeug als getrennt betrachtet wurde (durch Update auf Ladecontroller-Firmware 2.2.15) (Nur WARP2, WARP3) Unnötig lange Wartezeit nach Ende der CP-Trennung behoben (durch Update auf Ladecontroller-Firmware 2.2.15) (Nur WARP2, WARP3) Unterstützung für Eltako DSZ16DZE hinzugefügt Download: WARP1 2.8.9 bzw. WARP2 2.8.9 bzw. WARP3 2.8.9 bzw. WARP Energy Manager 2.4.9 bzw. WARP Energy Manager 2.0 1.3.9

Das ist ein bekanntes Problem, für das wir im Moment leider keine Lösung haben: https://github.com/Tinkerforge/esp32-firmware/issues/342 Irgendwie implementiert Safari auf iOS die Digest Authentication nicht richtig. (das betrifft dann auch alle anderen Browser weil Apple der Meinung ist, keine anderen Browser-Engines zuzulassen) Langfristig wollen wir auf eine andere Variante des Logins umsteigen, aber es ist noch niemand dazu gekommen, das zu implementieren.

Moin, als kurze Rückmeldung: klappt hervorragend. Start durch NFC lokal oder via OCPP. Letztlich hab ist 3 Dinge für mich angepasst. Das NFC Modul gibt Ocpp nicht mehr Bescheid das ein Tag gefunden wurde Nur nach OCPP Freigabe kann OCPP den Slot wieder sperren Bei jeder Freigabe durch User oder OCPP werden immer beide Slots freigegeben Vielen Dank das ihr mit eurem Open source Ansatz Nutzern wie mir Freiräume wie diese ermöglicht. Auch wenn die Box damals teuerer war als alternative Charger war die Option der Nachrüstung und Code Anpassung für mich damals absolut kaufentscheidend und dies ist das 2. Mal das ich mich darüber sehr freuen. Dank, Gruß jkw

Als einfache kurzfristige Lösung kann ich das aktuelle .apk hier im Forum hochladen, siehe Anhang. warp.apk

Auf unserer Todo-Liste steht, dass das Lastmanagement gesprächiger werden soll. Aus der Anzeige soll dann klar werden, dass die Wallbox wegen nicht angeschlossenem Fahrzeug blockiert ist.

Ich hole mal den alten Thread hoch. Ich habe gerade meine frisch installierte WARP3 Wallbox für PV-Überschussladen konfiguriert und besitze noch kein Fahrzeug. Kommt demnächst. Dadurch suchte ich länger Zeit wieso das Lastmanagement blockiert. Ich ging von einem Konfigurationsfehler aus. Erst als ich diesen Thread gefunden habe war mir das Verhalten klar! Aus User-Sicht wäre es echt gut, wenn das Lastmanagement nur eine Wallbox kontrolliert, dass dann diese auch ohne Fahrzeug freigegeben wird. Oder wenn das nicht machbar ist, ein Hinweis in den Tutorials: https://docs.warp-charger.com/docs/tutorials/pv_excess_charging https://docs.warp-charger.com/docs/tutorials/chargemanagement

Da können wir leider nichts machen. Die Wallbox macht das, was das Fahrzeug verlangt. Wenn es nur darum geht, wann du deinen WR abregelst und wann nicht, musst du wohl diese kurzen angeblichen Ladephasen rausfiltern und erst ab einer Ladedauer über einer Minute von einem tatsächlichen Ladevorgang ausgehen. Wie eine konkrete Implementierung zum Abfragen des Fahrzugzustands aussehen würde, kann ich noch nicht sagen, aber spontan fallen mir dazu zwei Zustände ein: Das Fahrzeug wird angeschlossen und einmal abgefragt. Lädt es dann nicht, wird sich der SOC nicht relevant von alleine ändern und es brauch nicht permanent abgefragt zu werden. Dementsprechend wird die Ladeelektronik nicht immer wieder aufgeweckt. Das Fahrzeug lädt und wird regelmäßig abgefragt. In diesem Fall ist die Ladeelektronik sowieso aktiv. Wir haben schon Gerüchte gehört von Fahrzeugen, die sich an einer einfachen AC-Wallbox leerstehen, weil die 12 V-Boardbatterie permanent durch die ineffiziente Ladeelektronik geleert wird, selbst wenn der Ladevorgang beendet wurde, weil die Traktionsbatterie voll ist. In dem Fall war das Fahrzeug Schuld und nicht die Wallbox, aber sowas wollen wir unseren Kunden definitiv nicht verursacht durch unsere Wallboxen zumuten.

Eine Wallbox mit Typ 2-Stecker begrenzt nicht den maximalen Stromfluss. Stattdessen signalisiert sie dem Fahrzeug, mit welchem Strom es maximal laden darf, und das Fahrzeug hat sich daran zu halten. Zwingen kann die Wallbox das Fahrzeug dazu nicht. Dementsprechend muss eine Wallbox auch nicht wissen, wie viel Strom das Fahrzeug gerade zieht. Somit ist ein Stromzähler nur für die Abrechnung nötig und verbessert nebenbei noch das Lastmanagement. Korrekt. Da die Wallbox, wie oben erwähnt, nur den maximal freigegebenen Strom meldet, steht des dem Fahrzeug frei, langsamer zu laden. Für die Abrechnung ist der Wert also nicht zu gebrauchen. An dieser Stelle sei dazu erwähnt, dass der andere User es sich unnötig schwer gemacht hat, und die gesamte Wallbox auseinandergenommen hat. Die neuen Kabel hinter die Hunschiene zu fummeln ist im eingebauten Zustand zwar etwas lästiger, aber prinzipiell muss man nur den Klemmenblock nach links verschieben und den Zähler dazwischen platzieren. Wenn du unbedingt eine Wallbox mit Zähler brauchst und den Umbau nicht selber machen möchtest, frag mal bei unserem Vertrieb (per Telefon oder Mail an sales@…) nach einem Angebot für eine Umrüstung von Smart auf Pro, für die du deine Smart allerdings einschicken müsstest.

Firmware: WARP1 2.8.0, WARP2 2.8.0, WARP3 2.8.0, WARP Energy Manager 2.4.0, WARP Energy Manager 2.0 1.3.0 Instabile Firmware-Aktualisierungen werden automatisch erkannt und auf die vorherige Firmware zurück gewechselt (Nur WARP2) Verbessertes PV-Überschussladen und dynamisches Lastmanagement für einphasig ladende Fahrzeuge auch ohne Energy Manager zur Phasenumschaltung (durch Update auf Ladecontroller-Firmware 2.2.11) (Nur WARP3) OCPP: Messwerte werden auch während eines Ladevorgangs gemeldet Modbus TCP: Unterstützung für SAX Power Home hinzugefügt Modbus TCP: Unterstützung für E3/DC Hauskraftwerk hinzugefügt Modbus TCP: Unterstützung für Huawei SUN2000 hinzugefügt Modbus TCP: Unterstützung für zweiten GoodWe-Batteriespeicher hinzugefügt Modbus TCP: GoodWe-Batterie-Leistung > 32kW repariert (Nur Energy Manager 2.0) Heizung: Knöpfe zur manuellen Kontrolle der SG-Ready-Ausgänge hinzugefügt (Nur Energy Manager 2.0) Heizung: Knopf zu Status-Seite hinzugefügt, um den blockierenden SG-Ready-Ausgang für eine bestimmte Zeit zu deaktivieren SunSpec: Bei Fehlern während der Gerätesuche wird eine Warnung im Webinterface angezeigt SunSpec: Unterstützung für Geräte mit Basisadresse 50000 und 0 repariert PV-Ertragsprognose: Sommer-/Winterzeit-Behandlung repariert Ein NFC-Tag kann nicht mehreren Benutzern zugeordnet werden (Nur WARP Energy Manager 2.0) Display: Anzeige des Bewölkt-Icons repariert Dynamisches Lastmanagement: Untergrenze für maximalen Strom am Netz­an­schluss von 25A auf 20A reduziert Fernzugriffs-Abschnitt zur Statusseite hinzugefügt Mehr Hilfetexte dem Webinterface hinzugefügt Aktualisierung der Haupt-Software-Bibliotheken (ESP-IDF 5.4 und arduino-esp32 3.2) Download: WARP1 2.8.0 bzw. WARP2 2.8.0 bzw. WARP3 2.8.0 bzw. WARP Energy Manager 2.4.0 bzw. WARP Energy Manager 2.0 1.3.0

Wenn es bei den Automatisierungen nun noch eine 2. Bedingung gäbe, wäre die WARP fast perfekt. Wenn der Front­taster gedrückt wird UND der Lademodus "AUS" ist, wechsle Lademodus auf PV. Wenn der Front­taster gedrückt wird UND der Lademodus "PV" ist, wechsle Lademodus auf Min + PV. Usw. Dann könnte man wenigstens alle Lade-Modis über den Taster steuern, was ich von einer Wallbox mit Taster eigentlich erwarte. Das wäre für mich als Kunde, der nicht den ganzen Tag das Smartphone in der Hand hat, die wichtigste Funktion für den Taster. Dazu noch die passende LED Farbe (z.b. PV=Grün / Min+PV= Grün-Gelb / Schnell=Blau) und die Sache wäre rund ;)

Hallo Sebastian, die Kombination von SolarEdge mit der Warp kann ich uneingeschränkt empfehlen. Ich bin sehr zufrieden mit dem Team von Tinkerforge. Anfragen aus der Community werden schnell beantwortet und bei Problemen wird konsequent an einer Lösung gearbeitet - es kommt vor, dass sogar an einem Sonntag die Entwickler eine Firmware speziell für einen User veröffentlichen! Die Anleitung zur WallBox ist sehr ausführlich gestaltet. Sowohl die Montage als auch die eigentliche Installation der WallBox ist kinderleicht. Bei Fragen wird einem hier im Forum gerne geholfen. Die eigentliche Benutzeroberfläche für die Einstellungen ist sehr intuitiv gestaltet und man merkt das hier einiges an Gedankten gefloßen ist, um dieses zu erreichen. Jetzt zu Deinen Fragen: Das Zusammenspiel zwischen dem SolarEdge Wechselrichter und der Warp3 ist - im positiven Sinne - sehr unauffällig: es läuft einfach! Ich bin sehr zufrieden mit der Kombination. Wenn Du MQTT in der Box aktivierst findet HomeAssistant die Box selbstständig als Gerät mit diversen Entities. (Siehe Screenshot) Ich habe mir im Vorfeld einige Wallboxen angeschaut und würde die Warp, mit meinen jetzigen Erfahrungen, jederzeit wieder kaufen. Schönes Wochenende und viele Grüße Stefan

Jetzt sieht es wieder gut aus, die Wallbox zieht zum Teil aus dem Netz, zum Teil aus dem Speicher. Von der Größenornung stimmt das mit den Daten aus HA überein. Offenbar war es wirklich eine Fehlkonfiguration der Energy Meter auf meiner Seite: Hier die Daten, nachdem der Akku leer ist - sieht gut aus.

Die Batteriesteuerung ist im heutigen Firmware-Release nicht enthalten. Es wird voraussichtlich bald eine neue Firmware mit Batteriesteuerung geben.

Hallo @Steff49 ich kann jetzt wiederum nicht verstehen das man in Frage stellt, dass die Wallbox dies nicht machen sollte. Ist ein "Rechner" der 24/7 läuft und dies auch kann, sonst hätten die Hersteller es nicht eingebaut/programmiert. Nur weil ein User schreibt das man es besser machen könnte, sollte/muss man nicht das ganze Verwerfen. Gruß meierchen006

Ich möchte Daten von meinem PC in einen MZ-80K Baujahr 1980 übertragen. Dafür habe ich mir eine Schnittstelle gelötet, die ich über ein IO16-v2 Bricklet ansteuere. Unter Visual Basic funktioniert das schon sehr gut, ich kann die Daten aus einer Datei in den MZ-80K übertragen. Diese Daten stammen aber eigentlich aus einer Excel-Tabelle. Anstatt diese Daten erst mal in eine Datei zu exportieren und diese dann mit Hilfe meines Übertragungsprogramms zu verarbeiten, müsste es doch eigentlich möglich sein, die Daten direkt mit Hilfe eines VBA-Makros zu übertragen. Das ist prinzipiell nichts neues für mich, ich habe bereits System-DLLs in VBA-Makros eingebunden und genutzt. Aber bei Tinkerforge kommen noch die Deklarationen hinzu, und da fehlen mir die Kenntnisse. Was mache ich mit folgenden Zeilen in Excel VBA? Imports Tinkerforge Public ipcon As New IPConnection Public io As New BrickletIO16V2()

Den Boost-Modus kannst du gefahrlos nutzen. Wie du der Beschreibung im Webinterface der Wallbox entnehmen kannst, werden einfach 0,24 A mehr freigegeben. Du solltest das eigentlich nur benutzen, wenn dein Fahrzeug mehr als 0,24 A unter der Freigabe bleibt. Auf L3 zieht dein Enyaq 15,9 A, was dann 16,14 A ergeben würde. Die Überschreitung ist aber minimal und noch weit weg von allem, was die Sicherung auslösen würde. Wenn bei dir eine B16 oder C16-Sicherung verbaut ist, würde die frühestens bei 18 A rausfliegen.

Ein SSR trennt nicht komplett sondern hat im nicht durchgeschalteten Zustand einen sehr hohen Widerstand. Hoch, aber nicht unendlich. Wenn du ein Kabel am Ausgang angeschlossen hast, an dem kein Verbraucher hängt, bilden Kabel und Erdpotenzial einen Kondensator mit geringer Kapazität. Der Widerstand des SSR und der Blindwiderstand des „Kondensators“ bilden einen Spannungsteiler, weshalb du am SSR-Ausgang eine Spannung messen kannst. Sobald du einen Verbraucher anschließt, bricht die Spannung am Ausgang zusammen. Bei bestimmten Verbrauchern kann es passieren, dass über den hohen Widerstand des nicht durchgeschalteten SSR gerade noch genug Strom fließt, um beim Verbraucher eine Reaktion zu verursachen. Ein typisches Problem ist beispielsweise, dass LED- oder Energiespar-Leuchtmittel hinter einem SSR regelmäßig aufblitzen können, wenn der durchgelassene Strom nach einigen Sekunden die Spannung im Schaltnetzteil des Verbrauchers soweit angehoben hat, dass es einschaltet. Zum dauerhaft Leuchten reicht der Strom dann aber nicht, weshalb die Lampe immer nur kurz aufblitzt. In so einem Fall hilft nur ein mechanisches Relais, das die Leitung komplett trennt (z B. das Industrial Dual Relay Bricklet ohne „AC“ im Namen).

Die Ladevorgänge werden von der Wallbox selbst festgelegt. Da EVCC die Wallbox üblicherweise nur alle 30 Sekunden abfragt, kann man es hinbekommen, dass zwei Ladevorgänge mit zwei unterschiedlichen Fahrzeugen, die von der Wallbox korrekt als zwei Ladevorgänge protokolliert werden, von EVCC für einen Ladevorgang gehalten werden. Die vielen 0-kWh-Eintrage entstehen bei der offiziellen 2.8.8er Version durch ein Problem bei der Phasenumschaltung, wodurch unter bestimmten Umständen die Phasenumschaltung als Ladeende und Beginn eines neuen Ladevorganges interpretiert wird. Bei der von mir verlinkten Beta-Firmware ist dieses Problem behoben und eine Phasenumschaltung unterbricht den Ladevorgang nicht mehr. Nur Beta-Firmwares haben einen langen Hash im Dateinamen. Die Hexadezimalzahl hinter der Versionsnummer, die in Beta-Firmwares und offiziellen Releases enthalten ist, enthält den Zeitpunkt, wann die Firmware gebaut wurde. Eine größere Hexadezimalzahl bedeutet also, dass die Firmware neuer ist. Wenn du neugierig bist, kannst du die Zahl von hexa in dezimal umrechnen und dann als Unix Timestamp interpretieren lassen.

ist dieser Thread bereits bekannt? Ladelog enthällt nicht die geladenen kWh Hier wird beschrieben wie ein alternativer Zähler einzurichten ist

Hallo, ich habe seit geraumer Zeit häufig (aber nicht immer) das Problem, dass ich mich 2x direkt hintereinander an der UI authentifizieren muss, wenn ich über ein Handy (iPhone) darauf im lokalen Netz zugreife. Das ist unabhängig von der iOS Version und dem Browser (Safari oder Firefox getestet). Vom PC passiert das nicht. Kennt ihr das Problem und lässt es sich lösen/umgehen? Danke!

Der pendelnde Ladestrom ist ein typisches Symptom bei Fahrzeugen, die ihre Ladeleistung nur stufenweise einstellen können. Ob es Stufen gibt, wo sie liegen und ob sie über den gesamten möglichen Bereich der Ladeleistung verteilt sind, ist von Fahrzeug zu Fahrzeug unterschiedlich. Dein BYD hat offensichtlich eine Stufe bei ca. 1300 W und eine bei 1700 W. Dazwischen kann das Fahrzeug keine andere Ladeleistung einstellen. Somit ist das eine Einschränkung des Fahrzeugs, nicht der Wallbox. Die Wallbox versucht immer, die Abweichung auszugleichen. Wenn sich die Leistungsregelung der Null-Linie nähert, macht das Fahrzeug dann plötzlich einen großen Sprung bei der Ladeleistung und die Wallbox versucht dann von der anderen Seite wieder an die Null-Linie zu kommen. Dadurch entsteht dieses Rechteck-Muster. Dass das Pendeln bei mehr PV-Leistung aufhört, scheint daran zu liegen, dass die Zuleitung der Wallbox auf 13 A begrenzt ist. Die meisten Fahrzeuge lassen einen gewissen „Angstabstand“ zum erlaubten Ladestrom. Wenn die Wallbox 13 A erlaubt, zieht der BYD anscheinend nur 12 A. Mit etwas Spannungsabfall auf der Leitung bist du bei 225 V. 225 W * 12 A = 2700 W. Darüber kann die Wallbox nichts freigeben und somit hört auch das Pendeln auf. Wenn du nur diesen BYD an der Wallbox lädst, kannst du im Webinterface unter Wallbox → Einstellungen den Boost-Modus aktivieren. Dann werden 0,25 A zusätzlich freigegeben.

Es gibt (gab) ein bekanntes Problem mit den Tagessummen, was üblicherweise zu unsinnigen, negativen Werten geführt hat. Auch wenn du jetzt an einer Stelle einen unsinnigen Positiven Wert hast, habe ich die Hoffnung, dass das das selbe Problem ist. Das Problem sollte mit der nächsten Firmware behoben sein, die hoffentlich zeitnah veröffentlicht wird.

Im Modus „Schnell“ wird auch an PV-Leistung genutzt, was da ist. Wenn du eine 11 kW-Wallbox hast, werden im Modus „Schnell“ diese 11 kW für das Auto freigegeben. Hast du aktuell 7 kW PV-Produktion und dein Auto kann mit 11 kW laden, heißt das, dass von diesen 11 kW 7 kW von deiner PV-Anlage kommen und zusätzlich 4 kW aus dem Netz zugekauft werden. Hast du mehr als 11 kW von deiner PV-Anlage, wird der Rest eingespeist. Im Modus „Min+PV“ wird der gesamte PV-Überschuss dem Auto zur Verfügung gestellt (bis zum Limit der Wallbox). Hast du 6 kW Überschuss, darf das Auto mit 6 kW laden. Hast du in der Nacht keinen Überschuss, darf nur mit dem eingestellten Minimum geladen werden. Unterbrechungsfreies Laden ist der typische Anwendungsfall für den Modus „Min+PV“. Die Mindestleistung stellst du auf 5,5 kW und dein Auto darf auch bei Bewölkung so schnell laden. Hast du aber 6 kW PV-Überschuss, darf das Auto auch mit 6 kW laden. Hättest du im Modus „Schnell“ den konfigurierten Ladestrom auf 8 A gestellt, dürfte das Auto immer mit exakt 5,5 kW laden. Bei 6 kW PV-Überschuss würde mit 5,5 kW aus der PV-Anlage geladen und die restlichen 0,5 kW würden ins Netz eingespeist.