DIY Home Automation mit Home Assistant

Home Automation kommt immer mehr im Mainstream an und die angebotenen Systeme und Alternativen werden immer zahl- und umfangreicher. Damit steigt auch die Anzahl der kompatiblen Geräte und Services, die leider viel zu oft auch ungefragt “nach Hause telefonieren” oder ohne diese permanente Anbindung gar nicht (vollständig) funktionieren. Weil ich aber finde dass beispielsweise die gemessene Lichtintensität hauptsächlich für meine Topfpflanze, in der der Sensor steckt, relevant ist, oder die eingestellte Farbe meiner Smart Lights eigentlich den Hersteller der Lampen nicht kümmern sollte, gibt es heute diesen Blogpost. Und vielleicht kann ich dich ja damit nochmal zum Nachdenken animieren, bevor du dein Alexa-aktiviertes WC mit dem Internet verbindest.

Unsere Reise durch die aufregende Landschaft von Home Automation beinhaltet neben einigen ernst gemeinten Statements und Produkten auch einige – wie soll man sagen – “interessante” und etwas fragwürdige Geräte. Wie beispielsweise diese 400$ (und anfänglich sogar 700$) billige smarte Saftpresse, die neben ihres horrenden Preises natürlich auch noch mit dem Internet verbunden werden kann, um dann keinen Saft auszupressen, falls das Internet in einer durstigen Minute mal nicht verfügbar sein sollte. Ach ja, hab ich schon erwähnt dass man die proprietären Saftpackungen, die natürlich vom selben Unternehmen extra für die Maschine vertrieben werden, einfach per Hand ausdrücken kann, ohne eine halbe Niere dafür hinzulegen? Soviel dazu, aber ich schweife ab.

Und, um eines gleich vorweg zu nehmen: ich bin absolut kein Gegner von Automation oder ähnlicher angebotener Services im Alltag – im Gegenteil. Ich versuche dabei nur, wenn nicht nötig, auf eine Anbindung an die großen Ökosysteme von beispielsweise Amazon, Apple oder Google zu verzichten, wenn ich sie nicht brauche – auch wenn das bedeutet, dass die Einrichtung mancher Geräte mit mehr Aufwand oder Wartung verbunden ist. Klar, das ist nichts für jeden, aber wer gerne herumbastelt oder mal eine kürzere Nacht einlegt, weil die Konfiguration eines neuen Geräts noch nicht zu 100% der eigenen Vorstellung entspricht, der ist hier genau richtig. Und ja, manche Menschen haben Spaß an so etwas – meine Wenigkeit inkludiert. Und um alle Anwesenden wieder zu beruhigen bzw. diese Aussage wieder zu relativieren: es hängen bei mir trotzdem auch ein Chromecast bzw. ein FireTV Stick am Monitor, die ich auch gerne verwende.

Home Assistant

Die Basis für mein System bildet Home Assistant, ein komplett freies, open-source Software Projekt, programmiert in Python, das als Hirn des gesamten Setups fungiert und derzeit auf einem Raspberry Pi 3B+ (kurz “RasPi”) läuft. Falls du vor hast, Home Assistant mal auszuprobieren, gibt es hier eine Demo, in der man sich austoben kann und falls du’s selber aufsetzen möchtest, würde ich als Basis ein RasPi 3B oder neuer empfehlen, da diese Boards mit einem Bluetooth Chip ausgestattet sind und auch die low energy Variante nativ unterstützen, ohne dass dann ein zusätzlich notwendiger Bluetooth Dongle einen USB Port blockiert. Um Home Assistant initial aufzusetzen reicht es, eines der angebotenen Images herunterzuladen, auf eine microSD zu flashen und selbige dann ins RasPi zu stecken und dieses an den Strom zu hängen. Alternativ gibt es natürlich auch die Möglichkeit einen Docker Container zu verwenden, aber es würde den Rahmen dieses Posts sprengen, wenn ich hier noch genauer darauf eingehen würde. Aber vertraue mir, ich verwende es und es funktioniert einwandfrei – für die Interessierten gibt es dieses Image auf Docker Hub. Ebenso findet man genug Informationen im Web, sollte man beim Setup auf Komplikationen stoßen. Gleiches gilt auch für die einzelnen Komponenten, um die es im nächsten Abschnitt gehen wird.

Komponenten und deren Konfiguration

Nachdem das eigentliche Grundsystem aufgesetzt wurde, geht der spannende Teil des Ganzen los. Home Assistant besteht aus verschiedenen Teilen, die untereinander für diverse einzelne Teilaspekte des Gesamtsystems verantwortlich sind, wie in der folgenden Abbildung ersichtlich. Einige davon kümmern sich dabei um den internen Zustand der einzelnen Teile (State Machine), andere hingegen um das hin- und her Senden von Events über den Event Bus und aus der für uns interessanten Box auf der linken Seite: die Komponenten.

https://developers.home-assistant.io/img/en/architecture/ha_architecture.svg

Quelle: Home Assistant Dev Docs

Wie schon im Bild angedeutet kann eine solche Komponente zuständig sein für Lichter oder Schalter und vieles, vieles mehr. Derzeit existieren über 1200 vorgefertigte Komponenten, die zur Verwendung “nur noch” zur Konfiguration des eigenen Home Assistants hinzugefügt werden müssen, um sie dann verwenden zu können. Manche der Komponenten können per UI konfiguriert werden, wie beispielsweise die Philips Hue, Google Cast oder seit neuestem auch die Z-Wave Komponente, wie im Screenshot ersichtlich. Einige andere befinden sich darunter in einer Liste und vereinfachen die Konfiguration ungemein, aber wo bleibt denn dann der Spaß an der ganzen Sache, richtig?

Eine manuelle Konfiguration hingegen kann wie folgt aussehen, wobei das folgende Beispiel für die Komponenten im nächsten Screenshot weiter unten verantwortlich ist. Um nicht den Großteil der Leser unnötig zu verwirren, ist die Konfiguration für weitere Screens an dieser Stelle allerdings nicht inkludiert.

homeassistant:
 name: Home
 latitude: 47.075262
 longitude: 15.440588
 elevation: 350
 unit_system: metric
 time_zone: Europe/Vienna
 customize: !include customize.yaml

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
zone: !include zones.yaml
scene: !include scenes.yaml

discovery:

sun:

device_sun_light_trigger:
 light_group: light.living_room
 device_group: group.people
      
device_tracker:
 - platform: nmap_tracker
   hosts: [IP Range meines Netzwerks]
   home_interval: 1
   new_device_defaults:
     track_new_devices: true
     hide_if_away: true

binary_sensor:
 - platform: workday
   country: AT
   province: ST

weather:
 - platform: zamg

sensor:
 - platform: time_date
   display_options:
     - 'date'
     - 'beat'

 - platform: miflora
   mac: [MAC Adresse des Sensors]
   name: MiFlora
   force_update: true
   median: 1
   monitored_conditions:
     - moisture
     - light
     - temperature
     - conductivity
     - battery

vacuum:
 - platform: roomba
   host: [IP Adresse des Staubsaugers]
   username: !secret roomba_blid
   password: !secret roomba_pw
   name: Roobert

shopping_list:

plant:
 Gummibaum:
   sensors:
     moisture: sensor.miflora_moisture
     battery: sensor.miflora_battery
     temperature: sensor.miflora_temperature
     conductivity: sensor.miflora_conductivity
     brightness: sensor.miflora_light_intensity

Im oberen Bereich sieht man einige Verweise (!include <Name>.yaml) auf andere Dateien, die weitere Subkomponenten beinhalten, wie zB. Groups, Zones oder Scenes, welche einzelne Geräte gruppieren, Zonen auf einer Karte mit Position und Radius definieren bzw. Szenen für smart lights auflisten. Diese obigen Zeilen zeigen jedenfalls die Konfiguration der Komponenten im folgenden Screenshot:

Wer jetzt aber dachte, das obige File reicht dann auch schon aus um diese erste Seite anzuzeigen, der liegt aber leider falsch. Immerhin habe ich von stundenlangem Konfigurationsaufwand geschrieben, also wollen wir diesem gefälligst auch gerecht werden.

UI “neu”: Lovelace

Die Darstellung der UI unter Home Assistant hat erst kürzlich eine große Neuerung erfahren. Sie setzt jetzt auf “Lovelace UI” und lässt sich mittlerweile auch über einen Editor Mode direkt im Browser ändern, was früher nicht möglich war. Die angezeigten Karten können auf die verschiedensten Arten und nach eigenem Belieben eingestellt werden, wobei es für diverse Komponenten schon die passenden Karten gibt, die die wichtigsten Funktionen derselben in den Vordergrund rücken. Nichtsdestotrotz gibt es auch hier eine zweite Variante zur Konfiguration, die früher leider (oder zum Glück?) noch die einzige war: das manuelle Skripten der UI per Textfile. Dazu wird ebenfalls jede Karte einzeln angelegt und jede Eigenschaft eigens eingetragen, nur eben in einem weiteren YAML File. Hätte ich das schon damals gewusst, als ich mit dem Setup meines Home Assistants angefangen habe, hätte ich vermutlich noch abgewartet, aber im Nachhinein ist man meist klüger – oder hat über die Zeit ein UI Konfigurationsfile mit fast 500 Codezeilen erschaffen. Eins von beiden. Und nein, das File poste ich hier nicht, sonst machen auch die letzten, die es bis hierher geschafft haben den Blogpost zu.

Wie die Darstellung im Endeffekt dann aussieht, kann ich dir dann auch nicht länger vorenthalten, darum ein paar Screenshots:

Ich stehe auf Graphen und Statusanzeigen, wie man vielleicht erkennen kann. Doch auch die fancy-sten Graphen und werden irgendwann zur Gewohnheit. Und vor allem fehlt für Home Automation halt nach wie vor ein Part, der auch schon im Wort vorkommt.

Automations

Nun zum letzten und einem der wichtigsten Parts des Ganzen: die Automatisierung. Diese Automations beschreiben im Endeffekt “nur”, was passieren soll, wenn sich ein Status zu einem anderen ändert oder ein anderer Trigger irgendeiner Art ausgelöst wird. Ob dadurch eine Aktion ausgeführt werden soll und wenn ja, welche und mit welchen Parametern. Einige wenige dieser Automations gibt es bereits vorgefertigt in Home Assistant, die eigenen müssen wiederum selbst erstellt werden – wer sich die obige Konfiguration genau durchsieht, hat womöglich diese Zeile entdeckt:

automation: !include automations.yaml

In der angegebenen Datei werden die eigenen Automationen niedergeschrieben und ein paar Zeilen darunter sieht man eine der vorgefertigten:

device_sun_light_trigger:
 light_group: light.living_room
 device_group: group.people

Im konkreten Fall kümmert sich diese Komponente um das automatische ein- und ausschalten des Lichts, gegliedert nach Gruppen für auslösende Geräte und geschaltete Lampen, basierend auf Präsenz und Sonnenstand. Klingt super kompliziert, heißt kurz und knackig aber einfach nur so viel wie:

  • + Home Assistant schaltet das Licht ein wenn die Sonne untergeht und jemand zuhause ist.
  • + Das Licht schaltet sich automatisch ein wenn jemand nach Sonnenuntergang nach Hause kommt.
  • + Das Licht schaltet sich automatisch aus, wenn alle (gewünschten) Geräte die Wohnung verlassen haben.

“Und woher weiß der Wunderwuzzi jetzt ob ich zuhause bin? Der hat doch auch kein Konzept von Helligkeit oder meinem Tagesablauf? SkyNet?! Aluhut?!”

Nur mit der Ruhe, ist alles ganz einfach und funktioniert ohne Robot Overlords – noch. Vielleicht hast du ja im ersten Screenshot der Konfiguration die Hue Lampen oder darauffolgenden die Karte mit “Active Devices” bzw. im Konfigurationsfile die folgenden Zeilen gesehen:

group: !include groups.yaml

sun:

device_tracker:
 - platform: nmap_tracker
   hosts: [IP Range meines Netzwerks]

Falls nicht, erzähl ich’s dir trotzdem, ich hab Zeit: diese Punkte spielen alle eine Rolle. Der device_tracker scannt kontinuierlich mein Netzwerk und sieht sich um, ob er eines der Geräte im Netzwerk findet, die in groups.yaml in der Gruppe people definiert sind (ich suche dabei in Wahrheit nach den Handies der Personen – ha, ausgetrickst). Dann überprüft er automatisch im Hintergrund ob die sun Komponente meldet, dass die Sonne bereits untergegangen ist und schaltet gegebenenfalls die Gruppe light.living_room ein. Ta-Da, Magie! Oder so ähnlich – zumindest fühlt es sich ein bisschen magisch an.

“So einfach” war das Ganze. Apropos Robot Overlords: du solltest nebenbei dann auch schon selber in der Lage sein, das Ganze für den Staubsaugerroboter nachzubauen. Also zumindest konzeptionell. Oder falls ich dich, wider Erwarten, auf den Geschmack gebracht habe, natürlich auch gerne in deiner eigenen Home Assistant Installation. Diese Automation macht nämlich auch nichts komplizierteres als bisher angeschnitten und verzichtet dabei auch noch auf den Sonnenstand, da dieser nun wirklich nicht relevant ist. Viel mehr wird er aktiviert, wenn es 9 Uhr an einem Arbeitstag ist, und sich niemand Zuhause aufhält. Wiederum, keine Raketenwissenschaft, aber dennoch beruhigend zu wissen, dass der Roboter scheinbar automatisch kapiert, wann er seine Arbeit zu verrichten hat. Besonders wenn man zwischendurch kurzzeitig vergessen hat, dass man das ja selbst mal so eingestellt hat.

Wie das allerdings in der Realität aussieht, wenn die kleinen Helferlein “hin und wieder” beschließen, sich selbstständig zu machen oder an den unmöglichsten Stellen festzufahren, ist eine andere Geschichte und liefert uns hier im Büro auch laufend den einen oder anderen Lacher. Als stolze “Eltern” mehrerer solcher Geräte könnten wir im Entwicklerbüro schön langsam einen ganzen Blogpost füllen mit Geschichten über ihre Abenteuer. Und neben der scheinbaren Arbeitserleichterung lehrt einen so ein Roboter vor allem eines: nichts mehr herumstehen zu lassen, das nicht eingesaugt, herumgezogen /-schoben oder zerbrochen werden soll.

Fazit

Wer’s bis hierher geschafft hat, dem möchte ich persönlich meinen Respekt aussprechen – ich bin selbst während des Schreibens mehrfach eingenickt. Aber vielleicht konnte ich ja bei jemandem das Interesse wecken, sich das Ganze selbst mal anzusehen. Oder vielleicht ist mir ja der ultimative Anwendungsfall selbst entgangen. Für neue Ideen, die ich zusätzlich einbauen könnte, bin ich daher jederzeit offen 🙂