MatzeTF

Wir sind hier alle Hacker (im traditionellen Sinne) und unsere Produkte richten sich überwiegend an Bastler. „Auseinandernehmen“ ist bei uns definitiv positiv besetzt. 😉 Der Regler weiß, wie viel Leistung er der Wallbox zugeteilt hat, und berücksichtigt das bei der Berechnung der verfügbaren Leistung. Andernfalls würde die verfügbare Leistung nach Ladebeginn sofort bei Null liegen und das Laden wieder beendet. Der negative Sprung kommt daher, dass die zugeteilte Leistung wegfällt.

Der Verdrahtungsplan ist leider irgendwie unter den Tisch gefallen und es hatte noch niemand die Gelegenheit, die Anleitung zu überarbeiten. 🙁 Das, was du gezeichnet hast, ist genau richtig.

Danke für die detaillierte Analyse. Ich finde es interessant, wie du unsere Debug-Informationen auseinandernimmst. 😀 Leider weiß ich noch nicht, wann ich dazu komme, mir das genauer anzusehen. Ich habe schon einen Tab mit diesem Thread auf, sodass er mich jeden Tag anstarrt. Edit: Wenn ich so drüber nachdenke, ist wahrscheinlich das Problem, dass durch die 5 Minuten Wartezeit im dreiphasigen Modus vor der Umschaltung so viel Energie aus dem Netz bezogen wird, dass power_available_filtered_w weit nach unten gedrückt wird. Wenn dann auf einphasig umgeschaltet wird und der Bezug plötzlich weg ist, erholt sich der Wert nicht schnell genug und ist eine Zeit lang negativ. In der Grafik zum zeitlichen Verlauf sieht man auch am Anfang, dass power_available_w kontinuierlich sinkt.

Wenn OCPP aktiviert ist, muss ein Ladevorgang auch unbedingt per OCPP freigegeben werden. Das lässt sich nicht per MQTT oder Start-Button überschreiben. Welchem Mitarbeiter sollte der Ladevorgang dann auch zugeordnet werden? Was genau stellst du dir darunter vor, wenn du per MQTT irgendwas starten willst?

Ja, das ist maximal ineffizient. Allerdings sind die Verluste in Summe exakt die gleichen, wenn du dein Auto aus dem Netz lädst (AC→DC) und dein Haus mit Batteriestrom betreibst (DC→AC), oder alternativ das Auto mit Batteriestrom lädst (DC→AC→DC). Die Verluste treten nur zu einer anderen Tageszeit auf. Von daher bin ich der Meinung, dass das nur bei dynamischen Strompreisen relevant ist. Ich könnte mir gut vorstellen, dass es bei EVCC die Option gibt, weil die Nutzer danach gefragt haben, und nicht unbedingt, weil es sinnvoll ist. 😉

Den Parameter gibt es auch für den WEM, allerdings undokumentiert und versteckt. Unter http://wem-ABC/charge_manager/config kannst du dir die aktuelle Konfiguration des Lastmanagers anzeigen lassen. Gegebenenfalls musst du bei deinem Browser noch auf die Rohansicht wechseln. Dort gibt es requested_current_margin, was 6000 sein sollte. Das kannst du einfach mal auf 5000 reduzieren oder auch irgendwas anderes ausprobieren. Unter 2000 wird der Regler nicht mehr sinnvoll arbeiten können. Möglicherweise kannst du 3000 nicht einstellen, weil das durch 6000 ersetzt wird. Nimm dann einfach 3001. Um die geänderte Konfiguration zu speichern, musst du auf http://wem-ABC/recovery gehen und dort das obere API-Fenster so befüllen: {"method":"PUT", "url":"/charge_manager/config_update", "payload":PAYLOAD} Statt PAYLOAD musst du die gerade geänderte Konfiguration einsetzen. Sieht dann z. B. so aus (das Beispiel hat keine Wallbox eingetragen): {"method":"PUT", "url":"/charge_manager/config_update", "payload":{"enable_charge_manager":true,"enable_watchdog":false,"default_available_current":0,"maximum_available_current":0,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":false,"requested_current_threshold":60,"requested_current_margin":5000,"chargers":[]}} Dann auf „Call API“ klicken und unten sollte 200 erscheinen. Viel Spaß beim Basteln. 😀

Genau so ist es. Da sich das Ganze relativ schnell einschwingt, halte ich das nicht für ein Problem. Natürlich wäre das ohne Überschwingen besser, aber der Regler ist wegen verschiedenster Sonderfälle schon komplexer, als mir das lieb ist. Auf unserer Todo-Liste steht die Überarbeitung des Lastmanagements, das vom Überschuss-Regler mit benutzt wird. Wir haben die Hoffnung, dass dadurch automatisch derartiges Überschwingen begrenzt wird. Wenn du experimentierfreudig bist, kannst du mal mit dem Spielraum des Phasenstroms rumspielen. Du findest die Einstellung bei den Experteneinstellungen vom Lastmanagement. Ein kleinerer Wert verringert das Überschwingen, führt aber auch dazu, dass bei plötzlich mehr Sonne der Regler langsamer hinterher kommt. Die Standardeinstellung passt für die meisten Fahrzeuge. Vielleicht findest du einen Wert, der für dein Fahrzeug besser passt.

Das solltest du damit machen können. Ich sehe keinen Grund, warum du es nicht permanent verbunden lassen können solltest. Stromfluss ist egal, Laden und Entladen kannst du beides messen. Und bei der Polung musst du halt aufpassen, dass du nicht Plus und Minus vertauscht. Das ist alles. Was für Stromspitzen erwartest du? Prinzipiell sollte das kein Problem sein, da das Bricklet einen Tiefpass am Messeingang hat, der alle problematischen Spitzen wegbügeln sollte. Spannungsspitzen könnten theoretisch ein Problem sein, wenn du damit über 36 V kommst, aber ich glaube nicht, dass du das bei einem 12 V-Akku hinbekommst.

Falls dein Router eine FritzBox ist, versuch mal 192.168.0.1

Kannst du mal 192.53.103.108 als ersten NTP-Server ausprobieren? Falls das auch nicht hilft, teste mal 162.159.200.1.

Die neue Grafik schaue ich mir morgen an. Kurz zum Lademodus: Den WEM stört es nicht, aber es macht das Log nutzlos und das Debuggen schwerer weil alle interessanten Nachrichten durch den Spam aus dem Log geschoben werden.

Das ist eine sehr schöne Grafik, die mir auch sehr weiterhelfen würde, wenn das Protokoll dazu passen würde. Das Protokoll reicht von 8:40:40 bis 8:40:45 und die Grafik reicht von 11:20 bis 11:40. Der Zeitraum der Grafik ist somit nicht im Protokoll enthalten. Ein Debug-Report + Ereignis-Log, was du unter System → Ereignis-Log findest, von 11:40 hätte mir da mehr geholfen, da ich die Meldungen aus dem Log für den Zeitraum der Grafik brauche. Ich bin allerdings verwirrt, warum in deinem Log permanent der Modus von 2 zu 2 geändert wird. Da du wahrscheinlich nicht von 8:28 bis 9:40 zwei Mal pro Minute auf den PV-Button geklickt hast, hast du irgendein Programm/Script am Laufen, das durchdreht? Ich habe auch gesehen, dass du MQTT aktiviert hast. Benutzt du zufällig ioBroker?

Da du das jetzt schon zum zweiten Mal erwähnt hast: Lass dir nicht einreden (auch nicht von dir selbst), dass du dafür zu alt bist. Auch wenn die Phrase ein bisschen abgedroschen ist, ist man nie zu alt, um etwas Neues auszuprobieren. Mit dem passenden Interesse und Motivation kann man viel erreichen und so ein privates Bastelprojekt, mit dem man ganz ungezwungen herumspielen kann, ist genau das Richtige dafür. 👍

Irgendwie hatte ich das mit EVCC gedanklich ausgeblendet. Wenn das PV-Überschussladen darüber läuft, braucht man die SHM-Integration in die WARP-Firmware in der Tat nicht. Laut Datenblatt ist der STP 15000 SunSpec-kompatibel. Da hing ich auch noch auf dem Stand fest, dass wenn der SHM im Spiel ist, wohl keines der Geräte SunSpec spricht. Die Integration von Batteriespeichern ist ansonsten leider nicht ganz so trivial, da sowohl das PV-Überschussladen, als auch der Batteriespeicher versuchen, den Netzbezug auf 0 zu regeln. Somit arbeiten beide gegeneinander. Ich weiß nicht, wie EVCC das macht, aber in unserem Energy Manager kann man dafür das Regelverhalten explizit einstellen, damit der EM entweder etwas Energie überlässt, damit der Batteriespeicher bevorzugt geladen wird und nur alles darüber hinausgehende ins Auto kommt, oder sich der EM alternativ vordrängelt und die Energie zuerst ins Auto kommt, potentiell auch aus dem Batteriespeicher. Richtig gut funktioniert das nur, wenn der EM weiß, was der Batteriespeicher macht, zusätzlich zu der Information, was gerade über den Hausanschluss fließt. Für das Batteriesystem von Sonnen habe ich das testweise mit deren proprietärer API implementiert, aber ich weiß noch nicht, wie man das gut abstrahieren kann, weil wir nicht für jeden Batteriespeicher eine gesonderte Implementierung machen können.

Eigentlich sollte das nicht passieren. Wenn das das nächste mal passiert, lade bitte ein Debug-Log runter und hänge es hier an.

Hätte ich einen besseren Vorschlag gehabt, hätte ich den schon in den Ring geworfen. 😉 Ich habe mir die Doku vom SAX schon gestern angesehen und er spricht leider kein SunSpec es gibt anscheinend auch sonst keine Möglichkeit, darüber an die Zählerwerte zu kommen. Die „beste“ Lösung wäre sicherlich, wenn du dir die Sunny Home Manager-Anbindung aus dem Fork in einen eigenen Fork für die Warp2 integrierst. Das ist allerdings etwas für Bastler und Programmierer, und da du dich selbst als Laien bezeichnet hast, ist das wahrscheinlich keine Option.

Um einmal kurz Spielverderber zu sein: Der besagte Fork ist meines Wissens für Warp1-Ladecontroller und funktioniert nicht mit einer Warp2.

In dem Fall hättest du auch einen USB WLAN Stick mit abnehmbarer Antenne plus eine einfache Außenantenne oder eine einfache Richtantenne nehmen können. Ich hatte eine Zeit lang einen TP-Link TL-WN722N mit dieser Richtantenne im Einsatz. Das Ganze stand wettergeschützt drinnen und hat durch die Wand gefunkt.

Der WLAN-Empfang wird auf jeden Fall schlechter, da die Antenne im PCB des Pi integriert ist und der HAT blockiert auf einer Seite die Abstrahlung bzw. verursacht Reflexionen. Da sich die Antenne in der Mitte des Pi befindet, kann es helfen, wenn du bei ein oder zwei angeschlossenen Bricklets nur die Ports A und D verwendest, da die Kabel an Port B und C im Weg sein könnten. Beim Pi Zero ist es für den WLAN-Empfang allerdings am wichtigsten, wie er ausgerichtet ist. Schau dir mal die Abstrahl-Charakteristiken im Datenblatt zur Antenne (Seite 4) an. Die Antenne ist stark horizontal polarisiert (bei liegendem Pi) und strahlt sehr schlecht in Richtung der kurzen PCB-Seiten. (Ich habe bei dem Datenblatt allerdings die Vermutung, dass die Farben für horizontal und vertikal in der V90-Ebene vertauscht sind.) Du solltest daher versuchen, die Antenne in Richtung deines Access Points zeigen zu lassen und das PCB sollte parallel zur AP-Antenne sein. Hat dein AP eine vertikale Antenne, sollte der Pi vertikal sein. Hat dein AP eine horizontale Antenne, dessen lange Seite in Richtung Gartenhaus zeigt, sollte der Pi horizontal sein. Hat dein AP eine horizontale Antenne, dessen Spitze auf das Gartenhaus zeigt, hast du damit keinen Empfang. 😉 Heutzutage haben alle APs mehrere Antennen, die orthogonal zueinander ausgerichtet sein sollten, und es reicht, wenn der Pi zu einer davon guten Empfang hat. Hat dein AP keine sichtbare Antenne, kannst du nur die Pi-Antenne auf den AP ausrichten und verschiedene Lagen ausprobieren (horizontal, vertikal, 45°, etc). Wenn du noch etwas mehr rumprobieren willst, kannst du auch versuchen, die Pi-Antenne nicht direkt auf deinen AP auszurichten, sondern 45° um die Längsachse vom HAT weggedreht. Das entspricht der 135°-Angabe in der V0-Ebene im Datenblatt. Das PCB muss dabei weiterhin parallel zur AP-Antenne ausgerichtet sein. Falls dir das alles zu kompliziert ist, versuch einfach, dass eine lange Seite oder die Unterseite des Pi in Richtung AP zeigt und auf keinen Fall eine der kurzen Seiten. Das Ganze ist natürlich eine eher theoretische Empfehlung. Möglicherweise gibt es in deinem Gartenhaus oder dessen Umgebung einen reflektierenden Gegenstand, was z. B. eine Wand sein kann, wodurch der Empfang aus der Richtung unerwartet besser sein kann. Wenn dein Gartenhaus ein Fenster in Richtung Haus hat, kann das vielleicht besser sein, als durch Holz mit Farbe/Lasur zu funken. Nebenbei: Bei der Installation in der Dachspitze wirst du möglicherweise das Problem bekommen, dass der Pi im Sommer gekocht wird, da es dort am heißesten sein wird.

Den HAT würde ich nicht im laufenden Betrieb auf- oder abstecken. Dabei mache ich mir weniger Sorgen um den HAT als um den Pi. Bricklets sind nicht dafür gemacht, im laufenden Betrieb an- und abgesteckt zu werden. In der Praxis funktioniert es trotzdem meistens, aber garantiert ist es nicht. Theoretisch kannst du dir dabei Bricklet oder HAT elektrisch schädigen. Vorgesehen ist, dass du den Pi ausschaltest und stromlos machst, dann die Bricklets umsteckst, und anschließend wieder die Stromversorgung verbindest. Deine Software musst du auf jeden Fall neustarten, weil die nicht mitbekommt, wenn Bricklets verschwinden. Es gibt kein „disconnected“-Event.

Also so weit ich weiß hat die Entladerate bei Lithium-basierten Batterien keinen Einfluss auf die Lebenserwartung, sofern die Batterie für die entsprechende Entladerate geplant wurde. Einfluss auf die Zellenalterung haben längere Zeit bei 100 % rumstehen (deswegen gibt es bei vielen Autos die 80 %-Regelung) längere Zeit unter 100 % pendeln, sodass die Zellen nie ausbalanciert werden besonders hohe oder niedrige Temperatur Anzahl der (Ent-)Ladezyklen Entladetiefe (DoD - Depth of Discharge) Wegen der letzten beiden Punkte kann man natürlich sagen, dass es besser für die Lebenserwartung ist, wenn du die Batterie nur einmal am Tag entlädst und dann auch nur bis 30 %. Allerdings ist das finanziell fragwürdig, weil du dann Geld für 30 % Batteriekapazität ausgegeben hast, die du nicht nutzt, und somit auch weniger Geld sparst. Man kann jetzt natürlich versuchen rauszufinden, ob die Lebenserwartung mehr als 30 % steigt und man somit 30 % seltener die Batterien ersetzen muss, aber das war mir dann zu kompliziert. Dazu kommt dann noch, dass die in stationären Batteriespeichern verwendeten Lithium-Eisenphosphat-Akkus besser für viele Ladezyklen geeignet sind, im Gegenteil zu den Lithium-Akkus mit Cobalt, wie sie in fast allen E-Autos eingesetzt werden. Deswegen habe ich dann beschlossen, den Batteriestrom einfach so wie vorgesehen zu nutzen, wenn er verfügbar ist. Ich bin ein großer Fan von Bastelprojekten und will dich nicht davon abhalten, eine Entladesperre für deinen Speicher zu bauen, aber meine Empfehlung ist, dass du dir das Leben leichter machst, wenn du dich nicht so sehr auf diesen Aspekt fokussierst, solange du nicht weißt, ob du dadurch tatsächlich einen nennenswerten Gewinn hast. Ein durchaus interessanter Ansatz mit der Entladesperre, der mit gerade einfällt, wäre, bei einer längeren Phase ohne Sonne im Winter das Entladen zu sperren, damit der Speicher auch im Winter mal wieder die 100 % erreicht, um die Zellen auszubalancieren. Mein Speicher lädt sich nach Wochen unterhalb von 100 % einfach mal aus dem Netz voll, wodurch er einen zusätzlichen Ladezyklus mitmacht und auch noch teuren Strom bezieht. Mit einer Entladesperre könnte ich ihn über mehrere Tage bis 100 % vollladen lassen und so den Extrazyklus und Stromeinkauf sparen.

Machst du die Batterie nachts dann auch nicht leer? Falls doch, geht das doch genauso auf die Lebensdauer. Falls nicht, wozu hast du dir dann den Batteriespeicher gekauft? 🤔

Aktuell gibt es weder eine gesonderte Anbindung für E3DC, noch eine Sonderbehandlung für Batteriespeicher über SunSpec. Ich habe einen Warp Charger mit einem Batteriespeicher von einem anderen Hersteller in Betrieb, musste mir die Anbindung aber selbst programmieren. So eine Idee hatte ich auch zuerst, habe sie dann aber wieder verworfen. Ob ich den Strom jetzt kaufe und in der Nacht den Speicher nutze, oder jetzt den Speicher nutze und in der Nacht den Strom kaufe, macht unterm Strich keinen Unterschied, sofern mich der Strom rund um die Uhr das Gleiche kostet. Ich muss exakt die gleiche Menge Strom kaufen, nur zu einer anderen Zeit. Verschone ich meinen Batteriespeicher mit dem Schnellladen und hebe mir den Strom für die Nacht auf, kann es dagegen passieren, dass der Speicher morgens gar nicht leer ist, und ich somit eigenen Solarstrom verschenkt habe, den ich besser ins Auto geschoben hätte. Lade ich mein Auto mittags schnell aus der Batterie, ist anschließend auch wieder mehr Platz drin, um nachmittags den Speicher nochmal voll zu laden. Dementsprechend versuche ich gar nicht, meinen Batteriespeicher zu sperren, sondern lade das Auto im Schnellmodus einfach aus dem Speicher. Was genau erhoffst du dir davon, die Entladung des Batteriespeichers zu sperren? Hast du einen dynamischen Stromtarif?

Edit: Ich habe gerade in einem deiner vorigen Posts gesehen, dass du einen SDM630 selbst nachgerüstet hast. Wahrscheinlich musst du jetzt den Zählertyp nochmal von Hand angeben. Geh dazu bei Firmware-Version 2.2.1 auf die Zählerseite und bearbeite den Wallbox-internen Zähler (blauer Button mit Stift-Icon). Wahrscheinlich steht der Zählertyp da auf „Automatisch“. Stell da einfach mal den SDM630 ein. Anschließend speichern und neustarten. Falls das nicht reicht, beachte das Durchgestrichene unten, das ich zuerst geschrieben hatte. Wo hast du eigentlich das mit dem Zähler löschen und neu konfigurieren gelesen? Der SDM630 sollte auch mit 2.2.1 und zukünftigen Versionen funktionieren. Wir wollen niemanden auf 2.1.5 sitzen lassen. Bitte installiere nochmal Version 2.2.1 und lade dann ein Debug-Log runter und hänge es hier an, damit wir uns den Fehlerfall ansehen können.

Ja, das sollte funktionieren. Dort musst natürlich entweder LAN oder ausreichend gutes WLAN verfügbar sein.