OpenCCU in Home Assistant: So habe ich Homematic, Shelly und Tasmota zusammengeführt

Seit Jahren laufen meine beiden Häuser mit OpenCCU auf einem Raspberry Pi. Dazu kommen Mosquitto als MQTT-Broker, Node-RED, ein paar Shellys, Tasmota-Steckdosen und einige ESP32-Eigenbauten. Das alles hat zuverlässig funktioniert, aber jedes Haus hatte seine eigene Oberfläche, und für fast jedes Gerät brauchte ich eine eigene App. Ich wollte eine gemeinsame App, mit der ich beide Häuser auch unterwegs über VPN steuern kann. In diesem Beitrag beschreibe ich, wie ich OpenCCU in Home Assistant eingebunden habe, ohne mein bestehendes System abzureißen, und an welchen Stellen ich hängen geblieben bin.

Ich habe den Umstieg Schritt für Schritt dokumentiert, so wie er bei mir abgelaufen ist, mit allen Umwegen. Wenn Du vor einem ähnlichen Umstieg stehst, findest Du hier die Reihenfolge, die bei mir funktioniert hat, und die Fehler, die Du Dir sparen kannst.

Kurz zusammengefasst: OpenCCU bleibt als Funkzentrale auf dem alten Raspberry Pi. Home Assistant läuft parallel auf einem Raspberry Pi 5 und bindet die CCU über die Integration „Homematic(IP) Local for OpenCCU“ ein. MQTT, Tasmota, Shelly, eine KI-Wasseruhr und das Energie-Dashboard kamen danach dazu. Den Fernzugriff löse ich mit WireGuard über die FRITZ!Box.

Warum ich von OpenCCU auf Home Assistant umgestiegen bin

OpenCCU (früher RaspberryMatic) ist eine sehr stabile Zentrale für Homematic und Homematic IP. Für Funkgeräte, Heizungssteuerung und Zentralenprogramme hatte ich nie einen Grund zur Klage. Mit der Zeit kamen aber immer mehr Geräte dazu, die nicht aus der Homematic-Welt stammen: Shelly für die Strommessung, Tasmota für Steckdosen, eigene ESP32-Projekte, ein Balkonkraftwerk und bald ein EcoFlow-Speicher. Jedes davon hatte seine eigene App oder Weboberfläche.

Dazu kommt, dass ich zwei Häuser habe, eins davon im Ausland. Beide sind per LAN-zu-LAN-VPN zwischen den FRITZ!Boxen verbunden, aber eine gemeinsame Bedienoberfläche gab es nicht. Home Assistant löst genau das: Die App kann mehrere Server verwalten, und für fast jedes Gerät gibt es eine fertige Integration.

Mir war wichtig, dass ich jederzeit zurück kann. Deshalb habe ich Home Assistant nicht anstelle von OpenCCU installiert, sondern daneben.

Meine Architektur: Home Assistant neben OpenCCU

Bevor ich irgendetwas installiert habe, habe ich mir drei Grundsatzentscheidungen überlegt.

Jedes Haus bekommt eine eigene Instanz

Technisch hätte ich beide CCUs in eine einzige Home-Assistant-Instanz einbinden können, weil die Netze über VPN gekoppelt sind. Das habe ich bewusst nicht gemacht. Fällt das Internet oder der Tunnel aus, würden im entfernten Haus keine Automationen mehr laufen, und Homematic-Rückmeldungen über eine lange Strecke sind nicht zuverlässig. Deshalb steht in jedem Haus ein eigener Home Assistant. In der App wechsle ich mit einem Tipp zwischen beiden.

OpenCCU bleibt die Funkzentrale

Es gibt ein OpenCCU-Add-on für Home Assistant. Bei einem Funkmodul auf der GPIO-Leiste, wie dem RPI-RF-MOD, braucht man dafür aber Kerneltreiber, die Home Assistant OS nicht mitbringt. Außerdem hingen dann Funkzentrale und Home Assistant an einem Gerät. Ich habe OpenCCU deshalb auf dem bestehenden Pi gelassen. Home Assistant spricht die CCU über das Netzwerk an, und meine Zentralenprogramme laufen unverändert weiter.

Ein Raspberry Pi 5 mit NVMe

Ich hatte noch mehrere Raspberry Pi 5 mit NVMe-HAT aus anderen Projekten übrig. Für Home Assistant ist das eine gute Basis. Eine SD-Karte würde ich für den Dauerbetrieb nicht nehmen, weil die Datenbank ständig schreibt.

Was ich für den Umstieg gebraucht habe

• einen Raspberry Pi 5 mit Netzteil, NVMe-HAT und einer kompatiblen M.2-NVMe-SSD (übergangsweise ging es mit einem USB-Stick)
• die bestehende OpenCCU mit Funkmodul, unverändert
• eine FRITZ!Box mit USB-Speicher für die Backups
• einen kostenlosen GitHub-Account für HACS
• am PC den MQTT Explorer, am Handy die Home-Assistant-App und die WireGuard-App

Für die Grundeinrichtung mit OpenCCU, Backups und MQTT solltest Du einen halben Tag einplanen. Wasseruhr, Energie-Dashboard und Fernzugriff haben bei mir zusammen noch einmal so lange gedauert, vor allem wegen der Fehlersuche.

Mein Tipp: Gib beiden Häusern von Anfang an unterschiedliche IP-Netze, zum Beispiel 192.168.[X].0/24 und 192.168.[Y].0/24. Nur dann lassen sich die Netze später per VPN koppeln, ohne dass Adressen doppelt vorkommen.

Schritt 1: Home Assistant auf dem Raspberry Pi 5 installieren

Das Image habe ich mit dem Raspberry Pi Imager geschrieben. Home Assistant OS findest Du dort unter „Other specific-purpose OS“ und „Home assistants and home automation“. Die offizielle Anleitung steht auf home-assistant.io.

Gleich am Anfang lief etwas nicht wie geplant: Die M.2-SSDs, die ich noch hatte, liefen nicht mit meinem PCIe-HAT. Ich habe neue SSDs bestellt und Home Assistant in der Zwischenzeit auf einem USB-Stick gestartet. Der spätere Umzug auf die NVMe ist kein Problem: Backup erstellen, Home Assistant OS frisch auf die SSD schreiben und beim Onboarding „Aus Backup wiederherstellen“ wählen.

Danach habe ich den Pi per LAN angeschlossen, in der FRITZ!Box eine feste DHCP-Reservierung vergeben und das Onboarding unter http://homeassistant.local:8123 durchlaufen.

Schritt 2: Backups auf die FRITZ!Box

Bevor ich irgendetwas eingerichtet habe, wollte ich eine funktionierende Datensicherung. Home Assistant kann Backups direkt auf eine Netzwerkfreigabe schreiben. Bei mir ist das ein USB-Speicher an der FRITZ!Box.

Hier habe ich zuerst einen Denkfehler gemacht. Ich hatte die Adresse der NAS-Weboberfläche aus dem Browser kopiert. Home Assistant braucht aber die Windows-Freigabe (SMB), und die hat eine andere Adresse. Ob SMB läuft, testest Du am Windows-PC im Explorer mit \\[IP-FRITZBOX]. Im Browser funktioniert dieser Test nicht, dort kommt nur eine Fehlerseite.

Im Explorer sah ich dann die Freigabe fritz.nas. Darin liegen die Ordner Bilder, Dokumente, Musik und Videos. Die gehören zum kleinen internen Speicher der Box. Mein USB-Speicher heißt [NAME-USB-SPEICHER], und dort habe ich den Ordner HA-Backup angelegt.

In Home Assistant habe ich unter Einstellungen, System, Speicher einen Netzwerkspeicher hinzugefügt:

• Verwendung: Backup
• Server: [IP-FRITZBOX]
• Typ: Samba/Windows (CIFS)
• Remote-Freigabe: fritz.nas/[NAME-USB-SPEICHER]/HA-Backup
• Benutzer: ein eigener FRITZ!Box-Benutzer mit dem Recht „Zugang zu NAS-Inhalten“

Anschließend habe ich unter Einstellungen, System, Backups ein tägliches automatisches Backup eingestellt und die FRITZ!Box als Speicherort angehakt. Wie viele Backups Du aufbewahrst, hängt vom Platz auf Deinem USB-Speicher ab. Ein bis zwei Wochen sind ein guter Anfang. Danach habe ich einmal von Hand ein Backup ausgelöst und im Explorer geprüft, ob die Datei im Ordner ankommt.

Schritt 3: OpenCCU für Home Assistant vorbereiten

Bevor Home Assistant auf die CCU zugreifen darf, habe ich in OpenCCU ein paar Dinge eingestellt. Zuerst ein Backup als .sbk-Datei, danach:

1. Einen eigenen Benutzer für Home Assistant mit Administratorrechten. Das Passwort sollte keine Sonderzeichen wie &, % oder # enthalten, die machen in manchen Schnittstellen Ärger.
2. In der Firewall-Konfiguration die „Homematic XML-RPC API“ und die „Remote Homematic-Script API“ auf „Eingeschränkt“.
3. Bei den IP-Adressen für den eingeschränkten Zugriff das Heimnetz eingetragen.
4. Den Mediola-Zugriff auf „Kein Zugriff“ gestellt, weil ich Mediola nicht nutze.

In meiner IP-Liste steckte ein Fehler, der mir bis dahin nicht aufgefallen war: Zwei Einträge klebten ohne Semikolon aneinander. Die Einträge müssen mit ; getrennt sein. Bei mir sieht die Liste jetzt so aus:

192.168.0.0/16;
fc00::/7;
fe80::/10

Der Eintrag 192.168.0.0/16 deckt beide Häuser ab, weil beide Netze im Bereich 192.168.x.x liegen.

Stolperstein: 401 Unauthorized in RedMatic

Ich hatte gleichzeitig die Authentifizierung in OpenCCU eingeschaltet. Kurz darauf meldete Node-RED (bei mir RedMatic auf der CCU) „getRegaPrograms Error: 401 Unauthorized“. In den Einstellungen der CCU-Verbindung von RedMatic steht, dass es die Geräteschnittstellen intern ohne Zugangsdaten erreicht. Die Abfrage der Programme und Systemvariablen läuft aber über die ReGa-Logikschicht, und die verlangt nach dem Einschalten der Authentifizierung offenbar eine Anmeldung. Wenn Du RedMatic nutzt, schalte die Authentifizierung testweise wieder aus und starte die Flows neu. Verschwindet die Meldung, kennst Du die Ursache. Weil die Firewall den Zugriff ohnehin auf das Heimnetz begrenzt, ist es aus meiner Sicht vertretbar, die Authentifizierung auszulassen, solange RedMatic noch läuft.

Schritt 4: OpenCCU in Home Assistant einbinden

Die Integration, die ich verwende, heißt „Homematic(IP) Local for OpenCCU“. Sie wird nicht über den normalen Integrationsdialog installiert, sondern über HACS, den Home Assistant Community Store.

HACS installieren

Ich habe das Add-on „Terminal & SSH“ installiert und im Terminal den Installationsbefehl aus der HACS-Dokumentation ausgeführt:

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

Nach einem Neustart habe ich die Integration HACS hinzugefügt und mit meinem GitHub-Konto verbunden. Ein kostenloser Account genügt.

Eine Sache hat mich dabei kurz aufgehalten: Viele Anleitungen sagen, dass Du im Benutzerprofil den „Erweiterten Modus“ einschalten sollst. In meiner Version gab es den Schalter nicht mehr. Ich habe ihn auch nicht gebraucht.

Die Integration einrichten

In HACS habe ich nach „Homematic“ gesucht. Die Integration heißt in der Liste etwas verkürzt „Homematicip Local“, in der Beschreibung steht „connects to OpenCCU“. Nach dem Herunterladen und einem Neustart konnte ich sie unter Einstellungen, Geräte & Dienste hinzufügen. Den Quellcode und die Dokumentation findest Du auf GitHub.

Die alte, eingebaute Integration „HomeMatic“ solltest Du nicht verwenden. Sie wird nicht mehr weiterentwickelt.

Im Dialog habe ich Folgendes eingetragen:

• Instanzname: [HAUS-1], kurz und klein geschrieben. Den Namen solltest Du später nicht mehr ändern.
• Host: [IP-OPENCCU]
• Benutzer und Passwort: der Home-Assistant-Benutzer aus der CCU
• TLS: aus

Bei den Schnittstellen habe ich Homematic IP, Homematic (BidCos-RF), Heizgruppen und CUxD eingeschaltet. Wired und CCU-Jack nutze ich nicht. Nach ein bis zwei Minuten standen 22 Geräte mit rund 870 Entitäten in Home Assistant, sortiert nach den Räumen aus der CCU. Auch die CUxD-Geräte waren dabei, zum Beispiel meine Ping-Abfragen für die Handys.

Mein Tipp: Teste nach der Einrichtung drei Dinge: einen Messwert ablesen (Thermometer), etwas schalten (Steckdose oder Thermostat) und eine Rückmeldung abwarten (Fenster öffnen). Wenn alle drei funktionieren, ist die Verbindung in beide Richtungen in Ordnung.

Schritt 5: Mosquitto und MQTT anbinden

Mein MQTT-Broker läuft auf der OpenCCU, anonym und ohne Passwort. Den habe ich vorerst gelassen, damit ich nicht alle Geräte gleichzeitig umstellen muss. Sicher ist das nur, solange der Broker aus dem Internet nicht erreichbar ist. Langfristig ziehe ich ihn in Home Assistant um und richte dabei Benutzer und Passwort ein. Home Assistant verbindet sich als zusätzlicher Client: Server [IP-OPENCCU], Port 1883, Benutzer und Passwort leer.

Beim ersten Versuch hatte der Browser automatisch ein gespeichertes Passwort in das Passwortfeld eingetragen, obwohl der Benutzername leer war. Bei einem anonymen Broker muss das Feld leer bleiben.

Um zu sehen, welche Geräte überhaupt per MQTT senden, habe ich den MQTT Explorer installiert. Er zeigt alle Topics als Baum. Bei mir kamen dabei zum Vorschein:

• tele/, stat/ und cmnd/ von zwei Tasmota-Geräten
• tasmota/discovery/ mit den Erkennungsdaten
• solaranzeige/ von der Software Solaranzeige auf einem weiteren Raspberry Pi
• ein alter Eintrag tele/tasmota, der nur noch „LWT = Online“ enthielt

Der letzte Eintrag ist vermutlich ein Überbleibsel: Wahrscheinlich hieß eines meiner Tasmota-Geräte bei der Ersteinrichtung „tasmota“ und wurde später umbenannt, und der Broker hat die gespeicherte Nachricht unter dem alten Namen behalten. Prüfen kannst Du das, indem Du einige Minuten wartest. Tasmota sendet standardmäßig alle fünf Minuten ein STATE. Kommt unter dem Topic nichts Neues an, kannst Du den Eintrag im MQTT Explorer löschen.

Schritt 6: Tasmota-Geräte automatisch erkennen lassen

Für Tasmota gibt es eine eigene Integration in Home Assistant. Damit die Geräte automatisch auftauchen, habe ich in der Konsole jedes Geräts diesen Befehl eingegeben:

SetOption19 0

Die Antwort {"SetOption19":"OFF"} sah für mich zuerst nach einem Fehler aus, ist aber richtig. „OFF“ heißt hier, dass das Gerät die Erkennung für die Tasmota-Integration nutzt. Danach schickte Tasmota eine ganze Reihe leerer Nachrichten an homeassistant/.../config. Auch das ist gewollt: Das Gerät räumt damit die alte Erkennungsmethode weg. Mehr dazu steht in der Tasmota-Dokumentation.

Kurz danach standen beide Geräte in Home Assistant, darunter der Sonoff, der die Leistung meines Balkonkraftwerks misst. Dabei habe ich auch gemerkt, dass die Solaranzeige-Software denselben Sonoff alle zwei Sekunden abfragt. Home Assistant bekommt die Daten jetzt direkt, deshalb kann ich den zusätzlichen Raspberry Pi irgendwann abschalten.

Schritt 7: FRITZ!Box und weitere Integrationen

Home Assistant hat von selbst eine ganze Reihe von Geräten im Netz gefunden. Eingebunden habe ich die FRITZ!Box Tools, weil sie die WLAN-Geräte für die Anwesenheitserkennung liefern. Beim ersten Versuch kam nur „Unknown error occurred“. Ich habe daraufhin in der FRITZ!Box zwei Einstellungen ergänzt, danach lief die Einrichtung durch:

• Der Benutzer für Home Assistant braucht zusätzlich das Recht „FRITZ!Box Einstellungen“.
• Unter Heimnetz, Netzwerk, Netzwerkeinstellungen müssen „Zugriff für Anwendungen zulassen“ und „Statusinformationen über UPnP übertragen“ aktiv sein.

Den FRITZ!Repeater, UPnP/IGD und den DLNA-Mediaserver habe ich ignoriert. Die Geräteverfolgung läuft im Mesh ohnehin über die FRITZ!Box.

Schritt 8: Node-RED als Add-on in Home Assistant

Mein Node-RED lief bisher als RedMatic auf der OpenCCU. Ich wollte es mit Home Assistant verbinden und habe dafür den Node „node-red-contrib-home-assistant-websocket“ installiert. URL und Token waren korrekt, trotzdem blieb der Node bei „connecting“ stehen. Im Protokoll von Home Assistant kam nicht einmal ein Anmeldeversuch an.

Woran es lag, habe ich nicht herausgefunden. RedMatic brachte bei mir ein aktuelles Node-RED mit, an der Version lag es also nicht. Statt lange weiterzusuchen, habe ich Node-RED als Add-on in Home Assistant installiert. Dort ist die Verbindung zu Home Assistant bereits eingerichtet, ein Token ist nicht nötig. RedMatic läuft parallel weiter, bis ich alle Flows umgezogen habe.

Beim Add-on habe ich ein credential_secret gesetzt, SSL ausgeschaltet und Watchdog sowie „In Seitenleiste anzeigen“ aktiviert. Automatische Updates habe ich ausgeschaltet, weil ein großer Versionssprung auch mal einen Flow durcheinanderbringen kann.

Mein Tipp: Einen langlebigen Zugriffstoken für Home Assistant solltest Du wie ein Administratorpasswort behandeln. Kopiere ihn direkt an die Stelle, an der er gebraucht wird, und nirgendwo sonst hin. Tokens, die Du nicht mehr brauchst, löschst Du im Profil unter Sicherheit.

Schritt 9: Die KI-Wasseruhr mit AI-on-the-edge

Mein Wasserzähler wird von einer ESP32-CAM mit der Firmware AI-on-the-edge abgelesen. Die Kamera fotografiert den Zähler und erkennt Ziffern und Zeiger mit einem kleinen neuronalen Netz. Dieser Teil hat mich mit Abstand am meisten Zeit gekostet.

MQTT richtig einstellen

In der Wasseruhr war MQTT schon aktiv, allerdings mit der IP-Adresse von Home Assistant als Broker. Dort läuft aber kein Broker. Die richtige Einstellung bei mir:

• URI: mqtt://[IP-OPENCCU]:1883
• Main Topic und Client ID: wasseruhr
• Retain Messages: an
• Homeassistant Discovery: an
• Meter Type: Watermeter (m³). Das Häkchen links daneben muss gesetzt sein, sonst ist das Feld ausgegraut.

Danach erschien die Wasseruhr als Gerät in Home Assistant. Der Zählerstand blieb aber auf „Unbekannt“.

Rate too high und Neg. Rate

Die Diagnose zeigte „Rate too high“. Der gespeicherte Vorwert war veraltet, die Differenz zum aktuellen Stand betrug über einen Kubikmeter. AI-on-the-edge hält das für einen Lesefehler und verwirft den Wert. Weil der Vorwert dadurch nie aktualisiert wird, bleibt das Gerät in dieser Schleife hängen. Die Lösung: Unter „Manual Control“ mit „Set Previous Value“ den echten Zählerstand eintragen und mit „Start Round“ eine Auswertung starten.

Kurz danach kam der umgekehrte Fehler: „Neg. Rate“. Der neue Wert lag zwei Liter unter dem Vorwert, der Zähler wäre also rückwärts gelaufen. Die Abweichung lag genau beim Liter-Zeiger. Der liegt bei meinem Zähler unter einer durchsichtigen Kuppel, auf der sich die LED der Kamera spiegelt, und wird dadurch nicht immer sauber erkannt.

Rahmen neu setzen

Ich habe die LED-Helligkeit gesenkt und den Fokus am Objektiv nachgestellt. Danach wurden plötzlich die Ziffern nicht mehr erkannt: NaN statt 0, oder 9 statt 0. An den kleinen Bildausschnitten der Erkennung sah ich, warum: Durch die Fokusänderung hatte sich das Bild verschoben, und die Rahmen saßen nicht mehr auf den Ziffern. Nach einer Änderung an Kamera oder Fokus musst Du in dieser Reihenfolge vorgehen:

1. Neues Referenzbild aufnehmen
2. Ausrichtungsmarken neu setzen, zum Beispiel auf „m³“ und eine Beschriftung, die sich nie ändert
3. Ziffern-Rahmen neu setzen, jeder genau auf ein weißes Ziffernfenster
4. Zeiger-Rahmen neu setzen, jeder Kreis mittig auf die Zeigerachse
5. Gerät neu starten, Vorwert setzen, Runde starten

Was mir am Ende geholfen hat, war unscheinbar: Im ROI-Editor gibt es Hilfsoptionen wie „Keep equidistance“, „Synchronize y, Δx and Δy“ und „Lock aspect ratio“. Sie zwingen alle Rahmen in ein gleichmäßiges Raster. Die Ziffernfenster meines Zählers liegen aber nicht exakt in diesem Raster. Erst als ich alle Häkchen entfernt und jeden Rahmen einzeln gesetzt habe, wurden alle Ziffern sauber erkannt.

Damit Fehlablesungen nicht als riesige Ausreißer in der Statistik landen, habe ich die Plausibilitätsprüfung unter Settings, Configuration, PostProcessing kontrolliert: MaxRateType steht auf „RateChange“ (Änderung pro Minute), MaxRateValue auf 0.05, also 50 Liter pro Minute, und negative Raten sind nicht erlaubt. Bei „AbsoluteChange“ würde die Grenze pro Runde gelten. Mit langen Intervallen reicht dann schon ein Vollbad, damit ein echter Wert abgelehnt wird.

Zum Schluss habe ich das Intervall von 60 auf 15 Minuten gesenkt. Die Änderung wird erst nach einem Neustart des Geräts aktiv. In Home Assistant habe ich die Anzeigeeinheit des Zählerstands auf Liter gestellt. Im Gerät selbst bleibt die Einheit m³, weil AI-on-the-edge beim Umstellen der Einheit nicht umrechnet.

Falls der Zeiger unter der Kuppel auf Dauer unzuverlässig bleibt, habe ich eine Rückfalllösung: Die beiden kleinsten Zeiger löschen und mit 10-Liter-Auflösung messen. Für den Tagesverbrauch reicht das.

Schritt 10: Energie-Dashboard mit saldierten Netzwerten

Mit Shelly Pro 3EM, Balkonkraftwerk und Wasseruhr hatte ich alles für das Energie-Dashboard beisammen. Nach dem ersten Tag sah ich etwas Merkwürdiges: Das Dashboard zeigte Netzeinspeisung, obwohl das Haus zur selben Zeit deutlich mehr verbraucht hat, als die PV geliefert hat.

Die Ursache: Einspeisung pro Phase

Mein Balkonkraftwerk speist auf Phase L3 ein. Wenn auf L3 gerade wenig Verbrauch anliegt, fließt dort Strom Richtung Netz, während L1 und L2 gleichzeitig Strom beziehen. Der Shelly Pro 3EM zählt Bezug und Einspeisung für jede Phase einzeln und meldet deshalb Einspeisung. Mein Stromzähler saldiert dagegen über alle drei Phasen und sieht nur den Bezug.

Die Lösung: eigene Zähler aus der Gesamtleistung

Der Shelly liefert neben den Phasenwerten einen Sensor „Leistung“ für alle drei Phasen zusammen, mit Vorzeichen: positiv bei Bezug, negativ bei Einspeisung. Daraus habe ich zwei Leistungssensoren gebaut und mit der Integral-Integration zu Energiezählern in kWh hochgerechnet.

Damit die configuration.yaml übersichtlich bleibt, nutze ich Packages. In der configuration.yaml steht dafür:

homeassistant:
  packages: !include_dir_named packages

Im Ordner packages liegt die Datei netz_saldiert.yaml. Die Entitäts-ID des Shelly musst Du durch Deine eigene ersetzen. Du findest sie, wenn Du beim Shelly-Gerät auf den Sensor „Leistung“ klickst und oben rechts das Zahnrad öffnest. Wichtig ist der Sensor des Hauptgeräts, nicht der von Phase A, B oder C. Je nach Systemsprache endet die ID auf _leistung oder _power.

# Saldierte Netzwerte aus dem Shelly Pro 3EM
template:
  - sensor:
      - name: "Netz Bezug Leistung"
        unique_id: netz_bezug_leistung
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        availability: "{{ has_value('sensor.shellypro3em_[SERIENNUMMER]_leistung') }}"
        state: "{{ [states('sensor.shellypro3em_[SERIENNUMMER]_leistung') | float(0), 0] | max }}"

      - name: "Netz Einspeisung Leistung"
        unique_id: netz_einspeisung_leistung
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        availability: "{{ has_value('sensor.shellypro3em_[SERIENNUMMER]_leistung') }}"
        state: "{{ [-(states('sensor.shellypro3em_[SERIENNUMMER]_leistung') | float(0)), 0] | max }}"

sensor:
  - platform: integration
    source: sensor.netz_bezug_leistung
    name: "Netz Bezug saldiert"
    unique_id: netz_bezug_saldiert
    unit_prefix: k
    unit_time: h
    method: left
    round: 3

  - platform: integration
    source: sensor.netz_einspeisung_leistung
    name: "Netz Einspeisung saldiert"
    unique_id: netz_einspeisung_saldiert
    unit_prefix: k
    unit_time: h
    method: left
    round: 3

Die Dateien habe ich mit dem Add-on „File editor“ angelegt. Nach dem Speichern prüfst Du unter Werkzeuge, YAML die Konfiguration und startest Home Assistant vollständig neu. Ein schnelles Neuladen reicht für die neuen Sensoren nicht.

Bevor Du das Energie-Dashboard umstellst, prüfe unter Werkzeuge, Zustände mit dem Filter netz_, ob die vier neuen Sensoren Werte liefern. Bei mir zeigte „Netz Bezug Leistung“ ungefähr denselben Wert wie die Shelly-Leistung, „Netz Einspeisung Leistung“ stand auf 0 W, und die beiden saldierten Zähler begannen bei 0 kWh.

Das Energie-Dashboard umstellen

Im Energie-Dashboard heißen Bezug und Einspeisung in meiner Version „Netzanschluss“. Ich habe dort genau einen Netzanschluss eingerichtet:

• Aus dem Netz bezogene Energie: Netz Bezug saldiert
• In das Netz eingespeiste Energie: Netz Einspeisung saldiert
• Art der Leistungsmessung: Standard, mit der Gesamtleistung des Shelly für die Live-Anzeige

Dazu kommen bei der Solarproduktion der Energiezähler des Sonoff am Balkonkraftwerk, als Prognose Forecast.Solar, und beim Wasserverbrauch der Zählerstand der Wasseruhr. Die alten Shelly-Zähler „Energie“ und „Energieeinspeisung“ habe ich aus dem Dashboard entfernt, weil sie die Phasen einzeln zählen.

Dabei bin ich noch zweimal gestolpert. Erstens gab es einen alten Netzanschluss, in dem nur noch die Shelly-Leistung steckte. Weil jeder Sensor nur einmal verwendet werden darf, tauchte die Gesamtleistung im neuen Anschluss nicht in der Auswahl auf. Erst nachdem ich den alten Eintrag gelöscht hatte, ließ sie sich auswählen. Zweitens zeigte das Dashboard nach der Umstellung beim Netz 0 Wh, und der Hausverbrauch entsprach genau der PV-Erzeugung. Das ist kein Fehler: Das Energie-Dashboard rechnet in Stundenschritten, und die neuen Zähler hatten noch keinen Stundenwert. Die Werte erscheinen erst nach der nächsten vollen Stunde. Den Verbrauch vor der Umstellung rechnet Home Assistant nicht nach, ab dem nächsten Tag ist das Bild vollständig.

Schritt 11: Fernzugriff mit WireGuard und der Home-Assistant-App

Ich nutze am Handy CyberGhost als VPN. Anfangs dachte ich, das reicht für den Fernzugriff. Ein Privatsphäre-VPN wie CyberGhost leitet den Verkehr aber zu einem Server irgendwo im Internet und nicht ins eigene Heimnetz. Für den Zugriff auf Home Assistant brauchst Du ein VPN, das zu Dir nach Hause führt.

Voraussetzung: eine öffentliche IPv4-Adresse

Im Online-Monitor der FRITZ!Box habe ich nachgesehen, ob mein Anschluss eine öffentliche IPv4-Adresse hat. Bei meinem DSL-Anschluss ist das der Fall, die Adresse wechselt aber. Das ist kein Problem, weil MyFRITZ! die jeweils aktuelle Adresse unter einem festen Namen bereitstellt. Hast Du einen Anschluss mit DS-Lite, funktioniert dieser Weg nicht direkt. Dann sind Tailscale oder Home Assistant Cloud die bessere Wahl.

WireGuard einrichten

1. In der FRITZ!Box unter Internet, MyFRITZ!-Konto die Registrierung abschließen
2. Unter Internet, Freigaben, VPN (WireGuard) eine Verbindung für ein Einzelgerät anlegen
3. Nur den Verkehr ins Heimnetz über VPN leiten, nicht den gesamten Verkehr
4. In der WireGuard-App den QR-Code scannen
5. Optional unter „Zulässige IPs“ zusätzlich das Netz des zweiten Hauses eintragen, damit es über die LAN-zu-LAN-Kopplung erreichbar ist. Ob die FRITZ!Box den Verkehr zwischen beiden Tunneln weiterleitet, musst Du ausprobieren. Klappt es nicht, legst Du in der FRITZ!Box des zweiten Hauses einen eigenen Zugang an und nutzt in der App zwei Profile.

Die Home-Assistant-App einstellen

Die Home-Assistant-App hatte ich schon installiert. Den Menüpunkt „Companion-App“ habe ich in den Einstellungen trotzdem lange gesucht. Er steht weit unten in der Liste und erscheint nur in der App, nicht im Browser. Dort habe ich für den Server die interne und die externe URL auf http://[IP-HOME-ASSISTANT]:8123 gesetzt und mein Heim-WLAN eingetragen. Unterwegs läuft die externe URL über den WireGuard-Tunnel.

Der Test war einfach: WLAN am Handy aus, WireGuard an, App öffnen. Das Dashboard erschien sofort.

Gut zu wissen: Ein Handy kann immer nur ein VPN gleichzeitig nutzen. Wenn ich unterwegs Home Assistant brauche, schalte ich WireGuard ein und CyberGhost aus. Auf Android kannst Du WireGuard als „Durchgehend aktives VPN“ einstellen, auf dem iPhone über „On-Demand“. Weil nur der Heimverkehr durch den Tunnel geht, merkst Du im Alltag davon nichts.

Was ich aus dem Umstieg mitnehme

Der Umstieg hat länger gedauert, als ich gedacht hatte. Die eigentliche Einbindung von OpenCCU in Home Assistant war schnell erledigt. Zeit gekostet haben die Details drumherum: ein vorausgefülltes Passwortfeld, ein fehlendes Semikolon, ein veralteter Vorwert in der Wasseruhr, Hilfsoptionen im ROI-Editor. Die meisten Fehler ließen sich mit einem Blick ins Protokoll oder in den MQTT Explorer eingrenzen.

Diese Punkte würde ich beim nächsten Mal genauso machen:

• Parallel aufbauen und das alte System erst abschalten, wenn das neue läuft
• Vor jeder größeren Änderung ein Backup, sowohl in Home Assistant als auch in OpenCCU
• Eine Sache nach der anderen einrichten und jeweils sofort testen
• Eigene YAML-Konfiguration in Packages auslagern
• Den MQTT Explorer von Anfang an offen haben

Wie es weitergeht

Im ersten Haus läuft jetzt alles in Home Assistant: OpenCCU mit CUxD, MQTT, Tasmota, Shelly, die FRITZ!Box, die Wasseruhr und das Energie-Dashboard. Als Nächstes stehen an:

• der Umzug vom USB-Stick auf die NVMe-SSD
• der Umzug der Flows aus RedMatic in das Node-RED-Add-on
• Mosquitto als Add-on in Home Assistant, dann mit Benutzer und Passwort
• die Einbindung des EcoFlow-Speichers, der den alten Wechselrichter ersetzt
• das zweite Haus, nach demselben Ablauf

Für das zweite Haus bereite ich den Pi zu Hause vor und stelle ihn kurz vor dem Transport auf die feste IP-Adresse im dortigen Netz um. Die Backups lasse ich gegenseitig laufen: Jedes Haus sichert auf die FRITZ!Box des anderen. So liegt jedes Backup außer Haus.

Häufige Fragen: OpenCCU in Home Assistant

Kann ich OpenCCU behalten, wenn ich Home Assistant nutze?

Ja. Mit der Integration „Homematic(IP) Local for OpenCCU“ bleibt OpenCCU die Funkzentrale für Homematic und Homematic IP. Home Assistant liest die Geräte über das Netzwerk und kann sie schalten. Programme und Systemvariablen der CCU laufen weiter.

Welche Integration brauche ich für Homematic IP in Home Assistant?

Ich verwende „Homematic(IP) Local for OpenCCU“ aus HACS. Sie arbeitet lokal ohne Cloud und unterstützt Homematic IP, klassisches Homematic, Heizgruppen, CUxD und Systemvariablen. Die alte eingebaute Integration „HomeMatic“ ist dafür nicht mehr gedacht.

Reicht ein Raspberry Pi 5 für Home Assistant?

Für meinen Umfang mit gut 20 Homematic-Geräten, MQTT, Node-RED und mehreren Integrationen reicht er gut aus. Wichtiger als die Rechenleistung ist ein Speicher, der Dauerschreiben verträgt, also eine SSD statt einer SD-Karte.

Warum zeigt Home Assistant Einspeisung, obwohl ich mehr verbrauche, als die PV liefert?

Wahrscheinlich misst Dein Energiemessgerät Bezug und Einspeisung je Phase. Ein saldierender Stromzähler verrechnet dagegen alle Phasen. Wenn Du die vorzeichenbehaftete Gesamtleistung in zwei Zähler aufteilst, wie oben beschrieben, stimmen die Werte mit dem Zähler überein.

Brauche ich für den Fernzugriff Home Assistant Cloud?

Nein. Mit einer öffentlichen IPv4-Adresse reicht WireGuard über die FRITZ!Box. Home Assistant Cloud (Nabu Casa) ist bequemer, kostet aber eine monatliche Gebühr und deckt nur Home Assistant ab, nicht die Oberfläche der CCU oder der FRITZ!Box.

Was bedeutet „Rate too high“ bei AI-on-the-edge?

Der neue Zählerstand weicht zu stark vom gespeicherten Vorwert ab, deshalb verwirft das Gerät den Wert. Setze den Vorwert mit „Set Previous Value“ auf den echten Zählerstand und starte eine neue Runde.

Weiterführende Links

• Home Assistant auf dem Raspberry Pi installieren
• HACS, der Home Assistant Community Store
• Homematic(IP) Local for OpenCCU auf GitHub
• MQTT-Integration in Home Assistant
• Tasmota-Integration in Home Assistant
• Shelly-Integration in Home Assistant
• FRITZ!Box Tools in Home Assistant
• Template-Sensoren in Home Assistant
• Dokumentation zu AI-on-the-edge
• MQTT Explorer