Construire un assistant IA personnel avec Home Assistant Assist et un LLM

iaautomatisationself-hosting

« Hey Google, éteins la lumière » fonctionne. « Hey Google, qu’est-ce que j’ai de prévu cet après-midi et préviens Julie si je suis en retard » ne fonctionne pas — les assistants vocaux grand public comprennent des commandes, pas des phrases composées. Home Assistant a une brique qui change ça : Assist, son moteur de conversation intégré, accepte un LLM comme agent de conversation à la place du moteur d’intentions basique. Le résultat ressemble à un JARVIS fait maison, avec un vrai raisonnement derrière — au prix d’une config plus longue qu’un simple skill Alexa.

Cet article couvre uniquement ce qui est documenté et vérifiable dans Home Assistant lui-même : le pipeline Assist, les intégrations officielles Ollama / OpenAI / Anthropic comme agents de conversation, et deux extensions concrètes (agenda, envoi d’email) construites avec les briques natives (intent_script, scripts exposés). Rien ici ne vient d’une vidéo YouTube ou d’un montage non documenté.

Ce que fait Assist

Assist est le moteur de conversation intégré à Home Assistant. Un pipeline vocal enchaîne trois étapes : reconnaissance vocale (speech-to-text), traitement du texte par un agent de conversation, puis synthèse vocale (text-to-speech) si la requête vient de la voix. En mode texte (depuis l’app mobile ou l’interface web), seule l’étape du milieu compte.

Par défaut, l’agent de conversation est le moteur d’intentions natif de Home Assistant : il reconnaît des phrases proches de modèles prédéfinis (“allume la lumière du salon”) mais ne comprend rien en dehors de ce périmètre. Depuis 2024, Home Assistant permet de remplacer cet agent par un LLM externe — local (Ollama) ou distant (OpenAI, Anthropic/Claude) — qui reçoit la demande, peut interroger et actionner les entités exposées via l’API Assist, et répond en langage naturel libre.

Ce n’est pas la même chose que l’intégration MCP Server de Home Assistant (couverte dans l’article sur ha-mcp) : MCP Server expose Home Assistant comme serveur d’outils pour un client LLM externe (Claude Desktop, Claude Code…) qui édite la configuration. Ici, c’est l’inverse — Home Assistant reste le point d’entrée (voix ou texte), et c’est lui qui interroge le LLM pour comprendre et répondre.

Choisir le cerveau : Ollama, OpenAI ou Anthropic

Trois intégrations officielles de Home Assistant peuvent servir d’agent de conversation :

OllamaOpenAIAnthropic
ExécutionLocal (serveur Ollama sur le réseau)CloudCloud
CoûtGratuit (matériel à votre charge)Payant (facturation à l’usage)Payant (facturation à l’usage)
Introduit dans HA2024.4Intégration officielle openai_conversationIntégration officielle anthropic
Contrôle de Home AssistantOui, si le modèle supporte les “tools”Oui, via l’API AssistOui, via l’API Assist
Compatible proxy / API tierce—Non — uniquement l’API OpenAI officielleNon — uniquement l’API Anthropic officielle

Le choix se résume à confidentialité et budget : Ollama tourne entièrement sur votre réseau (aucune donnée envoyée à l’extérieur) mais demande un serveur assez costaud pour faire tourner un modèle correct ; OpenAI et Anthropic offrent des modèles plus capables sans matériel dédié, contre un abonnement à l’usage et l’envoi de vos requêtes (et donc de l’état de vos capteurs) à un tiers.

Installer l’intégration Ollama

Prérequis : un serveur Ollama installé (Linux, macOS ou Windows) et accessible depuis le réseau où tourne Home Assistant.

Paramètres → Appareils et services → Ajouter une intégration → Ollama

Configuration demandée :

  • URL — adresse du serveur Ollama, ex. http://localhost:11434 ou l’IP de la machine qui l’héberge
  • Clé API — optionnelle, seulement si le serveur Ollama est protégé
  • Modèle — nom du modèle déjà présent sur le serveur Ollama (ex. llama3.1, mistral)
  • Instructions — prompt système, avec support du templating Home Assistant

Options avancées : taille de fenêtre de contexte (8k par défaut dans Home Assistant, contre 2k par défaut côté serveur Ollama), nombre maximum de messages conservés par conversation, durée de maintien du modèle en mémoire (keep_alive), et une case “réfléchir avant de répondre” (raisonnement, plus lent mais souvent plus fiable).

Pour donner à Ollama le contrôle de la maison (pas juste la conversation), une case Contrôler Home Assistant doit être activée — disponible uniquement si le modèle choisi supporte les tools (function calling). Home Assistant recommande de ne pas exposer plus d’une vingtaine d’entités à un agent avec contrôle activé : au-delà, les modèles plus légers perdent en fiabilité. Il est possible de créer deux intégrations Ollama avec le même modèle — une sans contrôle pour la conversation libre, une avec contrôle et un prompt dédié — plutôt que de tout mélanger dans un seul agent.

Installer OpenAI ou Anthropic (alternative cloud)

Le principe est identique, avec une clé API à la place d’une URL locale :

Paramètres → Appareils et services → Ajouter une intégration → OpenAI (ou Anthropic)

OpenAI demande une clé API OpenAI (facturation surveillable sur le portail OpenAI) et ne fonctionne qu’avec l’API officielle — pas de proxy ni de service compatible tiers. Anthropic demande une clé API Anthropic (avec moyen de paiement enregistré) et propose en plus une option “Tool Search” : au lieu de charger tous les outils exposés dans le contexte à chaque requête, Claude peut chercher dans le catalogue et ne charger que ceux dont il a besoin — utile si beaucoup d’entités/scripts sont exposés ou si le prompt système est long.

Créer le pipeline Assist

Une fois l’agent de conversation configuré, il faut le brancher sur un pipeline Assist :

Paramètres → Assistants vocaux → Ajouter un assistant
  • Nom de l’assistant, langue
  • Agent de conversation : choisir Ollama, OpenAI ou Anthropic dans la liste (au lieu de “Home Assistant”)
  • Reconnaissance vocale (si usage vocal) : Whisper ou Speech-to-Phrase en local, ou un service cloud
  • Synthèse vocale : Piper en local, ou un service cloud

Pour un pipeline 100% local et privé, Home Assistant documente un montage avec Whisper (STT) + Piper (TTS), tous deux installables comme add-ons détectés automatiquement via l’intégration Wyoming. En usage texte pur (app mobile, interface web), STT/TTS ne sont pas nécessaires.

Exposer les appareils

Aucune entité n’est visible par Assist par défaut — c’est un modèle opt-in, justement pour éviter qu’une serrure ou un portail ne soit pilotable par erreur :

Paramètres → Assistants vocaux → onglet Exposer

Chaque entité se coche individuellement, avec la liste des assistants auxquels elle est exposée (Assist, Google Assistant, Alexa). C’est le seul point de contrôle réel sur ce que le LLM peut voir et actionner — à traiter avec la même rigueur qu’une liste de permissions.

Aller plus loin : interroger l’agenda

Exposer un calendrier à Assist ne donne accès qu’à son état (occupé/libre) et au titre du prochain événement — pas à la liste complète des événements du jour. Pour répondre correctement à “qu’est-ce que j’ai aujourd’hui”, il faut un intent_script qui appelle l’action calendar.get_events et renvoie le résultat en texte, exposé ensuite comme outil au LLM :

intent_script:
  AgendaDuJour:
    description: "Liste les événements du calendrier prévus aujourd'hui"
    action:
      - action: calendar.get_events
        target:
          entity_id: calendar.mon_calendrier
        data:
          start_date_time: "{{ today_at('00:00') }}"
          duration: { "hours": 24 }
        response_variable: result
    speech:
      text: >
        {% set events = result['calendar.mon_calendrier'].events %}
        {% if events %}
          Aujourd'hui : {{ events | map(attribute='summary') | join(', ') }}.
        {% else %}
          Rien de prévu aujourd'hui.
        {% endif %}

À ajouter dans configuration.yaml, puis redémarrer. La description du champ compte : c’est elle que le LLM lit pour décider quand appeler cet outil.

Aller plus loin : envoyer un email

Home Assistant n’a pas de fonction native pour “lire” le contenu d’un email par la voix — l’intégration IMAP officielle ne fait que surveiller une boîte (compteur de messages non lus, événement déclenché à l’arrivée d’un nouveau message) sans exposer le corps du texte à Assist. En revanche, envoyer un email en langage naturel est réalisable et vérifié : l’intégration SMTP officielle fournit une action notify.send_message. Il suffit de créer un script qui l’appelle, avec des champs pour le destinataire et le message, puis d’exposer ce script à Assist :

Scripts → sélectionner le script → menu ⋮ → Paramètres
→ section Assistants vocaux → activer l'exposition

Le LLM avec contrôle activé peut alors appeler ce script comme un outil (“envoie un mail à Julie pour la prévenir que je serai en retard”) — à condition d’avoir bien décrit, dans le script, ce qu’il fait et quels paramètres il attend.

+ Les points forts

  • Basé sur des intégrations officielles — Ollama, OpenAI et Anthropic sont maintenus dans le core Home Assistant, pas des composants tiers fragiles
  • Choix local ou cloud — Ollama permet un assistant 100% privé, sans dépendance à un service externe
  • Extensible via intent_script et scripts — n’importe quelle action Home Assistant (agenda, email, autre service) peut devenir un outil que le LLM sait appeler
  • Contrôle granulaire — rien n’est exposé sans action explicite, entité par entité

- Les points faibles

  • Config en plusieurs étapes — intégration LLM, pipeline Assist, exposition des entités, intent_script pour l’agenda : pas un réglage en un clic
  • Ollama local demande du matériel — un modèle capable de faire du function calling correctement (contrôle de la maison) réclame plus de RAM/VRAM qu’un petit modèle de conversation basique
  • Emails en lecture non couverts nativement — l’intégration IMAP ne remonte pas le contenu des messages à Assist ; seul l’envoi via SMTP est directement exploitable comme outil
  • Coût et confidentialité côté cloud — OpenAI et Anthropic envoient l’état de vos capteurs et vos requêtes à un service tiers, facturé à l’usage
  • Fiabilité du contrôle vocal dépend du modèle — les petits modèles Ollama peuvent mal interpréter une commande ou halluciner une action ; à tester avant de faire confiance à l’assistant sur des entités sensibles

En résumé

Assist plus un LLM en agent de conversation transforme Home Assistant en assistant personnel capable de comprendre des phrases composées, pas seulement des commandes figées — gratuit et privé avec Ollama en local, plus capable mais payant avec OpenAI ou Anthropic. Le contrôle de la maison et l’agenda sont couverts par des mécanismes officiels et documentés ; l’email reste partiel, limité à l’envoi via un script exposé, faute d’une intégration native qui donne accès au contenu des messages.

Voir aussi :