MatzeTF

Spontan würde ich zu Schrittmotoren und dem Silent Stepper Bricklet 2.0 Bricklet raten. Die Geräuschentwicklung dürfte für deinen Anwendungsfall egal sein, aber im Silent-Betrieb solltest du glatte, ruckelfreie Bewegungen hinbekommen.

Hängst du die Logs auch hier an? 🙂 Für die meisten Sungrow-Bugs haben wir Workarounds. Was bleibt, sind häufige Lesefehler bei gleichzeitigen Modbus-Zugriffen. Wenn du da noch mit OpenHAB oder einer App draufhängst, wird das irgendwann unbenutzbar. Wechselrichter würden wir gerne bauen, allerdings ist die Konkurrenz bei Wallboxen schon schwierig. Das wird bei Wechselrichtern noch schlimmer sein.

Wir haben jetzt noch einige Korrekturen für Sungrow-Probleme eingebaut. Bitte teste mal diese Firmware und lade anschließend ein Log der Gerätesuche hier hoch. warp3_firmware_2_3_0_6626a111_0ca140bbadd4d87_merged.bin

Wenn die Wallbox längere Zeit im Status „ladebereit“ bleibt, heißt das entweder, dass das Fahrzeug voll ist oder dass es aus anderen Gründen nicht laden möchte, z.B. wegen 80%-Limit. Etwas besseres gibt es da aktuell nicht. Längere Zeit „ladebereit“, obwohl das Fahrzeug laden möchte, kann nur im Fehlerfall auftreten, wenn das Fahrzeug die Ladefreigabe nicht annimmt.

Der Widerstand zwischen PP und PE codiert die Belastbarkeit des Kabels. 1k5 bedeutet, dass es ein 13 A-Kabel ist. Meine Vermutung ist, dass für ISO15118 ein korrekter PP-Widerstand angelegt werden muss und pyPLC an der Stelle einfach den größtmöglichen Widerstand gewählt hat, da sie die AC-Leitung nicht nutzen. Der tatsächliche Wert des PP-Widerstands kann für CCS nicht verwendet werden, da sich damit maximal 63 A codieren lassen, DC-Lader aber mit bis zu 500 A laden.

Whandlerverlust 😀 Danke, ist gefixt.

Aktuell gibt es noch keine besondere Unterstützung für Batteriespeicher in der WARP, ist allerdings für die Zukunft geplant. Aktuell kann man das Regelverhalten des PV-Überschussladens so einstellen, dass entweder das Fahrzeug oder der Batteriespeicher bevorzugt geladen wird. Wird der Speicher bevorzugt, wird sämtliche darüber hinausgehende Energie trotzdem dem Fahrzeug bereitgestellt. Wenn der Speicher also von 98 bis 100% langsam lädt, ist das kein Problem. Ist genug Sonne da, gibt die Wallbox schon vorher den Strom frei, da sie nur die Netzeinspeisung betrachtet und den Speicherstand ignoriert. Das ist eine viel zitierte Aussage, die allerdings auf einer im Allgemeinen falschen Annahme beruht. Die Annahme ist, dass DC Speicher -> AC Netzspannung -> DC Fahrzeug zu mehr Verlusten führt und deswegen das Fahrzeug nicht aus dem Batteriespeicher versorgt werden soll, sondern nachts das Haus. Nehmen wir mal einen Wandlerverlust von 5% an. Vereinfacht gesagt gibt pro geladene Kilowattstunde 5% Verluste im Batteriespeicher und 5% Verluste im Auto-Lader, macht 10% Verluste, also 100 Wh pro Kilowattstunde. Lädt man das Fahrzeug mit Strom aus dem Netz, gibt es nur 5% Verluste im Auto-Lader, also 50 Wh. Hört sich also besser an, allerdings wird dann ja nachts das Haus aus dem Speicher versorgt und dort gibt es 5% Verluste, also 50 Wh. Zählt man das zusammen, kommt man genauso auf 100 Wh Verluste pro Kilowattstunde, die ins Fahrzeug geladen bzw. aus dem Speicher entnommen wurde. Das Fahrzeug nicht aus dem Batteriespeicher zu laden hat also keine Vorteile; die Verluste entstehen nur zu einer anderen Tageszeit. Interessant wäre das vielleicht mit dynamischen Strompreisen, allerdings würde ich dann davon ausgehen, dass der Strom tagsüber teuer ist und es erst recht sinnvoll ist, ein Fahrzeug aus dem Speicher zu laden und nachts den billigen Strom fürs Haus zu nutzen. Wenn man das Fahrzeug nicht aus dem Speicher lädt, sehe ich eher das Problem, dass der Speicherinhalt nachts gar nicht aufgebraucht wird, und der Speicher somit gar nicht vollständig genutzt wird. Alles, was morgens noch im Speicher ist, ist verschenkte Kapazität, die man besser zum Laden des Fahrzeuges verwendet hätte. Ein weiteres Szenario: Der Speicher wurde vormittags voll geladen und mittags wird bei nicht ausreichend PV-Leistung ein Fahrzeug geladen. Lädt das Fahrzeug aus dem Netz, bleibt der Speicher voll und kann nachmittags, wenn das Fahrzeug nicht mehr lädt, keine weitere Energie aufnehmen. Hätte man das Fahrzeug mittags aus dem Speicher geladen, hätte man nachmittags den Speicher ein zweites Mal voll laden können. Den Speicher generell zum Laden des Fahrzeuges zu nutzen, ist daher sogar sinnvoller.

Zählermodelle auszuwählen, die während der Suche nicht gefunden wurden, wird nicht funktionieren. Nach dem Verbindungsaufbau wird nämlich genau dieses Modell gesucht. Wird es nicht gefunden, werden auch keine Daten ausgelesen. Findet die Suche es nicht, findet der Verbindungsaufbau es auch nicht. Dass der Wechselrichter als einphasig erkannt wird, ist kein Problem. Das einphasige Modell kann exakt die gleichen Daten beinhalten wie das dreiphasige Modell. Der einzige Unterschied ist, dass beim einphasigen Modell nur die Werte für Phase 1 verpflichtend sind, die für Phase 2 und 3 optional. Beim dreiphasigen Modell sind die Werte für alle drei Phasen verpflichtend. So wie ich das sehe, läufst du aktuell in ein Problem mit Sungrow-Wechselrichtern, das wir vor Kurzen gefunden haben. Das Ende der Modellliste wird anscheinend nicht konform zum SunSpec-Standard gekennzeichnet, wodurch die Suche endlos weiterläuft, bzw. bis sie irgendwann abstürzt. In den nächsten Tagen sollte es eine Test-Firmware geben, die das Problem umgeht und das nicht-standardkonforme Ende der Modellliste erkennt. Die Hoffnung wäre, dass dein WR auf einer anderen Adresse noch einen weiteren Zähler meldet, der dann die Werte von deinem Hausanschluss hat. Der eine aktuell gefundene Zähler ist ziemlich offensichtlich nur für den WR bzw. Speicher, nicht für den Hausanschluss. Aktuell stirbt die Suche, bevor der möglicherweise vorhandene zweite Zähler abgefragt wird.

Ich habe foccci + ccs32clara im Blick. Das ist zwar für die Auto-Seite, aber die Hardware-Schnittstelle sollte in beide Richtungen die Gleiche sein. Also falls dir langweilig ist… oder du vielleicht einen neuen Job in Ostwestfalen suchst…

Du brauchst auf jeden Fall ein Hardware-Modul, da ISO 15118 CAN über IPv6 über PowerLAN über die CP-Leitung ist. Dafür hat der XMC1400 keine Hardware onboard. 😉 Das Problem bei der SwitchEV-Implementierung ist, dass sie Python benötigt, unsere Firmware aber in C/C++ geschrieben ist. MicroPython hilft uns da meines Wissens nicht weiter. Dazu kommt, dass wir aktuell immer noch in dringenderen Aufgaben versinken und niemand Zeit hat, um auszuprobieren, was von den vorhandenen Open Source Lösungen man für die Wallbox nutzen könnte.

Sieh beim nächsten Mal auf der Statusseite beim erlaubten Ladestrom nach. Wenn du die Ladung gestoppt hast, steht da „Blockiert durch Manuelle Lade­freigabe oder Taster“. Das Feature hätten wir auch gerne. Problem: Woher weiß die Wallbox, welches Format die Daten auf dem MQTT Topic haben? Es gibt dafür keinen Standard. Ist es einfach nur eine Zahl? Wenn ja, was für ein Wert ist das? Leistung? Spannung? Es es ein Array von Werten? Wenn ja, was bedeuten die ganzen Werte? Ist es ein assoziatives Array? Wenn ja und da "power" steht, ist das in Watt oder Kilowatt? Und so weiter… Wir haben intern zum Testen ein MQTT-Zählermodul, mit dem wir uns auf die Zähler von anderen Wallboxen hängen können. Das klappt aber nur, weil wir wissen, dass die Zählerdaten unser bekanntes Format haben.

Die SoC-Funktion wollen wir auch gerne nutzen. Das Problem ist, dass ein ISO 15118-Modul die Wallbox aktuell um mehrere hundert Euro teurer machen würde. Das ist einfach unrealistisch, nur für den SoC. Wir bleiben aber an dem Thema dran und hoffen auf eine günstigere Lösung oder etwas, was wir selbst mit vertretbarem Aufwand umsetzen können.

Laut Datenblatt sollte das Thermoelement im Heizer potentialfrei sein. Hast du schon nachgemessen, ob das der Fall ist? Also einfach mal den Widerstand zwischen allen Kombinationen aus Thermoelement-Kabeln und Heizer-Kabeln und Schutzleiter durchmessen, wenn sie nicht angeschlossen sind. Ansonsten mal zum Thermoelement nur den Schutzleiter, Schutzleiter + Neutral oder Schutzleiter + Phase über SSR anschließen. Sind die vom Thermoelement gemessenen Werte, wenn die Kaltgerätebuchse nicht angeschlossen ist, realistisch?

Bitte einen Debug-Report von der Wallbox runterladen (unter dem Menüpunkt Ereignis-Log) und hier anhängen. Bitte vorher ein ladebereites Fahrzeug anschließen und der Stromzähler sollte gerade mehr als 2000 W Einspeisung melden (also < -2000). Wie lange ist eigentlich „nie“? Die Wallbox muss mehr als fünf Minuten am Stück ausreichend Einspeisung gesehen haben. Wenn die Wallbox zuerst eine Weile mit einem gemeldeten Einspeisung von 0 W gelaufen ist und anschließend die Einspeisung nur knapp über 1400 W lag, kann es bis zu neun Minuten dauern.

If you’re not space-constrained, have you considered using a third-party PoE splitter to power an ESP32 Ethernet Brick? For example, a TP-Link TL-POE10R can output 5V that can be directly fed to the brick after soldering in the pin header in the middle of the board. Other PoE splitters outputting any voltage up to 28V can be used together with the ESP32 power supply.

Das ist in der Tat etwas verwirrend formuliert. Sowohl Smart als auch Pro können selbständig eine Phasenumschaltung durchführen, gesteuert entweder über internes PV-Überschussladen, EVCC oder manuelles Umschalten. Die Pro hat zusätzlich das Feature, dass beim Laden im dreiphasigen Modus erkannt wird, wenn ein einphasig ladendes Fahrzeug angeschlossen ist. In dem Fall wird ohne Unterbrechung auf einphasiges Laden umgeschaltet und für die Dauer des Ladevorganges kann auch nicht wieder in den dreiphasigen Modus gewechselt werden, was bei einem einphasig ladenden Fahrzeug ja auch sinnlos wäre. Bei den EVCC-Einstellungen musst du den Eintrag für den Energy Manager hinzufügen und dafür das gleiche Topic eintragen wie für die Wallbox, da sie das Feature integriert hat.

Das Ladekabel ist bis 20 A zugelassen, die Zuleitung mit 6 mm² sogar noch höher. Begrenzender Faktor ist allein der LS. Wenn du einen B16 verbaut hast, musst du ab 18 A damit rechnen, dass der rausfliegt. Das bezieht sich auf eine Temperatur von 30 °C im Sicherungskasten. Ist der Sicherungskasten im Keller, klappen vielleicht auch 19 A. Ist er in der Garage und dort herrschen sommerliche Temperaturen, hast du vielleicht nur 17 A. Am sichersten wärst du unterwegs, wenn du den LS gegen einen B20 austauscht. Achte darauf, einen dreipolig abschaltenden LS zu verwenden, keine drei einpoligen. Dann ist alles für 20 A ausgelegt und du kannst dir überlegen, ob du 18 A freigibst oder gleich auf 20 A gehst und deine 11 kW-Wallbox effektiv zu einer 14 kW-Wallbox machst. Technisch sollte das sicher sein, allerdings musst du eine Wallbox mit mehr als 11 kW beim Energieversorger anmelden. 😉 Außerdem solltest du bedenken, dass die Leitungsverluste quadratisch mit der Stromstärke steigen. Gerade bei den 2,5 mm² vom Ladekabel wird sich das bemerkbar machen, insbesondere bei einem 7,5 m-Kabel. Dafür ist im Winter beim Laden auf dem Hof der Weg zum Auto immer schnee- und eisfrei. 😜

20 s hört sich gut an. Das ist ungefähr die Zeit, die eine Phasenumschaltung mit CP-Trennung braucht. WEM und PV-Speicher arbeiten in der Tat gegeneinander, da beide die Hoheit über den Hausanschluss beanspruchen. Aktuell ist das leider auch nicht zu verhindern. Beim Überschwingen kann auch das Regelverhalten des Fahrzeugs eine Rolle spielen. Wir haben kürzlich festgestellt, dass einige Fahrzeuge ihre Ladeleistung relativ langsam hochregeln. Das alleine kann schon zu massivem Überschwingen führen, sogar ohne PV-Speicher. Eine längere Periodendauer des Überschussreglers dämpft derartiges Überschwingen recht gut, hat allerdings den Nachteil, dass die Regelung dann träger wird und sowohl langsamer auf sich ändernde Sonneneinstrahlung reagiert, als auch bei gleichbleibender Sonneneinstrahlung länger braucht, die optimale Ladeleistung zu finden. Angehängt findest du eine Test-Firmware, bei der man die Periodendauer der Überschussregelung einstellen kann. Dazu musst du die Recovery-Seite des WEM unter „wem-abcd/recovery“ öffnen und dann in das Textfeld „API“ das hier reinkopieren: {"method":"PUT", "url":"/charge_manager/control_cycle", "payload":{"period":10}} Wenn du dann auf "Call API" klickst, sollte unten "200" angezeigt werden. Dann musst du noch über die Firmware-Update-Seite neustarten und anschließend ist die Periodendauer des Reglers 10 s lang. Die Periodendauer wird nach einem Neustart zur Kontrolle im Ereignis-Log angezeigt. Du kannst auch gerne andere Werte ausprobieren und versuchen, den kleinsten Wert zu finden, bei dem das Überschwingen nicht relevant zunimmt. Berichte dann doch mal, wie das Ergebnis mit 10 s oder anderen Werten aussieht. energy_manager_firmware_2_1_0_661e8e7f_01d04970698ec42_merged.bin

Danke für das Angebot, aber ich bediene mich bei Gelegenheit einfach in deinem git. 😉 Wir haben leider (noch?) keinen SHM hier, um das Ganze zu testen, und wir möchten ungern etwas offiziell veröffentlichen, was wir weder testen noch warten können.

Das direkte Abfragen des Zählers ist keine Option, da Modbus ein Client/Server-Architektur (bzw. Master/Slave) nutzt, bei der es nur einen Client geben darf, der den Bus verwaltet. Um den Zähler auszulesen, müsste ein zweiter Client Anfragen auf dem Bus senden, was leider nur zu Datenmüll führt. Die Frage ist, ob die Sax Power Stromspeicher selbst eine Modbus-Schnittstelle als Server anbieten, die man mit einem Client abfragen kann.

Ich fürchte, der Hinweis ist schon lange veraltet. Es gibt bereits seit einiger Zeit das Silent Stepper Bricklet, inzwischen sogar als Version 2.

Ja, ist in Arbeit.

Der Flow verwendet die Legacy API, die nur einen Zähler unterstützt. Bei WEM und WARP ist das standardmäßig der erste Zähler (Nummer 0). Beim WEM hast du an der Position einen API-Zähler angelegt, den du beschreiben kannst. Bei der WARP ist das allerdings der Wallbox-interne Zähler, den du nicht überschreiben kannst. Es ist prinzipiell möglich, die Legacy API auf den anderen Zähler umzubiegen, allerdings kannst du dann darüber nicht mehr auf den internen Zähler zugreifen. Stattdessen solltest du die neue API nutzen, mit der du auf alle Zähler in allen Positionen gleichzeitig zugreifen kannst. Um die neue API nutzen zu können, musst du dir einen API-Zähler anlegen mit den Werten, die du setzen möchtest. Wenn du nur den Leistungswert setzen möchtest, brauchst du nur „Wirk­leistung (Bezug minus Ein­speisung); Σ L1, L2, L3 [W]“. Am einfachsten bekommst du den Wert, indem du die SDM72-Vorlage auswählst und dann alles außer dem ersten Wert rauswirfst. Per NodeRed musst du dann an meters/1/update (wenn dein API-Zähler die Nummer 1 hat) JSON im Format "[123.4]" schicken. Also eckige Klammern mit nur dem Leistungswert in Watt drin. Den unteren Flow aus dem von dir verlinkten Post brauchst du bei der neuen API nicht. Der setzt nur den Zählertyp bei der Legacy API, was bei der neuen API direkt beim Anlegen des Zählers im Webinterface passiert und dann permanent gespeichert wird.

Der Hersteller liest mit. 😉 Aktuell gibt es keine konkreten Pläne, die Legacy-API abzuschaffen, aber Irgendwann™ könnte das mal anstehen. Wenn du jetzt etwas Neues baust, solltest du besser direkt die neue API nutzen. Bitte erkläre etwas genauer, wie du aktuell versuchst, die neue API zu nutzen, und welche Fehler du bekommst. Hast du mal ins Ereignis-Log gesehen? Da sollte irgendwas drinstehen, wenn deine Werte ignoriert werden. Lade einfach mal ein Log runter und hänge es hier an, damit ich mir deine Zähler-Konfiguration ansehen kann.

30 V should be safe. The absolute maximum is probably about 36 V. The + pins are only used for voltage monitoring and the LED strip should not draw its power via the bricklet. If you need more than 30 V, just don’t connect any of the + pins. The voltage monitoring might actually saturate before reaching 36 V. If you want to know how high it can go, just keep an eye on the reported voltage while raising the input voltage until it saturates.