PV-Multi-Speicher & Warmwasser mit Home Assistant

Inhalt

1. Ausgangslage & Problemstellung
2. Lösungsarchitektur (BEMS)
3. Dachanlagen-Integration (Modbus TCP)
4. Virtuelle Messtechnik & Sensorik
5. Hoymiles Cloud: AI-Modus & Zugriffsgrenzen
6. Aktorik & Automatisierungs-Logik
7. Warmwasser-Boiler (Solar-Hybrid)
8. Visualisierung & Dashboards
9. Troubleshooting & Stolperfallen
10. Rechtliches: Anmeldepflicht

1. Ausgangslage & Problemstellung

Im Gebäude existieren mehrere getrennte, herstellerinkompatible Photovoltaik- und Verbrauchssysteme, die zunächst vollständig autark und ohne gemeinsame Regelung betrieben wurden. Über einen zentralen Mini-Computer sollen sie zu einem intelligenten Energiemanagement verschmolzen werden.

• Dachanlage (Ampere.StoragePro E3 / FoxESS-Plattform): Hybrid-Wechselrichter mit fest verdrahtetem Chint DTSU666 Smart Meter über einen exklusiven RS485-Bus und internem Dachspeicher.
• Zusatzsystem (Hoymiles HMS-1600-4T mit 3x HiBattery 1920 AC, 5,76 kWh): aufgeteilt in Station „Turm“ (2x Akku, Phase A) und Station „Speicher 3“ (1x Akku, Phase B).
• Warmwasserboiler Keller (2.100 W): konventioneller Boiler, bisher ohne intelligente Steuerung.

Technische Restriktionen

Der Chint DTSU666 kommuniziert über Modbus RTU (9600 Baud, 8N1) im Master-Slave-Prinzip. Die Dachanlage beansprucht den RS485-Bus exklusiv als Master – ein paralleler Zugriff der Hoymiles-Hardware auf denselben Bus ist physikalisch unzulässig (Bus-Kollision, fehlende Mehr-Master-Fähigkeit).

Korrektur (Stand September 2026): Der Chint DTSU666 misst den Verbrauch und Netzaustausch des gesamten Hauses, nicht nur den Dach-Strang. Belegt durch die Ampere-App und eine Messung vom 04.09., bei der der 2,1-kW-Kellerboiler bei leeren Speichern mit bis zu 2.796 W als Netzbezug in sensor.ampere_storagepro_grid_power erschien. Frühere Dokumentationen behaupteten das Gegenteil – das war falsch.

Wichtig: Hoymiles blockiert Mehrphasen-Konfigurationen ohne eigenen Smart Meter. Sobald mehr als zwei HiBattery-Einheiten erkannt werden, erzwingt die S-Miles-Firmware eine Phasenaufteilung (Phase A: 2x Turm, Phase B: 1x Einzelspeicher) und meldet ohne zugeordneten Zähler den Fehler „Zähleraddition des Mehrphasensystems anormal“. Die Folge: beide Speicher liefen nur starr nach Uhrzeit statt nach realem Solarüberschuss.

Gesucht war daher ein Weg, die hochpräzisen Netzübergabedaten der Dachanlage für das Zusatzsystem nutzbar zu machen – ohne Eingriff in den RS485-Bus, ohne zusätzlichen Netzanalysator und ohne Änderung an der bestehenden Elektroinstallation. Aus dieser Ursprungslösung heraus ist im Lauf des Projekts die Warmwasser-Integration als weitere Säule hinzugekommen.

2. Lösungsarchitektur (BEMS)

Ein lokaler Dell Wyse 5060 Thin Client (AMD GX-424CC, x86_64) mit Home Assistant OS als Bare-Metal-Installation übernimmt die Rolle eines softwaredefinierten Smart Meters und der zentralen Master-Zentrale. Er liest die Netzübergabedaten der Dachanlage transparent über die Modbus-TCP-Bridge des Wechselrichters aus, errechnet daraus den echten physikalischen PV-Überschuss und steuert die Speicher und den Warmwasserboiler über Shelly-Aktorik. Zusätzliche Messtechnik entfällt vollständig – 0 € Zusatzhardware.

Server-Plattform

Bare-Metal-Installation (HAOS Generic x86_64)

1. BIOS/UEFI: Boot Mode UEFI, Secure Boot: Disabled, AC Power Recovery: Power On, SATA Mode AHCI.
2. Flashen: Über ein Ubuntu-Live-System das HAOS-Raw-Image direkt auf die interne SSD schreiben.

xz -dc haos_generic-x86-64-13.1.img.xz | sudo dd of=/dev/sda bs=4M status=progress conv=fsync

3. Erstinbetriebnahme: Aufruf über http://homeassistant.local:8123, Administrator-Konto anlegen, Zeitzone setzen.
4. Werkzeuge: Add-on Terminal & SSH installieren, anschließend HACS (Home Assistant Community Store) einrichten:

wget -O - https://get.hacs.xyz | bash -

Vollständige Hardware- & Schnittstellen-Übersicht

Netzwerk-Setup: FRITZ!Box im Keller (2,4 GHz Kanal 11), TP-Link AP im 1. Stock (2,4 GHz Kanal 1, Modus g+n, 20 MHz). Beide Kanäle fest eingestellt, um WLAN-Interferenzen zu vermeiden und stabile Shelly-Verbindungen zu gewährleisten.

Architektur-Übersicht

                    [ 3-Phasen Hausanschluss 230V/400V ]
                                        │
                          ┌─────────────┴─────────────┐
                          │   Chint DTSU666 (Zähler)   │
                          │   misst GESAMTES HAUS      │
                          └─────────────┬─────────────┘
                                        │ RS485 (Exklusiv-Bus)
                                        ▼
    [ Solardach 10+ kWp ] ──► [ Ampere.StoragePro E3 ]
                                        │ WLAN-Stick "espressif" (Modbus TCP, Port 502)
                                        ▼
    ┌───────────────────────────────────────────────────────────────┐
    │            HOME ASSISTANT (Dell Wyse 5060 – HAOS)             │
    │            = "Virtueller Smart Meter & Master-Zentrale"       │
    └──┬──────────────┬──────────────┬───────────────────────────────┘
       │ WLAN         │ WLAN         │ WLAN
       ▼              ▼              ▼
  [Shelly Speicher3] [Shelly Turm]  [Shelly Warmwasser]
       │              │              │
       ▼              ▼              ▼
  [HiBattery 1920]  [Turm 2x Akku  [Warmwasser-
   (Erdgeschoss)    + HMS-1600]     boiler 2,1kW]

    [ S-Miles Cloud API ] ◄── Telemetrie ── [Turm / Speicher 3]

Die 4-Stufen-Prioritätskaskade

Durch die intelligente Lastverschiebung geht nahezu kein Watt Solarstrom verloren. Die Prioritätenreihenfolge:

1. Direkter Hausgrundverbrauch (Kühlschrank, IT, Standby)
2. Ladung Dachspeicher & Hoymiles Turm (Phase A)
3. Ladung Speicher 3 (Phase B)
4. Warmwasser-Boiler als thermische Batterie (2.100 W)
5. Erst der unvermeidbare Rest wird ins Netz eingespeist

3. Dachanlagen-Integration (Modbus TCP)

Der Ampere.StoragePro E3 basiert auf der industriellen FoxESS-Plattform. Der WLAN-Kommunikationsstick (ESP32-basiert, Hostname espressif) stellt die Netzübergabedaten des Chint-Zählers als Modbus-TCP-Server bereit.

Verbindungsparameter

Port-Verifikation vor der Integration

python3 -c "import socket; s=socket.socket(); s.settimeout(2); print('PORT 502 OFFEN' if s.connect_ex(('IP_DES_ESPRESSIF_GERAETS', 502))==0 else 'NICHT ERREICHBAR')"

Erwartetes Ergebnis: PORT 502 OFFEN.

Integration via HACS

1. HACS → ⋮ → Benutzerdefinierte Repositories.
2. Repository dboeni/home-assistant-ampere-storage-pro-modbus (alternativ Sven0111/Ampere-StoragePro-E3), Kategorie Integration.
3. Herunterladen und Home Assistant Core neu starten.
4. Einstellungen → Geräte & Dienste → Integration hinzufügen → Ampere.StoragePro mit Host, Port 502 und Slave-ID 247 einrichten.

Sensor-Mapping & Vorzeichen-Konvention

⚠️ Wichtige Stolperfalle: sensor.ampere_storagepro_pv_flow ist kaputt – der Sensor liefert konstant den Wert 1 (ein Status-Flag, keine Leistung). Immer stattdessen den Template-Sensor sensor.dachanlage_pv_leistung verwenden, der pv1_power + pv2_power addiert.

Vorzeichen battery_power: Positiv = ENTLADEN. Diese Konvention ist nirgends dokumentiert und wurde empirisch durch SoC-Verlauf gegen Leistungswert bestimmt. Die Shelly-Sensoren der Hoymiles-Speicher zählen genau umgekehrt (positiv = laden). Wer hier rechnet, prüft das Vorzeichen zuerst.

4. Virtuelle Messtechnik & Mathematische Sensorik

Der physische Smart Meter liefert einen bidirektionalen Wirkleistungswert P_grid. Für die Regelung und das Energie-Dashboard sind zwei Schritte nötig: die mathematische Trennung in zwei disjunkte positive Kanäle (Überschuss / Bezug) und die zeitliche Integration zu kumulierten Kilowattstunden.

E = (1 / 3600000) · ∫ P(t) dt  [kWh]

Stufe 1 – Template-Sensoren für Momentanleistung (Jinja2)

template:
  - sensor:
      - name: "Aktueller PV Ueberschuss"
        unique_id: pv_surplus_watts
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set grid = states('sensor.ampere_storagepro_grid_power') | float(0) %}
          {% if grid < 0 %}
            {{ (grid * -1) | round(0) }}
          {% else %}
            0
          {% endif %}

      - name: "Aktueller Netzbezug"
        unique_id: grid_import_watts
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set grid = states('sensor.ampere_storagepro_grid_power') | float(0) %}
          {% if grid > 0 %}
            {{ grid | round(0) }}
          {% else %}
            0
          {% endif %}

      - name: "Dachanlage PV Leistung"
        unique_id: dachanlage_pv_leistung
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {{ (states('sensor.ampere_storagepro_pv1_power') | float(0)
            + states('sensor.ampere_storagepro_pv2_power') | float(0)) | round(0) }}

Hausverbrauch gesamt – korrigierte Formel

Der Template-Sensor sensor.hausverbrauch_gesamt berechnet den Live-Hausverbrauch aus allen drei Speichern nach einer einheitlichen Konvention: Laden herausgerechnet, Entladen als Quelle gezählt.

template:
  - sensor:
      - name: "Hausverbrauch gesamt"
        unique_id: hausverbrauch_gesamt
        unit_of_measurement: "W"
        device_class: power
        state: >
          {{ (states('sensor.dachanlage_pv_leistung') | float(0)
            + states('sensor.ampere_storagepro_battery_power') | float(0)
            + states('sensor.ampere_storagepro_grid_power') | float(0)
            - states('sensor.1_stock_shellyplugsg3_speicher3_leistung') | float(0)
            - states('sensor.turm_speicher_leistung') | float(0)) | round(0) }}

Was früher falsch war: Bis September wurden die Hoymiles-Speicher mit max(0, …) gerechnet – ihr Laden wurde als Hausverbrauch addiert, ihr Entladen ignoriert. Das ist die gegensätzliche Konvention zum Dachspeicher. Nachts fehlten dadurch mehrere hundert Watt (Kontrollrechnung: 707 W neu gegenüber 223 W nach alter Formel).

Einspeise-Sensoren für die Energiefluss-Karte

Die power-flow-card-plus modelliert individual-Einträge grundsätzlich als Verbraucher (Pfeil Haus → Gerät). AC-Speicher, deren Sensor beim Einspeisen negativ wird, werden dadurch falsch herum dargestellt. Lösung: je Speicher ein Template-Sensor mit nur dem Einspeise-Anteil plus inverted_animation: true.

template:
  - sensor:
      - name: "Turm Einspeiseleistung"
        state: >
          {{ max(0, -1 * states('sensor.turm_speicher_leistung') | float(0)) | round(0) }}
        unit_of_measurement: "W"

      - name: "Speicher 3 Einspeiseleistung"
        state: >
          {{ max(0, -1 * states('sensor.1_stock_shellyplugsg3_speicher3_leistung') | float(0)) | round(0) }}
        unit_of_measurement: "W"

Stufe 2 – Riemann-Summen-Integralsensoren (kWh)

Da der Ampere-Wechselrichter die Netz-kWh nicht nativ als Zähler bereitstellt, werden über den HA-Helfer Integralsensor hochpräzise kumulative Energiezähler erzeugt. Gewählt wird die Linke Riemannsche Summe (left): Bei abrupten Leistungsänderungen (Großverbraucher, Ladevorgänge) liefert sie die exakteste Energieakkumulation ohne Überschwingen.

Stufe 3 – Utility-Meter & Gestern-Ketten

An den Integralen hängen utility_meter mit cycle: none, die ausschließlich durch eine Automation um 10:00 Uhr zurückgesetzt werden. Diese schiebt gleichzeitig die Vortageswerte in input_number-Helfer weiter – eine Gestern-Kette für Warmwasser, mobilen Strommesser, Netzbezug und Netzeinspeisung. Die Template-Sensoren sensor.*_gestern sind bewusst ohne state_class angelegt (Anzeigewerte, keine Zähler).

⚠️ utility_meter beim Quellwechsel: Der Zähler behält seinen Zählerstand und übernimmt die neue Einheit → Faktor-1000-Fehler in der Langzeitstatistik. Nach jedem Quellwechsel utility_meter.reset aufrufen; Statistik-Korrektur per WebSocket-Command recorder/adjust_sum_statistics (Plural).

5. Hoymiles Cloud: AI-Modus & Zugriffsgrenzen

Der HMS-1600-4T kommuniziert per Sub-1-GHz-Funk, die HiBattery-Einheiten senden ihre Telemetrie per WLAN an die Hoymiles S-Miles Cloud. Die Anbindung erfolgt über die HACS-Integration Philra94/homeassistant-hoymiles-cloud (v1.3.0, zuvor v1.1.0), die sich über den Hoymiles-v3-OAuth/IAM-Endpunkt authentifiziert und beide Stationen automatisch als Geräte anlegt.

Aktiver Regler: AI-Modus (nicht TOU!)

Turm und Speicher 3 laufen im Hoymiles-AI-Modus, nicht in einem festen TOU-Programm. Belegt durch die Diagnose-Entitäten beider Stationen:

sensor.turm_ai_mode_status        = active
sensor.speicher_3_ai_mode_status   = active
sensor.turm_ai_compound_mode      = 3002
sensor.speicher_3_ai_compound_mode = 3002
binary_sensor.turm_ai_mode_active = on

Beobachtet wurde: Ladebeginn punktgenau 11:00 an beiden geprüften Tagen, Entladung bis zum Geräte-Floor von ~9 % gegen 04:00 – also weit über eine angebliche Fenstergrenze 23:59 hinaus. Was der Code 3002 bedeutet, ist nicht belegt; die Integrationsdokumentation kennt Mode 2 (Economy) und Mode 8 (Time of Use), aber keine vierstelligen Codes.

Die Preistabelle – Werkseinstellung erklärt das Verhalten

Die AI optimiert gegen eine Preistabelle, die auf Werkseinstellung steht (def: true). Die Einspeisevergütung ist 0,00 €. Bei null Vergütung ist gespeicherte Energie sofort verbraucht immer bares Geld wert und aufgehoben nie. Also fährt die AI die Speicher durch, bis sie leer sind, und hält bewusst nichts für den Morgen zurück. Das ist kein Fehler des Geräts, sondern die logische Antwort auf ein falsch hinterlegtes Preismodell.

Arbeitstag:  00:00-16:00 → 0,25 €   16:00-21:00 → 0,35 €   21:00-23:59 → 0,25 €
Wochenende:  00:00-16:00 → 0,25 €   16:00-23:59 → 0,35 €
Preisliste:  [0,46 / 0,35 / 0,25 / 0,05] €      Arbeitspreis p = 0,25 €   Steuer 19 %
Einspeisevergütung (sell price): 0,00 €

Kein Schreibzugriff – aber nicht aus Rechtegründen

Korrektur (08.09., v1.3.0): Die Aussage „der Account kann nur lesen" war im Ergebnis richtig, aber falsch begründet. Die neuen Diagnosefelder von v1.3.0 zeigen: Es ist keine Rechte- oder Eigentumsfrage, sondern die Produktklasse.

Der Befund: die API weist nichts ab, sie hat nichts. Pro Station und Endpunkt legt v1.3.0 offen, was der Abruf tatsächlich zurückgibt (device_fetch_status):

dtus / inverters / batteries / meters / microinverters
   → ok: true   status: "0"   message: "success"   total: 0

Kein Fehler, keine Rechteverweigerung – die API antwortet „erfolgreich" und liefert eine leere Liste. battery_settings und relay_settings melden folgerichtig readable: false, writable: false, Fehlertext „The device list is empty". Es gibt keine Einstellung, die verweigert wird; es gibt nichts, woran eine Einstellung hängen könnte.

Dazu die Anmeldekette: web_v3 und installer_v3 scheitern, nur home_v3 meldet sich an. Der Account ist ein reiner S-Miles-Home-Account. Für Stationen ohne registrierte Einzelgeräte ist die leere Geräteliste laut Changelog v1.2.1 der erwartete Zustand.

Konsequenz: Aus Home Assistant heraus ist an Turm und Speicher 3 nichts zu steuern. Die Regelung bleibt dauerhaft bei den Shelly-Steckern – das ist keine Übergangslösung mehr, sondern der Endzustand. Der Weg über den Verkäufer ist gegenstandslos, ein Test in der S-Miles-App unnötig.

Belastbare vs. unbelastbare Entitäten

⚠️ Die Hoymiles-Cloud liefert 62 Entitäten je Station (seit v1.3.0), viele davon dauerhaft unknown, 0.0 oder 0. Dazu gehören turm_pv_power, turm_grid_power, turm_load_power, turm_battery_power und sämtliche *_profit/*_spend. Nicht auf diese Werte regeln. Belastbar sind SoC, today_s_energy und seit v1.3.0 battery_charge/discharge_energy_today; alles Momentane kommt vom Shelly.

⚠️ grid_import_energy_today / grid_export_energy_today nicht ungeprüft verwenden. Sie stammen aus meter_b_in_eq / meter_b_out_eq der Cloud. Bei Speicher 3 passt die Lesart „AC-Bezug zum Laden" (1.837 Wh gegen 1.875 Wh BMS-Ladung am 08.09.), beim Turm ergeben 527 Wh Bezug für eine reine PV-Ladestation wenig Sinn. Bedeutung ungeklärt – vor einer Übernahme ins Energie-Dashboard mehrere Tage gegen die Shelly-Werte halten.

Cloud-Fehlwert: 0 % SoC jede Nacht um Mitternacht

Die Hoymiles-Cloud liefert den 0-%-SoC-Fehlwert jede Nacht um Mitternacht – gleichzeitig für Turm und Speicher 3, und länger als 4 Minuten anstehend. Am 06.09. hat er um 00:04:21 den Speicher-3-Stecker abgeschaltet, obwohl der Akku real bei ~37 % lag. Konsequenz: keine Abschaltlogik auf den Cloud-SoC stützen – siehe Kapitel 6.

Turm-PV: Ertragsprofil

Vormittags liefern die Turm-Module nur 20–80 W, während die Dachanlage bereits 4–8 kW macht. Der Sprung liegt bei 12:15 (Verschattung/Ausrichtung, keine Abregelung). Tagesertrag rund 3 kWh. Die Energie, die der Turm bewegen kann, ist durch seine eigenen Module begrenzt – dass er morgens leer ist, lässt sich durch keine Umtaktung beheben. Der Turm soll sich ausschließlich aus seiner eigenen PV laden, nie aus Hausnetz-Überschuss.

6. Aktorik & Automatisierungs-Logik

Zur physikalischen Leistungsfreigabe dienen mehrere Shelly Plus Plug S/Outdoor Gen3 Zwischensteckdosen (cloudunabhängiges WebSocket-RPC/CoIoT über WLAN). Home Assistant steuert die Hoymiles-Speicher ausschließlich über „Strom an / Strom aus" – was das Gerät mit dieser Freigabe macht (laden, entladen, nichts), entscheidet die Hoymiles-Cloud im AI-Modus.

Aktorik-Übersicht

⚠️ Geräte-Historie & Entitäts-IDs: Die Shelly-Stecker wurden mehrfach umgewidmet, die Entitäts-IDs behielten ihre alten Namen. So gehört sensor.1_stock_shellyplugsg3_turm_energie im Klartext zum Boiler, nicht zum Turm. Regel für neue Geräte: umbenennen, bevor die erste Referenz existiert.

8 aktive Automationen

1. Solar-Überschussladung Speicher 3

Periodischer 10-Min-Check, 3 Zweige: (1) SoC > 97 %, Fenster, Schalter an → aus; (2) Nachtfenster, Schalter fälschlich aus → an (Selbstheilung); (3) Ladefenster, Überschuss > 300 W, SoC < 98 %, Schalter aus → an (Flanken-Nachladung).

2. Turm – Sicherheitsnetz (umgedreht)

Der Turm-Stecker ist dauerhaft an; das Gerät regelt selbst über die Hoymiles-Cloud (AI-Modus). Die Automation ist ein reiner 10-Min-Check „Stecker aus → einschalten" (Selbstheilung nach WLAN-/Stromausfall). Es gibt keinen Abschaltpfad mehr. Bei unavailable passiert bewusst nichts. Für Wartungsarbeiten die Automation vorher deaktivieren.

Warum der Tiefentladeschutz entfernt wurde: Das Geräte-BMS begrenzt selbst bei 8–9 % SoC. Belegt am Turm: Dessen Stecker ist permanent an, HA hat nie eingegriffen – und der SoC bleibt bei 9 % stehen. Bilanz des HA-Schutzes: null verhinderte Tiefentladungen, mindestens zwei reale Fehlabschaltungen (05.09. Turm nach HA-Neustart, 06.09. 00:04 Speicher 3 bei real ~37 %). Ein Schutz, der nie schützt und regelmäßig stört, ist keine Vorsorge, sondern eine Fehlerquelle.

3. Warmwasser-Boiler Keller

Siehe Kapitel 7 für die detaillierte Beschreibung. Master-Schalter input_boolean.warmwasser_automatik ist derzeit bewusst AUS (seit 02.09.).

4. Wächter: Kernautomationen deaktiviert

Meldet, wenn eine der vier Kernautomationen länger als 5 Minuten nicht auf on steht (auch unavailable/ unknown). Entwarnt automatisch. Der 30-Minuten-Check ist das Sicherheitsnetz, falls der Zustandswechsel verpasst wurde.

{{ ['automation.solar_ueberschussladung_speicher_3',
    'automation.solar_ueberschuss_warmwasser_keller',
    'automation.turm_eigenverbrauch_sicherheitsnetz',
    'automation.waechter_einspeisung_nacht_drift']
   | reject('is_state','on') | list | count > 0 }}

Zwei Kanäle parallel: persistente Benachrichtigung (Protokoll, bleibt in der Glocke) und Push über notify.mobile_app_******* (Companion-App, Android). Wichtig: alert_once: true nicht entfernen – sonst piept der 30-Minuten-Check halbstündlich.

Warum automation.einspeisung_nacht_tarifumschaltung bewusst NICHT in dieser Liste steht: Ihr Ausfall meldet sich selbst. Bleibt die 23:00-Umschaltung aus, steht der Nachtzähler morgens auf null, und der Drift-Wächter meldet das als eigene Lage („keine Messung"). Die Liste deckt ab, was sonst niemand bemerkt – nicht alles, was neu ist.

5. Tageszähler-Reset um 10:00 Uhr

Läuft täglich um 10:00 und arbeitet strikt in dieser Reihenfolge: Warmwasser-Kette weiterschieben (vor_3_tagen ← vorgestern ← gestern ← Tageszähler), Strommesser-Kette, Netzbezug sichern, Netzeinspeisung sichern, dann utility_meter.reset auf alle Tageszähler. Die Reihenfolge ist die ganze Logik – alle input_number.set_value-Aktionen müssen vor dem Reset stehen.

6. Strommesser-Reset-Knopf

Setzt den Zähler sensor.aussen_strommesser_mobil_strommesser_verbrauch_seit_reset auf Knopfdruck zurück.

7. Einspeisung Nacht – Tarifumschaltung (neu 08.09.)

23:00  →  select.select_option  select.einspeisung_nacht = "nacht"
06:00  →  select.select_option  select.einspeisung_nacht = "tag"

Schaltet nur den Tarif des Zählers aus Kapitel 7 (Drift-Wächter) um. Keine Bedingungen, keine Zustandsprüfung. Das gemessene Fenster ist 00:00–06:00, nicht 23:00–06:00: Der Zähler läuft mit cycle: daily und setzt sich um Mitternacht selbst auf null; die 23:00-Umschaltung ist reiner Vorlauf, damit der Tarif zum Reset-Zeitpunkt schon richtig steht.

8. Drift-Wächter: Einspeisung Nacht (neu 08.09.)

Der eigentliche Wächter – vollständige Herleitung in Kapitel 7. Urteilt täglich um 06:05 (5 Min. nachdem der Wert eingefroren ist), plus Dauerwache auf > 3 kWh (greift nur im Defektfall). Drei choose-Zweige: (1) Tarif hängt (> 3 kWh → „Drift-Wächter defekt"), (2) Tagesurteil & Wert > 0,5 kWh → „Nachteinspeisung gestiegen", (3) Tagesurteil & not (numeric_state above 0.01) → „Wächter hat nicht gemessen". Trifft keiner zu, passiert nichts – der Normalfall ist Stille.

Push auf notify.mobile_app_*******, Android-Kanal PV Waechter mit importance: low, tag: einspeisung_nacht (ersetzt die Karte statt zu stapeln).

Produktions-Automatisierung (Speicher 3)

alias: "Solar: Ueberschussladung Speicher 3"
description: "Tag-Ueberschussladung & Nacht-Einspeisung – kein Tiefentladeschutz (BMS)"
mode: single
trigger:
  - platform: time_pattern
    minutes: "/10"
    id: "periodic_check"

  - platform: numeric_state
    entity_id: sensor.aktueller_pv_ueberschuss
    above: 300
    for:
      minutes: 1
    id: "einschalten_solar"

  - platform: state
    entity_id: input_boolean.zwangsladung_speicher_3
    to: "on"
    id: "zwangsladung_ein"

  - platform: state
    entity_id: input_boolean.zwangsladung_speicher_3
    to: "off"
    id: "zwangsladung_aus"

action:
  - choose:
      # Zweig 1: Volltag-Schutz
      - conditions:
          - condition: trigger
            id: "periodic_check"
          - condition: time
            after: "11:30:00"
            before: "19:00:00"
          - condition: numeric_state
            entity_id: sensor.speicher_3_battery_state_of_charge
            above: 97
          - condition: state
            entity_id: switch.1_stock_shellyplugsg3_speicher3
            state: "on"
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.1_stock_shellyplugsg3_speicher3

      # Zweig 2: Selbstheilung Nachtfenster
      - conditions:
          - condition: trigger
            id: "periodic_check"
          - condition: time
            after: "19:00:00"
            before: "11:30:00"
          - condition: state
            entity_id: switch.1_stock_shellyplugsg3_speicher3
            state: "off"
        sequence:
          - action: switch.turn_on
            target:
              entity_id: switch.1_stock_shellyplugsg3_speicher3

      # Zweig 3: Flanken-Nachladung
      - conditions:
          - condition: trigger
            id: "einschalten_solar"
          - condition: time
            after: "11:30:00"
            before: "19:00:00"
          - condition: numeric_state
            entity_id: sensor.speicher_3_battery_state_of_charge
            below: 98
          - condition: state
            entity_id: switch.1_stock_shellyplugsg3_speicher3
            state: "off"
        sequence:
          - action: switch.turn_on
            target:
              entity_id: switch.1_stock_shellyplugsg3_speicher3

      # Zwangsladung / Manuell
      - conditions:
          - condition: trigger
            id: "zwangsladung_ein"
        sequence:
          - action: switch.turn_on
            target:
              entity_id: switch.1_stock_shellyplugsg3_speicher3

      - conditions:
          - condition: trigger
            id: "zwangsladung_aus"
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.1_stock_shellyplugsg3_speicher3

7. Warmwasser-Boiler (Solar-Hybrid)

Der 2.100 W Warmwasserboiler im Keller wird über einen schaltbaren Shelly Plus Plug S Gen3 gesteuert. Die intelligente Hybrid-Steuerung kombiniert garantierte Grundversorgung mit kostenlosem Solar-Zuheizen und integriertem Dachspeicher-Schutz.

Warum die Automatik aus ist: Am 06.09. waren bis 14:00 bereits 8,23 kWh eingespeist (Dachertrag 46,8 kWh, Netzbezug 0 Wh), während der Boiler nur in den Festzeiten lief. Bewusste Entscheidung – der Dachspeicher wird geschont.

Speicher-Sollwerte & Über-Lieferung

Turm und Speicher 3 entladen mit festen Wattzahlen, die in der Hoymiles-App hinterlegt sind. Liegt der Sollwert über der Hauslast, geht die Differenz ins Netz. Erste Messung über drei Nächte (Fenster 20:00–07:00):

Selbst die vollen 0,17 kWh als vermeidbare Über-Lieferung sind rund 4 Cent pro Nacht, grob 15 € im Jahr. Eine Zweipunktregelung über die Shelly-Relais wurde deshalb verworfen – sie kostet Relaislebensdauer für Centbeträge.

Der Drift-Wächter (gebaut 08.09.)

Anstelle eines Reglers wurde ein Wächter gebaut – er regelt nichts, sondern schaut hin und meldet, wenn sich der Betrag verschiebt. Sein Zweck ist Merken, nicht Sparen.

Neumessung 08.09. – saubereres Fenster 00:00–06:00

Die Tabelle oben rechnet ab 20:00 und schleppt Dämmerungsstunden mit, in denen noch Rest-PV einspeist. Für die Frage „liefern die Speicher über?" ist 00:00–06:00 das sauberere Fenster – dort ist garantiert keine PV im Spiel. Neumessung aus der Langzeitstatistik:

Pro Stunde durchgehend 0,01–0,02 kWh, jede Nacht gleich – ein konstantes Rinnsal von rund 10–15 W. Das ist kein überlaufender Speicher: Das Haus sitzt nachts praktisch exakt auf dem Nullpunkt und kippt in Zehnerschritten mal auf die eine, mal auf die andere Seite. Hochgerechnet rund 3 kWh im Jahr – etwa ein Euro. Genau deshalb ist die Schwelle belastbar: 0,5 kWh ist das Sechsfache der Basis und kommt nicht durch Zufall zustande.

Aufbau: Tarif-Zähler statt Schnappschuss

Ein utility_meter „Einspeisung Nacht" mit Tarifen (cycle: daily, Reset um Mitternacht) zählt nur im Tarif nacht. Die Automation aus Kapitel 6 schaltet 23:00 → nacht und 06:00 → tag. Der Messwert sensor.einspeisung_nacht_nacht friert um 06:00 ein und bleibt bis Mitternacht ablesbar.

Warum kein Schnappschuss-Ansatz: Ein rechnender Entwurf (Zählerstand sichern, Differenz bilden) hängt daran, dass zwei Automationen acht Stunden auseinander in der richtigen Reihenfolge feuern. Fällt eine aus, kommt trotzdem eine Zahl heraus – eine plausibel aussehende, falsche. Der Tarif-Zähler rechnet nicht. Er zählt oder er zählt nicht. Kein Ausfall erzeugt eine glaubwürdige Fehlzahl.

Drei unterscheidbare Lagen

Alle drei Meldungen gehen auf den Android-Kanal PV Waechter mit importance: low (lautlos, keine Einblendung). Der Normalfall ist Stille – bei einer Basis von 0,07–0,09 kWh und einer Schwelle von 0,5 kWh soll dieser Wächter im Regelbetrieb nie etwas von sich hören lassen.

⚠️ Name und Wichtigkeit eines Android-Benachrichtigungskanals werden bei der allerersten Zustellung festgeschrieben. Eine spätere Änderung im HA-Config wird ignoriert; man muss den Kanal in den App-Einstellungen des Telefons von Hand löschen. Deshalb wurde der Kanal sofort mit einer Testmeldung angelegt und als zugestellt und lautlos bestätigt – nicht erst bei der ersten echten Meldung in einigen Wochen.

8. Visualisierung & Dashboards

Das Monitoring ist auf zwei spezialisierte Dashboards aufgeteilt, die unterschiedliche Betriebs- und Analyseaufgaben abdecken. Die Kartenanordnung richtet sich nach Nutzerpräferenz und Monitorgröße.

Dashboard 1: „Energieportal" (Haupt-Dashboard)

Das zentrale Dashboard mit drei Sections: „Energie" (Live-Energiefluss, Warmwasser-Kacheln, 24-h-Verlauf) und „Auswertung & Steuerung" (drei Batterie-Gauges, Tageswert-Tiles, Steuerungs-Zentrale mit Automationstoggles) sowie „Messstecker" (mobiler Strommesser).

# Karte: Live-Energiefluss mit korrigierter Flussrichtung
type: custom:power-flow-card-plus
title: "Live-Energiefluss"
entities:
  grid:
    entity: sensor.ampere_storagepro_grid_power
    name: "Stromnetz"
    invert_state: true
  solar:
    entity: sensor.dachanlage_pv_leistung
    name: "Dachanlage"
  battery:
    entity: sensor.ampere_storagepro_battery_power
    state_of_charge: sensor.ampere_storagepro_battery_percent
    name: "Dachspeicher"
    color_icon: true
  home:
    name: "Hausverbrauch"
  individual:
    - entity: sensor.turm_einspeiseleistung
      name: "Turm"
      icon: mdi:battery-high
      color_icon: true
      display_zero: true
      inverted_animation: true
      secondary_info:
        entity: sensor.turm_battery_state_of_charge
        unit_of_measurement: "%"
    - entity: sensor.speicher_3_einspeiseleistung
      name: "Speicher 3"
      icon: mdi:battery-medium
      color_icon: true
      display_zero: true
      inverted_animation: true
      secondary_info:
        entity: sensor.speicher_3_battery_state_of_charge
        unit_of_measurement: "%"
display_zero_lines:
  mode: grey_out
clickable_entities: true
use_new_flow_rate_model: true
w_decimals: 0
min_flow_rate: 0.75
max_flow_rate: 6

Flussrichtung korrigiert: Die power-flow-card-plus (v0.3.7) modelliert individual-Einträge als Verbraucher. Das beworbene Feature „Bidirectional Individual Entities" greift nicht. Lösung: Template-Sensoren mit nur dem Einspeise-Anteil (max(0, -1 * leistung)) plus inverted_animation: true. Beim Laden geht der Wert auf 0, die Linie wird ausgegraut – keine Information geht verloren.

Dashboard 2: „Statistik" (24h-Panel-Vollbild)

Große ApexCharts-Karte über die gesamte Bildschirmbreite mit 8 synchronen Datenreihen auf Dual-Y-Achsen (Watt links, Prozent rechts). Konfiguration in apexcharts_karte.yaml / dashboard_energie-analyse.yaml.

Energie-Dashboard (HA-intern)

Netz aus netzbezug_gesamt/ netzeinspeisung_gesamt, Solar aus Ampere + Turm, Batterien Ampere + Speicher 3.

9. Troubleshooting & Stolperfallen

Kurzcheck: Was tun, wenn…

Die wiederkehrenden Fehlerbilder

1. Hoymiles-Cloud liefert 0 % SoC als Fehlwert – jede Nacht um Mitternacht, gleichzeitig für Turm und Speicher 3, länger als 4 Minuten anstehend. Nie auf einen Einzelmesswert hin schalten. Konsequenz: gar keine SoC-abhängige Abschaltung mehr.
2. numeric_state sind Flanken-Trigger – sie feuern beim Überschreiten der Schwelle, nicht im Zustand. Wird die Schwelle vor Fensterbeginn überschritten und fällt danach nie darunter, kommt keine zweite Flanke. Jeder periodische Sicherheitscheck muss in beide Richtungen schalten.
3. utility_meter beim Quellwechsel – behält den Zählerstand, übernimmt die neue Einheit (Faktor 1000). Danach utility_meter.reset und ggf. recorder/adjust_sum_statistics.
4. Die meisten Hoymiles-Momentanwerte sind dauerhaft 0.0 oder unknown. Belastbar sind nur SoC und Tages-Energiezähler; alles Momentane kommt vom Shelly.
5. power-flow-card-plus modelliert individual-Einträge als Verbraucher. AC-Speicher werden falsch herum dargestellt. Lösung: Einspeise-Sensoren + inverted_animation.
6. Kein HA-seitiger Tiefentladeschutz für die Hoymiles-Speicher. Nicht wieder einbauen. Das Geräte-BMS begrenzt selbst bei 8–9 % SoC.
7. numeric_state-Bedingungen greifen bei unknown und unavailable NICHT – und schweigen dabei. Ein condition: numeric_state mit below: 0.01 trifft auf einen Sensor, der unknown liefert, schlicht nicht zu. Der Zweig läuft nicht – kein Fehler, keine Meldung, kein Trace-Eintrag. Wer damit einen Ausfall erkennen will, baut sich genau die Blindstelle ein, die er sucht. Richtig ist die Negation der Gegenrichtung: condition: not um ein numeric_state mit above: 0.01. Die trifft zu, wenn der Wert klein ist – und ebenso, wenn gar keiner da ist.

Betriebs-Checkliste (TL;DR)

• Speicher 3 Tag: Überschuss > 300 W (1 min), Fenster 11:30–19:00, SoC < 98 % → lädt.
• Speicher 3 Nacht: 19:00–11:30 bedingungslos eingeschaltet (kein Tiefentladeschutz).
• Turm: Stecker dauerhaft an, AI-Modus regelt selbst. Automation = Selbstheilung.
• Warmwasser: Feste Zeiten 04:45/10:25/14:00. Solar-Automatik derzeit AUS.
• Wächter: binary_sensor.kernautomation_deaktiviert = off = alles ok (überwacht 4 Automationen).
• Drift-Wächter: sensor.einspeisung_nacht_nacht steht ab 06:00 fest, Normalbereich 0,07–0,09 kWh. Stille = alles ok.
• Backup: Vor jedem Core-Update, vor Helfer-Löschung, vor Registry-Eingriffen.
• Vorzeichen-Merkregel: grid_power negativ = Einspeisung, positiv = Bezug. ampere_battery_power positiv = entladen. Shelly-Sensoren positiv = laden.

10. Rechtliches: Anmeldepflicht der Hoymiles-Anlage

Der Aufbau HMS-1600-4T + 3× HiBattery 1920 AC fällt nicht unter die vereinfachte Steckersolar-Regelung. Er ist anmeldepflichtig an zwei Stellen:

Warum der vereinfachte Weg nicht greift

Zwei voneinander unabhängige Gründe, jeder allein reicht aus:

• Leistungsgrenzen: Die Sonderregelung gilt nur bis 800 VA Wechselrichter und 2.000 W Modulleistung. Der HMS-1600-4T ist ein 1.600-VA-Gerät.
• Batteriespeicher (der härtere Grund): Das EEG kennt keine Ausnahmeregelung für Batteriespeicher bei Steckersolar-Geräten. Selbst ein auf 800 VA gedrosselter Wechselrichter würde am Speicher scheitern.

Kein Rechtsrat. Diese Zusammenfassung fasst öffentliche Aussagen von Bundesnetzagentur, Verbraucherzentrale und VDE zum Stichtag (06.09.2026) zusammen. Verbindlich ist der Netzbetreiber mit seinen technischen Anschlussbedingungen; im Zweifel dort oder bei einem Fachanwalt nachfragen.

Stand 08.09.2026: Die Anmeldung erfolgt am 09.09.2026. Zur Vorbereitung liefert die Cloud sensor.turm_reported_inverter_count = 2 und sensor.speicher_3_reported_inverter_count = 1 – die Geräteanzahl, die die Cloud je Station führt (insgesamt 3 Wechselrichtereinheiten).