Jackery SolarVault & SmartMeter 3P Integration repariert & erweitert! (Custom HACS Repository)

[csoscd]

Hallo zusammen,

falls ihr einen Jackery SolarVault 3 Pro Max Heimspeicher oder den Jackery SmartMeter 3P (HTO907A) nutzt, kennt ihr das Problem wahrscheinlich: Die offizielle Integration wurde seit Längerem nicht gepflegt. So ging es mir zumindest, als ich meine SolarVault 3 Pro Max mit HA verbunden habe.

Um das System wieder voll funktionsfähig zu machen, habe ich einen Community-Fork erstellt. Dieser modernisiert den Code, behebt die fehlerhafte Energiefluss-Berechnung und fügt wichtige neue Sensoren hinzu.

GitHub Repository: GitHub - csoscd/ha-solarvault · GitHub

Was wurde repariert & hinzugefügt?

• SmartMeter 3P Fix (HTO907A): Die originale Integration hat den SmartMeter fälschlicherweise als schaltbare Steckdose statt als CT-Meter klassifiziert, wodurch überhaupt keine Netz-Messdaten ankamen. Dieser Fork korrigiert das und stellt 16 dedizierte Sensoren pro SmartMeter bereit (Gesamt- & Phasen-Leistung (L1/L2/L3) für Import/Export sowie die kumulierten Energiewerte).
• Neue Sensoren für den SolarVault 3 Pro Max: Echtzeit-Sensoren (Datenabruf alle 10 Sekunden via MQTT) für Inverter-Stack-Eingangs-/Ausgangsleistung, korrekt skalierte BMS-SoC-Werte, Batteriestatus, WLAN/Ethernet-Diagnose sowie die konfigurierten Standby-Limits.
• Code-Modernisierung: Veraltete synchrone Setup-Muster (setup_platform) wurden auf moderne, asynchrone Methoden umgestellt, und veraltete Attribute wurden korrigiert, damit das Home Assistant Log sauber bleibt.

Installation via HACS

Ihr könnt die Integration ganz einfach als benutzerdefiniertes Repository in HACS hinzufügen:

1. Geht in HACS auf Integrationen, klickt oben rechts auf die drei Punkte und wählt Benutzerdefinierte Repositories.
2. Fügt die URL ein: https://github.com/csoscd/ha-solarvault und wählt als Kategorie Integration.
3. Sucht nach “Jackery SolarVault” und ladet die Integration herunter.
4. Startet Home Assistant neu.
5. Geht zu Einstellungen ➔ Geräte & Dienste ➔ Integration hinzufügen ➔ Sucht nach “Jackery” und gebt eure Seriennummer (SN) sowie das Token ein (zu finden in den MQTT-Einstellungen der Jackery-App).

(Hinweis: In der README des Repositories findet ihr auch ein fertiges YAML-Beispiel, um die neuen Sensoren direkt in die beliebte Energy Flow Card Plus auf eurem Dashboard einzubinden!)

Feedback & Hilfe

Wenn ihr einen SolarVault im Einsatz habt, testet den Fork gerne aus. Falls ihr auf Fehler stoßt oder Verbesserungsvorschläge habt, schreibt einfach hier in die Kommentare oder eröffnet ein Issue auf Github.

Ich hoffe, das hilft dem einen oder anderen, sein Energie-Dashboard wieder geradezurücken!

Viele Grüße
Christian

[csoscd]

Update: Weitere Bugfixes und neue Features

Kleines Update zum Repository, dass ich kurz zusammenfassen möchte.

---

Bugfixes

SmartMeter flappt alle ~11 Sekunden (Issue #16)

Wer den SmartMeter 3P nutzt, hat vielleicht bemerkt, dass er im laufenden Betrieb ständig kurz als nicht verfügbar auftaucht. Der Grund liegt in der Original-Integration: Der Cache für CT-Zähler (cts) wurde bei jedem eingehenden Type-101-MQTT-Ereignis überschrieben – auch wenn die Nachricht gar keine CT-Daten enthielt (z. B. eine Steckdosen-Abfrage). Dadurch wurde der SmartMeter-Eintrag im Cache alle ~11 Sekunden gelöscht und neu angelegt, was das Flapping verursacht hat.

Der Fix prüft jetzt, ob die Payload tatsächlich CT- oder Steckdosen-Daten enthält, bevor der jeweilige Cache-Eintrag aktualisiert wird.

Netzeinspeisung wird als 0 W angezeigt

Ein Berechnungsfehler führte dazu, dass gridSellPw (Netzeinspeisung) unter bestimmten Bedingungen fälschlicherweise mit 0 W ausgewiesen wurde, obwohl tatsächlich Strom ins Netz geflossen ist.

---

Neue Features

BP2500 Expansionsbatterie

Die BP2500 taucht in Type-23-MQTT-Nachrichten unter ihrer eigenen Seriennummer auf – unabhängig von der Haupteinheit. Die Integration wertet diese Nachrichten jetzt aus und stellt zwei kumulative Energiesensoren bereit:

• BP2500 Charge Energy – gesamte in die BP2500 geladene Energie (kWh)
• BP2500 Discharge Energy – gesamte aus der BP2500 entladene Energie (kWh)

Echtzeit-Leistungsdaten der BP2500 sind via MQTT leider nicht verfügbar; die sind nur über die Jackery-App / Cloud zugänglich.

Steuerung: SOC Force Charge Target

Das Feld socForceChg ist jetzt als beschreibbares Number-Entity (0–100 %) verfügbar. Der genaue Zweck ist noch nicht vollständig geklärt – die wahrscheinlichste Hypothese ist ein manueller Kraft-Ladezielsatz oder ein Backup-Reserve-Schwellwert. Bestätigt ist: Die Storm-Warning-Funktion in der Jackery-App setzt dieses Feld nicht.

Neue Energiesensoren (neuere Firmware)

Neuere Firmware-Versionen (ab 1.4) liefern zwei zusätzliche systemweite Energiezähler über Type-23-MQTT:

• CT Import Energy (inCtEgy) – kumulierte vom CT-Zähler gemessene Netzbezugs-Energie
• CT Export Energy (outCtEgy) – kumulierte vom CT-Zähler gemessene Netzeinspeis-Energie

Die Sensoren werden nur angelegt, wenn das Gerät diese Felder tatsächlich sendet – bei älterer Firmware tauchen sie schlicht nicht auf.

---

Automatisierte Tests

Die Integration hat jetzt eine Test-Suite mit 48 automatisierten Tests, die Energiefluss-Berechnungen, MQTT-Nachrichtenrouting und Sensor-Skalierungen abdecken – inklusive Regressionstest für den CT-Cache-Bug. Kein echter MQTT-Broker oder Home Assistant erforderlich; einfach uv run pytest tests/ -v im Repository-Verzeichnis ausführen.

---

[operator]

Danke für die Fixes, insbesondere für das Smart Meter! Gibt es irgendwo eine gute Beschreibung der >100 Entitäten von Jackery SolarVault 3 Pro + Jackery SmartMeter 3P zu finden?

Als Einsteiger bin ich völlig überfahren bei der Auswahl zw. den vielen, sehr ähnlichen Sensoren/Werten (bei Leistung & Energie) für ein simples Energie-Dashboard (Stromnetz, Heimspeicher, PV).

[csoscd]

Sehr berechtigte Frage – über 100 Entitäten für einen Speicher sind auf den ersten Blick erschlagend.
Hier eine strukturierte Erklärung, damit du weißt, welche Sensoren du wirklich brauchst:

---

Warum so viele Sensoren?

Die Integration bezieht Daten aus drei Quellen:

1. SolarVault – Gerätestatus alle ~11 s
2. SmartMeter 3P – Hausanschluss-Messung alle ~11 s
3. Energiezähler – kumulierte kWh-Werte alle ~10 min

Viele Sensoren existieren deshalb doppelt, weil SolarVault und SmartMeter denselben Wert aus unterschiedlicher Perspektive messen.

---

Die ~8 wichtigsten Sensoren für ein einfaches Dashboard

Leistung (W, Echtzeit):

HA-Entität	Bedeutung
Solarleistung	PV-Produktion gesamt
Hausverbrauchsleistung	Berechneter Heimverbrauch*
Netzbezugsleistung (gesamt)	Aktueller Netzbezug — SmartMeter-Wert
Einspeiseleistung (gesamt)	Aktuelle Einspeisung — SmartMeter-Wert
Ladeleistung Batterie	Akku wird geladen
Entladeleistung Batterie	Akku entlädt
Batterieladezustand	SOC in %

* Berechneter Wert aus Netz + PV − Akku − Einspeisung; wird auf ≥ 0 W begrenzt.

Energie (kWh) — für HA Einstellungen → Energie:

HA-Entität	Dashboard-Slot
Solarenergie	Solar-Produktion
Netzbezugsenergie (gesamt)	Netzbezug ← SmartMeter bevorzugen
Eingespeiste Energie (gesamt)	Rückspeisung ← SmartMeter bevorzugen
Geladene Energie (Batterie)	Batterie-Ladung
Entladene Energie (Batterie)	Batterie-Entladung

---

Das häufigste Verwirrungsthema: SolarVault vs. SmartMeter

Für Netz-Import/Export gibt es jeweils zwei Sensoren:

• Netzbezugsleistung (SolarVault-intern): misst nur den Stromfluss am eigenen Netzanschluss des SolarVault
• Netzbezugsleistung (gesamt) (SmartMeter): misst den tatsächlichen Netzbezug an der gesamten Hausanschlussleitung

→ Für das Energie-Dashboard immer den SmartMeter-Wert (gesamt) nehmen — der entspricht dem Ferraris-Zähler.

---

Die anderen ~90 Sensoren

• PV-Strings einzeln (PV1–PV4): nur relevant, wenn du die Strings separat auswerten möchtest
• Phasen L1/L2/L3: Detailauswertung pro Phase
• Energie-Flüsse (PV→Akku, Akku→Netz, …): für tiefergehende Auswertungen oder Sankey-Diagramme
• Diagnose & Konfiguration (WiFi-Signal, IP-Adresse, Status-Werte, Limits): technische Überwachung, Automationen

---

Ich habe den Bedarf nach einer formalen Entitäts-Dokumentation als Feature Request im Repository festgehalten:
➜ docs: Entity reference — which sensor to use for energy dashboards? · Issue #9 · csoscd/ha-solarvault · GitHub

Dort soll künftig eine Referenzseite entstehen, die genau diese Fragen beantwortet.
Fragen zu einzelnen Sensoren gerne hier oder direkt im Issue stellen!

[operator]

Kann es sein, dass die Energiewerte des Smart Meters, also Netzbezugsenergie & Einspeiseleistung, nicht saldiert sind? Die Daten im Energie-Dashboard verwirren und passen nicht zu den Tagesdifferenzen abgelesen direkt am Stromzähler.

[csoscd]

Ja, das ist tatsächlich so. Der SmartMeter 3P misst pro Phase getrennt — wenn L1 gleichzeitig Strom bezieht und L3 einspeist, zählt er beides separat. Ein klassischer Ferraris-Zähler reagiert dagegen auf die Summe aller drei Phasen und saldiert dabei automatisch. Das erklärt die Abweichung zur Tagesablesung am physischen Zähler, besonders bei Phasen-Ungleichgewicht.

Die Echtzeit-Leistungswerte tPhasePw und tnPhasePw sind übrigens bereits saldiert — das Problem betrifft nur die kumulativen Energiezähler aus den 10-Minuten-Updates.

Lösung für jetzt: Über den eingebauten HA-Helfer Riemann-Summen-Integration kannst du aus den saldierten Leistungswerten saldierte Energiewerte berechnen lassen:

• Helfer 1: Riemann-Summe von sensor.jackery_<SN>_ct_3phase_import_total → saldierte Netzbezugsenergie
• Helfer 2: Riemann-Summe von sensor.jackery_<SN>_ct_3phase_export_total → saldierte Einspeiseenergie

Diese Werte stimmen dann mit dem überein, was ein Ferraris-Zähler erfassen würde — und können direkt im Energy Dashboard verwendet werden.

Ich schaue mir das Thema weiter an und analysiere, ob und wie sich eine saldierte Darstellung direkt in der Integration umsetzen lässt.

[csoscd]

Ich habe das jetzt mit einem 24-stündigen Messtest (30.07. 22:52 – 31.07.) belegt. Kurze Zusammenfassung:

Was die Energiezähler wirklich messen

Die Sensoren grid_import_energy (tPhaseEgy) und grid_export_energy (tnPhaseEgy) summieren die Rohwerte aller drei Phasen ohne Saldierung:

▎ L1-Import + L2-Import + L3-Import = tPhaseEgy (Differenz nach 24h: 0,01 kWh = reiner Rundungsfehler)

Das ist kein Fehler der Integration, sondern das was die Jackery-Firmware in diese Felder schreibt.

Was das konkret bedeutet

Wenn deine Jackery auf L3 einspeist, während du auf L1 Strom beziehst, zählt der Energiezähler beides separat. In meinem Test hat das über ~24h zu einer Abweichung von 2,49 kWh geführt — genau diese Menge hat die Firmware einmal als Import und einmal als Export gezählt, obwohl sie sich beim Haushaltszähler weitgehend aufhebt.

Die korrekte Lösung: Riemann Sum Integration

Für saldierte Werte (also das, was dein Haushalts-Stromzähler zeigt und was zur Abrechnung relevant ist) empfehle ich den HA-Helfer „Riemann-Summen-Integration":

• Auf grid_import_power (tPhasePw) → saldierter Netzbezug
• Auf grid_export_power (tnPhasePw) → saldierte Netzeinspeisung

Die Leistungssensoren tPhasePw/tnPhasePw sind bereits saldiert (das hat die Jackery-Firmware korrekt implementiert). Der Riemann-Helfer integriert diese Werte über die Zeit und liefert damit ein gutes Abbild dessen, was dein Netzbetreiber misst.

Einschränkung: Der Helfer startet bei 0 und akkumuliert ab dem Zeitpunkt der Einrichtung — historische Werte aus der Vergangenheit können nicht nachberechnet werden.

Ich habe diese Einschränkung auch in der Dokumentation ergänzt. Eine mögliche künftige Verbesserung wäre, direkt in der Integration abgeleitete saldierte Energiesensoren anzubieten — das ist aber aufwändiger und steht noch nicht auf dem Roadmap.

[cookie_dent]

Zuerst einmal, vielen Dank für die tolle Arbeit, die offizielle Integration ist ja ziemliche Grütze, auch die App hat noch Luft nach oben.

Mein Problem ist, dass bei mir der Slider “Max. Einspeisegrenze” ohne Funktion ist.

Ich weis leider nicht, ob ich irgendwo noch irgendwas einstellen muss, damit er funktioniert.

Es ist dabei egal, auf welcher Position der Schalter “Max. Einspeiseleistung (OnGrid)” steht.

Ich kann diesen bei meiner Pro Max auf 800 oder 2500 W stellen, was einwandfrei funktioniert.

Bei der offizielle Integration VOR 2.0 war es möglich mit dem Slider zwischen 0 und 2500W zu regeln. Ich meine, das er bei der v2.0 verschwunden war, weshalb ich eigentlich ein Downgrade machen wollte.

Gibt es die Möglichkeit das zu fixen? Ich selbst bin als Anfänger noch ziemlich unbeholfen..

[csoscd]

Kurze Erklärung was die zwei Felder wirklich bedeuten — das hat jetzt ein Live-MQTT-Capture geklärt:

Max. Einspeiseleistung (OnGrid) (maxOutPw, Select 800/1200/2500 W): Begrenzt wie viel die SolarVault ins Hausnetz liefern darf. Das ist der Betriebsmodus-Schalter, direkt aus der App.

Max. Einspeisegrenze (maxFeedGrid, Slider): Begrenzt wie viel ins öffentliche Stromnetz exportiert werden darf — die klassische Einspeiseleistungsbegrenzung für den Netzbetreiber. Funktioniert nur sichtbar, wenn das Gerät gerade tatsächlich ins öffentliche Netz einspeist. Im Eigenverbrauch-Modus, wo der SmartMeter nahezu null Netto-Export misst, scheint der Slider wirkungslos — ist er aber nicht.

Unser Fehler: Der Slider war in der Integration fälschlicherweise auf 0–800 W begrenzt. Die App erlaubt 0–2500 W, der MQTT-Capture bestätigt das. Wir haben das gerade in v2.3.0 korrigiert.

Für dein Szenario: Wenn du aktiv ins öffentliche Netz einspeist (SmartMeter zeigt Netzeinspeisung > 0), wirst du den Slider jetzt in der korrigierten Version tatsächlich wirken sehen.

[cookie_dent]

Ich habe jetzt mal die v 2.3.0 installiert.

Zu aller erst: Ich nutze kein Smartmeter, weil mein Verteilerschrank eingeputzt ist und ich den zum Einbau eines SM herausbrechen müsste. Ich nutze 4 Shelly Plugs, das ist leider das Maximum, was Jackery zulässt. Ich arbeite ausschließlich im benutzerdefinierten Modus.

Der Slider geht jetzt bis 2500W, soweit OK, hat aber immer noch keinen sichtbaren Effekt. Der Slider der (älteren) offiziellen Version war in der Lage, die Einstellungen “Max. Einspeiseleistung” zu übersteuern, das kann er jetzt nicht mehr.

Beispiel:

Waschmaschinenplug zeigt 2000W Verbrauch, Einstellung von maxOutPw ist 800W → SV3 liefert 800W. Slider auf 1500W gezogen → SV3 liefert 1500W. Der Slider war auch in der Lage die “Standard-Ausgangsleistung” zu übersteuern. 200 oder 800W eingstellt, Slider auf 100W gezogen → SV3 liefert nur noch 100W.

Wenn ich jetzt 200 oder 800W in der App als Ausgangsleistung definiere und die Plugs melden einen Gesamtverbrauch von 200W, liefert die SV3 400 oder 1000W (die 1000 nur, sofern maxOutPwauf 2500W steht), die Ausgabeleistung wird also aufsummiert. Die 200 oder 800W laufen dabei dann immer ins öffentliche Netz, bzw. dienen mir dazu, Geräte zu versorgen, die nicht an einem Plug sitzen.

In der v2.3.0 sind verschiedene Werte durcheinander.

Der Sensor “batterie_nettoleistung” meldet unplausible Werte, die Powercard zeigt dadurch ebenfalls verrückte Werte an. Ich habe gerade z.B. eine PV Leistung von schlappen 400W, AC Dose zieht 100W, Hauslasten 200W, App sagt 100 Watt gehen in die Batterie, HA sagt: Batterie Ladeleistung Null. Geht ja schon mathematisch nicht auf. Gerade sagt die App, Batterie wird mit 50W geladen, HA sagt: wird mir 60W entladen….

Das scheint der gleiche Fehler zu sein, den ich schon beim offiziellen Jackery Rep (issue #25) bemängelt hatte.

[csoscd]

Danke für das ausführliche Feedback — das hilft wirklich weiter!

Batterie-Anzeige (0 W / falsche Werte): Das ist ein echter Bug, den ich reproduzieren und eingrenzen konnte. Die SolarVault schickt alle ~30 Sekunden auf meine Anfrage hin einen kompletten Systemstatus-Snapshot. Dieser Snapshot enthält auch Batterie-Leistungswerte — aber vom Zeitpunkt der Anfrage, nicht von jetzt. Dieser ältere Snapshot hat die aktuelleren Echtzeit-Messwerte (~11-Sekunden-Takt) überschrieben. Das erklärt genau das Muster das du beschreibst — kurzzeitig falsche oder auf null stehende Batterieleistung. Der Fix ist in v2.3.0-beta.4 enthalten — ich würde mich freuen wenn du die Version testen könntest.

Zum Slider ohne sichtbaren Effekt: Der neue Slider steuert die Einspeiseleistungsgrenze — also das Maximum an Leistung, das der SV3 ins öffentliche Stromnetz zurückschicken darf. Er greift nur dann, wenn dein SV3 tatsächlich gerade aktiv ins Netz einspeist. Falls du keine oder selten Netzeinspeisung hast, wirst du dort keinen Effekt sehen — das ist erwartetes Verhalten.

Zur Maximalen Netzausgangsleistung: Da schaue ich mir die Einstellmöglichkeiten noch einmal genau an — melde mich dazu.

Noch zwei kurze Fragen: Erscheinen deine vier Shelly Plugs in Home Assistant als eigene Entitäten mit Leistungswert? Und hast du den SV3 Pro oder Pro Max?

[cookie_dent]

Fangen wir beim System an, ich habe eine SV3 pro Max.

Die Shellys musste ich erst bei Shelly anmelden und für Jackery freigeben. Dann werden sie per Jackery App über “Geräte” verbunden und ins System hereingeholt. In HA tauchen sie dann unter “Verbundene Geräte” auf, also da, wo auch die Erweiterungsakkus stehen.

Die Plugs liefern dann Sensordaten Power und Energy und ich kann sie schalten.

Die Geräteinfos sehen dann so aus:

• Geräte-Informationen

  Sub-device Type 6

  von Jackery

  Verbunden über Jackery

Und jetzt der Batteriebug, der auch in der Beta 4 noch da ist:

Wie Du siehst, wird die Ladeleistung der Batterie falsch angezeigt.

AC Ausgang 89W, Hauseingang ist 30W über “Standard-Ausgangsleistung” + 35W Verbrauch den die Shellys melden = ca. 66W Leistung die über die “Netz AC-Ausgangsleistung” ins Haus geht.

PV Leistung ist 672W - 155W Verbrauch = 517W, die in die Batterie gehen. Die App zeigt das so auch an, HA meint aber, es werden nur 104W in die Batterie geladen. In dem Fall also eine Dikrepanz von 413W. Der Slider “Max. Einspeisegrenze” steht auf null, es werden auch nur die 30W ins “Netz/Haus” eingespeist. Ca. 25W Verbraucht mein Mini PC, auf dem HA läuft (sonst läuft aktuell im Hauch nichts), es ist also faktisch nahezu eine Null Einspeisung.

P.S. Ich logge die Ausgangsleistung zusätzlich am AC und Grid Ausgang mit 2 Plugs über VeSync, da mit der Anfangs Firmware von Jackery in der App verrückte Leistungswerte angezeigt wurden. Die ermittelten Werte sind nahezu deckungsgleich mit den Ausgangswerten die die SV3 Meldet. Die vermissten 413W werden also tatsächlich nirgens irgendwo eingespeist oder verbraucht.

Ich hoffe ich habe mich verständlich und hilfreich ausgedrückt.

[HaGoDo]

Wie genau lauten die von dir verwendeten Entitäten für Ladeleistung und Entladeleistung.

Ich habe eine Solar Vault 3 Pro Max AC und da werden die Werte korrekt angezeigt. Keine Diskrepanz zwischen App und HA.

Die zugehörigen Entitäten sind

sensor.kellerflur_jackery_battery_charge_power

sensor.kellerflur_jackery_battery_discharge_power

Version der Integration ist 2.0.2

[cookie_dent]

Ich habe derzeit die Version 2.3.0 Beta 4 drauf.

Die Entität ist die:

sensor.schuppen_jackery_batterie_nettoleistung

welche mit der v 2.2.0 noch die richtigen Werte ausgegeben hatte.

Die Entitäten die Du angibst, hatte ich bei der offiziellen Rep noch benutzt, evtl. wäre das eine Möglichkeit.

[csoscd]

Hallo cookie_dent,

vielen Dank für deinen detaillierten Bericht - der hat mir wirklich geholfen.

Zum Batterie-Bug: Du liegst vollständig richtig - allerdings ist es kein Bug der Integration, sondern ein Protokollproblem.

Ich habe das mit einem eigenen MQTT-Messexperiment bestätigt: Die SolarVault sendet batInPw ausschließlich mit der Ladeleistung der Haupteinheit. Die BP2500-Ladeleistung taucht im MQTT-Protokoll schlicht nicht auf - das Gerät liefert sie nicht. Die Integration hat bisher korrekt das weitergegeben, was die SolarVault sendet. Der irreführende Sensorname (“Battery Charge Power” statt “Main Unit Charge Power”) war mein Fehler.

Da sich am Protokoll nichts ändern lässt, habe ich die einzig mögliche Lösung umgesetzt: einen berechneten Sensor über die Energiebilanz - identisch mit deinem Workaround. Im Messexperiment ≤13 W Abweichung zur App-Anzeige.

Soeben veröffentlicht: v2.3.0-beta.5

Darin sind zwei neue berechnete Sensoren:

• sensor.jackery_{sn}_total_battery_charge_power
• sensor.jackery_{sn}_total_battery_discharge_power

Breaking Change: calc_battery_charge_power und calc_battery_discharge_power wurden entfernt - sie waren entweder identisch mit dem (falschen) Main-Unit-Wert oder nutzten intern eine fehlerhafte Fallback-Formel. Wer diese Sensoren in Automationen oder dem Energy-Dashboard verwendet, muss auf die neuen total_*-Sensoren umstellen.

Außerdem habe ich den Display-Namen von battery_charge_power auf “Main Unit Charge Power” geändert, damit die Semantik klar ist. Die Entity-ID bleibt unverändert.

Deinen Hinweis zur grid_export_power habe ich ebenfalls aufgegriffen: Der Sensor heißt jetzt “OnGrid AC Output Power” - du hattest völlig recht, dass der alte Name irreführend war.

Zur Frage Slider für “Maximale Netzausgangsleistung”:
Das schaue ich mir noch genauer an. Die App bietet 800 W / 2500 W als feste Optionen - ob Zwischenwerte tatsächlich vom Gerät akzeptiert und wirksam angewendet werden, muss ich noch verifizieren. Ich melde mich sobald ich das geklärt habe.

Schön zu hören, dass die Shelly Plugs bei dir funktionieren.

Viele Grüße

[cookie_dent]

Die Sensoren zeigen mit der Beta 5 das Richtige an.

Irgendwie dauert das mindestens einen Tag, bevor die neuste Version laden kann, obwohl sie schon angezeigt wird.