LHlab Wiki - Letzte Änderungen [de]

Syslog-Server Docker Stack mit Webinterface für Log-Analyse

Andreas — Fri, 13 Nov 2026 10:42:39 GMT

SMA MQTT Bridge: Wechselrichter und eCharger in openHAB integrieren

Andreas — Sat, 07 Nov 2026 17:57:39 GMT

← Nächstältere Version		Version vom 7. November 2026, 18:57 Uhr
Zeile 313:		Zeile 313:

	Die Prognose-Widgets verwenden bereits vorhandene Prognose-Items. Die Bridge berechnet keine eigene Wetter- oder PV-Prognose.		Die Prognose-Widgets verwenden bereits vorhandene Prognose-Items. Die Bridge berechnet keine eigene Wetter- oder PV-Prognose.

			[[Datei:Daily-energy-overview-demo.jpg\|600x600px]]

			[[Datei:Live-energy-flow-demo.jpg\|600x600px]]

	=== Import über die MainUI ===		=== Import über die MainUI ===

Datei:Live-energy-flow-demo.jpg

Andreas — Sat, 07 Nov 2026 17:57:23 GMT

Andreas lud Datei:Live-energy-flow-demo.jpg hoch

Neue Seite

Live-energy-flow-demo

Datei:Daily-energy-overview-demo.jpg

Andreas — Sat, 07 Nov 2026 17:56:44 GMT

Andreas lud Datei:Daily-energy-overview-demo.jpg hoch

Neue Seite

Daily-energy-overview-demo

BMW MQTT Bridge mit Docker: CarData in openHAB einbinden

Andreas — Sat, 07 Nov 2026 12:46:36 GMT

Fahrzeugkarte oder Listenwidget

← Nächstältere Version		Version vom 7. November 2026, 13:46 Uhr
Zeile 121:		Zeile 121:

	=== Fahrzeugkarte oder Listenwidget ===		=== Fahrzeugkarte oder Listenwidget ===
			[[Datei:Openhab-demo-details.jpg\|rechts\|331x331px]]
	Im [https://github.com/alaub81/bmw-mqtt-bridge/tree/main/openHAB openHAB-Verzeichnis] liegen die kanonische Widgetdatei und daraus erzeugte Einzelimporte.		Im [https://github.com/alaub81/bmw-mqtt-bridge/tree/main/openHAB openHAB-Verzeichnis] liegen die kanonische Widgetdatei und daraus erzeugte Einzelimporte.

Datei:Openhab-demo-details.jpg

Andreas — Sat, 07 Nov 2026 12:45:59 GMT

Andreas lud Datei:Openhab-demo-details.jpg hoch

Neue Seite

Openhab-demo-details

BMW MQTT Bridge mit Docker: CarData in openHAB einbinden

Andreas — Sat, 07 Nov 2026 12:43:29 GMT

← Nächstältere Version		Version vom 7. November 2026, 13:43 Uhr
Zeile 1:		Zeile 1:
			[[Datei:Bmw-mqtt-bridge-article.png\|rechts\|250x250px]]
	BMW-Fahrzeugdaten im eigenen Smart Home anzeigen: Die BMW MQTT Bridge leitet den CarData-Datenstrom an deinen MQTT-Broker weiter. Hier zeige ich dir die Einrichtung mit Docker Compose, die Anmeldung bei BMW und die Einbindung in openHAB – einschließlich Updates, Backup und Fehlersuche.		BMW-Fahrzeugdaten im eigenen Smart Home anzeigen: Die BMW MQTT Bridge leitet den CarData-Datenstrom an deinen MQTT-Broker weiter. Hier zeige ich dir die Einrichtung mit Docker Compose, die Anmeldung bei BMW und die Einbindung in openHAB – einschließlich Updates, Backup und Fehlersuche.

Datei:Bmw-mqtt-bridge-article.png

Andreas — Sat, 07 Nov 2026 12:42:55 GMT

Andreas lud Datei:Bmw-mqtt-bridge-article.png hoch

Neue Seite

Bmw-mqtt-bridge-article

BMW MQTT Bridge mit Docker: CarData in openHAB einbinden

Andreas — Sat, 07 Nov 2026 12:42:17 GMT

Die Seite wurde neu angelegt: „BMW-Fahrzeugdaten im eigenen Smart Home anzeigen: Die BMW MQTT Bridge leitet den CarData-Datenstrom an deinen MQTT-Broker weiter. Hier zeige ich dir die Einrichtung mit Docker Compose, die Anmeldung bei BMW und die Einbindung in openHAB – einschließlich Updates, Backup und Fehlersuche. == Was macht die BMW MQTT Bridge? == Die Bridge verbindet den BMW-CarData-Streamingdienst mit deinem eigenen MQTT-Broker. Die Anmeldung erfolgt über den OAuth Device F…“

Neue Seite

BMW-Fahrzeugdaten im eigenen Smart Home anzeigen: Die BMW MQTT Bridge leitet den CarData-Datenstrom an deinen MQTT-Broker weiter. Hier zeige ich dir die Einrichtung mit Docker Compose, die Anmeldung bei BMW und die Einbindung in openHAB – einschließlich Updates, Backup und Fehlersuche.

== Was macht die BMW MQTT Bridge? ==
Die Bridge verbindet den BMW-CarData-Streamingdienst mit deinem eigenen MQTT-Broker. Die Anmeldung erfolgt über den OAuth Device Flow: Du bestätigst den Zugang im Browser, die Bridge speichert die erhaltenen Tokens in einem Docker-Volume und erneuert sie im laufenden Betrieb automatisch.

Du kannst vollständige JSON-Nachrichten weiterreichen, einzelne Felder auf eigene Topics aufteilen und zusätzlich Homie 4 für die openHAB-Erkennung aktivieren. Welche Fahrzeugdaten eintreffen und wie häufig BMW sie aktualisiert, hängt vom Fahrzeug und der freigegebenen Datenauswahl ab. Die Bridge ist kein frei einstellbares Abfragesystem. Die Widgets zeigen Daten an und senden keine Fahrzeugbefehle.

Das Projekt ist eine unabhängige Community-Bridge und basiert auf der Arbeit von dj0abr.

== Voraussetzungen ==
* Docker mit Compose-Plugin, beispielsweise auf einem Linux-Server, NAS oder Raspberry Pi mit 64-Bit-System.
* Ein erreichbarer MQTT-Broker, zum Beispiel Mosquitto. Die Bridge installiert keinen Broker.
* Ein BMW-Konto mit zugeordnetem Fahrzeug und nutzbarem CarData-Streamingzugang.
* Für die optionale Anzeige: openHAB mit MQTT Binding und Homie-Unterstützung passend zur installierten Version.

Die Container werden für amd64 und arm64 gebaut. Ein Port muss für die Bridge nicht veröffentlicht werden: Sie baut ausgehende Verbindungen zu BMW und deinem Broker auf.

== BMW CarData vorbereiten ==
Öffne das [https://www.bmw-connecteddrive.com/ BMW-Portal] und suche beim Fahrzeug nach CarData. Die genaue Menübezeichnung kann sich ändern.

# Erstelle eine Client-ID für den CarData-Zugang. Die Funktion „Authenticate Vehicle“ ist dafür nicht der hier beschriebene Weg.
# Übernimm die Client-ID als <code>BMB_BMW_CLIENT_ID</code>.
# Öffne bei CarData Stream die Verbindungsdetails. Den dortigen Benutzernamen trägst du als <code>BMB_BMW_GCID</code> ein.
# Aktiviere in der Datenauswahl die gewünschten Fahrzeugdaten.

== Docker-Schnellstart ==
Lege ein eigenes Verzeichnis an:
<syntaxhighlight lang="bash">
mkdir -p ~/bmw-mqtt-bridge
cd ~/bmw-mqtt-bridge
</syntaxhighlight>

Erstelle darin die Datei <code>docker-compose.yml</code>:
<syntaxhighlight lang="yaml">
services:
bmw-mqtt-bridge:
image: ghcr.io/alaub81/bmw-mqtt-bridge:${BMB_VERSION:-latest}
env_file: .env
volumes:
- data_bmb_token:/app/token
restart: unless-stopped

volumes:
data_bmb_token:
</syntaxhighlight>

Daneben kommt eine <code>.env</code>:
<syntaxhighlight lang="ini">
BMB_BMW_CLIENT_ID=DEINE-CLIENT-ID
BMB_BMW_GCID=DEIN-CARDATA-BENUTZERNAME
BMB_MQTT_LOCAL_HOST=192.168.1.10
</syntaxhighlight>

Ersetze die Beispielwerte. Dieses Minimalbeispiel verwendet Port 1883 ohne TLS und ohne Broker-Anmeldung. Benötigt dein Broker Zugangsdaten, ergänze:
<syntaxhighlight lang="ini">
BMB_MQTT_LOCAL_USER=DEIN-MQTT-BENUTZER
BMB_MQTT_LOCAL_PASSWORD='DEIN-MQTT-PASSWORT'
</syntaxhighlight>

Bei Sonderzeichen im Passwort die Compose-Regeln für <code>.env</code> beachten; einfache Anführungszeichen erhalten beispielsweise ein Dollarzeichen als Literal. Verwende auf nicht vertrauenswürdigen Netzen TLS mit Zertifikatsprüfung. Für einen Broker mit öffentlich vertrauenswürdigem Zertifikat beispielsweise:
<syntaxhighlight lang="ini">
BMB_MQTT_LOCAL_HOST=mqtt.example.org
BMB_MQTT_LOCAL_PORT=8883
BMB_MQTT_LOCAL_TLS=true
BMB_MQTT_LOCAL_TLS_VERIFY=true
</syntaxhighlight>

Für eine eigene CA beschreibt die Repository-Dokumentation den zusätzlichen Zertifikatsmount. Der Brokername muss zum Zertifikat passen. <code>localhost</code> bezeichnet im Container den Container selbst. Verwende die erreichbare LAN-Adresse oder den Dienstnamen des Brokers im gemeinsamen Docker-Netz.

Die beiden Dateien reichen für den Einstieg. Zusätzliche Konfigurationsdateien im Container sind nicht erforderlich. Das ausführliche Compose-Beispiel im Repository ergänzt Healthcheck, begrenzte Logs und weitere Härtung.

== Einmal anmelden und starten ==
<syntaxhighlight lang="bash">
chmod 600 .env
docker compose pull
docker compose run --rm -it bmw-mqtt-bridge ./bmw_flow.sh
docker compose up -d
docker compose logs -f bmw-mqtt-bridge
</syntaxhighlight>

Öffne den vom Helfer ausgegebenen Link und bestätige den angezeigten Gerätecode bei BMW. Die Tokens landen im Volume unter <code>/app/token/tokens.json</code>. Bei späteren Starts bleibt die Anmeldung erhalten, solange die Zugangsdaten gültig sind. Zum Beenden der Logansicht drückst du Strg+C; der Container läuft weiter.

Betreibe nur eine Bridge pro BMW-Zugang beziehungsweise gemeinsamem Tokenbestand. Für eine erneute Anmeldung zuerst den laufenden Dienst stoppen:
<syntaxhighlight lang="bash">
docker compose stop bmw-mqtt-bridge
docker compose run --rm -it bmw-mqtt-bridge ./bmw_flow.sh
docker compose up -d
</syntaxhighlight>

== Welche MQTT-Ausgaben gibt es? ==
Standardmäßig veröffentlicht die Bridge vollständige Nachrichten unter <code>bmw/raw/<VIN>/<eventName></code> sowie auf dem Legacy-Pfad <code>bmw/<VIN>/<eventName></code>. Optional lassen sich einzelne Felder aufteilen:
<syntaxhighlight lang="ini">
BMB_MQTT_SPLIT_TOPICS=1
</syntaxhighlight>

Diese erscheinen unter <code>bmw/vehicles/<VIN>/<property></code>. Die tatsächlichen Feldnamen ergeben sich aus den empfangenen BMW-Nachrichten. <code>bmw/status</code> beschreibt den Verbindungszustand, wenn RAW- oder Split-Ausgabe aktiv ist. Es ist kein Nachweis für aktuelle Werte aller Fahrzeugfelder.

Mit <code>BMB_MQTT_RETAIN=1</code> bleiben die letzten RAW-/Split-Werte auf dem Broker erhalten. Status sowie Homie-Metadaten und Homie-Werte werden unabhängig davon retained veröffentlicht. Ein alter gespeicherter Wert ist keine neue Messung.

Nach Änderungen an der <code>.env</code> den Container neu erstellen:
<syntaxhighlight lang="bash">
docker compose up -d --force-recreate
</syntaxhighlight>

== openHAB über Homie anbinden ==
Ergänze in der <code>.env</code>:
<syntaxhighlight lang="ini">
BMB_MQTT_HOMIE=1
</syntaxhighlight>

# Erstelle den Bridge-Container neu.
# Verbinde in openHAB eine MQTT Broker Bridge mit deinem lokalen Broker und aktiviere die Homie-Unterstützung deiner Version.
# Warte auf eine gültige Fahrzeugnachricht. Übernimm das erkannte Fahrzeug aus der Inbox.
# Verknüpfe die gewünschten Channels mit Items.
# Verknüpfe <code>telemetry#lastUpdate</code> mit einem DateTime-Item und Standardprofil.

Die Bridge veröffentlicht Homie unter <code>homie/bmw-<VIN in Kleinbuchstaben>/</code>. Ein eigener <code>.things</code>-Import oder JSONPath ist für diesen Weg nicht nötig. Broker-ACLs müssen auch diese Topics und das Last Will erlauben.

„Last update“ ist die Empfangszeit der letzten gültigen Nachricht in der Bridge. Eine Teilnachricht kann nur einzelne Felder aktualisieren; die anderen Werte können älter sein. Auch wiederhergestellte Cachewerte müssen nicht frisch sein.

=== Fahrzeugkarte oder Listenwidget ===
Im [https://github.com/alaub81/bmw-mqtt-bridge/tree/main/openHAB openHAB-Verzeichnis] liegen die kanonische Widgetdatei und daraus erzeugte Einzelimporte.

* '''Dateiinstallation:''' <code>bmw-vehicle-widgets.yml</code> nach <code>$OPENHAB_CONF/yaml/</code> kopieren und MainUI neu laden.
* '''Einzelimport:''' In MainUI unter Entwicklerwerkzeuge → Widgets ein Widget anlegen und den YAML-Code vollständig durch den gewünschten Import aus <code>openHAB/imports/</code> ersetzen.

Verwende je UID einen Installationsweg. Die Fahrzeugkarte lässt sich auf einer Layout-Seite einsetzen; das Listenwidget eignet sich als Default List Widget einer Fahrzeuggruppe. Wähle Fahrzeugname, Antrieb und die vorhandenen Items in der Instanz aus. Nicht benötigte Parameter bleiben leer.

Die Widgets unterstützen unter anderem Reichweite, Akku oder Tank, Verriegelung, Ladeinformationen und ausgewählte Fenster-/Türzustände. Nicht eingerichtete Messwerte werden ausgeblendet; unbekannte Zustände bleiben unbekannt. Reifendruck und Wallboxleistung haben dokumentierte Einheitenumrechnungen. Die Wallboxleistung stammt aus einem separat gewählten Leistungs-Item deines Strommessers und wird nicht von der Bridge erzeugt.

== Update ==
Sichere zuerst Konfiguration und Token-Volume. Für eine gezielte Version setze <code>BMB_VERSION</code> in der <code>.env</code> auf einen tatsächlich veröffentlichten Image-Tag ohne führendes <code>v</code>. Danach:
<syntaxhighlight lang="bash">
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 bmw-mqtt-bridge
</syntaxhighlight>

Auch <code>latest</code> aktualisiert einen laufenden Container nicht von selbst. Versionstags können durch regelmäßige Basisimage-Neubauten ersetzt werden; notiere für einen exakten Rollback den Image-Digest. Bei Formatmigrationen gehört der passende Zustandsstand zum Rollback.

== Backup und Restore ==
Das Volume enthält Tokens und bei Homie-Nutzung den Cache. Ein Backup des Images allein reicht nicht. Sichere zusätzlich <code>.env</code>, Compose und eigene Zertifikate. Die Archive enthalten Zugangsdaten und gehören auf einen geschützten zweiten Speicherort.

Im Compose-Verzeichnis:
<syntaxhighlight lang="bash">
umask 077
mkdir -p backups
docker compose stop bmw-mqtt-bridge
docker compose run --rm --no-deps -T --entrypoint tar bmw-mqtt-bridge \
-C /app/token -czf - . > backups/token-volume.tar.gz
tar -czf backups/config.tar.gz .env docker-compose.yml
tar -tzf backups/token-volume.tar.gz
docker compose start bmw-mqtt-bridge
</syntaxhighlight>

Prüfe nach jedem Befehl den Erfolg. Ein fehlgeschlagener Export kann eine leere Datei hinterlassen. Eigene Zertifikatsdateien zusätzlich sichern.

Zum Wiederherstellen zuerst die Konfiguration zurückspielen und ein '''leeres''' Token-Volume verwenden. Die Bridge muss gestoppt sein. Der folgende Befehl schreibt in das konfigurierte Volume:
<syntaxhighlight lang="bash">
docker compose stop bmw-mqtt-bridge
docker compose run --rm --no-deps -T --entrypoint tar bmw-mqtt-bridge \
-C /app/token -xzf - -o < backups/token-volume.tar.gz
</syntaxhighlight>

Prüfe Inhalt und Eigentümer vor dem Start. Für einen Restore-Test ein getrenntes Compose-Projekt benutzen und keine zweite Bridge mit echten wiederhergestellten Tokens starten. Ein älteres Token-Backup kann nach einer Tokenrotation eine erneute BMW-Anmeldung erfordern. <code>docker compose down -v</code> löscht das Volume.

Weitere Grundlagen: [[Docker Backup und Restore - eine kleine Anleitung]].

== Troubleshooting ==
{| class="wikitable"
! Problem !! Prüfen und beheben
|-
| Image lässt sich nicht laden || Existiert der Tag und ist das GHCR-Paket öffentlich? Ein Git-Tag und ein Image-Tag sind unterschiedlich: Image-Versionen haben kein führendes v.
|-
| Verbindung zum lokalen Broker fehlt || LAN-Adresse, Port, Benutzer, Passwort, Listener und ACLs prüfen. TLS wird ausdrücklich aktiviert, nicht allein durch Port 8883.
|-
| Anmeldung funktioniert, aber keine Fahrzeugdaten || CarData-Datenauswahl und BMW-Verbindung prüfen. Auf neue BMW-Nachrichten warten; die Bridge erzwingt keine neue Messung.
|-
| Keine Homie-Erkennung || BMB_MQTT_HOMIE prüfen, Container neu erstellen, homie/-ACLs und zusätzliche Homie-Verbindungslogs prüfen. Mindestens eine gültige Nachricht muss verarbeitet worden sein.
|-
| Widget leer oder zeigt — || Itemparameter und tatsächliche Rohzustände prüfen. Channels müssen mit passenden Items verknüpft sein. Zustandszuordnungen und Einheiten stehen in der Widget-Anleitung.
|-
| Konfigurationsänderung ohne Wirkung || docker compose up -d --force-recreate ausführen. Ein restart übernimmt keine neuen Umgebungsvariablen.
|-
| Unhealthy im ausführlichen Compose-Beispiel || Heartbeat und länger unterbrochene BMW-/Broker-Verbindung prüfen. Ein laufender Prozess kann unhealthy sein; Docker startet ihn dadurch nicht automatisch neu.
|-
| Tokenverzeichnis nicht beschreibbar || Rechte prüfen: Der Container läuft als UID/GID 10001:10001. Für alte root-eigene Volumes die dokumentierte Migration nach vorherigem Backup verwenden.
|}

Für eine kurze Fehlersuche kann <code>BMB_LOG_LEVEL=debug</code> helfen. Debuglogs können Fahrzeugdaten enthalten. Vor dem Teilen Tokens, VIN, Kontokennungen und Positionen entfernen. Sicherheitslücken über den privaten Meldekanal im Repository melden.

== Quellen und weiterführende Anleitungen ==
* [https://github.com/alaub81/bmw-mqtt-bridge BMW MQTT Bridge auf GitHub]
* [https://github.com/alaub81/bmw-mqtt-bridge/blob/main/docs/configuration.md Konfiguration und MQTT-Ausgaben]
* [https://github.com/alaub81/bmw-mqtt-bridge/blob/main/docs/operations.md Betrieb und Diagnosewerkzeuge]
* [https://github.com/alaub81/bmw-mqtt-bridge/tree/main/openHAB Widget-Anleitungen und Importe]
* [https://www.openhab.org/addons/bindings/homie/ openHAB Homie Binding]

[[Kategorie:Docker]]
[[Kategorie:MQTT]]
[[Kategorie:OpenHAB]]
[[Kategorie:SmartHome]]

SMA MQTT Bridge: Wechselrichter und eCharger in openHAB integrieren

Andreas — Sat, 07 Nov 2026 12:22:00 GMT

← Nächstältere Version		Version vom 7. November 2026, 13:22 Uhr
Zeile 1:		Zeile 1:
			[[Datei:Sma-mqtt-bridge-artikelbild.png\|rechts\|rahmenlos\|400x400px]]
	Mit der SMA MQTT Bridge integrierst du Wechselrichter, Home Manager, eCharger und BYD-Speicher per MQTT in openHAB – mit einfachem Docker-Setup.		Mit der SMA MQTT Bridge integrierst du Wechselrichter, Home Manager, eCharger und BYD-Speicher per MQTT in openHAB – mit einfachem Docker-Setup.

Datei:Sma-mqtt-bridge-artikelbild.png

Andreas — Sat, 07 Nov 2026 12:20:41 GMT

Andreas lud Datei:Sma-mqtt-bridge-artikelbild.png hoch

Neue Seite

Sma-mqtt-bridge-artikelbild

SMA MQTT Bridge: Wechselrichter und eCharger in openHAB integrieren

Andreas — Sat, 07 Nov 2026 12:17:19 GMT

Die Seite wurde neu angelegt: „Mit der SMA MQTT Bridge integrierst du Wechselrichter, Home Manager, eCharger und BYD-Speicher per MQTT in openHAB – mit einfachem Docker-Setup. Wer die Daten seiner SMA-Anlage im eigenen Smart Home verwenden möchte, braucht vor allem eines: eine zuverlässige Verbindung zwischen den Geräten und der Hausautomation. Genau dafür ist die SMA MQTT Bridge gedacht. Sie liest Messwerte und ausgewählte Einstellungen aus und veröffentlicht sie über MQTT.…“

Neue Seite

Mit der SMA MQTT Bridge integrierst du Wechselrichter, Home Manager, eCharger und BYD-Speicher per MQTT in openHAB – mit einfachem Docker-Setup.

Wer die Daten seiner SMA-Anlage im eigenen Smart Home verwenden möchte, braucht vor allem eines: eine zuverlässige Verbindung zwischen den Geräten und der Hausautomation. Genau dafür ist die SMA MQTT Bridge gedacht. Sie liest Messwerte und ausgewählte Einstellungen aus und veröffentlicht sie über MQTT.

Die Bridge läuft als einzelner Docker-Service, beispielsweise auf einem Raspberry Pi oder einem Linux-Server. Durch die Homie-Konvention kann openHAB die bereitgestellten Geräte automatisch entdecken. Passende Widgets für Energiefluss, Tageswerte und die Wallbox sind ebenfalls im Repository enthalten.

Das Projekt findet ihr hier:
* [https://github.com/alaub81/sma-mqtt-bridge SMA MQTT Bridge auf GitHub]

== Was macht die SMA MQTT Bridge? ==

Die Bridge verbindet mehrere Datenquellen mit einem vorhandenen MQTT-Broker. Je nach angeschlossenen Geräten stehen unter anderem folgende Informationen zur Verfügung:

* '''PV-Anlage:''' aktuelle Leistung, Ertrag und weitere Wechselrichterdaten.
* '''Batteriespeicher:''' Ladezustand, Lade- und Entladeleistung sowie Energiezähler.
* '''Sunny Home Manager:''' Netzbezug, Einspeisung und abhängig vom gewählten Zugriff weitere Messwerte.
* '''SMA eCharger:''' Ladeleistung, Fahrzeugstatus, Sitzungsenergie und Ladeeinstellungen.
* '''BYD Battery-Box:''' optional direkte Batteriedaten sowie zusätzliche Zell-, Temperatur- und Diagnosedaten.
* '''Anlagenberechnungen:''' optional Hausverbrauch, Tagesenergien, Stromkosten und Einspeisevergütung.

Jede Datenquelle wird einzeln aktiviert. Für den Einstieg reicht deshalb ein einzelner unterstützter Wechselrichter. Home Manager, Wallbox und weitere Geräte können später ergänzt werden.

Die Geräteanbindung erfolgt überwiegend lokal. Für den Mindest-PV-Anteil des eChargers gibt es zusätzlich eine optionale Anbindung an Sunny Portal ennexOS. Dieser Portalzugriff wird separat eingerichtet.

== Unterstützte Geräte ==

Für folgende Geräte sind Profile beziehungsweise Adapter enthalten:

{| class="wikitable"
! Gerät
! Modell / Umfang
! Verbindung
|-
| Sunny Tripower 8.0
| STP8.0-3AV-40
| Modbus TCP
|-
| Sunny Boy Storage 3.7
| SBS3.7-10
| Modbus TCP
|-
| Sunny Boy 4.0
| SB4.0-1AV-41
| Modbus TCP
|-
| Sunny Home Manager 2.0
| Messwerte über Modbus TCP oder UDP
| Lokales Netzwerk
|-
| SMA eCharger
| EVC22-3AC-20
| Lokale HTTPS-API, optional SEMP
|-
| BYD Battery-Box Premium HVS
| Unterstütztes HVS-Profil mit vier Modulen
| Lokaler Diagnosezugriff
|}

'''Wichtig:''' Ein ähnlicher Modellname bedeutet nicht automatisch, dass ein Gerät kompatibel ist. Vor der Einrichtung sollten Modell, Firmware und Profil zusammenpassen. Besonders die direkte BYD-Anbindung ist an die dokumentierte Topologie und Firmware gebunden und keine allgemeine Unterstützung aller HVS- oder HVM-Systeme.

Weitere Wechselrichter lassen sich durch verifizierte JSON-Profile ergänzen. Die Profile enthalten die benötigten Registerzuordnungen und Metadaten; Zugangsdaten und Geräteadressen gehören in die eigene Konfiguration.

Details dazu:
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/PROFILES.md Unterstützte Profile und eigene Profile]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/BYD.md Voraussetzungen der BYD-Anbindung]

== Architektur kurz erklärt ==

Der Weg der Daten sieht so aus:

<pre>
SMA Wechselrichter ─┐
Home Manager ───────┤
SMA eCharger ───────┼── SMA MQTT Bridge ── MQTT-Broker ── openHAB
BYD Battery-Box ────┘
</pre>

Die Bridge veröffentlicht die Daten nach '''Homie 4'''. Damit werden neben den Messwerten auch Informationen wie Bezeichnungen, Datentypen und Einheiten über MQTT bereitgestellt.

openHAB kann daraus Geräte und Channels erkennen. Anschließend werden die gewünschten Channels mit eigenen Items verknüpft.

Ein MQTT-Broker und eine eigene Weboberfläche sind im Bridge-Container nicht enthalten. Für die Anzeige verwenden wir in dieser Anleitung openHAB. Andere MQTT-Anwendungen können die Topics ebenfalls nutzen.

== Voraussetzungen ==

Für die Einrichtung benötigen wir:

* Einen Linux-Host mit Docker und '''Docker Compose ab Version 2.24'''.
* Git zum Herunterladen des Repositorys.
* Einen erreichbaren MQTT-Broker, beispielsweise Mosquitto.
* Mindestens ein unterstütztes Gerät mit aktivierter benötigter Schnittstelle.
* Für die mitgelieferten dateibasierten Widgets: '''openHAB ab Version 5.2'''.

Die veröffentlichten Docker-Images unterstützen '''amd64''' und '''arm64'''. Damit kann derselbe Imagename auf einem üblichen x86-Server und einem Raspberry Pi mit 64-Bit-System verwendet werden.

Bei Wechselrichtern muss Modbus TCP gegebenenfalls zuerst in der Gerätekonfiguration aktiviert werden. Die Bridge übernimmt diese Freischaltung nicht.

== Installation mit Docker Compose ==

Für den ersten Start richten wir zunächst einen Wechselrichter ein. Sobald dessen Werte ankommen, lassen sich weitere Geräte ergänzen.

=== 1. Repository herunterladen ===

In einem Verzeichnis eurer Wahl:

<syntaxhighlight lang="bash">
git clone https://github.com/alaub81/sma-mqtt-bridge.git
cd sma-mqtt-bridge

mkdir -p data/sma-mqtt-bridge
touch smab.env
chmod 600 smab.env
</syntaxhighlight>

Die Datei <code>smab.env</code> enthält unsere Einstellungen und Zugangsdaten. Sie liegt direkt neben den Compose-Dateien und bleibt lokal.

Für einen normalen Start ist keine zusätzliche JSON-Konfiguration notwendig. Alle verfügbaren Einstellungen sind in <code>smab.example.env</code> beschrieben. Diese Datei dient als Nachschlagewerk; für den Einstieg müssen nicht sämtliche Optionen übernommen werden.

=== 2. MQTT und Wechselrichter konfigurieren ===

Die Datei <code>smab.env</code> mit einem Texteditor öffnen und folgende Einstellungen eintragen:

<syntaxhighlight lang="ini">
SMAB_MQTT_HOST=mqtt.example.invalid

SMAB_INVERTER1_ENABLED=true
SMAB_INVERTER1_HOST=inverter.example.invalid
SMAB_INVERTER1_PROFILE=sma-stp8-0-3av-40

SMAB_LANGUAGE=de
</syntaxhighlight>

Die Beispieladressen müssen durch die eigenen Hostnamen oder IP-Adressen ersetzt werden. Das Profil im Beispiel gehört zum '''Sunny Tripower STP8.0-3AV-40'''.

Für die drei mitgelieferten Wechselrichterprofile stehen folgende IDs zur Verfügung:

{| class="wikitable"
! Modell
! Profil-ID
|-
| STP8.0-3AV-40
| <code>sma-stp8-0-3av-40</code>
|-
| SBS3.7-10
| <code>sma-sbs3-7-10</code>
|-
| SB4.0-1AV-41
| <code>sma-sb4-0-1av-41</code>
|}

Mit <code>SMAB_LANGUAGE=de</code> werden die bereitgestellten Geräte- und Messwertbezeichnungen auf Deutsch veröffentlicht.

'''Wichtig bei MQTT:''' Standardmäßig verwendet die Bridge TLS auf Port '''8883''' mit Zertifikatsprüfung.

Wenn euer Broker ausdrücklich ohne TLS auf Port 1883 betrieben wird, müssen zusätzlich beide Einstellungen gesetzt werden:

<syntaxhighlight lang="ini">
SMAB_MQTT_TLS=false
SMAB_MQTT_PORT=1883
</syntaxhighlight>

Falls der Broker eine Anmeldung verlangt:

<syntaxhighlight lang="ini">
SMAB_MQTT_USERNAME=bridge-user
SMAB_MQTT_PASSWORD='PASSWORT_EINTRAGEN'
</syntaxhighlight>

Einfache Anführungszeichen erhalten auch Sonderzeichen wie <code>$</code> oder <code>#</code> im Passwort.

Bei einer privaten Zertifizierungsstelle wird das vertrauenswürdige CA-Zertifikat unter <code>data/sma-mqtt-bridge/certificates/</code> abgelegt und über <code>SMAB_MQTT_TLS_CA_FILE</code> ausgewählt. Die genaue Einrichtung steht in der [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/WIKI_QUICKSTART.md Installationsanleitung].

Der Broker muss aus dem Container erreichbar sein. <code>localhost</code> bezeichnet dort den Bridge-Container selbst. Läuft Mosquitto in einem anderen Docker-Container, benötigt die Verbindung beispielsweise ein gemeinsames Docker-Netzwerk oder einen erreichbaren Zugang über den Host.

=== 3. Image laden und Konfiguration prüfen ===

Wir verwenden die Compose-Datei für das veröffentlichte Image. Ein eigener Build ist dafür nicht notwendig:

<syntaxhighlight lang="bash">
docker compose -f compose.example.yml pull

docker compose -f compose.example.yml run --rm --no-deps \
sma-mqtt-bridge --check-config
</syntaxhighlight>

Für unser Beispiel mit einem aktivierten Wechselrichter sollte die Prüfung sinngemäß Folgendes ausgeben:

<syntaxhighlight lang="json">
{"valid": true, "enabledSources": 1, "readOnly": true}
</syntaxhighlight>

Die Prüfung kontrolliert Einstellungen und benötigte lokale Dateien. Dabei wird noch keine Verbindung zum Wechselrichter oder MQTT-Broker aufgebaut.

<code>enabledSources: 0</code> bedeutet, dass keine Datenquelle aktiviert ist. Eine eingetragene IP-Adresse allein reicht dafür nicht aus; die zugehörige <code>ENABLED</code>-Einstellung muss ebenfalls gesetzt sein.

=== 4. Container starten und Werte kontrollieren ===

Nach erfolgreicher Prüfung:

<syntaxhighlight lang="bash">
docker compose -f compose.example.yml up -d

docker compose -f compose.example.yml ps sma-mqtt-bridge

docker compose -f compose.example.yml logs --tail=100 sma-mqtt-bridge
</syntaxhighlight>

Für die ersten Abfragen etwas Zeit einplanen. Anschließend lassen sich die MQTT-Nachrichten beispielsweise mit einem MQTT-Viewer kontrollieren.

Der erste Wechselrichter verwendet standardmäßig diesen Topic-Bereich:

<pre>
homie/sma-inverter1/
</pre>

Darunter befinden sich Homie-Metadaten, der Gerätezustand und die Messwerte.

Ein laufender oder als <code>healthy</code> gemeldeter Container allein bestätigt noch keine aktuellen Gerätedaten. Deshalb immer auch Logs, Quellenstatus und tatsächliche Messwerte prüfen.

== Weitere Geräte ergänzen ==

Die folgenden Einstellungen werden ebenfalls in <code>smab.env</code> ergänzt. Anschließend die Konfiguration erneut prüfen und den Container mit <code>up -d</code> übernehmen. Ein einfacher Container-Neustart lädt geänderte Umgebungsvariablen nicht neu.

=== Weitere Wechselrichter ===

Für zusätzliche Wechselrichter wird der jeweilige Block mit einer anderen Nummer wiederholt:

<syntaxhighlight lang="ini">
SMAB_INVERTER2_ENABLED=true
SMAB_INVERTER2_HOST=storage.example.invalid
SMAB_INVERTER2_PROFILE=sma-sbs3-7-10

SMAB_INVERTER3_ENABLED=true
SMAB_INVERTER3_HOST=solar.example.invalid
SMAB_INVERTER3_PROFILE=sma-sb4-0-1av-41
</syntaxhighlight>

Die Nummer legt das Modell nicht fest. Entscheidend ist das ausgewählte Profil. Dasselbe passende Profil kann auch für mehrere Geräte verwendet werden.

=== Sunny Home Manager 2.0 ===

Für die standardmäßige Modbus-TCP-Anbindung:

<syntaxhighlight lang="ini">
SMAB_HOME_MANAGER_ENABLED=true
SMAB_HOME_MANAGER_HOST=home-manager.example.invalid
SMAB_HOME_MANAGER_SERIAL=DEINE_NUMERISCHE_SERIENNUMMER
</syntaxhighlight>

Adresse und Seriennummer durch die tatsächlichen Werte ersetzen. Die Seriennummer wird zur Gerätezuordnung benötigt.

Alternativ können UDP-Metertelegramme verwendet werden. Auch zusätzliche Phasenmesswerte neben Modbus sind möglich. Dafür müssen Netzwerk und Multicast-Empfang passen; für Linux enthält das Repository die separate Vorlage <code>compose.host.example.yml</code>.

Die Varianten sind in der [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/HOME_MANAGER_MODBUS.md Home-Manager-Anleitung] beschrieben.

=== SMA eCharger ===

Für die lokale API werden der lokale Benutzer und das lokale Passwort der Wallbox benötigt:

<syntaxhighlight lang="ini">
SMAB_ECHARGER_ENABLED=true
SMAB_ECHARGER_HOST=echarger.example.invalid
SMAB_ECHARGER_USERNAME=LOKALER_BENUTZER
SMAB_ECHARGER_PASSWORD='LOKALES_PASSWORT'
SMAB_ECHARGER_EXPECTED_SERIAL=DEINE_WALLBOX_SERIENNUMMER
</syntaxhighlight>

Die lokalen Zugangsdaten sind unabhängig vom Sunny-Portal-Konto.

Auch hier ist die TLS-Prüfung standardmäßig aktiv. Wenn das Wallbox-Zertifikat nicht bereits vertrauenswürdig ist, muss ein passendes vertrauenswürdiges Zertifikat beziehungsweise CA-Zertifikat eingebunden werden. Zertifikat und verwendeter Hostname müssen zusammenpassen.

SEMP und der optionale ennexOS-Portalzugriff werden separat aktiviert. Die vollständigen Einstellungen stehen in der [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/CONFIGURATION.md Konfigurationsreferenz].

=== BYD Battery-Box ===

Die direkte BYD-Anbindung ergänzt die Messwerte des SMA-Batteriewechselrichters um eigene Batterieinformationen.

Vor der Aktivierung unbedingt die [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/BYD.md BYD-Anleitung] prüfen. Das mitgelieferte Profil gilt für das dort beschriebene HVS-System mit vier Modulen und den passenden Firmwareständen.

Die BYD-Anbindung ist optional und ersetzt nicht die bisherigen SMA-Batteriewerte oder die Anlagenberechnung.

== Geräte in openHAB einbinden ==

Sobald die Bridge Daten veröffentlicht, kann openHAB die Homie-Geräte entdecken:

# Das '''MQTT-Binding''' installieren und ein MQTT-Broker-Thing einrichten oder das vorhandene verwenden.
# Prüfen, ob das Broker-Thing verbunden ist.
# In der Inbox einen Scan des MQTT-Bindings starten.
# Die gefundenen Homie-Geräte dem passenden Broker zuordnen und hinzufügen.
# Unter den Channels die gewünschten Messwerte mit eigenen Items verknüpfen.

Für Leistungswerte eignet sich <code>Number:Power</code>, für Energie <code>Number:Energy</code>. Die Einheiten liefert die Bridge mit. Zusätzliche Umrechnungen sind nur erforderlich, wenn die eigene weitere Verarbeitung sie tatsächlich benötigt.

Die Bridge und openHAB benötigen jeweils ihre eigene funktionierende Verbindung zum MQTT-Broker.

Bei einer bestehenden Installation können vorhandene Itemnamen und deren Historie erhalten bleiben. Vor dem Umstellen eines Links die bisherigen und neuen Werte vergleichen. Eigene Regeln und Berechnungen werden durch die Geräteerkennung nicht automatisch übertragen.

Weitere Informationen:
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/openHAB/openHAB.md openHAB-Einrichtung im Repository]
* [https://www.openhab.org/addons/bindings/homie/ Offizielle openHAB-Homie-Dokumentation]

== Fertige Widgets für die MainUI ==

Im Repository sind Widgets für folgende Ansichten enthalten:

* '''Live-Energiefluss:''' aktuelle Leistungen von PV, Haus, Netz, Batterie und optionalen Verbrauchern.
* '''Tagesenergieübersicht:''' Tagesertrag, Verbrauch, Netzbezug und Einspeisung sowie Batterieladung und -entladung.
* '''PV-Dachproduktion:''' DC-Leistung für drei konfigurierte Modulflächen.
* '''PV-Prognose:''' Tagesprognosen mit einstellbaren Ampelgrenzen.
* '''eCharger:''' Fahrzeugstatus, Ladeleistung, Sitzungsanzeige und optional Bedienelemente.
* '''Ladeplan:''' separate Karte und Listeneintrag für Zielenergie und Endzeit.

Die Prognose-Widgets verwenden bereits vorhandene Prognose-Items. Die Bridge berechnet keine eigene Wetter- oder PV-Prognose.

=== Import über die MainUI ===

Für den Einstieg können die vorbereiteten Dateien unter <code>openHAB/mainui/widgets/</code> verwendet werden:

# In openHAB als Administrator '''Entwicklerwerkzeuge → Widgets''' öffnen.
# Mit '''+''' ein neues Widget anlegen.
# Den vollständigen Inhalt der passenden Importdatei in den YAML-Editor übernehmen.
# Die mitgelieferte UID beibehalten und speichern.
# Das Widget einer Seite hinzufügen und in dieser Instanz die eigenen Items auswählen.

Alternativ lassen sich die kanonischen Dateien aus <code>openHAB/yaml/widgets/</code> unter <code>$OPENHAB_CONF/yaml/widgets/</code> installieren. Diese Variante wird über Dateien gepflegt und ist in der MainUI schreibgeschützt.

'''Pro Widget-UID nur eine Installationsmethode verwenden.''' Die Dateiinstallation und der manuelle Import sind zwei Varianten derselben Widgetdefinition.

Für eine erste Ansicht kann bei den unterstützten Widgets <code>demoMode</code> aktiviert werden. Damit werden gekennzeichnete Beispielwerte angezeigt. Für die eigenen Messwerte den Demomodus wieder ausschalten und die passenden Items auswählen.

Das Installieren eines Widgets legt keine Items, Links oder Regeln an. Die Zuordnung erfolgt bewusst über die Widget-Einstellungen.

Anleitungen und Beispiele:
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/openHAB/README.md Widget-Übersicht]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/openHAB/mainui/README.md MainUI-Import und Aktualisierung]

== Wallbox steuern und Ladepläne verwenden ==

Die Bridge startet mit deaktivierten Geräte-Schreibzugriffen. Wer zunächst nur Messwerte anzeigen möchte, kann es dabei belassen.

Für lokale eCharger-Befehle müssen zusätzlich zur aktivierten lokalen Anbindung beide Schreibfreigaben gesetzt werden:

<syntaxhighlight lang="ini">
SMAB_COMMANDS_ENABLED=true
SMAB_ECHARGER_COMMANDS_ENABLED=true
</syntaxhighlight>

Damit können unterstützte Einstellungen wie Ladefreigabe, Lademodus oder maximale Ladeleistung genutzt werden. Ladepläne übertragen Zielenergie und Endzeit gemeinsam. Die Bridge prüft die Gerätevorgaben und liest Änderungen zurück, bevor sie einen bestätigten Zustand veröffentlicht.

Der Mindest-PV-Anteil nutzt die separate Portal-Anbindung und deren eigene Freigabe.

Im eCharger-Widget werden Bedienelemente zusätzlich über <code>enableControls</code> freigegeben. Schreibbare openHAB-Items sollten <code>autoupdate=false</code> verwenden, damit eine Bedienung nicht bereits als bestätigte Geräteänderung erscheint.

Der Sunny Home Manager bleibt für die Laderegelung zuständig. Die Bridge ermöglicht die dokumentierten Einstellungen und stellt Messwerte bereit.

== Anlagenwerte und Tagesbilanzen ==

Die optionale Anlagenberechnung kann mehrere Quellen zusammenführen. Dazu gehören beispielsweise Hausverbrauch, täglicher Netzbezug, Einspeisung und getrennte Tageswerte für Batterieladung und -entladung.

Dafür müssen die beteiligten Quellen und ihre Rollen passend konfiguriert sein. Die Einrichtung ist in der [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/PLANT.md Anleitung zur Anlagenberechnung] beschrieben.

'''Bei Tageswerten beachten:''' Nach der ersten Einrichtung beginnen einige Zählerdifferenzen mit der ersten gespeicherten Ausgangsmessung. Der erste Tag kann deshalb nur einen Teil des Tages abdecken. Der zugehörige Abdeckungsstatus hilft, diese Werte einzuordnen.

Die Tagesübersicht zeigt die bereitgestellten Energiewerte an. Sie berechnet keine eigenen Tagesdifferenzen aus Gesamtzählern.

== Updates und Backup ==

Die Beispiel-Compose-Datei verwendet standardmäßig das veröffentlichte Image mit dem Tag <code>latest</code>. Wer eine bestimmte Version festhalten möchte, kann <code>SMAB_BRIDGE_VERSION</code> in der optionalen root-Datei <code>.env</code> setzen. Die Geräte- und MQTT-Einstellungen bleiben in <code>smab.env</code>.

Vor einem Update sollten mindestens folgende Daten gesichert werden:

* <code>smab.env</code> und gegebenenfalls <code>.env</code>.
* Eigene Konfiguration, Profile und Zertifikate unter <code>data/sma-mqtt-bridge/</code>.
* Das persistente Zustandsvolume <code>data_smab_state</code>; Docker stellt dem tatsächlichen Volumenamen normalerweise den Compose-Projektnamen voran.

Im Zustandsvolume liegen unter anderem gespeicherte Ausgangswerte für Energiebilanzen und die Verwaltung bereits veröffentlichter MQTT-Topics. Es sollte beim Austausch des Containers erhalten bleiben.

Das normale Update erfolgt im bisherigen Projektverzeichnis:

<syntaxhighlight lang="bash">
git pull --ff-only

docker compose -f compose.example.yml pull

docker compose -f compose.example.yml run --rm --no-deps \
sma-mqtt-bridge --check-config

docker compose -f compose.example.yml up -d
</syntaxhighlight>

Vor dem Start die Versionshinweise lesen und die erfolgreiche Konfigurationsprüfung abwarten. Bei fest eingestelltem Image-Tag muss dieser für einen Versionswechsel entsprechend angepasst werden.

Compose-Projektname und Zustandsvolume beibehalten. <code>docker compose down -v</code> würde die zugehörigen benannten Volumes löschen.

Details:
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/UPDATING.md Updates und Sicherung der Bridge]
* [[Docker Backup und Restore - eine kleine Anleitung]]

== Troubleshooting ==

{| class="wikitable"
! Problem
! Was prüfen?
|-
| Der Container startet nicht.
| Zuerst <code>--check-config</code> und anschließend die Container-Logs prüfen. Häufig fehlen Pflichtangaben einer aktivierten Quelle.
|-
| Keine Verbindung zum MQTT-Broker.
| Adresse aus Sicht des Containers, Port, TLS-Einstellung, Zertifikate und Zugangsdaten kontrollieren.
|-
| Keine Wechselrichterwerte.
| Passendes Modellprofil, Geräteadresse und aktivierte Modbus-Schnittstelle prüfen. Eine Adresse allein aktiviert den Adapter nicht.
|-
| openHAB findet keine Geräte.
| Prüfen, ob die Bridge tatsächlich unter <code>homie/</code> veröffentlicht und openHAB denselben Broker sowie den passenden Homie-Präfix verwendet.
|-
| Ein Widget zeigt nur Striche.
| Item-Zuordnung, Itemzustand und Einheit prüfen. Tagesenergie benötigt Energie-Items, keine Leistungswerte oder Gesamtzähler.
|-
| Das Widget zeigt weiterhin Beispielwerte.
| <code>demoMode</code> in der verwendeten Seiteninstanz ausschalten.
|-
| Änderungen an <code>smab.env</code> greifen nicht.
| Die Konfiguration erneut prüfen und den Container mit derselben Compose-Datei über <code>up -d</code> neu erstellen lassen.
|-
| Home-Manager-Phasenwerte fehlen.
| UDP-Konfiguration, Seriennummer, Netzwerkmodus und Multicast-Erreichbarkeit prüfen.
|}

Ausführlichere Hinweise stehen in der [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/OPERATIONS.md Betriebs- und Fehlerbehebungsanleitung].

== Weiterführende Links ==

* [https://github.com/alaub81/sma-mqtt-bridge GitHub-Repository]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/WIKI_QUICKSTART.md Schrittweise Docker-Einrichtung]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/smab.example.env Alle Konfigurationsoptionen]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/docs/WERTEKATALOG.md MQTT-Wertekatalog]
* [https://github.com/alaub81/sma-mqtt-bridge/blob/main/openHAB/README.md openHAB-Widgets und Anleitungen]
* [https://github.com/alaub81/sma-mqtt-bridge/releases Releases und Versionshinweise]
* [https://www.openhab.org/addons/bindings/homie/ openHAB Homie Convention]
* [https://www.openhab.org/docs/configuration/yaml/widgets.html openHAB YAML-Widgets]

[[Kategorie:SMA]]
[[Kategorie:Photovoltaik]]
[[Kategorie:MQTT]]
[[Kategorie:OpenHAB]]
[[Kategorie:Docker]]
[[Kategorie:Docker Compose]]
[[Kategorie:SmartHome]]