How-to: Feste IP-Adresse für deCONZ Container in Home Assistant vergeben
Einführung / Off-Topic:
In der Smart Home Welt gilt Zigbee als einer der beliebtesten Funkstards zur Einbindung allerlei Sensoren, Schaltern, Lampen, Steckdosen und co. ins heimische Netzwerk. Nicht zu letzt deswegen, da mittlerweile Discounter wie Lidl mit der Eigenmarke Silvercrest den Einstieg mit Hilfe relativ günstiger Smart Home Produkte erleichert.
Um jedoch nicht an „Hersteller-gebundene“ Gateways gebunden zu sein, empfiehlt sich der Einsatz eines „universellen“ Zigbee Gateways („Coordinator“). Ein in der Zigbee-Welt beliebtes Gateway ist der Conbee 2 vom Hersteller dresden elektronik. Dieser USB-Stick kann direkt unter Windows, Linux oder in Form eines Addons / einer Integration in Home Assistant genutzt werden und bedient problemlos bis zu 200 Zigbee-Geräte.
Als Schnittstelle zwischen den Zigbee-Geräten und dem Conbee 2 kommt die ebenfalls von dresden elektronik entwickelte Software deCONZ zum Einsatz. Die Middleware verarbeitet alle API-Aufrufe zwischen dem ConBee II-Stick und den Zigbee-Komponenten. Sie verfügt über eine offene API, die von vielen Geräteherstellern (wie IKEA, Philips und Xiaomi/Aqara) sowie von Hausautomatisierungssystemen wie eben zum Beispiel auch Home Assistant verwendet wird.
…und nun zum eigentlichen Problem inklusive der passenden Lösung:
Problem: Wechselnde IP-Adresse des deCONZ Containers
Wer sich dafür entscheidet, einen Conbee II mit deCONZ auf einem Rasberry Pi innerhalb von Home Assistant zu betreiben, wird während des Setups von deCONZ bzw. der Installation der Home Assistant Integration nach einer IP-Adresse für das Gateway gefragt. Diese wird einfach auf der deCONZ Konfigurationsseite ausgelesen und sieht in der Regel so oder so ähnlich aus:
Die gezeigte IP-Adresse wird automatisch für den des deCONZ Docker Container während des Installationsvorgangs für deCONZ von Home Assistant vergeben. Leider ist die Adresse nicht statisch und kann sich, beispielsweise bei einem (ungewollten) Reboot des Hosts, beliebig ändern. So könnte die Adresse vor dem Reboot 172.30.33.4 und anschließed 172.30.33.44 lauten.
Diese nicht geplante und ungewollte Änderung führt dazu, dass das Zigbee-Mesh an sich weiterin funktioniert, jedoch Home Assistant keine Verbindung mehr zum deCONZ-(Docker-) Container aufbauen kann, somit keine REST-Calls abgesetzt und letztendlich keines der angelernten eingebunden Zigbee-Geräte mehr kontrolliert werden kann.
Lösung: IP-Adresse des Hostsystems (z.B. Raspberry Pi) verwenden
Die Lösung für dieses Problem ist relativ simpel:
Durch das manuelle setzen einer IP-Adresse in einer (versteckten) Home Assistant Konfigurationsdatei, kann die ungewollte Adressänderung und sämtliche unangenehme Nebeneffekte mit wenigen Klicks verhindert werden.
Hierzu wird die IP-Adresse des Hostsystems (in diesem Beispiel der Raspberry Pi auf dem sich der Home Assistant befindet) konfiguriert. Die IP des Raspis bleibt aufgrund einer DCHP-Reservierung auf dem heimischen DHCP-Servers in der Regel immer gleich.
Zur Anpassung kann das Tool „SSH server“ aus dem HA Add-on-Store bezogen verwendet werden. Bei diesem Tool handelt es sich um eine einfache, aber durchaus funktionale „onboard“ Lösung , die den Remote Zugriff via SSH (z.B. putty) ermöglich und zusätzlich einen eingebauten, lokalen SSH Client bietet.
Die versteckte Konfigurationsdatei ist unter folgendem Pfad zu finden und wird mit dem vi-Texteditor bearbeitet:
/config/.storage/core.config_entries
Sobald die Datei mit vi geöffnet wurde, wird nach dem deconz Abschnitt (domain) gesucht. Unter host wird nun core-deconz eingetragen.
Dies sorgt dafür, dass der Container immer die IP des Hostsystems nutzt und das Gateway eine feste, statische IP hat. Diese bleibt nach einem (un-) geplanten Neustart des Hosts gleich und alle REST Calls kommen wie gewünscht ans Ziel. Sind alle Änderungen vorgenommen gespeichert muss Host neugestartet werden. Das Ergebnis sieht so aus:
Meine Erfahrungen mit mehreren Installationen haben gezeigt, das es sich immer bewährt hat die IP fix einzustellen um eine potentielle „Fehlerquelle“ in einem 24/7/365 laufenden System von Anfang an zu umschiffen.