ha-llmvision: Kameraereignisse in Home Assistant per multimodalen LLM auswerten

Welches Problem LLM Vision in einem bestehenden Kamera-Setup löst

Eine Überwachungskamera liefert Bewegung, aber keine Bedeutung. Wer wissen will, ob eine Person im Vorgarten stand, ob ein Paket abgelegt wurde oder ob die Katze wieder auf der Fensterbank sitzt, muss entweder selbst in die Aufnahmen schauen oder klassische Objekterkennung mit festen Klassen trainieren. LLM Vision setzt an dieser Stelle an: Die Integration schickt Bilder, Videodateien, Live-Kamerastreams oder Frigate-Ereignisse zusammen mit einem Prompt an ein multimodales Sprachmodell und übernimmt die textuelle Antwort zurück in Home Assistant. Laut README kann sie Fragen beantworten und Beschreibungen liefern, sich Personen, Haustiere und Objekte merken und eine Timeline der Kameraereignisse führen, die sich auf einem Dashboard anzeigen oder über Assist abfragen lässt. Zielgruppe sind damit nicht Einsteiger ohne Kameras, sondern Leute, die bereits eine Aufnahme-Infrastruktur und eine Automatisierungsschicht in Home Assistant betreiben und dort eine semantische Ebene ergänzen wollen. Wer nur eine einzelne Türklingel mit Bewegungsmeldung hat, gewinnt wenig.

Wie die Verarbeitung abläuft: Provider, Prompt, Sensor

Die Integration ist als Home-Assistant-Integration mit konfigurierbaren Einträgen aufgebaut. Ein Eintrag steht für einen AI-Provider, ein zweiter für die Integration selbst. Aus dem README geht hervor, dass LLM Vision OpenRouter, OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure, Groq, Ollama, Open WebUI, LocalAI sowie jeden Anbieter mit OpenAI-kompatiblen Endpunkten unterstützt. Der Datenfluss ist damit im Kern immer derselbe: Ein Auslöser in Home Assistant (Blueprint, Automatisierung oder Dienstaufruf) übergibt ein Medium und einen Prompt an die Integration. Die Integration leitet das an den konfigurierten Provider weiter und schreibt die Modellantwort in Sensoren, die sich in Automatisierungen weiterverwenden lassen. Zusätzlich speichert sie Ereignisse in einer Timeline, die laut README optional über eine Timeline Card im Dashboard dargestellt wird. Für die Zwischenspeicherung von Snapshots nutzt die Integration das Verzeichnis /media, das Home Assistant als sicherer als das Konfigurationsverzeichnis beschreibt. Das ist eine bewusste Entscheidung gegen das Ablegen von Bilddaten unter /config, und sie hat Konsequenzen für Container-Installationen.

Installation über HACS und der Stolperstein /media

Der Quick Start Guide im README beschreibt sechs Schritte. Zuerst wird LLM Vision über HACS installiert, das Projekt liegt im Default-Repository von HACS. Danach folgt ein Neustart von Home Assistant. Anschließend sucht man in Einstellungen unter Geräte und Dienste nach LLM Vision und bestätigt die Einrichtung mit den Standardeinstellungen. Danach richtet man den Medienordner ein: LLM Vision verwendet /media zum Speichern von Snapshots. Wer Home Assistant Container betreibt, muss laut README möglicherweise einen Ordner auf /media im Container mounten, sonst schlägt die Ablage fehl. Zum Schluss kehrt man auf die Integrationsseite zurück und fügt über Add Entry den ersten AI-Provider hinzu. Der Blueprint ist ein separater Schritt: Er erzeugt Benachrichtigungen zu Kameraereignissen, die von der KI zusammengefasst werden, und kann Ereignisse zusätzlich in der Timeline ablegen. Die Einrichtung des Blueprints ist in der verlinkten Dokumentation beschrieben, nicht im README selbst. Wer den Container-Mount vergisst, bekommt keine sinnvolle Fehlermeldung im README, sondern muss die Dokumentation bemühen.

Was die Provider-Auswahl praktisch bedeutet

Die Liste der unterstützten Anbieter ist lang, aber sie ist keine Geschmacksfrage. Cloud-Anbieter wie OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure oder Groq verarbeiten die Bilder außerhalb des eigenen Netzes. Ollama, Open WebUI und LocalAI erlauben den Betrieb auf eigener Hardware, was den Datenfluss im Haus hält, aber eigene Rechenkapazität voraussetzt. Die OpenAI-kompatible Schnittstelle ist der eigentliche Integrationspunkt: Alles, was diese API-Form spricht, lässt sich als Provider eintragen. Das README nennt keine Modellnamen, keine Kontextgrenzen und keine Kosten pro Anfrage. Wer abschätzen will, was ein Dauerbetrieb mit mehreren Kameras kostet, findet im Repository-Material dafür keine Grundlage. Das ist eine echte Lücke in der Dokumentation, denn gerade bei kontinuierlich auslösenden Kameras ist das der relevanteste Planungsparameter. Die Entscheidung für einen Provider sollte man daher anhand eigener Tests mit den eigenen Aufnahmen treffen, nicht anhand der Liste.

Grenzen und Fälle, in denen LLM Vision das falsche Werkzeug ist

Die Integration ist von einem externen Modell abhängig. Ohne erreichbaren Provider-Endpunkt liefert sie keine Auswertung, und bei Cloud-Anbietern hängt die Verfügbarkeit an einem fremden Dienst. Für zeitkritische Auslöser, etwa eine Alarmkette, die im Sekundenbereich reagieren muss, ist eine Anfrage an ein multimodales Modell strukturell der falsche Baustein: Der Modellaufruf dauert länger als eine lokale Objekterkennung und kann fehlschlagen. Auch die Genauigkeit ist nicht garantiert. Ein Sprachmodell beschreibt, was es im Bild zu erkennen meint; es liefert keine verlässliche Klasse mit Konfidenzwert, auf die man eine Sicherheitsentscheidung stützen sollte. Wer eine harte, reproduzierbare Erkennung mit fester Objektliste braucht, ist mit einem dedizierten Detektor besser bedient. Und wer keine Kontrolle über die Speicherung der Snapshots hat oder /media nicht bereitstellen kann, sollte die Installation gar nicht erst beginnen.

Abgrenzung zu klassischer Objekterkennung und zu Frigate

Der naheliegendste Vergleich ist eine lokale Objekterkennung, wie sie in Kamera- und NVR-Systemen üblich ist. Diese arbeitet mit festen Klassen, liefert Boxen und Konfidenzwerte und braucht kein Netz. LLM Vision arbeitet mit natürlicher Sprache: Der Prompt bestimmt, was gefragt wird, und die Antwort ist ein Satz, kein Label. Genau darin liegt der Unterschied in der Nutzung. Eine Frage wie ob eine Person ein Paket abgestellt hat lässt sich mit einem Detektor nicht beantworten, mit einem multimodalen Modell schon, allerdings ohne Garantie auf Korrektheit. Interessant ist das Verhältnis zu Frigate, das das README ausdrücklich als Quelle nennt: LLM Vision kann Frigate-Ereignisse analysieren, setzt also auf einer bestehenden Erkennungspipeline auf, statt sie zu ersetzen. Wer Frigate bereits laufen hat, bekommt damit eine zweite, sprachbasierte Auswertungsebene über den Ereignissen. Wer kein Frigate betreibt, kann trotzdem Bilder, Videodateien und Live-Feeds direkt übergeben, verliert dann aber die Vorauswahl durch Frigate.

Wartung, Release-Rhythmus und Lizenz

Die letzten Releases liegen dicht beieinander: v1.7.2 vom 3. September 2026, davor v1.7.2-beta.1 am 30. August 2026 und v1.7.1 am 4. August 2026. Die Versionshinweise sind mit Bug Fixes und Bug Fixes and Performance Improvements überschrieben, das Projekt befindet sich also in einer Phase, in der Fehlerkorrekturen und kleinere Verbesserungen dominieren. Das bedeutet für Betreiber: Updates über HACS sind regelmäßig, und jede Aktualisierung sollte man gegen die eigenen Automatisierungen prüfen, weil Änderungen an der Auswertung oder an Sensorwerten bestehende Automationen beeinflussen können. Das Repository trägt das Maintenance-Badge für 2026, ist nicht archiviert und wird aktiv gepflegt. Die Lizenz ist Apache-2.0. Das erlaubt die Nutzung, Veränderung und Weitergabe, auch in kommerziellen Kontexten, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben. Wer die Integration verändert und weitergibt, muss auf die Kennzeichnung geänderter Dateien und den mitgelieferten Lizenztext achten. Das ist keine Rechtsberatung; für den eigenen Fall sollte man die Lizenz im Repository lesen.

Wann sich der Einsatz lohnt und was vorher zu klären ist

Der Aufwand liegt nicht in der Installation, sondern in der Auswahl des Providers und im Prompt-Design. Die Installation selbst ist mit HACS, Neustart, Einrichtung der Integration und Add Entry für den Provider in wenigen Minuten erledigt, sofern /media korrekt gemountet ist. Der eigentliche Aufwand entsteht danach: Welche Kamera löst aus, welcher Prompt wird übergeben, welcher Sensor wird daraus, und welche Automation reagiert darauf. Wer diesen Teil scheut, wird die Integration schnell wieder entfernen. Wer ihn beherrscht, bekommt eine Ebene, die klassische Detektion nicht liefert. Zwei Dinge lassen sich aus dem vorliegenden Material nicht beantworten und sollten vor der Entscheidung geklärt werden: die tatsächlichen Kosten pro Auswertung beim gewählten Provider und die Frage, ob das gewählte Modell sowohl Bilder als auch Videodateien verarbeitet, denn die Provider-Dokumentation ist separat und das README macht dazu keine Aussage.

Redaktionelles Fazit

Wer bereits Kameras und am besten Frigate in Home Assistant betreibt und einen OpenAI-kompatiblen Endpunkt oder einen der genannten Cloud-Anbieter nutzen will, findet hier eine Integration, die sich über HACS installieren und mit wenigen Schritten konfigurieren lässt. Wer keine Kontrolle über die Datenhoheit braucht oder keinen Provider betreiben will, sollte es lassen. Vor dem ersten Ereignis-Trigger würde ich zwei Dinge prüfen: ob /media im Container tatsächlich gemountet ist, denn ohne dieses Verzeichnis schlägt die Snapshot-Ablage fehl, und ob der gewählte Provider Bild- und Videoeingaben in der benötigten Form akzeptiert, denn die Dokumentation behandelt jeden Provider separat und nicht jeder Modelltyp deckt beide Fälle ab.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. valentinfrlch/ha-llmvision on GitHub