PROJEKTEINBLICK ·
Wenn ein Auftrag das Haus erreicht
Bis hierhin hatte mein Assistent vor allem auf dem Rechner gearbeitet: sprechen, Informationen anzeigen, Erinnerungen verwalten und Befehle ausführen. Mit Home Assistant kam eine Verbindung zu Geräten und Zuständen im Haus hinzu. Damit wurde die Unterscheidung zwischen einem verstandenen Auftrag und seiner tatsächlichen Wirkung noch wichtiger.
Ich konnte Joris bitten, das Licht in einem bestimmten Raum ein- oder auszuschalten, die Rollläden herunterzufahren oder eine Steckdose zu schalten. Auch den Ventilator konnte ich einschalten und Heizungswerte abfragen. Es gab etliche Möglichkeiten, bei denen aus einem gesprochenen Wunsch eine konkrete Aktion im Haus wurde.
Ich wollte dafür aber nicht selbst jede Geräteanbindung entwickeln. Mit Home Assistant gab es bereits eine Anwendung, deren Aufgabe genau darin lag. Mein Assistent konnte einen Zugang zu ihr bekommen und dabei seine eigene Rolle behalten.
Die Geräteverwaltung blieb bei Home Assistant
Joris musste nicht für jedes Gerät wissen, welches Protokoll dahinterstand. Die Anbindung übergab einen Auftrag an Home Assistant. Dort lag die Zuständigkeit für die eingerichteten Geräte und die weitere Verarbeitung.
Das hielt die Grenze zwischen den beiden Anwendungen überschaubar. Mein Assistent nahm die Eingabe entgegen, erkannte den passenden Weg und nutzte seine dafür vorgesehene Fähigkeit. Home Assistant lief auf einem Raspberry Pi in meinem Netzwerk, also auf einem separaten Gerät. Mein Assistent übermittelte den Auftrag über die Schnittstelle von Home Assistant dorthin.
Eine weitere Fähigkeit musste nicht bedeuten, dass ich auch das gesamte System dahinter nachbauen musste.
Im vorhandenen Handler geschieht das über die Gesprächsschnittstelle von Home Assistant. Der Befehl wird als Text übergeben. Eine zurückgelieferte sprachliche Antwort kann mein Assistent anschließend für seine Rückmeldung verwenden.
Ein Auftrag brauchte mehr als eine Adresse
Für die Verbindung brauchte die Anwendung die Adresse von Home Assistant und ein Zugriffstoken. Ohne Token wurde der Auftrag nicht einfach versuchsweise abgeschickt, sondern mit einer entsprechenden Rückmeldung abgelehnt.
Auch der eigentliche Befehl durfte nicht fehlen. Eine leere Eingabe war keine brauchbare Aufgabe für die andere Anwendung. Solche Prüfungen gehörten vor den Netzwerkaufruf.
| Schritt | Zuständigkeit |
|---|---|
| Eingabe verarbeiten | Joris erkennt den Auftrag und den passenden Skill |
| Ausführung freigeben | Die Anwendung bewertet den vorgesehenen Aktionspfad |
| Auftrag übergeben | Der Handler ruft die Gesprächsschnittstelle von Home Assistant auf |
| Rückmeldung verarbeiten | Joris übernimmt die gelieferte Antwort oder meldet ein Übertragungsproblem |
Die Freigabefrage aus Teil 4 bekam hier einen sehr konkreten Anlass. Der Home-Assistant-Befehl ist im vorgesehenen Approval-Pfad als bestätigungspflichtige Aktion eingeordnet. Die Modellantwort allein sollte nicht entscheiden, ob ein solcher Auftrag losgeschickt wurde.
Die Anbindung blieb gleichzeitig eine eigene Fähigkeit. Sie musste nicht überall in die Anwendung hineinreichen, nur weil ihre mögliche Wirkung größer war als die einer Wetterabfrage.
Gesendet war noch nicht nachgemessen
Bei der Rückmeldung musste ich genauer unterscheiden. Wenn der HTTP-Aufruf erfolgreich war, hatte mein Handler eine Antwort von Home Assistant erhalten. Daraus folgte nicht automatisch, dass Joris den tatsächlichen Zustand eines Geräts unabhängig überprüft hatte.
Der vorhandene Ablauf übernimmt die sprachliche Antwort aus der Schnittstelle. Wenn keine solche Antwort vorliegt, gibt es eine allgemeine Rückmeldung zum gesendeten Auftrag. Eine zusätzliche Abfrage des Gerätezustands gehört in diesem Handler nicht dazu.
Das war dieselbe Grundfrage, die mich schon bei den erfundenen Erfolgsmeldungen beschäftigt hatte. Nur ging es jetzt nicht mehr allein darum, was mein Sprachmodell behauptete. Auch die Bedeutung der Antwort eines angebundenen Systems musste klar sein.
Ein Fehler beim Aufruf oder ein nicht erreichbarer Dienst konnten als konkrete Probleme zurückgemeldet werden. Die Verbindung sollte nicht durch eine freundlich formulierte Antwort besser aussehen, als sie tatsächlich war.
Lokal bedeutete auch hier mehrere Systeme
Home Assistant konnte im eigenen Netzwerk stehen und war trotzdem eine weitere Anwendung mit einer eigenen Laufzeit. Mein Assistent musste sich mit ihr verbinden, Zugangsdaten verwenden und auf ihre Antwort warten.
Die räumliche Nähe nahm mir diese Aufgaben nicht ab. Ein Dienst im eigenen Netz konnte genauso ausfallen oder einen Auftrag ablehnen. Deshalb gehörten Zeitlimits und Fehlerbehandlung auch hier zur Integration.
Für mich passte das zu der Entwicklung von Local-only zu einem bewussteren Umgang mit Verbindungen. Ich wollte verstehen, welche Aufgabe mein Programm selbst erledigte und wo es sie an ein anderes System weitergab.
Der nächste Schritt führte in die Werkstatt
Mit Home Assistant war die Umgebung meines Rechners stärker Teil des Projekts geworden. Die Fähigkeiten ließen sich erweitern, während Sprache, Routing und Rückmeldungen weiterhin ihren gemeinsamen Unterbau nutzten.
Gleichzeitig wurde deutlicher, warum ich die Grenzen zwischen Vorschlag, Freigabe und Ausführung beibehalten wollte. Je greifbarer die Wirkung einer Aktion wurde, desto weniger genügte mir eine bloße Erfolgsmeldung.
Eine andere Erweiterung würde diese Frage noch weiterführen. Dort sollte aus einer Beschreibung nicht nur ein Auftrag entstehen, sondern zunächst ein sichtbares Modell, das ich prüfen und verändern konnte.
