evcc-io
Unify Mtec & Wattsonic templates
Also:
Ich habe eben mit meinem M-TEC Gen3 mit nagelneuester FW
bei voller Hausbatterie und 2-3kW PV-Power eine Testreihe im Schnelllademodus durchgefahren mit
a) der M-TEC Gen3 yaml original aus der V0.209.6 (hat nur "batterymode:")
b) der Wattsonic Gen3 yaml original aus der V0.209.6 (hat nur "limitsoc:")
c) einer M-TEC Test yaml, bei der die original MTEC Yaml um "limitsoc:" / minsoc / maxsoc aus der Wattsonic Gen3 erweitert wurde
Alle Tests wurden mit DIESEN Batterie-Einstellungen gefahren:
bei a) geht der M-TEC in den ECO-Modus ("Hold" in evcc-Terminologie), die Batterie wird als gesperrt angezeigt und ist es auch, die Leistung aus der Batterie bleibt bei 0
bei b) wird die Batterie als gesperrt angezeigt, aber die Sperre wirkt nicht, es werden 7.x kW aus der Batterie gesaugt, alles was von PV-Seite her an den 11kW fehlt. Es wird NICHTS an den SOC-Limits MinSOC / MaxSOC verstellt, um die Batterie zu schützen:
bei c) wird die Batterie als gesperrt angezeigt, aber die Sperre wirkt nicht, es werden 7.x kW aus der Batterie gesaugt, alles was von PV-Seite her an den 11kW fehlt. Es wird NICHTS an den SOC-Limits MinSOC / MaxSOC verstellt, um die Batterie zu schützen. Es wird NICHTS am Betriebsmodus (Hold/Charge/Normal) verstellt, als hätte die (nicht funktionierende limitsoc Funktionalität Prio über den batterymode:
Wie funktioniert das mit dem limitSOC? oder wie SOLL das funktionieren? in der yaml ist ein Register angegeben, mit dem die SOC-Untergrenze (im On-Grid-Betrieb) angegeben wird. Das ANDERE Register, mit dem die SOC-Obergrenze eingestellt wird, ist aber in der yaml nicht spezifiert und ich habe auch nichts in der Doku gefunden, ob/wie das eingestellt wird, ob/wie das in der yaml definiert wird....
So wie es sich mom darstellt, funktioniert der batterymode mit den Gen3-Geräten (und vorbehaltlich Tests auch mit den Gen2), aber der limitsoc Mechanismus funktioniert definitiv NICHT mit Gen3-Geräten bisher
Also mit den Testergebnissen oben wäre halt die große Frage, WIE ein konsolidiertes YAML für Gen3 aussehen sollte: batterymode oder limitsoc oder beides drin????
limitsoc: source: modbus {{- include "modbus" . | indent 2 }} register: address: 52503 # min soc type: writeholding encoding: uint16 scale: 10
Das angegebene Register stellt das SOC Limit der Batterie im Netzbetrieb ein, unter diesen Wert wird nicht entladen, fällt der SOC darunter (weil z.B. das Limit über den SOC hochgesetzt wird), wird mit 1-2 kW aus dem Netz geladen, bis das SOC-Limit erreict ist... Es gibt ein Pendant dazu in 52505, dort wird das untere Limit der Batterie für den Off-Grid-Betrieb / Backup-Betrieb eingestellt. Und seit im Laufe von 2025 (je nach "Hersteller") gibt es in 52506 eine SOC-Obergrenze, bis zu der geladen wird - default sind 100% - bei alten/älteren FW-Versionen kommt auf dieser Adresse ein Zugriffsfehler oder es wird der Wert 0xffff = -1 geliefert, wenn der Fehler abgefangen wird.
Idealerweise sollen keinerlei Manipulationen an irgendwelchen SoC-Limits vorgenommen werden. Also dem batterymode ist grundsätzlich Vorrang zu geben. limitsoc ist nur die Implementierungsrückfallebene wenn nichts anderes geht.
Laut der mir vorliegenden Doku soll aber angeblich schon "GEN2" alles können was man für eine ordentliche Implementierung braucht. Den Ist-Zustand kannst du dahingehend erstmal vergessen. Das ist erstmal nur irgendwas zusammenkopiert.
Idealerweise sollen keinerlei Manipulationen an irgendwelchen SoC-Limits vorgenommen werden. Also dem batterymode ist grundsätzlich Vorrang zu geben. limitsoc ist nur die Implementierungsrückfallebene wenn nichts anderes geht.
Laut der mir vorliegenden Doku soll aber angeblich schon "GEN2" alles können was man für eine ordentliche Implementierung braucht. Den Ist-Zustand kannst du dahingehend erstmal vergessen. Das ist erstmal nur irgendwas zusammenkopiert.
Wie du an meinen Tests gesehen hast, ist definitiv dem batterymode der Vorrang zu geben, denn DER FUNKTIONIERT.... und die drei Modi für Hold/charge/normal gab es in dieser Form von Anfang an bei Gen2 auch schon, also auch DA ist definitiv dem batterymode der Vorzug zu geben...
Bei den Betriebsmodi der Gen3 Geräte hat es in den letzten drei Jahren den einen/anderen Zuwachs gegeben:
Letztens dazugekommen die untere Zeile... Kann also sehr gut sein, dass beim Start des evcc-Ladevorgangs NICHT der GeneralMode 257 aktiv ist...
In Anbetracht dessen wäre es eine Überlegung wert, am Ende des Ladevorgangs nicht stur auf GeneralMode (zurück) zu schalten, sondern beim Start des Ladevorgangs den Betriebsmodus zu speichern und bei Beendigung des Ladevorgangs wieder entsprechend zu restaurieren... Evtl. nicht nur für die Solinteg-Gen3-Geräte interessant, sondern als generelles Feature???
NICHT für diesen PR, aber for-future-extension?
Die Doku spricht im Anhang vom EMS_BattCtrlMode und den Registern
- Battery Power Setting (50207) - Set Pbat
- AC Top Limit Setting (50208) - Set PupLimit
- AC Bottom Limit Setting (50209) - Set PlowerLimit
- Supply Power Priority (50210) - Supply Priority
Das sieht eigentlich wesentlich passender aus. Vielleicht ist aber die aktuelle Modusumschaltung auch genau so gut.
Die Doku spricht im Anhang vom
EMS_BattCtrlModeund den Registern* Battery Power Setting (50207) - Set Pbat * AC Top Limit Setting (50208) - Set PupLimit * AC Bottom Limit Setting (50209) - Set PlowerLimit * Supply Power Priority (50210) - Supply PriorityDas sieht eigentlich wesentlich passender aus. Vielleicht ist aber die aktuelle Modusumschaltung auch genau so gut.
Die aktuelle Modusumschaltung funktioniert einwandfrei, wenn limitsoc nicht dazwischenfunkt... in 50202 gibt es einen Inverter AC Power Setting Selektor, der darüber entscheidet, ob und welche Register ab 50203ff. zur Anwendung kommen... ich weiß NICHT, ob das auch die Register 50207ff. mit einschließt... ich weiß aber, dass diese Register bei den neuen Modi wie z.B. ToU (TimeOfUse) explizit anhand eines Schedules gesetzt werden... und zwar aus einem Activity Schedule, der oben in der Cloud gesetzt und verwaltet wird... vor Nutzung/Änderung dieser Register würde ich seeeeeeeehr genau und penibel funktionstesten und kompatibilitätstesten...
Wenn wir das Gen3 yaml schon am ummodeln sind: Kannst du den energy Block mit einfügen?
Dann würde auch bei den Gen3 Geräten so wie bei vielen anderen WRs auch die erzeugte Energie angezeigt werden...
Explizit nur für Gen3 angefragt, weil ich mir bei den Gen2 Geräten mangels Doku über den 30000er Bereich nicht sicher bin, ob das DA auch funktioniert...
Hinzufügung von Energie-Werten bei den Gen2- und Gen3-Geräten:
Gen3 arbeitet mit dem Register 31112 wie oben im Screenshot dargestellt. Gen2 verfügt ebenfalls über diesen Energiewert, der sitzt dort aber in Register 41112, mit gleichem Type und Scale wie bei Gen3
Gen2 wurde mit Nutzern von M-TEC Gen2 Betreibern abgeprüft, sollte auch bei anderen Brands identisch sein, da es sich um eine der Grundfunktionen der Wechselrichter handelt....
Im solinteg-gen2.yaml fehlt im params Block:
- name: capacity advanced: true
Dann sollte der letzte Check auch noch erfolgreich sein...