MatzeTF

Schnell editieren, hatte deine Frage zuerst falsch verstanden… Die Indices sind nicht fix und können sich ändern, wenn wir z. B. irgendwas an der Zählerbehandlung ändern. Aktuell haben wir nicht geplant, etwas an den Indices der verbauten Zähler zu ändern, aber wir garantieren das nicht und die Indices könnten sich jederzeit ändern. Es ist beabsichtigt, dass du die passende ID raussuchst und dann deren Index verwendest.

Das DC SSR hat einen gepolten Ausgang, beschriftet mit "-1" und "2+". Auf deinem Foto ist zu sehen, dass du den Ausgang einfach falschrum angeschlossen hast. Im durchgeschalteten Fall hast du einen Spannungsabfall nahe 0 V weil es halt durchgeschaltet hat. Im nicht durchgeschalteten Fall misst du 0,6 V, was dem Spannungsabfall der Inversdiode des SSR entspricht. Wenn du es falschrum anschließt, lässt diese Diode immer den Strom durch. Details dazu auf Wikipedia. Wenn du den Akku darüber laden und entladen möchtest, musst du natürlich bedenken, dass das SSR in eine der beiden Richtungen, also entweder Laden oder Entladen, dementsprechend immer durchgeschaltet ist (mit relativ hohem Verlust). Möchtest du das unterbinden und der Stromfluss soll in beide Richtungen getrennt werden, brauchst du ein zweites SSR, dass du umgekehrt gepolt in Serie mit dem ersten schaltest. Es sollte funktionieren, beide SSR mit einem SSR-Bricklet zu schalten, indem du die Eingänge der SSR parallel anschließt. Die Eingänge müssten dabei gleich gepolt sein.

Warp3 kann das nicht. borgs Post gilt dafür genauso.

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.