LLM Vision : brancher un modèle multimodal sur les caméras de Home Assistant
Visual intelligence for your home.
En bref
- De quoi s’agit-il ?
- Cette intégration HACS fait décrire par un LLM les images, vidéos et flux de caméras de Home Assistant, avec une chronologie des événements. Le point délicat n'est pas le modèle, c'est le stockage des captures dans /media et le coût par appel.
- À qui s’adresse-t-il ?
- LLM Vision convient aux installations Home Assistant qui possèdent déjà des caméras ou Frigate et qui acceptent de payer chaque analyse. À éviter si vous voulez de la détection locale sans appel réseau ni coût variable.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 10 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : une caméra qui détecte mais ne raconte rien
Une détection de mouvement classique produit un booléen et une notification. Elle ne dit pas si c'est le facteur, un chat ou un inconnu qui a sonné. LLM Vision prend le problème à l'autre bout : au lieu d'améliorer le classifieur local, il envoie l'image ou l'extrait à un modèle multimodal et récupère une phrase en langage naturel. Le README annonce que l'intégration analyse des images, des fichiers vidéo, des flux de caméras en direct et des événements Frigate, et qu'elle peut aussi tenir une chronologie des événements analysés, affichable via une Timeline Card. La cible est donc l'utilisateur de Home Assistant qui a déjà des caméras et veut des notifications compréhensibles, pas celui qui cherche un système de détection autonome.
Ce qui circule entre la caméra et le fournisseur
Le mécanisme est un enchaînement simple. Une source fournit une image (capture de flux, fichier, événement Frigate). L'intégration joint cette image et votre prompt à un fournisseur de modèle multimodal, puis exploite la réponse. Deux usages distincts ressortent du README : la description, et l'extraction de données qui alimentent des entités. La phrase « Seamlessly updates sensors based on data extracted from camera streams, images or videos » indique que la réponse du modèle n'est pas seulement affichée, elle est transformée en état d'entité. C'est là que se joue la fiabilité : un capteur dont la valeur dépend d'un texte généré peut changer de format d'une réponse à l'autre. Le README mentionne aussi que l'intégration « Remembers people, pets and objects », sans détailler la persistance. Cette mémoire est annoncée, pas documentée dans le matériel fourni.
Le dossier /media, première vraie contrainte
L'étape 5 du guide de démarrage rapide est la plus concrète : « LLM Vision uses the more secure /media folder for storing snapshots. If you're running Home Assistant Container, you may need to mount a folder to /media in your container settings. » Autrement dit, l'intégration écrit des captures sur disque, et cette écriture échoue si /media n'est pas monté. C'est le premier point de blocage en installation conteneurisée, bien avant la question du choix du modèle. Le guide renvoie d'ailleurs vers la documentation pour ce point précis. À l'inverse, une installation Home Assistant OS expose ce dossier par défaut, ce qui rend l'étape transparente. Cette asymétrie explique probablement une bonne part des rapports de bug : le README demande explicitement d'activer les journaux de débogage depuis la page de réglages de l'intégration avant de signaler un problème.
Installation : HACS, redémarrage, puis un fournisseur
La séquence documentée est courte. Installez LLM Vision depuis HACS (l'intégration figure dans le dépôt par défaut), redémarrez Home Assistant, cherchez LLM Vision dans Paramètres puis Appareils et services, validez la configuration par défaut, montez /media si nécessaire, puis revenez sur la page de l'intégration et appuyez sur « Add Entry » pour ajouter votre premier fournisseur. Le choix du fournisseur est la partie ouverte : le README liste OpenRouter, OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure, Groq, Ollama, Open WebUI, LocalAI, ainsi que tout service exposant une API compatible OpenAI. Un blueprint est fourni pour obtenir des notifications d'événements caméra résumées, avec stockage optionnel dans la chronologie. La documentation des fournisseurs se trouve sur llm-vision.gitbook.io, pas dans le README. Ce qui n'apparaît nulle part dans le matériel fourni : les clés de configuration exactes par fournisseur, les valeurs par défaut de prompt, et la façon dont les entités sont nommées.
Ce que l'intégration ne fera pas pour vous
Le coût. Chaque analyse est un appel à un service externe, sauf si vous passez par Ollama, LocalAI ou Open WebUI. Avec un fournisseur commercial, une caméra qui déclenche souvent produit un flux d'appels facturés à l'image ou à la seconde de vidéo. Le README ne donne aucun chiffre de consommation ni de mécanisme de limitation visible. La latence, ensuite : le temps de réponse d'un modèle multimodal s'ajoute au délai entre le mouvement et la notification. Pour une sonnette, c'est perceptible. Troisièmement, la dépendance réseau : couper l'accès sortant vers le fournisseur désactive l'analyse, sauf configuration locale. Enfin, l'intégration n'est pas un détecteur. Elle ne remplace pas la détection de mouvement de votre caméra ni celle de Frigate, elle s'y ajoute pour l'interprétation. Si vous cherchez à réduire les faux positifs sans appel à un modèle, ce n'est pas le bon outil.
Face à Frigate alone ou à un détecteur local
La comparaison la plus directe est avec Frigate utilisé seul. Frigate fait de la détection et du suivi d'objets en local, avec des modèles dédiés, et produit des événements. LLM Vision ne détecte pas : il consomme les événements Frigate, comme l'indique le README, et les traduit en descriptions. La différence d'approche est nette : Frigate répond à « y a-t-il un objet, et lequel », LLM Vision répond à « que se passe-t-il sur cette image ». Un détecteur local classique reste déterministe et gratuit à l'usage, mais il ne produit pas de phrase et ne sait pas répondre à une question libre du type « le colis est-il toujours devant la porte ». L'inverse est vrai aussi : LLM Vision n'offre aucune garantie de stabilité de sortie, ce qu'un capteur binaire exige.
Maintenance, licence et coût de mise à jour
Le dépôt est actif : dernière poussée en septembre 2026, versions 1.7.2 et 1.7.2-beta.1 en septembre 2026, 1.7.1 en août 2026, toutes étiquetées corrections de bugs ou améliorations de performance. Le badge de maintenance du README indique « yes/2026 ». Le projet n'est pas archivé. La licence est Apache-2.0, ce qui autorise l'usage, la modification et la redistribution, y compris commerciale, avec conservation des mentions de licence et du fichier NOTICE le cas échéant. Cela ne dit rien du contrat qui vous lie à votre fournisseur de modèle : les conditions d'OpenAI, Anthropic ou Google s'appliquent à ce que vous leur envoyez, et des images de votre domicile en font partie. Point pratique : la mise à jour passe par HACS, donc par un redémarrage de Home Assistant. Les versions bêta existent et sont publiées sur le même canal, ce qui suppose de choisir consciemment entre stabilité et accès anticipé aux correctifs.
Conclusion éditoriale
LLM Vision convient aux installations Home Assistant qui possèdent déjà des caméras ou Frigate et qui acceptent de payer chaque analyse. À éviter si vous voulez de la détection locale sans appel réseau ni coût variable. Avant d'installer, vérifiez deux choses : que votre instance expose bien un dossier /media accessible en écriture (contrainte réelle en Home Assistant Container) et que votre fournisseur accepte les images envoyées depuis votre réseau.
Notes de la communauté