Unify Mtec & Wattsonic templates

[premultiply]

No description provided.

[yewbacca]

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.

[premultiply]

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.

[yewbacca]

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...

[yewbacca]

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?

[premultiply]

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.

[yewbacca]

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 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...

[yewbacca]

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...

[yewbacca]

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....

[yewbacca]

Im solinteg-gen2.yaml fehlt im params Block:

• name: capacity
  advanced: true

Dann sollte der letzte Check auch noch erfolgreich sein...

[andig]

Was fehlt hier?