SunEnergyXT 500

Sunenergyxt500 Adapter für ioBroker

Integration und Eigenverbrauchssteuerung für SunEnergyXT 500 / 500 PRO Wechselstromgekoppelte Hybrid-Batteriespeichersysteme (Hersteller: SunEnergyXT)](https://www.sunenergyxt.com/)) über die lokale HTTP-API des Geräts - kein Cloud-Konto erforderlich. Eine Instanz verwaltet bis zu drei Speichereinheiten.

Sprache

• Englisch (Standard)
• Deutsch

Merkmale

• Verwaltet ein bis drei Köpfe in einer einzigen Instanz, jeder unter seinem eigenen Unterbaum heads.<n>.*, plus kombinierte total.*-Aggregate.
• Fragt die lokale API ab (GET /read) und spiegelt alle stabilen Felder in Zuständen wider: SoC, Batterie-/Netz-/Last-/PV-Leistung, Strom/Spannung pro MPPT, tägliche Energiezähler, SoC pro Akkupack, Geräte-/Firmware-Informationen und Zählerstatus.
• Beschreibbare Steuerfelder (POST /write, durch erneutes Einlesen bestätigt), die der offiziellen Steuerungsoberfläche der Integration entsprechen, mit Ausnahme der Felder, die in der API-Dokumentation als reserviert gekennzeichnet sind: Netzsollwert GS, Wechselrichter-Ausgangsgrenze IS, SoC-Grenzwerte SI/SA/SO, Eigenverbrauchsmodus MM, Zählerkonfiguration MD, Zeitzone TZ, Neustart RT, maximale Netzleistung MG, die Schalter LFB/LPS/PM und der lokale Modus LM (⚠️ LM=1 blockiert die Cloud-/App-Steuerung bis zum Reset). Die SoC-Hysterese SI1/SA1 (vom Hersteller als beschreibbar dokumentiert, Standardwert jeweils 5 %, zulässiger Bereich 0…100 %) behält ihre festgelegten heads.<n>.battery.*-IDs, sodass bestehende Aufzeichnungen erhalten bleiben. Felder, die in der API-Dokumentation weiterhin als reserviert gekennzeichnet sind (z. B. PT), sind schreibgeschützt.
• Zwei umschaltbare Steuerungsmodi: ein adapterseitiger Eigenverbrauchs-Regler (schreibt GS aus jedem ioBroker-Zählerstatus, Vorwärtskopplung + P, mit Watchdog/Failsafe), der einen Netzsollwert auf alle Zähler aufteilt, oder eine Geräte-Selbstregulierung (bindet einen unterstützten Zähler in einen einzigen Speicher ein und ermöglicht es dem Gerät, sich selbst zu steuern) - plus ein Aus-Modus für die reine Überwachung.
• Eine Schaltfläche "Alle Köpfe testen" im Adminbereich prüft die Erreichbarkeit jedes konfigurierten Kopfes (Modell + SoC), bevor Sie speichern.
• Verbindungsindikator (info.connection) plus info.lastUpdate und pro Kopf online / lastError.
• Die vollständige, unveränderte /read-Antwort jedes Heads wird in heads.<n>.info.rawResponse (JSON) gespeichert, sodass jedes Feld, das der Adapter keinem dedizierten Zustand zuordnet, dennoch von dort gelesen werden kann.

So funktioniert dieser Adapter

Dieser Adapter steuert den Speicher lokal, ohne die Hersteller-Cloud. Eine einzelne Instanz verwaltet ein bis drei Speichereinheiten. Der Eigenverbrauch kann auf zwei sich gegenseitig ausschließende Arten erfolgen - Sie wählen eine über die Einstellung Steuerungsmodus aus:

Modus B - Adaptersteuerung (Standardeinstellung empfohlen, funktioniert mit jedem Zähler, 1-3 Zählerköpfe). ioBroker liest die aktuelle Netzleistung aus einem beliebigen Zustand, auf den Sie ihn verweisen (gridPowerStateId), und der Adapter schreibt den Netzsollwert GS (Vorsteuerung + P-Korrektur, mit Watchdog). Der Zähler kann jedes sein, was ioBroker unterstützt - Shelly, Tasmota, ein Smart-Meter/Modbus-Adapter - einschließlich Zähler, die der Speicher nicht selbst auslesen kann. Sie geben einen Zustand an, der die Netzleistung in Watt enthält (>0 = Entnahme, <0 = Einspeisung; Quellenvorzeichen umkehren aktivieren, falls umgekehrt; für kW-/Split-Import/Export-/Phasenzähler wird zunächst ein sauberer Nettowert in einem kleinen ioBroker-Zustand berechnet). Bei mehreren Zählern berechnet der Regler einen Gesamtsollwert und teilt diesen gleichmäßig auf die angeschlossenen Zähler auf. Die Leistung ist dabei beim Entladen auf die netzgekoppelte Ausgangsleistungsgrenze (MG) und beim Laden auf die jeweilige Ladegrenze begrenzt. Ein voller (beim Laden) oder leerer (beim Entladen) Zähler wird übersprungen; sein Anteil wird auf die übrigen Zähler verteilt. Der Adapter erzwingt MM=0 für jeden Zähler, sodass die Geräte GS ausführen und der Zähler in ioBroker voll funktionsfähig bleibt.

Modus A - Geräte-Selbstregulierung (unterstützte Zähler, nur Einzelzähler). Der Adapter bindet einen unterstützten Zähler in den Speicher (MM=1 + MD) ein und ermöglicht dem Gerät die Selbstregulierung - den Eigenverbrauch des Herstellers, der schneller reagieren kann als eine externe Regelung. Dieser Modus ist nur mit einem Einzelzähler verfügbar; bei zwei oder drei konfigurierten Zählern kann er nicht ausgewählt werden - verwenden Sie stattdessen den Adapter-Controller. Es werden nur vier Zählertypen unterstützt (EcoTracker, Shelly 3EM, Shelly Pro 3EM, Tasmota), und der Zähler muss über das LAN vom Speicher erreichbar sein. Der Adapter schreibt in diesem Modus nicht in GS. Die Bindung erfolgt lediglich über mDNS/HTTP-Polling, sodass der Zähler in ioBroker weiterhin nutzbar bleibt - im Gegensatz zur Zählerkonfiguration der Hersteller-App, die den Zähler neu konfigurieren und aus ioBroker entfernen kann. Dieser Adapter bindet direkt und vermeidet das.

Aus (Standardeinstellung, nur Überwachung). Der Adapter schreibt niemals in die Zustände MM/MD/GS; er fragt sie nur ab. Sie können die Zustände control.* weiterhin manuell steuern.

In beiden Steuermodi **besitzt der Adapter MM **: Bei jeder Abfrage prüft er den Wert von MM jedes Messkopfes anhand des gewählten Modus und stellt ihn (mit einer Warnung) wieder her, falls er geändert wurde - so kann eine fehlerhafte Zählerbindung oder ein externes Skript die Steuerung nicht unbemerkt deaktivieren. Hinweis: Ein Messkopf führt einen geschriebenen Wert von GS nur dann aus, wenn MM=0 aktiv ist; bei einer Zählerbindung (MM=1) reguliert er sich selbst und ignoriert GS.

Mehrere Zählerköpfe müssen an unterschiedlichen Phasen angeschlossen sein. Dies liegt in der Verantwortung des Netzbetreibers - der Adapter überprüft dies nicht (und kann es auch nicht). Der Regler steuert die Netto-Netzleistung, die Ihr Zähler meldet. Dies entspricht der Abrechnung eines standardmäßigen deutschen bidirektionalen Netzzählers; eine Optimierung pro Phase fällt nicht in seinen Leistungsumfang.

Der lokale Modus (LM=1) ist erforderlich. Jedes Gerät stellt seine lokale HTTP-API (/read / /write) nur dann bereit, wenn der lokale Modus aktiviert ist. Ist er deaktiviert, liefert /read keine Daten (bestätigt in der getesteten Firmware). Durch Aktivieren des lokalen Modus wird auch die Fernsteuerung per Cloud/App deaktiviert; folglich kann die Smartphone-App des Herstellers das Gerät nicht mehr steuern.

Anforderungen

• Ein bis drei SunEnergyXT 500 (PK=1, 800 W) oder 500 PRO (PK=2, 2400 W) Leuchtenköpfe, die im lokalen Netzwerk erreichbar sind (gemischte Modelle sind zulässig).
• Lokaler Modus (LM=1) auf jedem Gerät aktiviert - erforderlich, damit die lokale HTTP-API Werte liefern kann (siehe Funktionsweise dieses Adapters). Dadurch wird auch die Fernsteuerung per Cloud/App deaktiviert.
• Ein Zähler, abhängig vom Steuermodus: Im Modus B (Adaptersteuerung) ein beliebiger Zähler, dessen Netzstrom als ioBroker-Status verfügbar ist; im Modus A (Geräte-Selbstregulierung, Einzelkopf) einer der vier unterstützten Zähler (EcoTracker, Shelly 3EM, Shelly Pro 3EM, Tasmota), die über den Speicher im LAN erreichbar sind. Im Aus-Modus nicht erforderlich.

Installation

1. Öffnen Sie in ioBroker Admin den Menüpunkt Adapter, suchen Sie nach sunenergyxt500 und installieren Sie es.
2. Nach der Installation wird eine Instanz namens „sunenergyxt500.0“ erstellt. Öffnen Sie deren Einstellungen und geben Sie die IP-Adresse/den Hostnamen von Sensor 1 ein (fügen Sie Sensor 2/3 hinzu, falls Sie weitere Sensoren haben). Lassen Sie den Steuerungsmodus für die reine Überwachung auf Aus.
3. Speichern & schließen - der Adapter beginnt mit dem Abfragen und füllt den Objektbaum unter sunenergyxt500.0.heads.* (und total.*).

Konfiguration

Verbindung

• Head 1 IP-Adresse/Hostname (erforderlich) und Head 2/Head 3 (optional) - lokale Adressen Ihrer Speicherköpfe, jeweils mit optionaler Bezeichnung. Bis zu drei Köpfe werden von dieser Instanz verwaltet. Schließen Sie mehrere Köpfe an verschiedene Phasen an (Verantwortung des Betreibers); der Adapter regelt die gesamt Netzleistung. Dieselbe Adresse darf nicht zweimal eingegeben werden.
• Test aller Köpfe - prüft jeden konfigurierten Kopf und meldet Modell + SoC (oder einen Fehler), sodass Sie die Adressen vor dem Speichern überprüfen können.
• Abfrageintervall (s) - wie oft jeder Kopf über /read abgefragt wird (Standardwert 5 s).
• Anfrage-Timeout (ms) - HTTP-Timeout (Standard 8000 ms).
• Einstellungen nach einem Neustart des Prozessors wiederherstellen (standardmäßig aktiviert) - siehe Einstellungen nach einem Neustart des Prozessors weiter unten.

Steuerung - wählen Sie einen Steuerungsmodus:

Aus (Standardeinstellung) - nur Überwachung; der Adapter schreibt niemals MM/MD/GS.

Adapter-Controller (Modus B) - Felder:

• Netzstromquellenstatus - ein externer Status, der den Netzstrom Ihres Hauszählers speichert. Konvention: >0 = Netzbezug, <0 = Einspeisung. Aktivieren Sie Quellenvorzeichen umkehren, wenn Ihr Zähler die umgekehrte Konvention verwendet.
• Adaptive Regelung (standardmäßig aktiviert): Regelt in drei vom Hersteller bewährten Stufen - kleine Abweichungen sanft (alle 7 s, 20-W-Schritte), mittlere Abweichungen alle 2,5 s (120 W), große Lastsprünge sofort (450 W), mit einer festen Gitter-Totzone von 5 W. Beachten Sie, dass zusätzlich die pro Kopf schreibbare Totzone (standardmäßig 10 W) gilt: Eine Korrektur unterhalb dieses Wertes wird nur dann geschrieben, wenn sich der Gesamtsollwert um mindestens denselben Betrag ändert. In der Praxis bleiben Abweichungen unter etwa 10 W daher unverändert. Deaktivieren Sie die adaptive Regelung, um den Regler manuell über die Felder für Verstärkung, Totzone, Schreibintervall und Schrittbegrenzung einzustellen (diese werden nur dann angezeigt).
• Zielnetzleistung (W, Standardwert 0): 0 = keine Einspeisung; positive Werte sorgen für eine geringe, bewusste Netzentnahme (niemals Einspeisung), negative Werte für eine geringe, bewusste Einspeisung - gleiche Vorzeichenkonvention wie beim Quellzustand (>0 = Entnahme).
• Entladeschwelle des Controllers (%), Standardwert 0 = aus: Der Controller stoppt die Entladung eines Ladekopfes, sobald dessen leerster Akku diesen Wert erreicht hat, während die eigene Entladeschwelle des Ladekopfes (SI) niedriger bleibt. Der Ladekopf erreicht dann nie seine eigene Entladeabschaltung, bei der die Firmware 1.1.5 sich aufhängen und den Ladevorgang verweigern kann, bis die Verbindung zum Netz getrennt wird. Die Messung erfolgt am leersten Akku, da sich die Akkus eines Ladekopfes im Laufe der Zeit voneinander entfernen; die Entladung wird fortgesetzt, sobald der Ladezustand durch die Hysterese des Ladekopfes (SI1) wieder angestiegen ist. Nur im Controller-Modus.
• Maximale Anpassung pro Korrektur (W, Standard 500, 0 = unbegrenzt): Begrenzt die Abweichung des Sollwerts pro Regelschritt, sodass eine hohe Verstärkung bei Messspitzen nicht überschwingen kann.
• Verstärkung (Standard 0,3), Totzone (W), Mindest-Schreibintervall (ms), Totzone pro Kopf (W - minimale Änderung des Sollwerts eines Kopfes, bevor er neu beschrieben wird, um Störungen beim Verschieben des Splitts zu vermeiden). Die maximale Leistung jedes Kopfes wird automatisch vom Gerät erkannt (800 W für einen 500, 2400 W für einen 500 PRO), sodass gemischte Setups ohne zusätzliche Konfiguration funktionieren.
• Zähler-Einschwingzeit (ms) (Standardwert 0) - Messwerte, die vor der letzten Sollwertfestlegung erfasst wurden, werden immer verworfen, da sie noch den Zustand davor beschreiben. Behalten Sie den Wert 0 für Zähler bei, deren Wert der physikalischen Änderung unmittelbar folgt; erhöhen Sie ihn leicht über die gemessene Inhaltsverzögerung für Zähler, die neue Zeitstempel veröffentlichen, während der Wert noch verzögert ist.
• Zusätzliche Steuerung des Wechselrichterlimits (IS) (standardmäßig deaktiviert) - Zusätzlich zu GS legt der Controller die maximale Wechselrichterleistung fest: den Entladeanteil von GS plus die vom Lastanschluss aufgenommene Leistung, begrenzt auf die aktuelle PV-Leistung, sobald ein Solarmodul seine minimale Entladeleistung erreicht hat. Dies ist nur sinnvoll, wenn eine Last an den Lastanschluss angeschlossen ist; andernfalls werden lediglich Schreibvorgänge hinzugefügt. Im Fehlerfall und bei Abschaltung des Adapters wird das Limit nach bestem Bemühen (innerhalb des Abschaltbudgets und nur für Solarmodule, die antworten) wieder auf den Maximalwert des Solarmoduls zurückgesetzt. Ein abruptes Beenden des Prozesses kann dies nicht bewirken - siehe die unten aufgeführten Einschränkungen.
• Watchdog-Warnung / Failsafe-Funktion(en) - Wenn die Grid-Quelle veraltet, protokolliert der Controller eine Warnung und erzwingt schließlich GS=0 an allen erreichbaren Heads (sicherer neutraler Zustand), bis sich die Quelle erholt hat. Die Watchdog-Telemetriedaten sind unter controller.* verfügbar.

Der Regler arbeitet mit dem zuletzt vorgegebenen Sollwert, nicht mit einem neuen Messwert des Geräts. Die abgefragte Netzspannung (GP) dient der Korrektur: Weicht ein Gerät sichtbar länger als 10 Sekunden vom Sollwert ab (interne Begrenzung durch SoC oder Temperatur), wird der gemeldete Wert als neue Vorsteuerungsbasis verwendet - ein Schutz vor Windup ohne zusätzlichen Messwert pro Zyklus. Außerdem vergleicht er die von jedem Gerät zurückgegebenen Werte (GS) mit den vorgegebenen Werten und warnt bei Abweichungen - dies bedeutet, dass ein zweiter Regelpfad (die Hersteller-App oder eine andere Automatisierung) ebenfalls GS schreibt. Schreibvorgänge an verschiedene Leseköpfe erfolgen gleichzeitig, sodass ein langsamer Lesekopf innerhalb eines Zyklus die anderen nicht verzögert. Der nächste Zyklus wartet weiterhin auf die Antwort des langsamsten Lesekopfs. Daher verwenden Regelschreibvorgänge eine kürzere Frist (2,5 Sekunden) als das konfigurierte Anforderungs-Timeout.

Geräte-Selbstregulierung (Modus A, nur Einzelkopf) - Felder:

• Zählertyp - EcoTracker / Shelly 3EM / Shelly Pro 3EM / Tasmota.
• Zähler-SN/IP - die Seriennummer für Shelly/Tasmota (aufgelöst über mDNS) oder die LAN-IP-Adresse für EcoTracker (direkt). Verwenden Sie für Tasmota das SN-Präfix ohne die letzten vier Zeichen und stellen Sie den Ein-/Ausschalter entsprechend Ihrem Energiemonitor-Subtyp ein.

Der Adapter bindet den Zähler (MM=1 + MD), und das Gerät regelt sich selbst; der Adapter beschreibt GS nicht. Der gebundene Zähler bleibt in ioBroker nutzbar. Dieser Modus wird ausgeblendet/gesperrt, sobald ein zweiter oder dritter Messkopf konfiguriert ist.

Sicherheitshinweise: Im Aus-Modus ist der Adapter schreibgeschützt - er fragt lediglich den Zustand /read ab und schreibt nur dann, wenn Sie den Zustand control.* anweisen. Im Steuermodus **erzwingt der Adapter den Zustand MM ** für jeden Messkopf in diesem Modus und stellt ihn nach externen Änderungen wieder her. Führen Sie nicht gleichzeitig einen zweiten Schreiber für GS aus (z. B. Ihr eigenes Skript oder den Schreiber für MM eines Geräts mit einem anderen Messgerät), da diese sonst die Batterie beanspruchen.

Regelverhalten, Genauigkeit und Grenzen

Was Sie erwarten können: Der Regler hält die Netzleistung typischerweise innerhalb eines Bereichs von ±10-20 W um Null und korrigiert Lastsprünge - abhängig von den Einstellungen - innerhalb von ca. 1-3 Sekunden bis zu ca. 30 Sekunden. Ein dauerhafter, exakter Wert von 0,0 W ist systembedingt nicht erreichbar - mit keinem Regler auf dieser Hardware.

• Messgenauigkeit und Rauschen: Das externe Messgerät selbst misst mit einer Toleranz und einem Rauschen von wenigen Watt - eine Regelung unterhalb dieses Wertes ist sinnlos. (Der Sollwert „GS“ hat eine Auflösung von 1 W, die Sollwertgenauigkeit ist also nicht der limitierende Faktor.)
• Latenz der Messkette: Messwerte → ioBroker-Status → Controller → /write → Geräterampen. Zwischen einem Lastschritt und seiner Korrektur vergehen unvermeidbar etwa 1-3 Sekunden.
• Lastdynamik: Ein Kompressor oder Wasserkocher schaltet sich in Millisekunden ein - jeder Regler reagiert erst danach. Kurze Leistungsspitzen in Ihren Diagrammen sind normal und energetisch bedeutungslos (Wattsekunden). Der Regler regelt auf die konfigurierte Ziel-Netzleistung (Standardwert 0) und oszilliert symmetrisch um diesen Wert - kurze, geringe Einspeisevorgänge gehören zur Null-Einspeisung. Wenn Sie niemals Strom einspeisen möchten, stellen Sie den Zielwert auf eine geringe, bewusst gewählte Leistungsaufnahme ein (z. B. +10 W).

So wirken sich die Einstellungen aus:

Adaptive Steuerung (Standardeinstellung) passt die Geschwindigkeit automatisch an die jeweilige Leistungsstufe an. Im manuellen Modus stehen zwei bewährte Profile zur Verfügung: Entspannt (Standardeinstellungen - ruhiger Betrieb, minimale Geräteeingaben, ±20-30-Watt-Band) und Präzise (Verstärkung 0,8-1,0 · Totzone 0 · Intervall 1000 ms · Schreib-Totzone 0 - ±10-20-Watt-Band, Einschwingzeit 1-3 Sekunden). Über einen Tag hinweg erzielen beide Profile praktisch die gleiche Energiebilanz - der Unterschied liegt lediglich in der Darstellung des Diagramms, nicht im Preis.

Vorzeichenkonventionen

• GP (Netzstrom): >0 = Einspeisung, <0 = Entnahme - Gegenteil eines Shelly-Zählers (api.GP ≈ −shelly.gridPower).
• BP (Batterieleistung): >0 = Laden, <0 = Entladen.
• GS (Netzsollwert): >0 = Einspeisung/Entladung, <0 = Netzladung (1-W-Auflösung). Die Grenze ist bei einem Standard-500-Watt-Gerät nicht symmetrisch: Es kann bis zu 800 W einspeisen, aber dennoch bis zu 2400 W entnehmen, da MG nur die Leistung begrenzt.

Objektbaum

Jeder Kopf erhält seinen eigenen Unterbaum unter ** heads.<n>.* ** (n = 1…3) sowie kombinierte ** total.* **-Aggregate und adapterbezogene controller.* / info.*. Innerhalb eines Kopfes sind die Zustände in thematischen Kanälen gruppiert; das Blatt jeder Objekt-ID ist der API-Feldcode des Geräts (die Entitäts-ID aus der offiziellen Feldreferenz), und der zweisprachige Objektname beschreibt ihn - der Baum entspricht also 1:1 den dokumentierten Feldern des Geräts.

Beschreibbare Steuerelemente (heads.<n>.control.*)

Gemäß der ioBroker-Konvention befinden sich alle beschreibbaren Felder unter dem jeweiligen Head control.*. Da dies die Themen vereinfacht, zeigt diese Tabelle, worauf sich jedes Feld bezieht:

Tipp: In der ioBroker-Administration können Sie die Objektliste auch nach dem writable-Flag filtern, um alle Steuerelemente auf einmal zu finden.

device.PK wird von DevType auf Firmware abgeleitet, die PK nicht mehr meldet. SI1/SA1 sind beschreibbar (SoC-Hysterese, Standard 5 %); Felder, die weiterhin als reserviert markiert sind (PT), sind schreibgeschützt. Felder, die vom Hersteller entfernt wurden (UP) oder die nur in der Dokumentation vorhanden sind (WT, BN), sind nicht zugänglich; alle nicht zugeordneten Felder sind weiterhin in heads.<n>.info.rawResponse verfügbar.

Einstellungen nach einem Neustart des Headers

Die Firmware 1.1.5 (gemeldet als ES 1.1.15) speichert die über die lokale API geschriebenen Werte nicht: Nach einem Neustart verwendet der Lesekopf die älteren gespeicherten Einstellungen und greift nachts (beobachtet um 3:00 Uhr, ohne Neustart) automatisch wieder auf diese zurück. Im lokalen Modus kann die Hersteller-App die Einstellungen ebenfalls nicht ändern, sodass eine über diesen Adapter vorgenommene Einstellung stillschweigend auf den vorherigen Wert zurückgesetzt wird und dort verbleibt.

Der Adapter merkt sich daher die über ihn eingestellten Werte - SI, SA, SO, SI1, SA1, IS, MG und die Schalter LFB, LPS, PM - in heads.<n>.info.desiredSettings und schreibt einen neuen Wert, sobald der Lesekopf einen anderen Wert meldet (protokolliert auf Informationsebene). Ein Lesekopf, der einen Wert wiederholt ablehnt, wird langsamer erneut angesteuert und nach drei Versuchen als Warnung gemeldet. GS, MM und MD werden vom Kontrollmodus verarbeitet, RT ist ein Trigger, LM wird nie erzwungen, und TZ wird ausgelassen, da der Kopf es möglicherweise in einer anderen Form ausgibt, als es geschrieben wurde.

Nur Werte, die nach dem Update auf eine Version mit dieser Funktion festgelegt wurden, werden gespeichert. Stellen Sie diese daher einmalig über den Adapter ein. Bei Firmware, die ihre Einstellungen beibehält, bleiben alle Einstellungen unverändert und es werden keine Daten geschrieben. Deaktivieren Sie die Option, wenn diese Einstellungen von einem anderen Tool verwaltet werden.

Manuelle Mess-/Modusfelder (MM / MD)

MM/MD sind die verbrauchsabhängigen Werte eines einzelnen Messkopfes. Wenn Sie einen Steuermodus auswählen, übernimmt der Adapter die Verwaltung (Modus A setzt MM=1 + MD auf den einzelnen Messkopf; Modus B erzwingt MM=0 auf alle Messköpfe), und der Schutzmechanismus stellt beim nächsten Abruf den modusspezifischen Wert MM wieder her - daher ist jede manuelle Änderung eines Steuermodus nur vorübergehend.

Die Rohdatenfelder bleiben für die manuelle Nutzung durch Experten beschreibbar (z. B. im Aus-Modus). Sie entsprechen der offiziellen Verknüpfung: Das Deaktivieren von MM löscht auch MD, und das Schreiben von MD aktiviert MM (sofern nicht leer) oder deaktiviert es (sofern leer). Die JSON-Formate für MD für die vier unterstützten Zähler befinden sich in der lokalen API-Referenz des Geräts; im Modus Geräte-Selbstregulierung erstellt der Adapter diese automatisch anhand des Zählertyps und der Seriennummer/IP-Adresse.

Einschränkungen

• Bis zu drei Köpfe pro Instanz. Der Betrieb mit einem einzelnen Kopf wurde auf realer Hardware validiert, der Betrieb mit zwei Köpfen von einem Tester bestätigt. Die Aufteilung in drei Köpfe ist durch Komponententests abgedeckt, wurde jedoch noch nicht auf realer Hardware getestet - Rückmeldungen zu Setups mit mehreren Köpfen sind sehr willkommen. Die Selbstregulierung des Geräts ist nur für einen einzelnen Kopf verfügbar.
• Die Netzanschlüsse müssen an unterschiedlichen Phasen angeschlossen sein (Verantwortung des Netzbetreibers). Der Adapter regelt die gesamte Netzleistung, nicht die Leistung pro Phase.
• Die Akku-spezifische Lastverteilung erfolgt durch das jeweilige Batteriemanagementsystem (BMS) des Blitzkopfes - der Adapter steuert lediglich die Gesamtleistung des Blitzkopfes und liest den Wert battery.SC (total) zur Kontrolle aus; er verwaltet keine einzelnen Akkus.
• Die täglichen Energiezähler (PD/GD1/GD2/LD) erfassen den Rohverbrauch in Wh, nicht in kWh. Für PD ist die Steuermodul-Firmware ES 1.1.14 erforderlich (vermarktet als „1.1.4“ - die öffentliche Nummerierung weicht von der internen in ES ab); ältere Firmware lässt das Feld einfach weg, und der Status bleibt leer.
• Die Tageszähler werden vom Gerät beim Neustart zurückgesetzt, sodass ein Firmware-Update mitten am Tag sie wieder auf 0 zurücksetzt.
• MD und TZ werden sofort wirksam, es wird jedoch nicht garantiert, dass sie vom Gerät wortgetreu wiedergegeben werden - die Bestätigung erfolgt durch die Wirkung, nicht durch die Wiedergabe.
• Bei einem schwerwiegenden Ausfall des ioBroker-Hosts bleibt der zuletzt gesetzte Wert aktiv. Die Schreib-/Leseköpfe haben kein eigenes Timeout für gesetzte Werte: Der zuletzt geschriebene Wert von GS wird so lange ausgeführt, bis ein SoC-Limit ihn stoppt. Normale Stopps, Neustarts oder Modusänderungen werden abgefangen - der Adapter neutralisiert die Schreib-/Leseköpfe und merkt sich den Zustand (info.gsOwned), falls dies fehlschlägt, und führt die Verarbeitung beim nächsten Start fort. Ein Stromausfall oder ein beendeter Prozess können auf diese Weise nicht abgedeckt werden.
• PV-Eingänge sind nicht mit Hardware getestet (die Referenzinstallation läuft ohne PV-Module, daher sind PV1-4 immer 0). Integration und Regler sind PV-unabhängig und vollständig, jedoch sind Grenzfälle der PV-Firmware (z. B. Batterie voll + PV-Überschuss, USV/Bypass-Felder FP/UG) nicht verifiziert - Feedback ist willkommen. Strom und Spannung pro MPPT werden als Zehntelwerte erfasst und mit 0,1 skaliert, entsprechend der Integration des Herstellers. Falls die Werte in einer realen PV-Anlage um den Faktor zehn abweichen, ist dort die Fehlerursache zu finden.

Fehlerbehebung

• ** info.connection bleibt false / keine Daten:** Stellen Sie zunächst sicher, dass der lokale Modus (LM=1) auf dem Gerät aktiviert ist - andernfalls liefert die lokale API keine Werte. Überprüfen Sie anschließend, ob http://<Geräte-IP>/read vom ioBroker-Host aus erreichbar ist (Test mit einem Browser oder curl). Pro Head zeigen heads.<n>.info.online und heads.<n>.info.lastError an, welcher Head fehlschlägt.
• Es wird nichts gesteuert: Überprüfen Sie den Steuerungsmodus - Aus schreibt nie. Stellen Sie im Adapter-Controller einen gültigen Netzstromquellenstatus ein; stellen Sie in der Geräte-Selbstregulierung einen unterstützten Zählertyp und SN/IP ein.
• Gerät ignoriert GS / Batterie reagiert nicht: Ein Messkopf führt ein geschriebenes GS nur aus, wenn MM=0. Im Adapter-Controller-Modus wird dies vom Adapter erzwungen. Wenn Sie GS manuell schreiben, stellen Sie sicher, dass kein Zähler angeschlossen ist (MM=0). Bei angeschlossenem Zähler (MM=1) reguliert sich das Gerät selbst und ignoriert GS.
• Der Regler ist zu langsam / erreicht nie exakt 0: Siehe Regelverhalten, Genauigkeit und Grenzen - die Messkette verursacht eine Latenz von ca. 1-3 s, und das Messgerät selbst hat eine begrenzte Genauigkeit. Daher ist ein Bereich von ±10-20 W um den Zielwert physikalisch optimal. Für die schnellste Reaktion verwenden Sie das Profil Präzise (Verstärkung 0,8-1,0, Totzone 0, minimales Schreibintervall 1000 ms). Um eine Einspeisung zu vermeiden, stellen Sie die Zielnetzleistung auf einen kleinen positiven Wert ein.
• Status-Zeitstempel wirken veraltet / Qualitätsflag 32: Der Adapter schreibt einen Status nur, wenn sich sein Wert ändert (Standardverfahren - dies schützt die Statusdatenbank vor Millionen identischer Schreibvorgänge). Der Zeitstempel eines Status zeigt daher die letzte Wertänderung an, nicht die letzte Abfrage. Überprüfen Sie die Aktualität der Daten mit info.lastUpdate (wird bei jeder erfolgreichen Abfrage aktualisiert) und heads.<n>.info.online. Die Qualität 32 („Anfangswert ersetzen“) wird nur für Status verwendet, die das Gerät nie liefert (z. B. den SoC von nicht installierten Erweiterungspaketen). Nach jedem Start des Adapters werden alle gelieferten Werte einmal geschrieben, sodass ihre Zeitstempel mindestens so aktuell sind wie beim Start.
• Der Speicher hat keinerlei Funktion - er lädt weder noch entlädt er sich: Im Controller-Modus schaltet der Adapter die geräteeigene Regelung (MM) ab. Wenn der Regelkreis des Geräts also nicht aktiv wird, findet keine Regelung statt. Lesen Sie controller.gridPower: Dieser Wert bleibt leer, wenn der Controller keinen Wert erreicht hat (prüfen Sie die Status-ID und ob die Quelle mit ack=true beschrieben ist - nicht bestätigte Werte werden absichtlich ignoriert; controller.status wechselt zu failsafe, und der Status wird im Protokoll vermerkt). Zeigt der Wert einen positiven Wert an, obwohl das Haus Strom einspeist, ist die Vorzeichenkonvention invertiert - aktivieren Sie Netzstrom invertiert. Ist der Wert negativ und ist auch controller.totalTarget negativ, fordert der Controller Strom an, der vom Gerät jedoch verweigert wird: Prüfen Sie heads.<n>.device.ST (2 = läuft) und heads.<n>.battery.ON.
• Zwei Controller konkurrieren um die Batterie: Verwenden Sie nur einen. Der Adapter erzwingt MM für den ausgewählten Modus - deaktivieren Sie vor der Verwendung eines Steuermodus alle externen GS-Skripte (oder das geräteeigene MM mit einem anderen Zähler).
• Einige Zustände bleiben leer (0 / ""): Ein Gerät gibt nur die Felder zurück, die seine Firmware/Topologie tatsächlich bereitstellt (z. B. zusätzliche Pakete SC2-SC5 oder Fehlerbitmasken nur im Fehlerfall). Die vollständige Rohantwort ist immer in heads.<n>.info.rawResponse verfügbar.
• Nach dem Update von einer Single-Head-Version sieht die Baumstruktur fehlerhaft aus: Die Objektstruktur wurde in Version 0.2.0 in heads.<n>.* umstrukturiert. Der Adapter entfernt veraltete Objekte automatisch beim Start; falls noch Objekte vorhanden sind, löschen Sie diese (oder fügen Sie die Instanz erneut hinzu).
• Sporadische Verbindungsabbrüche / Ping-Timeouts: Das WLAN-Modul des Heads ist schwach, und durch das Stapeln der Einheiten befindet sich ein Metallgehäuse direkt über der Antenne. Überprüfen Sie heads.<n>.device.network.WR (Signalstärke in dB) - unter −75 dB wird die Verbindung unzuverlässig. Trennen Sie die gestapelten Einheiten und erhöhen Sie das Abfrageintervall auf 10-15 s (die Steuerungsqualität leidet kaum: Der Controller reagiert auf die Netzstromversorgung, nicht auf diese Abfrage). Um den Adapter als Fehlerquelle auszuschließen, stoppen Sie die Instanz und pingen Sie den Head einige Minuten lang an - wenn die Verbindungsabbrüche weiterhin auftreten, ist die Abfrage nicht die Ursache. Der Adapter selbst sendet pro Head und Intervall ein /read, versetzt mehrere Heads, schließt jede Verbindung nach Gebrauch und fährt nach fehlgeschlagenen Abfragen automatisch zurück.

Changelog

0.3.4 (2026-09-28)

• (Creekhail) New: a discharge floor kept by the controller itself. Firmware 1.1.5 can lock up at the moment a head cuts off discharging at its own floor (SI): the status LED turns red, the grid LED blinks, and the head refuses to charge — even from its own PV inputs — until it is disconnected from the grid; a restart over the API does not reliably clear it. The problem occurs with floors of 5, 10 and 30 % and without this adapter as well. With the new option the controller stops asking a head to discharge once its emptiest pack reaches the set value, above the head's own floor, so the head never reaches the point where it locks up. Measured on the emptiest pack because the packs of a head drift apart. Off by default; controller mode only.
• (Creekhail) Shorter help texts in the instance settings. Each field now shows one short line; the full explanation appears when you hover over the field, and a link under it opens the matching section of this README, so the details are reachable on a phone or tablet as well. The introductions above the sections are shortened too.

0.3.3 (2026-09-27)

• (Creekhail) Settings survive a head restart again. Firmware 1.1.5 does not keep values written through the local API: after a restart the head comes back with an older stored set, and with local mode on nothing else can change them. Found on a 500 PRO when a discharge floor raised to 10 % was back at 5 % after a restart; a test showed the same for the off-grid floor and the self-consumption mode. The head also falls back to that older set on its own at night, without a restart: at 03:00 it switched self-consumption mode off while running, which in device self-regulation would have ended the regulation for the rest of the night. The adapter now remembers the settings you make through it (SoC limits and hysteresis, inverter and grid output limits, the load-port switches) in heads.<n>.info.desiredSettings and writes them again when the head reports something else. On by default, with an option to turn it off; values set before this version are not known to the adapter, so set them once again. Firmware that keeps its settings sees no extra writes.

0.3.2 (2026-09-25)

• (Creekhail) Fixed: after a short head restart the controller could stop writing altogether. A head that reboots comes back with GS=0, and if it answers again before three polls have failed, it never leaves the control loop. The controller still believed its last setpoint was in place, and as long as its target held still — steady surplus, or a head refusing charge with the anti-windup pulling it back to the same step — nothing counted as due, so the storage sat idle in full sun until the load changed or the instance was restarted. A GS echo that differs from the commanded value now marks the head for a resend, whether a restart or a second writer caused it. The foreign value is still never adopted; the controller puts its own back. A zero echo is logged as a probable restart rather than blamed on a second controller.

0.3.1 (2026-09-21)

• (Creekhail) Fixed a blocker in 0.3.0: the instance configuration could not be saved. Heads 2 and 3 were marked invalid whatever was in them — including the empty fields a single-head installation leaves — and because those fields refuse to save while invalid, the whole settings page was stuck. The cause was a validator expression that ioBroker admin evaluated as a statement instead of a condition; it now returns its result explicitly. 0.2.10 was not affected.

0.3.0 (2026-09-21)

• (Creekhail) The heads' own SoC hysteresis is respected. A head that has reached its discharge floor (SI) does not accept power again until its charge has risen by SI1 above it, and the same applies at the top with SA/SA1. Without that, the controller kept commanding a head that was refusing — a stream of writes every few seconds, a setpoint that never took effect, and the other heads carrying a share that was silently missing. The share of a head that is held back is redistributed across the ones that can take it. The block is tracked from the reported charge alone, so it is set when a head reaches a limit and lifted when its charge leaves the band, whether or not the controller happens to be asking for power at that moment. A head whose charge is already inside a band when the adapter starts is assumed to be held there until it leaves it: from outside there is no way to tell whether the device has released it, and waiting costs a few percent of one battery while guessing wrong costs a continuous stream of writes the device ignores.
• (Creekhail) Fixed: a head with a lowered feed-in limit is no longer throttled when charging or supplying its own load. MG caps what a head puts into the grid; it says nothing about what it may draw or what its inverter may produce for the load port — the device takes up to 2400 W in either of those regardless. Using MG for all three left a 500, or a PRO whose owner had capped feed-in at 800 W, charging at a third of its rate with the surplus going to the grid, and unable to cover a load larger than its export cap.
• (Creekhail) A setpoint left on a head is not forgotten across a restart. A head has no setpoint timeout of its own: whatever GS was written last keeps being executed until something says otherwise, so a crash or a power cut could leave one charging or discharging at full power with nothing watching it. The adapter records that it has set one (info.gsOwned) before the first write goes out, neutralises the heads on the next start, and only clears the record once every head has confirmed — retrying from each head's own poll until it does.
• (Creekhail) Optional: the controller can steer the inverter limit (IS) alongside the grid setpoint — the discharge part of GS plus whatever the load port draws, capped to the PV power once the head has reached its discharge floor. Off by default; it is only useful with a load wired to the load port. It has its own write dead band, and the limit is handed back to the device maximum on failsafe and shutdown, so a stopped controller never leaves the inverter throttled.
• (Creekhail) New option "meter settling time" for meters that publish a fresh timestamp while the value still lags behind the physical change. Readings taken before the last setpoint write were already discarded — they describe the state before it — and this extends that window. A source whose clock runs behind this host no longer freezes the loop either: regulation falls back to one correction per 30 s and the log says why.
• (Creekhail) Field names and ranges checked against the manufacturer's own Home Assistant integration. Every field it exposes is covered here, with the same meaning and unit; the only deliberate differences are the daily energy counters (raw Wh as the API delivers them, where the integration converts to kWh) and the SoC limits SI/SA/SO, which stay at 1…100 % because the API calls its narrower figures recommended values, not device limits. The SoC hysteresis SI1/SA1 now accepts 0…100 % as it does there — a cap of 50 % here had been refusing settings the device accepts.
• (Creekhail) Manual writes to the control states are range-checked. A typo in a script (GS=99999, SI=150) no longer reaches the hardware. The ranges follow the device: IS is 1…2400 W on both models, while the two grid-tied output fields (GS, MG) drop to 800 W on a standard 500 as soon as a poll reports the model, just as the manufacturer's own integration does. What a head draws and what its inverter may produce stay at 2400 W on both.
• (Creekhail) Two states renamed for accuracy — the object ids are unchanged, so history and existing scripts keep working. control.IS was called "Max. grid feed-in / inverter output limit", which conflated the two limits the device keeps apart: it is the inverter output limit, while MG caps the grid feed-in. total.maxPower was "Total available power", but it sums MG and therefore says what the plant may put out, not what it may take in — now "Total grid-tied output limit".
• (Creekhail) All 57 Tasmota / BitShake meter subtypes are selectable. Thirteen were missing — every one of them a subtype whose power key is a term (power_in - power_out, (Pp - Pm) * 1000) rather than a plain field name, so meters like Siemens, eHZ, Metcom or AS1440 could not be configured for device self-regulation at all. The device evaluates the term itself; the adapter passes it through. Meter model names are also shown untranslated again in every language — the machine translation had turned Q3A into "Pytanie 3A" and eBZ into a chemical, so the entry a user was looking for was not findable.
• (Creekhail) controller.status reports one thing at a time: failsafe whenever anything is in failsafe, warn while a warning stands, ok otherwise. A head that answers but delivers no usable SoC data is neutralised and reported instead of being regulated on placeholder limits, and if no head is regulatable at all the controller goes to failsafe rather than looking healthy.
• (Creekhail) Fixed: selecting device self-regulation with more than one head no longer clears a meter binding. That combination is refused and the adapter falls back to monitoring — but it used to release the binding on the way, switching off the device's own regulation without anything taking over.
• (Creekhail) Heads are addressed the way you typed them, but compared normalised: 192.168.1.5, 192.168.1.5/ and http://192.168.1.5 are recognised as one device.
• (Creekhail) Robustness: an HTTP response that errors or closes mid-body can no longer leave a request hanging forever; a control cycle that throws is logged instead of taking the adapter down; requests to one head are serialised and stop at shutdown.

0.2.10 (2026-08-03)

• (Creekhail) Gentler on the heads' Wi-Fi: with two or three heads the adapter no longer polls them all in the same instant — each head now runs its own cycle, staggered by up to 1 s. After a failed poll that head is backed off (doubling up to 60 s) instead of being polled at full rate, which only added to the congestion that made it drop out. The other heads keep their own rhythm either way.
• (Creekhail) Every HTTP connection is closed after use (Connection: close, a dedicated connection pool per head). Node's default keeps a socket open for 5 s, which at a 5 s poll means permanently — a slot the head's ESP32 cannot reclaim if the close is lost on a weak link. Reads and writes to the same head are now serialized as well, so a control write no longer opens a second parallel connection while a poll is running, and all sockets are closed on unload.
• (Creekhail) The request timeout now covers the whole request instead of only the phase after a socket was assigned.
• (Creekhail) Admin: the poll interval carries a help text recommending 10–15 s for two or more heads or a weak Wi-Fi signal; new troubleshooting entry for sporadic head drop-outs.

0.2.9 (2026-08-02)

• (Creekhail) The controller now publishes what it actually sees: controller.gridPower is the house grid power the way the loop understands it (after the inverted option, >0 = draw) and is updated for every accepted value — even while the dead band suppresses any write, so "no value arrives" and "values arrive but nothing happens" are finally distinguishable. controller.totalTarget shows the total setpoint before it is split across the heads; a negative value means the controller wants to charge, so a storage that stays idle anyway is a device-side problem.
• (Creekhail) Fixed a silent standstill: if the configured grid-power source never delivered a single value (wrong state id, or a state written with ack=false), the controller sat at GS=0 forever without any warning — while control mode had already switched the device's own regulation (MM) off. Nothing regulated at all, and the status still read ok. The watchdog now escalates to failsafe after the configured failsafe time and logs the state id together with what to check.
• (Creekhail) A grid-power source that is written with ack=false is still ignored (an unacknowledged value must not drive the battery), but the adapter now warns once, names the state and points at both remedies instead of dropping every value silently.
• (Creekhail) Renamed total.gridPower to "Storage grid-port power, total" — it sums the storages' grid ports and was too easily mistaken for the house connection. The object id is unchanged, so history and existing scripts keep working.

0.2.8 (2026-07-29)

• (Creekhail) Support for control module firmware ES 1.1.14 (marketed by the manufacturer as "1.1.4"): the reinstated field PD is now exposed as heads.<n>.pv.PD — today's PV generation energy in raw Wh. Verified against a 500 PRO before and after the update: no field was removed and no control value was reset, so older firmware keeps working unchanged — the state simply stays empty where the device does not deliver PD.
• (Creekhail) Documentation: noted that the device's public firmware numbering differs from the internal one reported in ES (public 1.1.4 = internal 1.1.14) — feature availability is therefore detected by field presence, never by comparing version strings; and that the daily counters (PD/GD1/GD2/LD) are reset by the device on reboot, so a firmware update mid-day drops them to 0.

0.2.7 (2026-07-05)

• (Creekhail) New adaptive control (enabled by default): the controller regulates in three manufacturer-proven tiers — small deviations gently (every 7 s, 20 W steps), medium ones every 2.5 s (120 W), large load steps immediately (450 W), with a fixed 5 W dead band. Disable the new checkbox to keep tuning gain, dead band, write interval and step limit manually. Existing installations are switched to adaptive by this update (uncheck to return to your manual tuning).
• (Creekhail) Admin: help texts for gain, dead band and min. write interval; requires admin >= 7.8.23; CHANGELOG_OLD.md added and the Dependabot auto-merge workflow aligned with the canonical template (iobroker-bot).

0.2.6 (2026-07-04)

• (Creekhail) Controller: new target grid power (deliberate small draw or feed-in — e.g. +10 W to never feed in; the manufacturer's HA blueprint offers the same option) and a maximum adjustment per correction step (default 500 W) that allows a high gain without overshoot on meter spikes.
• (Creekhail) Documentation: corrected the setpoint-granularity statement — the device accepts GS with 1 W resolution (previously documented as 10 W steps); the practical accuracy limits are measurement-chain latency and meter noise.

0.2.5 (2026-07-02)

• (Creekhail) Review follow-up: added the manufacturer/product link to the README, and the controller now only accepts acknowledged grid-power values (ack=true) from the configured meter state (a manually written test value can no longer drive the battery).

0.2.4 (2026-07-02)

• (Creekhail) State names are now provided in all ioBroker languages: English and German stay hand-written, the other languages are machine-translated (generated file, merged at object creation; existing installations are updated in place).

0.2.3 (2026-07-02)

• (Creekhail) Object-tree compliance for the repository review:
  • The heads container is now a folder so the hierarchy follows the required device→channel→state order.
  • The switch states control.MM / LM / LFB / LPS / PM are now real booleans (previously 0/1 numbers) — adjust scripts that read or write them; the device still receives 0/1.
  • Corrected roles: GS/IS/MG use level, ups.UO uses value.
  • Object definitions are merged onto existing objects on start, so role/type/name updates reach existing installations (user settings like history configs are preserved).

0.2.2 (2026-07-02)

• (Creekhail) Repository-checker compliance: complete admin translations in all languages (including the validator messages), release notes translated into all languages, removed an unknown jsonConfig property from the test button and use the adapter-managed timer during unload.

0.2.1 (2026-07-01)

• (Creekhail) Controller robustness and hardening:
  • Config values of 0 are respected (gain / dead bands) instead of silently becoming defaults.
  • A failing GS write on one head no longer aborts the setpoints of the other heads.
  • Anti-windup: when a device visibly limits internally (SoC/temperature), the controller adopts the reported grid power as its feed-forward base.
  • GS is neutralized to 0 on all reachable heads when the controller stops (adapter stop/restart or leaving controller mode), so no head keeps executing a stale setpoint unwatched.
  • Heads are polled in parallel (one unreachable head no longer stretches the poll cycle); fewer state-DB reads per poll.
  • The startup object cleanup only touches adapter-managed subtrees; user-created states in the namespace survive.
  • Missing MG falls back to the model's power limit (500 → 800 W) instead of assuming a PRO; device responses are size-capped.
  • Manual GS writes are rejected (with a warning) while the controller is active; failsafe no longer retries offline heads every tick.
  • New unit tests for the controller (regulation, dead bands, throttling, failsafe, anti-windup).

0.2.0 (2026-06-30)

• (Creekhail) Multi-head support: manage up to three SunEnergyXT heads in one instance. The adapter controller now computes one grid setpoint and splits it across all online heads (equal split, gated by each head's SoC headroom, with per-head power caps and overflow redistribution). New per-head object tree heads.<n>.* and combined total.* aggregates; a "Test all heads" connectivity button; device self-regulation is restricted to a single head. The object tree was restructured — existing single-head instances should be re-created (delete the old objects / re-add the instance).

0.1.1 (2026-06-29)

• (Creekhail) Released via npm trusted publishing (provenance) and a package metadata fix.

0.1.0 (2026-06-28)

• (Creekhail) Initial release: local-API polling to states; writable control fields; two switchable control modes — an adapter-side self-consumption controller (any ioBroker meter state, feed-forward + P, with watchdog/failsafe) and device self-regulation (binds a supported meter: EcoTracker / Shelly 3EM / Shelly Pro 3EM / Tasmota); plus a monitoring-only mode, with an MM-mode guard.

License

MIT License

Copyright (c) 2026 Marcus Bortel (Creekhail) marcus@bortel.de

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.