Blog

Langlebige Zugriffstoken in Home Assistant: erstellen, warum vom Admin, und „verbunden, aber leer“

Mit einem langlebigen Zugriffstoken meldet sich eine App oder ein Skript ohne Passwort bei Home Assistant an. Hier steht, wo es liegt, wie du eines erstellst, das auf Anhieb funktioniert, und warum „verbunden, aber leer“ fast immer heißt, dass der falsche Benutzer es erstellt hat.

Veröffentlicht 19 Min. Lesezeit

In diesem Artikel
  1. Die kurze Antwort
  2. Was ein langlebiges Zugriffstoken ist
  3. Wo du es findest
    1. „Ich finde es nicht“
  4. Erstellen und kopieren
  5. Warum manche Apps das Token eines Administrators brauchen
    1. Ist es eine gute Idee, einer App Adminrechte zu geben?
  6. „Es funktioniert, zeigt aber nichts“: die 401 bei /api/template
    1. Was Home Assistant anzeigt
    2. Wie AmazHA es erkennt und benennt
    3. So prüfst du, ob ein Benutzer Administrator ist
  7. Selbst prüfen mit curl
    1. Die 401 bei „Local access only“
  8. Probleme beim Einfügen
    1. Was AmazHA bereinigt und was es ablehnt
  9. Sicher aufbewahren
  10. In AmazHA
    1. Ein Token, zwei Adressen
    2. Wohin das Token geht und wohin nicht
    3. Wenn AmazHA etwas zum Token meldet
  11. Häufige Fragen

Die kurze Antwort

Ein langlebiges Zugriffstoken ist ein Passwortersatz für Apps und Skripte: Du erstellst es in deinem Home-Assistant-Profil, im Tab Sicherheit, unter Langlebige Zugriffstoken, und Home Assistant zeigt es nur ein einziges Mal an. Es ist 10 Jahre gültig. Manche Apps brauchen das Token eines Administrators, weil Teile der API, etwa /api/template, jeden anderen Benutzer mit einer 401 abweisen.

Der Rest dieses Artikels geht jeden Punkt durch: was das Token ist, wo du es findest, wie du es kopierst, ohne es zu beschädigen, warum die Admin-Frage wichtig ist, wie du ein Token mit zwei curl-Befehlen testest und wie du deine Token im Griff behältst. Das durchgehende Beispiel ist AmazHA, eine Home-Assistant-App für Amazfit-Uhren, weil sie jeden dieser Punkte berührt: Sie braucht ein Token, sie braucht das Token eines Administrators, und sie muss mit Token umgehen, die beim Kopieren und Einfügen verstümmelt ankommen.

Was ein langlebiges Zugriffstoken ist

Ein langlebiges Zugriffstoken ist ein Berechtigungsnachweis, mit dem ein Programm als dein Home-Assistant-Benutzer handeln kann, ohne über den Anmeldebildschirm zu gehen. Meldest du dich in der Weboberfläche an, gibt Home Assistant deinem Browser ein kurzes Zugriffstoken (30 Minuten) und ein Aktualisierungstoken, das es erneuert. Ein Skript, eine Handy-App oder eine Uhren-App kann diesen Anmeldeablauf nicht ohne Weiteres durchlaufen, deshalb bietet Home Assistant eine zweite Art Token an: eines, das du von Hand erstellst, einmal kopierst und dem Programm gibst.

In der Praxis zählen drei Eigenschaften:

  • Es ist 10 Jahre gültig. Die Dokumentation der Authentifizierungs-API von Home Assistant sagt, dass langlebige Token „10 Jahre gültig“ sind, und die Profilseite wiederholt es: Jedes Token gilt 10 Jahre ab seiner Erstellung.
  • Es wird nur einmal angezeigt. Home Assistant speichert das Token selbst nicht und kann es deshalb nicht noch einmal anzeigen. Verlierst du es, erstellst du ein neues.
  • Es ist der Benutzer, der es erstellt hat. Ein Token trägt die Berechtigungen des Benutzers, der es erstellt hat, nicht mehr und nicht weniger. Ein Token eines Administrators ist bei jeder Anfrage, die es signiert, ein Administrator; ein Token eines normalen Benutzers ist ein normaler Benutzer.

Das Token reist bei jeder Anfrage in einem HTTP-Header mit:

Authorization: Bearer <your token>

Mehr muss ein Client nicht tun. Es gibt keinen Benutzernamen, kein Passwort und keine Sitzung: Jede Anfrage mit einem gültigen Token in diesem Header wird als dieser Benutzer angenommen.

Wo du es findest

Langlebige Zugriffstoken erstellst du in deinem eigenen Benutzerprofil, im Tab Sicherheit. In der Home-Assistant-App oder im Browser:

  1. Öffne die Seitenleiste (das Menü ≡ auf dem Handy) und tippe unten auf deinen Namen.
  2. Öffne in deinem Profil den Tab Sicherheit.
  3. Weiter unten in diesem Tab ist der Abschnitt Langlebige Zugriffstoken, mit der Liste deiner vorhandenen Token und der Schaltfläche Token erstellen.

Die Benutzerdokumentation von Home Assistant beschreibt es genauso: Benutzerprofil › Sicherheit, die Seite, auf der du auch dein Passwort änderst, die Multi-Faktor-Authentifizierung einrichtest und Aktualisierungstoken verwaltest.

„Ich finde es nicht“

Der häufigste Grund ist der Tab. Das Profil öffnet sich mit seinen allgemeinen Einstellungen (Sprache, Design und Ähnliches); der Abschnitt mit den Token ist im Tab Sicherheit. Viele ältere Anleitungen sagen, du sollst ans Ende der Profilseite scrollen, was stimmte, bevor das Profil in Tabs aufgeteilt wurde.

Zwei weitere Gründe:

  • Du suchst das Token von jemand anderem. Jeder Benutzer sieht und verwaltet nur seine eigenen Token. Ein Token, das eine andere Person im Haushalt erstellt hat, erscheint nicht in deinem Profil, und du kannst es von dort aus nicht löschen.
  • Du bist als ein anderer Benutzer angemeldet, als du denkst. Prüf den Namen unten in der Seitenleiste. Braucht eine App das Token eines Administrators (mehr dazu unten), stell vor dem Erstellen sicher, dass dieser Name einem Administrator gehört.

Erstellen und kopieren

Ein Token zu erstellen, dauert vier Tipps; beim Kopieren geht es schief. Die Schritte:

  1. Tippe im Tab Sicherheit unter Langlebige Zugriffstoken auf Token erstellen.
  2. Home Assistant bittet dich, dem Token einen Namen zu geben. Nimm den Namen der App, zum Beispiel AmazHA. Die Namen müssen unter deinen Token eindeutig sein.
  3. Der nächste Dialog zeigt das Token mit dem Hinweis, dass du es jetzt kopieren sollst, weil es nicht noch einmal angezeigt wird. Kopiere es jetzt, vollständig.
  4. Schließ den Dialog. Das Token erscheint jetzt in der Liste unter seinem Namen, mit dem Tag seiner Erstellung.

Ein Token ist eine lange Zeichenkette aus Buchstaben, Ziffern, - und _, in drei durch Punkte getrennten Teilen. Ihre Länge ist der Grund für die meisten Probleme beim Kopieren: Sie passt nicht in eine Zeile, eine nachlässige Auswahl erwischt also nur einen Teil, und manche Apps kürzen eine lange Zeichenkette auf dem Bildschirm mit einer Auslassung (…) und kopieren dann, was sie anzeigen.

Praktische Gewohnheiten, die Ärger vermeiden:

  • Nutze die Kopierschaltfläche im Dialog, keine Auswahl von Hand.
  • Füge es direkt in die App ein, die es braucht. Ein Umweg über einen Chat, eine E-Mail oder eine Notiz-App kann unsichtbare Zeichen, typografische Anführungszeichen oder Zeilenumbrüche hinzufügen.
  • Setz kein Bearer davor, es sei denn, die App verlangt ausdrücklich den ganzen Header. Fast jede App fügt dieses Wort selbst hinzu.
  • Brauchst du es auf einem anderen Gerät, erstelle dort ein zweites Token, statt das erste herumzuschicken.

Warum manche Apps das Token eines Administrators brauchen

Manche Apps brauchen das Token eines Administrators, weil Home Assistant einige API-Endpunkte Administratoren vorbehält und ein Token nur kann, was sein Benutzer kann. Das deutlichste Beispiel ist der Template-Endpunkt, POST /api/template, der ein Jinja-Template auf dem Server rendert und das Ergebnis zurückgibt.

Im Quellcode von Home Assistant ist bei der View, die ihn bedient, APITemplateView in homeassistant/components/api/__init__.py, die Methode post mit @require_admin dekoriert. Dieser Decorator prüft den Benutzer hinter dem Token; ist er kein Administrator, löst er Unauthorized aus, was die HTTP-Schicht von Home Assistant in 401 Unauthorized verwandelt. Die Dokumentation der REST-API kennzeichnet den Endpunkt ebenfalls mit „Admin“.

Er ist nicht der einzige. Die REST-API teilt sich ungefähr so auf:

Endpunkt Token eines normalen Benutzers Token eines Administrators
GET /api/ (läuft die API?) Ja Ja
GET /api/states, GET /api/states/<entity_id> Ja Ja
POST /api/services/<domain>/<service> (Dinge ein- und ausschalten) Ja Ja
GET /api/camera_proxy/<entity_id> Ja Ja
POST /api/template Nein: 401 Ja
POST oder DELETE /api/states/<entity_id> (einen Zustand direkt schreiben) Nein Ja
POST /api/events/<event_type> Nein Ja
GET /api/error_log Nein Ja

Warum sollte eine App überhaupt den Template-Endpunkt brauchen? Weil manche Informationen nicht in den einfachen REST-Endpunkten stehen. Der deutlichste Fall sind die Bereiche: /api/states liefert jede Entität mit ihrem Zustand und ihren Attributen, aber nicht den Bereich, zu dem sie gehört, und die REST-API hat keinen Endpunkt, der Bereiche auflistet. Ein Template kann danach fragen: area_id(entity_id) und area_name(...) liefern den Bereich, den Home Assistant für jede Entität ermittelt, über die Einstellung der Entität selbst oder die ihres Geräts. Eine App, die dein Zuhause Raum für Raum zeigen will, so wie die Dashboards von Home Assistant, rendert deshalb ein Template und braucht dafür einen Administrator.

Ist es eine gute Idee, einer App Adminrechte zu geben?

Die Sicherheitshinweise von Home Assistant raten, Administratorzugriff nur Konten zu geben, die ihn brauchen. Eine App, die /api/template braucht, ist so ein Fall, und du hast zwei vernünftige Möglichkeiten:

  • Erstelle das Token mit deinem eigenen Administrator-Benutzer. Die einfachste Möglichkeit. Das Token steht unter seinem Namen in deinem Profil, und wenn du es löschst, widerrufst du nur diese eine App.
  • Leg für die App einen eigenen Administrator-Benutzer an, unter Einstellungen › Personen, melde dich einmal als dieser Benutzer an und erstelle dort das Token. Seine Angaben zur letzten Nutzung bleiben von deinen getrennt, und du kannst den ganzen Benutzer später abschalten. Lass ihn aktiv, solange die App ihn nutzt: Die Token eines deaktivierten Benutzers funktionieren nicht mehr. Schalte Local access only nicht ein, wenn sich die App auch von außerhalb deines Zuhauses verbindet, aus dem Grund, der im Abschnitt zur 401 unten steht.

So oder so verdient das Token dieselbe Sorgfalt wie ein Passwort: Das Token eines Administrators kann in Home Assistant alles, was du kannst.

„Es funktioniert, zeigt aber nichts“: die 401 bei /api/template

Wenn eine App sich erfolgreich verbindet und trotzdem nichts zeigt, ist die Ursache fast immer das Token eines Benutzers, der kein Administrator ist. Der Verbindungstest klappt, weil die meisten Apps mit GET /api/ testen und dieser Endpunkt jedes gültige Token akzeptiert. Auch die Zustände lassen sich lesen. Nur die Template-Anfrage scheitert, mit einer 401, und eine App, die ihre Geräteliste aus diesem Template baut, hat am Ende nichts anzuzeigen.

Der Ablauf, aus Sicht der App:

  1. GET /api/ mit dem Token: 200, {"message": "API running."}. Die App meldet „verbunden“.
  2. GET /api/states/...: 200. Die Zustände sind da.
  3. POST /api/template, um Entitäten Bereichen zuzuordnen: 401. Keine Bereiche, also keine Räume, also ein leerer Bildschirm.

Verwirrend ist, dass sonst nichts falsch aussieht. Die Adresse stimmt, das Token ist gültig, Home Assistant läuft. Sogar Aktionen können funktionieren: POST /api/services/... steht normalen Benutzern offen, ein Licht lässt sich mit demselben Token also weiterhin aus der App schalten.

Was Home Assistant anzeigt

Home Assistant zählt jede 401, die es sendet, als fehlgeschlagene Anmeldung, auch die aus der Admin-Prüfung. Sein Log bekommt eine Warnung, die mit „Login attempt or request with invalid authentication from …“ beginnt und die Adresse nennt, von der die Anfrage kam (zu Hause meist dein Handy oder dein Server), und die Weboberfläche zeigt die Benachrichtigung Login attempt failed (Anmeldeversuch fehlgeschlagen). Hast du die IP-Sperre mit einer Anzahl von Anmeldeversuchen bis zur Sperre eingeschaltet, sperren genug dieser 401 diese Adresse: Ab dann bekommt sie für alles 403 Forbidden, bis du sie aus ip_bans.yaml entfernst und Home Assistant neu startest.

Siehst du also wiederholt Benachrichtigungen über fehlgeschlagene Anmeldeversuche, die auf dein eigenes Handy zeigen, ist eine App mit dem Token eines normalen Benutzers, die einen Admin-Endpunkt aufruft, eine mögliche Erklärung, neben einem gelöschten Token.

Wie AmazHA es erkennt und benennt

AmazHA, das deine Bereiche über /api/template liest, prüft diesen Fall absichtlich, statt dich mit einer leeren Uhr allein zu lassen:

  • Wenn du auf Verbinden tippst, prüft das Handy zuerst die Adresse mit GET /api/ und sendet dann ein triviales Template, {{ 1 }}, an /api/template. Wird dieses Template mit einer 401, einer 403 oder einer 400 abgewiesen, wird das Token als nicht von einem Administrator markiert. Der Bildschirm Home Assistant zeigt dann Verbunden ✓ mit einer gelben Zeile darunter: „Verbunden, aber dieser Token hat keine Administratorrechte, daher kann die Uhr deine Entitäten nicht laden. Erstelle einen langlebigen Token bei einem Home-Assistant-Benutzer mit der Rolle Administrator und füge ihn oben ein.“
  • Auf der Uhr zeigt der Startbildschirm, wenn die Räume nicht geladen werden können, weil das Bereichs-Template abgewiesen wird, das Banner Admin-Token nötig · „Dein Token hat keine Adminrechte — nutze einen Home-Assistant-Admin-Benutzer“, statt eines allgemeinen Offline.
  • Im Support-Bericht, den du aus den AmazHA-Einstellungen senden kannst, sagt eine Zeile „HA token“, ob das Token als das eines Administrators erkannt wurde, ohne jemals das Token selbst zu enthalten.

Die Lösung ist in jedem Fall dieselbe: Erstelle als angemeldeter Administrator ein neues langlebiges Token, füge es ein und tippe noch einmal auf Verbinden. Schritt 5 von Wenn etwas nicht klappt zeigt es im Video.

So prüfst du, ob ein Benutzer Administrator ist

Öffne Einstellungen › Personen und dann den Tab Benutzer. Die Spalte Gruppe zeigt bei einem Administrator Administratoren; öffnest du einen Benutzer, siehst du den Schalter Administrator (mit dem Hinweis, dass Administratoren Benutzer, Geräte, Automationen und Dashboards verwalten können).

Es gibt einen schnelleren Test: Hat die Seitenleiste des Kontos, mit dem du angemeldet bist, gar keinen Eintrag Einstellungen, ist dieser Benutzer kein Administrator. Home Assistant registriert sein Konfigurationspanel nur für Administratoren, normale Benutzer sehen es also nie. Melde dich in diesem Fall ab, melde dich als Administrator an und erstelle das Token dort.

Selbst prüfen mit curl

Du kannst jedes Token in einer Minute von einem Computer im selben Netz testen, mit zwei curl-Befehlen: einem gegen /api/, den jedes gültige Token besteht, und einem gegen /api/template, den nur das Token eines Administrators besteht. Die Beispiele verwenden 192.168.1.50:8123 als Adresse von Home Assistant; ersetze sie durch deine. Sie laufen so, wie sie sind, in einem Terminal unter macOS oder Linux.

Damit das Token nicht in deinem Shell-Verlauf landet, liest du es zuerst in eine Variable ein. Füge das Token ein, wenn der Befehl wartet, und drück dann Enter:

read -rs HA_TOKEN

Test 1: Ist das Token gültig?

curl -s -w "\nHTTP %{http_code}\n" \
  -H "Authorization: Bearer $HA_TOKEN" \
  http://192.168.1.50:8123/api/

Ein gültiges Token antwortet mit {"message":"API running."} und HTTP 200. Achte auf den Schrägstrich am Ende: Der Endpunkt ist /api/, nicht /api.

Test 2: Gehört das Token einem Administrator?

curl -s -w "\nHTTP %{http_code}\n" -X POST \
  -H "Authorization: Bearer $HA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "{{ 1 }}"}' \
  http://192.168.1.50:8123/api/template

Das Token eines Administrators bekommt das gerenderte Template, 1, und HTTP 200. Das Token eines normalen Benutzers bekommt HTTP 401.

So liest du die beiden Ergebnisse zusammen:

Test 1 (/api/) Test 2 (/api/template) Was es bedeutet Was du tun kannst
200 200 Ein gültiges Token eines Administrators Das Token ist in Ordnung; such woanders
200 401 Ein gültiges Token eines normalen Benutzers Erstelle als Administrator ein neues Token
401 401 Das Token ist ungültig: gelöscht, abgeschnitten, der Benutzer deaktiviert, oder Local access only von außerhalb Erstelle ein neues Token und kopiere es vollständig
403 403 Die Adresse, von der du testest, ist gesperrt Entferne sie aus ip_bans.yaml und starte Home Assistant neu
404 oder eine Webseite (beliebig) Die Adresse ist nicht die API: ein Pfad hinter dem Port oder ein anderer Server Nimm nur die Server-Adresse, ohne etwas dahinter
Keine Antwort Keine Antwort Falsche Adresse, oder von deinem Standort aus nicht erreichbar Prüf zuerst die Adresse und das Netz

Zwei Einschränkungen. Erstens testet das das Token von deinem Computer aus; eine App auf deinem Handy kann einen anderen Weg zu Home Assistant nehmen, besonders unterwegs. Zweitens beweist ein bestandener Test 1 allein für Apps, die Bereiche brauchen, sehr wenig: Genau diesen Test besteht auch das Token eines normalen Benutzers.

Die 401 bei „Local access only“

Ein Benutzer mit eingeschaltetem Local access only kann sich nur aus deinem lokalen Netz anmelden, und Home Assistant wendet dieselbe Regel auf seine Token an. Eine Anfrage von einer Adresse außerhalb deines Netzes oder eine, die über Home Assistant Cloud ankommt, wird mit einer 401 abgewiesen, obwohl dasselbe Token zu Hause tadellos funktioniert. Funktioniert eine App in deinem WLAN und scheitert unterwegs mit einer 401, öffne den Benutzer unter Einstellungen › Personen und sieh dir diesen Schalter an, bevor du die Remote-Adresse verdächtigst. Zur Remote-Adresse selbst siehe Home Assistant unterwegs auf deiner Uhr.

Probleme beim Einfügen

Ein Token, das richtig aussieht, kann trotzdem falsch sein, weil das, was du eingefügt hast, nicht immer das ist, was Home Assistant dir gegeben hat. Home Assistant vergleicht das Token Zeichen für Zeichen, ein einziges zusätzliches oder fehlendes Zeichen macht es also ungültig und bringt eine 401. Die üblichen Verdächtigen:

Was passiert Wie es hineinkommt Folge
Unsichtbare Zeichen: ein Leerzeichen mit Nullbreite, ein geschütztes Leerzeichen, eine Byte-Order-Mark, ein weicher Trennstrich Kopieren über einen Chat, eine E-Mail oder eine Notiz-App Die Anfrage scheitert, manchmal noch bevor sie das Gerät verlässt
Typografische Anführungszeichen um das Token, etwa “…” oder ‘…’ Eine Notiz-App oder eine Tastatur, die Anführungszeichen „verschönert“ 401
Ein mit eingefügtes Bearer Einen ganzen Beispiel-Header aus einer Anleitung kopiert Die App sendet Bearer Bearer eyJ…: 401
Ein gekürztes Token, das auf … endet Von einem Bildschirm kopiert, der die lange Zeichenkette gekürzt hat 401, oder vom HTTP-Stack des Handys abgewiesen
Ein Zeilenumbruch in der Mitte Ein Token kopiert, das über zwei Zeilen umgebrochen war 401

Das Heilmittel ist für alle dasselbe: Kopiere das Token noch einmal mit der Kopierschaltfläche des Dialogs und füge es direkt ein. Ist der Dialog schon geschlossen, ist das Token weg; erstelle ein neues und lösch den alten Eintrag.

Was AmazHA bereinigt und was es ablehnt

AmazHA behebt die behebbaren Fälle selbst, sowohl beim Speichern des Tokens als auch noch einmal, wenn das Handy es für eine Anfrage liest:

  • Entfernt: Leerzeichen, Zeilenumbrüche, Zeichen mit Nullbreite, geschützte Leerzeichen, Byte-Order-Marks, weiche Trennstriche und Richtungszeichen, überall im Token. Keines davon kann Teil eines Home-Assistant-Tokens sein, das aus Buchstaben, Ziffern, -, _ und Punkten besteht.
  • An den Enden abgeschnitten: gerade und typografische Anführungszeichen, Backticks und Guillemets.
  • Am Anfang weggelassen: ein mit eingefügtes Bearer (in beliebiger Groß- und Kleinschreibung), weil AmazHA dieses Wort selbst hinzufügt.

Was die Bereinigung nicht beheben kann, ist ein sichtbares Zeichen, das in keinem Token vorkommt, typischerweise das … einer abgeschnittenen Kopie. AmazHA rät nicht: Es weigert sich, dieses Token überhaupt zu senden, es erreicht also keine Anfrage Home Assistant, und es wird kein fehlgeschlagener Anmeldeversuch gezählt. Der Bildschirm Home Assistant in den Einstellungen zeigt Token ungültig mit der Erklärung „Der Token enthält ein Zeichen, das ein Home-Assistant-Token nicht haben kann — meist eine abgeschnittene Kopie (…). Kopiere den vollständigen Token erneut aus deinem Home-Assistant-Profil › Sicherheit und füge ihn oben ein.“ Die Uhr zeigt Token prüfen · „Enthält ein ungültiges Zeichen — bitte neu einfügen“. Das ist Schritt 6 von Wenn etwas nicht klappt.

Sicher aufbewahren

Behandle jedes langlebige Token wie ein Passwort, das 10 Jahre lang nicht abläuft: ein Token pro App, ein Name, der sagt, welche App, und lösch es an dem Tag, an dem du diese App nicht mehr nutzt. Konkret:

  • Ein Token pro App oder Gerät. Gibst du dasselbe Token an drei Programme, kannst du keines widerrufen, ohne die anderen beiden lahmzulegen, und du kannst nicht erkennen, welches davon gerade zugreift.
  • Benenne es nach der App. „AmazHA“, „Backup-Skript“, „Wand-Tablet“. Der Name ist alles, was du später in der Liste siehst; das Token selbst wird nie wieder angezeigt.
  • Wirf ab und zu einen Blick auf die Liste. Jeder Eintrag zeigt, wann er erstellt wurde und, sobald er genutzt wurde, wann und von wo zuletzt. Ein Token, das seit Monaten niemand genutzt hat, ist ein Kandidat zum Löschen.
  • Widerrufen heißt löschen. Lösch das Token im Tab Sicherheit anhand seines Namens. Die App, die es genutzt hat, scheitert bei ihrer nächsten Anfrage mit einer 401; sonst wird nichts angefasst.
  • Könnte ein Token in falsche Hände geraten sein, lösch es und erstelle ein neues. Löschen ist der einzige Weg, ein einzelnes Token zu widerrufen; der Ersatz ist in einer Minute in der App.
  • Füge ein Token nie in eine Support-Anfrage, einen Forenbeitrag oder einen Screenshot ein. Die Diagnose einer guten App braucht es nie.

Löschst du im selben Tab alle Aktualisierungstoken, meldet das deine Geräte ab, lässt aber die aktuelle Sitzung und deine langlebigen Token bestehen, wie der Bestätigungsdialog von Home Assistant sagt. Langlebige Token werden einzeln widerrufen.

In AmazHA

AmazHA braucht genau ein langlebiges Token, von einem Administrator, einmal in den AmazHA-Einstellungen in der Zepp-App eingetragen; dieses eine Token gilt für die lokale und die Remote-Adresse, und es bleibt auf deinem Handy. Die Verbindungsfelder stehen bereit, sobald die Vollversion freigeschaltet ist (eine einmalige Freischaltung, kein Abo: siehe Vollversion freischalten). Dann:

  1. Erstelle das Token als Administrator, wie oben beschrieben (Schritte 1–3 von Home Assistant verbinden).
  2. Geh in der Zepp-App zu Profil › deine Uhr › Apps › AmazHA › Einstellungen und tippe auf Home Assistant (Schritt 4).
  3. Trag deine Adresse zu Hause bei Lokale URL (LAN) ein, zum Beispiel http://192.168.1.50:8123, und, wenn die Uhr auch unterwegs funktionieren soll, die Adresse von außen bei Remote-URL. Jedes der beiden Felder darf leer bleiben.
  4. Füge das Token bei Langlebiges Zugriffstoken ein (Schritt 7).
  5. Tippe auf Verbinden. Sind beide Adressen eingetragen, zeigt das Ergebnis jede einzeln an, LAN und Remote; mit einer Adresse steht dort Verbunden ✓. Gehört das Token keinem Administrator, erscheint darunter die oben beschriebene gelbe Zeile.

Ein Token, zwei Adressen

Für die Remote-Adresse brauchst du kein zweites Token. Ein Token gehört zu einem Benutzer, nicht zu einer Adresse: Dasselbe Token ist gültig, ob die Anfrage Home Assistant über dein WLAN oder von außen erreicht. Zu Hause nutzt AmazHA die lokale Adresse; die Remote-Adresse ist nur für die Zeit, in der das Handy unterwegs ist. Die einzige Ausnahme ist der oben beschriebene Benutzer mit Local access only, dessen Token von außen absichtlich abgewiesen wird.

Wohin das Token geht und wohin nicht

Die Uhr spricht nie direkt mit Home Assistant. Das tut dein Handy, über die Zepp-App, und dort, auf dem Handy, ist das Token gespeichert. Es wird nur an deinen Home-Assistant-Server gesendet, im Header Authorization der eigenen Anfragen des Handys; es wird nie an die Uhr gesendet, die über ihre Bluetooth-Verbindung mit dem Handy nur bekommt, was sie anzeigt. AmazHA hat keinen eigenen Server, über den das Token laufen könnte, und der Support-Bericht enthält es nie.

Was das Handy mit dem Token tut, Anfrage für Anfrage:

Was Home-Assistant-Endpunkt Admin nötig?
Die Adresse prüfen, wenn du auf Verbinden tippst GET /api/ Nein
Prüfen, ob das Token einem Administrator gehört POST /api/template mit {{ 1 }} Ja
Die Zustände der gewählten Geräte lesen GET /api/states, GET /api/states/<entity_id> Nein
Jedes Gerät seinem Bereich zuordnen, damit die Uhr Räume zeigt POST /api/template Ja
Dinge ein- und ausschalten, Szenen starten POST /api/services/<domain>/<service> Nein
Kamerabilder /api/camera_proxy/<entity_id> Nein
Die eigenen Sensoren der Uhr registrieren, wenn du sie einschaltest POST /api/mobile_app/registrations Nein

Die letzte Zeile ist die Funktion Uhr-Sensoren, die Herzfrequenz, Schritte, Akku und mehr deiner Amazfit als Gerät der Integration Mobile App an Home Assistant sendet: Die Daten deiner Amazfit an Home Assistant senden erklärt sie.

Wenn AmazHA etwas zum Token meldet

Auf der Uhr In den AmazHA-Einstellungen Ursache Lösung
Admin-Token nötig Verbunden ✓ mit der gelben Admin-Zeile Das Token gehört einem normalen Benutzer Neues Token von einem Administrator (Fehlerbehebung, Schritt 5)
Token prüfen Token ungültig Das Token enthält ein Zeichen, das kein Token hat, meist … aus einer gekürzten Kopie Kopiere das ganze Token noch einmal (Fehlerbehebung, Schritt 6)
Offline · Home Assistant nicht erreichbar, mit einem Code, der 401 nennt Fehler 401 (sind beide Adressen eingetragen, wird die fehlerhafte rot angezeigt) Das Token wurde gelöscht, sein Benutzer deaktiviert, oder es wird von außen abgewiesen Erstelle ein neues Token und füge es ein
„Öffne die Phone-App und trage HA-Server-URL + Token ein“ URL und Token eingeben Noch nichts gespeichert Trag eine Adresse und das Token ein und tippe auf Verbinden

Der kleine Code unter Offline ist für den Support da: Wenn du uns schreibst, verrät ein Foto der Uhr genau, was schiefgelaufen ist. Für jede andere Meldung, die die Uhr zeigen kann, siehe Wenn etwas nicht klappt.

Häufige Fragen

Wo finde ich die langlebigen Zugriffstoken in Home Assistant?

Öffne dein Benutzerprofil (tippe unten in der Seitenleiste auf deinen Namen) und wechsle in den Tab Sicherheit. Dort ist der Abschnitt Langlebige Zugriffstoken mit der Schaltfläche Token erstellen. Ältere Anleitungen, die sagen „scroll ans Ende der Profilseite“, stammen aus der Zeit vor den Tabs.

Warum fehlt der Abschnitt Langlebige Zugriffstoken?

Meist, weil du im ersten Tab des Profils bist: Der Abschnitt ist im Tab Sicherheit. Jeder Benutzer sieht und verwaltet nur seine eigenen Token, ein Token, das ein anderer Benutzer erstellt hat, findest du in deinem Profil also nicht.

Wie lange ist ein langlebiges Zugriffstoken gültig?

Ein Token, das du auf der Profilseite erstellst, ist ab seiner Erstellung 10 Jahre gültig. Es läuft nicht ab, wenn du dich abmeldest, und funktioniert, bis du es löschst, der Benutzer deaktiviert wird oder die 10 Jahre vorbei sind.

Kann ich ein Token noch einmal sehen, nachdem ich den Dialog geschlossen habe?

Nein. Home Assistant speichert das Token selbst nicht und kann es deshalb nicht noch einmal anzeigen. Hast du es verloren, lösch den alten Eintrag und erstelle ein neues.

Warum bekomme ich 401 Unauthorized mit einem Token, das vorher funktioniert hat?

Das Token wurde gelöscht, der Benutzer wurde deaktiviert, oder das Token wurde unvollständig eingefügt. Auch ein Benutzer mit Local access only (nur lokaler Zugriff) bekommt eine 401, wenn die Anfrage von außerhalb des Netzes oder über Home Assistant Cloud kommt. Teste es mit den curl-Befehlen aus diesem Artikel.

Muss das Token von einem Administrator stammen?

Nur für Apps, die Teile der API nutzen, die Administratoren vorbehalten sind. POST /api/template ist einer davon: Der Code von Home Assistant markiert ihn mit @require_admin. Das Token eines normalen Benutzers kann Zustände lesen und Dienste aufrufen, aber jede Template-Anfrage bekommt eine 401.

Braucht AmazHA ein Admin-Token?

Ja. AmazHA liest deine Bereiche über die Template-API, die Home Assistant Administratoren vorbehält. Mit dem Token eines normalen Benutzers klappt die Verbindung, aber die Uhr kann deine Räume nicht laden, und AmazHA zeigt Admin-Token nötig. Siehe Schritt 5 von Wenn etwas nicht klappt.

Wie widerrufe ich ein Token?

Such das Token in deinem Profil, Tab Sicherheit, unter Langlebige Zugriffstoken anhand seines Namens und lösch es. Die App, die es nutzt, funktioniert ab ihrer nächsten Anfrage nicht mehr; alles andere bleibt unberührt.

Im Video ansehen

Die kurzen Anleitungen, auf denen dieser Artikel aufbaut: Videos auf Englisch, jeder Schritt auf Deutsch ausgeschrieben.

Alle Artikel