MatzeTF

So ist es.

Selbstabholung kannst du beim Bestellen mit angeben. Warte aber besser, bis die WARP3 in unserem Shop steht, statt deine Bestellung hier im Forum zu lassen. 😉

Der neue Stand ist der alte Stand: siehe borg’s vorletzter Post. Die letzten fehlenden Teile sollen am 28.3. geliefert werden. Sobald die da sind, beginnt die Fertigung.

Das kann ich leider gerade nicht so einfach erklären. Ich repariere es einfach und baue dann für dich eine Test-Firmware, damit du ausprobieren kannst, ob es damit weg ist.

EVCC läuft doch auf irgendeinem RPi oder PC, was beides keinen Modbus-Anschluss hat. Mit der Modbus-Adresse wirst du also nichts anfangen können (es ist übrigens 1). Du kannst die Zählerwerte per MQTT vom WEM bekommen und sie an EVCC weiterleiten. Wie man die Werte in EVCC rein bekommt, weiß ich nicht. Vielleicht machst du dafür einen neuen Thread auf, weil ein paar andere Leute hier im Forum sowas schon machen.

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.