Dein Smart Home endet nicht an der Haustür. Irgendwann willst du Daten von außen reinholen: einen Wert von einer Web-API, eine Information, für die es keine fertige Integration gibt. Oder umgekehrt: Ein externer Dienst soll bei dir zuhause etwas auslösen. Für beide Richtungen hat Home Assistant Bordmittel, REST-Sensoren und Webhooks.
Im Video baue ich beides einmal komplett auf, vom API-Aufruf bis zur fertigen Automation. Hier das Prinzip zum Nachlesen.
Zwei Richtungen, zwei Werkzeuge
| Werkzeug | Richtung | Home Assistant ist... | Beispiel |
|---|---|---|---|
| REST-Sensor | Daten kommen rein, auf Abruf | der Fragende | Spritpreise, Witz des Tages, eigene Server-API |
| Webhook | Ereignis kommt rein, per Anstoß | der Empfänger | Externer Dienst meldet "Paket versendet" |
Der Unterschied liegt im Wer-fragt-wen. Beim REST-Sensor fragt Home Assistant regelmäßig bei einer URL nach und speichert die Antwort als Sensorwert. Beim Webhook stellt Home Assistant eine eigene URL bereit und wartet, bis jemand von außen anklopft.
REST-Sensor einrichten: Schritt für Schritt
Ein REST-Sensor ist schnell konfiguriert: eine URL, ein Abfrage-Intervall und die Angabe, welcher Teil der Antwort dich interessiert. Mein Lieblingsbeispiel aus dem Video ist der "Dad Joke of the Day" auf meinem Dashboard. Null praktischer Mehrwert, aber ein perfektes Übungsobjekt, weil die API kostenlos ist und sauberes JSON liefert.
Bevor du YAML schreibst, schau dir die API-Antwort an. Die meisten Dienste dokumentieren das, und so eine JSON-Antwort sieht etwa so aus:
{
"id": "abc123",
"joke": "Why did the scarecrow win an award? He was outstanding in his field.",
"status": 200
}Drei Felder: eine ID, der eigentliche Witz und der Status (200 heißt, die Anfrage hat geklappt). Uns interessiert nur das Feld joke, und genau das sagt das value_template:
1sensor:
2 - platform: rest
3 name: "Witz des Tages"
4 resource: https://api.beispiel.de/witz
5 headers:
6 Accept: application/json
7 scan_interval: 43200
8 value_template: "{{ value_json.joke }}"Der Header Accept: application/json teilt der API mit, dass du die Antwort als JSON willst und nicht als HTML-Seite. value_json ist dann die fertig eingelesene Antwort, mit dem Punkt greifst du auf einzelne Felder zu. Nach dem Speichern lädst du die YAML-Konfiguration neu und findest den Sensor in den Entwicklerwerkzeugen unter Zuständen. Ab da ist er eine ganz normale Entity: Du legst sie aufs Dashboard, lässt sie dir vorlesen oder triggerst Automationen damit. Eine kompakte Anleitung zum Nachbauen habe ich auch als Snippet.
Zwei Praxis-Hinweise. Wähle das scan_interval so groß wie möglich, viele kostenlose APIs begrenzen die Zahl der Anfragen. Der Wert ist in Sekunden, 43200 heißt also alle zwölf Stunden, und für einen Witz des Tages reicht das dicke. Und wenn die API einen Schlüssel verlangt, gehört der in die secrets.yaml, nicht in die Konfiguration. Wie das geht, steht im YAML-Guide.
Komplexere Antworten: Wenn der Wert tiefer im JSON steckt
Nicht jede API liefert so ein flaches JSON wie die Witz-API. Auf meinem Dashboard zeige ich zum Beispiel meine YouTube-Abonnenten an, und die Statistik-API dahinter packt die Werte in eine Tabelle mit mehreren Einträgen. Dann reicht ein einfacher Punkt-Zugriff nicht mehr, du musst über die Liste laufen und den richtigen Eintrag herausfischen:
1sensor:
2 - platform: rest
3 name: "YouTube Abonnenten"
4 resource: https://api.beispiel.de/statistik
5 scan_interval: 43200
6 value_template: >-
7 {%- for eintrag in value_json.table -%}
8 {%- if eintrag.name == 'subscribers' -%}
9 {{ eintrag.count }}
10 {%- endif -%}
11 {%- endfor -%}Die Schleife geht alle Einträge durch, und sobald der Name passt, gibt sie das Feld count zurück. Solche Templates testest du am besten vorab in den Entwicklerwerkzeugen im Template-Tab, da siehst du sofort, ob dein Pfad durch das JSON stimmt. Mehr Beispiele für externe Daten auf dem Dashboard zeigt das REST-API-Snippet.
Und wenn der Sensor trotzdem nur "unknown" anzeigt? Dann stimmt fast immer der Feldname im Template nicht mit der echten Antwort überein. Ruf die API-URL einmal im Browser auf und vergleiche Buchstabe für Buchstabe. Eine zweite Stolperfalle: Der Zustand einer Entität darf maximal 255 Zeichen lang sein. Ein sehr langer Witz fliegt also raus, dann hilft nur Kürzen per Template.
Webhooks: Von außen Automationen anstoßen
Ein Webhook ist in Home Assistant einfach ein Trigger-Typ. Du legst eine Automation an, wählst "Webhook" als Auslöser, und Home Assistant generiert dir automatisch eine ID. Ab dann lauscht das System auf der Adresse /api/webhook/deine-id. Schickt irgendjemand eine Anfrage dorthin, feuert die Automation.
Das Schöne: Die Gegenseite braucht keinerlei Home-Assistant-Kenntnisse. Jeder Dienst, der eine URL aufrufen kann, kann deine Automation starten. Klassische Kandidaten sind Automatisierungsplattformen wie make.com, eigene Skripte auf einem Server oder Geräte, die bei Ereignissen eine URL ansteuern können.
Zum Ausprobieren brauchst du nicht mal ein externes Tool. Im Video baue ich eine Automation, die bei einem Webhook-Aufruf eine anhaltende Benachrichtigung erzeugt:
1automation:
2 - alias: "Webhook: Neue E-Mail"
3 trigger:
4 - platform: webhook
5 webhook_id: "neue-email-x7k2m9p4q8w1"
6 allowed_methods:
7 - GET
8 local_only: true
9 action:
10 - service: persistent_notification.create
11 data:
12 title: "Neue E-Mail"
13 message: "Du hast Post. Schau mal in dein Postfach."Dann rufst du im Browser http://deine-home-assistant-adresse:8123/api/webhook/neue-email-x7k2m9p4q8w1 auf. Du siehst nur eine weiße Seite, das ist normal und heißt: Anfrage angekommen. In Home Assistant ploppt im selben Moment die Benachrichtigung auf.
Ein Detail, an dem viele beim Testen scheitern: Der Browser schickt beim Aufruf einer URL immer einen GET-Request, Webhooks erwarten standardmäßig aber POST. Deshalb steht im Beispiel allowed_methods: GET, im Editor ist das der Haken bei "GET" in den Trigger-Einstellungen. Für den produktiven Einsatz mit einem Dienst, der POST schickt, nimmst du den Haken wieder raus.
Mitgeschickte Daten landen in der Trigger-Variable und lassen sich per Template in den Aktionen weiterverwenden. Hängst du an die URL etwa ?betreff=Rechnung an, liest du den Wert mit {{ trigger.query.betreff }} aus. Bei POST-Requests mit JSON-Inhalt heißt es {{ trigger.json.betreff }}. So transportiert ein einziger Webhook auch Inhalte, nicht nur das nackte "es ist passiert".
Das Thema Sicherheit
Ein Webhook hat keine Authentifizierung. Die ID in der URL ist das einzige Geheimnis. Daraus folgen drei Regeln, die ich dir ans Herz lege.
Erstens: Behandle die Webhook-ID wie ein Passwort. Lang, zufällig, nicht licht-an. Der Editor generiert dir automatisch eine zufällige ID, nimm die. Zweitens: Lass Webhooks nur lokal erreichbar, wenn der Auslöser aus dem eigenen Netz kommt. Der Haken "Nur über das lokale Netzwerk zugänglich" ist standardmäßig gesetzt, und das aus gutem Grund. Erst wenn ein externer Dienst den Webhook auslösen soll, nimmst du ihn raus. Dafür muss dein Home Assistant natürlich von außen erreichbar sein, wie das sicher geht, steht im Guide zu Fernzugriff und Sicherheit. Drittens: Häng an Webhook-Automationen keine kritischen Aktionen wie das Entriegeln der Haustür. Für Licht, Benachrichtigungen und Status-Updates sind sie großartig, für die Tür nicht.
Wann lohnt sich das alles?
Mein Rat: Schau zuerst, ob es eine fertige Integration gibt, notfalls über HACS. Die ist fast immer komfortabler als ein selbstgebauter REST-Sensor. Aber für die Lücken dazwischen, die kleine Nischen-API oder den Dienst, der einfach nur eine URL aufrufen kann, sind REST und Webhooks genau das richtige Werkzeug. Einmal verstanden, hast du damit eine Schnittstelle zu praktisch allem, was im Internet spricht.
Häufige Fragen
Wie richte ich einen REST-Sensor in Home Assistant ein?
Du brauchst nur einen Eintrag in der configuration.yaml oder einer eingebundenen Datei: platform: rest, dazu die URL als resource, ein scan_interval in Sekunden und ein value_template, das den gewünschten Wert aus der Antwort zieht. Danach die YAML-Konfiguration neu laden, und der Sensor taucht in den Entwicklerwerkzeugen auf. Eine Codeoberfläche oder Programmierkenntnisse brauchst du dafür nicht, kopieren und anpassen reicht.
Warum zeigt mein REST-Sensor "unknown" oder "unavailable" an?
"Unavailable" heißt meist, dass die URL nicht erreichbar war oder die API einen Fehler liefert. "Unknown" deutet auf ein Template-Problem hin: Der Feldname in value_json passt nicht zur echten Antwort. Ruf die API-URL im Browser auf, vergleiche die Feldnamen exakt und teste dein Template in den Entwicklerwerkzeugen. Und denk an die Grenze von 255 Zeichen pro Zustand, längere Werte verwirft Home Assistant.
Was bedeutet value_json im value_template?
value_json ist die JSON-Antwort der API, die Home Assistant für dich schon eingelesen hat. Mit der Punktschreibweise greifst du auf einzelne Felder zu, value_json.joke holt also das Feld "joke" aus der Antwort. Bei verschachtelten Antworten hängst du weitere Punkte an oder gehst mit einer Schleife durch Listen.
Brauche ich für Webhooks eine Portfreigabe?
Solange der Auslöser aus deinem eigenen Netzwerk kommt, nicht. Erst wenn ein externer Dienst wie make.com deinen Webhook aufrufen soll, muss deine Home-Assistant-Instanz von außen erreichbar sein, etwa über Home Assistant Cloud oder einen Reverse Proxy. Dann entfernst du am Trigger den Haken für "nur lokal" und behandelst die Webhook-ID wie ein Passwort.
