Smart Home – Home Assistant Konfiguration
In diesem Beitrag geht es um die Home Assistant Konfiguration. Dies ist der zweite Teil der Serie, zum Vergleich von openHAB 2 vs. Home Assistant. Primär geht es in diesem Beitrag um einen Vergleich der beiden Programmiersprachen der System. Sowohl openHAB 2 als auch Home Assistant nutzen hier eine eigene Syntax, die sich nicht jedem von vornherein erschließt. Im Beitrag Smart Home openHAB 2 Konfiguration könnt ihr nachlesen wie ihr Items konfiguriert und diese in eine Sitemap einbindet. Items und Sitemaps kennt Home Assistant nicht. Die Konfiguration von Home Assistant erfolgt in der Sprache YAML. YAML hieß ausgeprochen mal Yet Another Markup Language. Es steht aber inzwischen für YAML A’int A Markup Language, da es mehr als eine einfache Markup-Sprache wie z.B. HTML ist. Ob diese nun von Vorteil oder Nachteil ist, werde ich am Ende im Fazit beschreiben.
Home Assistant Konfiguration – Editor
Zur Konfiguration von Home Assistant wird ein einfacher Texteditor verwendet. Ich empfehle jedem Notepad++, da dies wesentlich komfortabler als das normale Notepad ist. Ihr könnt natürlich auch direkt bei nano oder vi auf dem PI editieren. Für mich ist das aber nichts =)
Wenn ihr dem Beitrag Home Assistant Raspberry Pi Installation gefolgt seid, könnt ihr das Verzeichnis des Raspberry Pi als Netzwerklaufwerk einbinden. Ruft hierfür im Explorer folgendes auf.
\\homeassistant\
Nun macht eine Rechtsklick auf den Ordner „HOME ASSISTANT“ und wählt den Eintrag „Netzlaufwerk verbinden…“, so habt ihr das Laufwerk auch später für Konfigurationen im Zugriff. In diesem Verzeichnis liegt die Datei „configuration.yaml“. Diese wird Euch nun sehr sehr lange begleiten. Der Knaller ist, ihr könnt alles in diese eine Datei schreiben. Ich kann dies aber keinem empfehlen, da ihr Euch ansonsten durch tausende Zeile scrollen müsst. Entscheiden müsst ihr es allerdings selbst und ein aufteilen in mehrere Dateien ist später immer noch möglich.
Was ich bei dieser Möglichkeit wirklich gut finde ist, dass ihr so Eure eigene Struktur anlegen könnt und dies nicht vorgeben ist. Mir fallen dazu spontan mehrere alternative Ideen ein.
- Eine Technologie in eine Datei z.B. KNX.yaml die sowohl die Konfiguration als auch die gesamten Gewerke enthält.
- Alle Gewerke Technologie übergreifend in einer Datei. Alle Schalter wie KNX, Z-Wave, ZigBee … in eine schalter.yaml
- Die Gesamte Konfiguration aller Komponenten in einer Datei. KNX, Hue Emulation etc in konfiguration.yaml
Die Dateien werden später in die „configuration.yaml“ per include integriert. Was das ganze wirklich enorm flexibel macht, ist dass integrieren ganzer Verzeichnisse. Das heißt, ihr legt die Dateien x.yaml und y.yaml in ein Unterverzeichnis und bindet das gesamte Verzeichnis ein.
Nichts verstanden? Keine Angst, ich habe das anfangs auch nicht verstanden. Daher mal ein Beispiel. Anfangs sieht die Datei z.B. so aus (schon durch mich reduziert):
homeassistant: # Name of the location where Home Assistant is running name: Home # Location required to calculate the time the sun rises and sets latitude: 54.8667 longitude: 8.4333 # Impacts weather/sunrise data (altitude above sea level in meters) elevation: 0 # metric for Metric, imperial for Imperial unit_system: metric # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones time_zone: Europe/Berlin ...
Nachdem ich die ersten beiden KNX Geräte integriert habe, sieht die Datei so aus. Wie das ganze bei mehr als 50 KNX Komponenten aussieht, könnt ihr euch denken. Laaaaang =)
homeassistant: # Name of the location where Home Assistant is running name: Home # Location required to calculate the time the sun rises and sets latitude: 54.8667 longitude: 8.4333 # Impacts weather/sunrise data (altitude above sea level in meters) elevation: 0 # metric for Metric, imperial for Imperial unit_system: metric # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones time_zone: Europe/Berlin # KNX ANFANG knx: host: <GATEWAY_IP> port: 3671 switch db_ring: name: Home Assistant Schalter platform: knx address: 1/3/1 light db_lampe: name: Home Assistant Lampe emulated_hue_name: "Home Assistant Lampe" platform: knx address: 1/3/3 # KNX ENDE
Also nehmen wir nun den Teil der KNX Konfiguration und lagern diesen in einen Unterordner „includes“ in eine Datei KNX.yaml aus. Der Inhalt wird sich daraufhin wie folgt ändern.
homeassistant: # Name of the location where Home Assistant is running name: Home # Location required to calculate the time the sun rises and sets latitude: 54.8667 longitude: 8.4333 # Impacts weather/sunrise data (altitude above sea level in meters) elevation: 0 # metric for Metric, imperial for Imperial unit_system: metric # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones time_zone: Europe/Berlin knx: !include includes/knx.yaml
Dieser ganze Teil wandert in die Datei.
# KNX ANFANG knx: host: <GATEWAY_IP> port: 3671 switch db_ring: name: Home Assistant Schalter platform: knx address: 1/3/1 light db_lampe: name: Home Assistant Lampe emulated_hue_name: "Home Assistant Lampe" platform: knx address: 1/3/3 # KNX ENDE
Euch ist die KNX Datei immer noch zu groß? Dann könnt ihr diese auch in mehrere Dateien aufteilen und diese in einen eigenen Unterordner „knx“ legen. Als Beispiel:
- knxconf.yaml => enthält die KNX Konfiguration
- knxeg.yaml => enthält alle EG Gewerke oder
- knxlights.yaml => enthält alle Lichtquellen
Diese Dateien könnt ihr nun alle mittels folgender Zeile in die Konfiguration einbinden.
knx: !include_dir_merge_list includes/knx
Doch was ist denn eigentlich mit einer syntaktischen Prüfung wie im Smart Home Designer? Tja, die fehlt leider. Aber es gibt ja fasst alles und daher könnt ihr den YAML Code unter folgender Adresse prüfen.
http://beautifytools.com/yaml-validator.php
Home Assistant Konfiguration – YAML Syntax
YAML arbeitet mit einer eigenen Syntax und eigenen Elementen. Es lassen sich grob folgende Elemente unterscheiden.
- Komponenten
- sind das Hauptelement und bilden eine logische Bündelung von Plattformen
- sind ähnlich wie Bindings in OH2 und bieten die Anbindung von Technologien (KNX, Z-Wave) oder Services (Nachrichten wie Telegram, Sprache wie Google Home, Alexa)
- werden auch zur Bündelung von Gewerken wie z.B. Schalter mit den Plattformen (KNX, Z-Wave) verwendet
- Plattformen
- sind quasi eine Unterkategorie von den Komponenten.
- Die Komponente für Nachrichten kann so für die unterschiedlichsten Plattformen genutzt werden (Telegram, Slack, Twitter und und und)
- Die Komponente für Schalter wird anhand der Plattformen KNX, Z-Wave usw. unterteilt.
Hmm, auch wieder nicht ganz einfach. Daher auch hierfür mal eine einfaches Beispiel anhand von Hue und KNX. Wir möchten sowohl ein KNX als auch ein Z-Wave Schalter integrieren.
Hierfür definieren wir zuerst den Zugriff auf unsere Schnittstellen Z-Wave über den Pfad zum Z-Wave Modul und KNX über den Zugriff auf die IP Schnittstelle.
# Komponenten zwave: usb_path: /dev/ttyUSB0 knx: host: <GATEWAY_IP> port: 3671
Weiterhin müssen wir nun die Schalter-Komponente integrieren. Dies machen wir wie folgt.
# Z-Wave Schalter # ??? # KNX Schalter switch db_ring: name: Home Assistant Schalter platform: knx address: 1/3/1
Warum ist bei Z-Wave nichts? Die Komponenten werden angeblich automatisch erkannt und eine Konfiguration entfällt. Dies solle ja auch einer der großen Vorteile gegenüber openHAB 2 sein. Ich bin gespannt, ob es wirklich so ist.
Home Assistant Konfiguration – openHAB 2 vs Home Assistant
Die Home Assistant Konfiguration bewerte ich im Verlgeich zu openHAB 2 wie folgt.
| Vergleich | openHAB 2 | Home Assistant | Begründung |
|---|
Wie geht es weiter? Ich werde wie hier bereits angedeutet meine KNX Installation integrieren. Hier plane ich insbesondere einen Vergleich der Integration verschiedener Gewerke. Weiterhin werde ich – wenn ich es hinbekomme – ein Video zu den Reaktionszeiten drehen.
