Actuellement en plein dev d'un jarvis également, j'ai quelque chose de plutôt fonctionnel mais je ne suis pas satisfait du réalisme. J'ai créé une video.mp4 qui s'anime quand jarvis parle mais je n'ai pas le rendu comme sur la vidéo de NEO5980. Quelle est l'application utilisée pour générer un avatar 3D avec un lip-sync réaliste et fluide comme sur cette video ? Merci
les LLM en local faut oublier a part pour donner des instructions bete genre 'allume la lumiere", en encore si t'es pas pressé.
Faut utiliser du LLM cloud, y'a tout un tas de services avec du free tier plus ou moins important mais souvent le free tier est moins prioritaire que les payents donc parfois ça rame.
A partir du moment ou le LLM est externalisé n'importe quelle machine peut faire l'affaire, vu qu'elle se contente d'utiliser les API des fournisseurs de LLM
En ce moment la meilleure offre pour ce que j'en fais c'est clairement opencode, la formule ZEN permet d'utiliser leur agent Opencode en terminal avec quelques modeles gratuits performants (BigPickle qui est un GLM 4.6 tuné pour le code) et un enorme free tier qui permet de develoipper du script ou du debug largement sans payer.
A coté de ça ils ont une formule opencode GO (5$ le premier mois et 10$ apres avec un acces a deepseekV4 et des pools de tokens faramineux).
Si ça interesse j'ai des codes de parrainage, qui donne 5$ de credit (et j'en recupere ($ aussi).
a coté de ça tu as du free tier, limité sur ollama avec leurs modeles cloud, du gree tier relativement genereux avec gemini, des modeles gratuits sur openrouter ou aihubmix, plein de modeles gratuits sur Nvidia NIM mais c'est très lent ou encore des modeles de transcription type whisper gatuits sur Groq.
Perso je suis sous "BigPickle / opencode zen" pour l'agent de coding et "Deepseek V4 flash / opencode go" pour le bot.
ça marche assez bien, j'ai prevu un canal de retour vers HA ou vers telegram, etant donné que la typologie de retour attendue est pas forcément la même.
Le polling ça marche mais ça oblige am ultiplier les operations et a consommer du token pour rien, la au moins j'ai un declencher type "evennement" pour actionner le bot.
Il semblerait que les autres cannaux de com type matrix ou slack ne limitent pas la communicatio nentre bots comme sur telegram, ce qui sur le principe voudrait dire qu'en changeant de messagerie il suffriait d'utiliser un bot pour HA et un bot pour le llm pour leur permettre de discuter. j'ai pas encore testé
Sur le local vs cloud mon retour rejoint en partie le tien : pour le cerveau agent (raisonnement, orchestration) le cloud reste devant niveau qualite et latence. En revanche je garde du local sur les briques simples et sensibles a la latence ou a la vie privee (wake-word, STT Whisper, TTS) qui tournent bien sur une petite machine sans dependre d'une API. Du coup chez moi c'est hybride : local pour la couche perception/commande, cloud pour le raisonnement. Ca evite de consommer des tokens pour allumer une lumiere tout en gardant un agent capable sur le reste. Merci pour le retour d'experience, je vais regarder de mon cote.
Sur le canal retour, je suis assez d'accord : c'est souvent ce qui fait la différence entre un assistant gadget et un système vraiment opérable.
Chez moi je sépare deux choses : le canal humain, aujourd'hui Telegram, pour validation, arbitrage et résumé ; et le canal machine, plutôt des états/événements structurés côté HA. Ça évite qu'un bot parle directement à un autre bot sans contrat clair.
Matrix ou Slack peuvent très bien servir de bus de conversation, mais pour HA je préfère garder un chemin plus strict : événements, helpers, scripts bornés, logs auditables. L'agent peut proposer, expliquer et demander validation ; HA reste la source de vérité et le point de contrôle.
L'objet est pas de les laisser décider seul, simplement de permettre un échange bidirectionnel "visuel" et plus fluide qu'un webhook.
A partir du moment ou le bot reçoit la requête il est bien libre d'aller interroger ha si besoin d'infos complémentaires ou même de lancer des actions, mais ça se fait en arrière plan. L'intérêt de changer de bus ce serait plutôt la facilité d'afficher la demande de ha vers le bot et et la réponse du bot au ha.
Idem je fais tourner en local les whisper/piper et autres embeddings pour les recherches sémantiques mais en-dehors de ces applications c'est ingérable en local. Quand y'a de l'imagerie / vidéo a traiter j'utilise summarize qui délégue ca a un modèle VL cloud gratuit, ça marche plutôt bien mais c'est pas très rapide
Les commandes internes, le "assistant" de ha ne passent pas par un système de llm par défaut ça le rend plus réactif mais aussi moins adaptatif.
Sur le bus "visuel" je te rejoins : pouvoir lire en clair la requête HA→bot et la réponse bot→HA, ça change tout pour le debug et la confiance. Chez moi le canal humain (Telegram) joue ce rôle d'observabilité ; ce que tu décris avec Matrix/Slack reviendrait à fusionner ce canal lisible avec le canal machine, et j'en vois l'intérêt en arrière-plan tant que HA garde le dernier mot.
Sur le local, même constat : wake-word, Whisper, TTS et embeddings tournent en local chez moi aussi, mais dès qu'il y a de l'image ou de la vidéo je délègue à un modèle VL cloud — lent mais correct, exactement comme ton "summarize".
Et ton dernier point est le vrai arbitrage : l'assistant natif de HA sans LLM est réactif mais figé. Du coup je fais du routage : chemin déterministe rapide pour les intentions connues (allumer, scènes, états), et bascule LLM seulement quand la demande sort du cadre. On garde la réactivité sans perdre l'adaptatif. Merci pour l'échange, c'est exactement le genre de retour qui fait avancer.
Quelques info trouvées là sur comment faire des trucs:
En mode tuto Pas à pas pour ceux qui cherchent "comment" faire certains trucs. Ce n'est visiblement pas au même niveau que les agents que vous proposez... Mais ça peut être un premier pas pour beaucoup d'entre nous.
Merci pour le partage. L'approche MCP est vraiment une porte d'entrée très accessible, c'est d'ailleurs par là qu'on a commencé côté contrôle Home Assistant : donner à l'IA une surface d'outils propre, plutôt que lui demander d'improviser dans la config.
Là où ça change d'échelle ensuite, c'est quand on ajoute des garde-fous autour : qui a le droit de faire quoi, quelles actions restent en validation humaine, comment on journalise, et comment on sépare le canal conversation du canal machine.
Pour beaucoup de monde, un tuto comme celui-là est déjà un excellent premier pas. Après, on peut empiler mémoire, agents spécialisés, QA, sécurité, mais la base reste la même : HA comme source de vérité, MCP pour exposer les capacités, et l'IA comme orchestrateur contrôlé plutôt que pilote libre.
J'ai suivi le tuto pour découvrir tout ça et je bloque sur la partie configuration du fichier claude_desktop_config.json
Le contenu du fichier de configuration (en ayant remplacé l'adresse de HA et la clé Token) et l'image de ce que l'on doit avoir après modification n'est pas la même
le MCP c'est la base de l'interconnexion avec HA, d'autant que ce MCP donne acces direct aux yaml et permet à l'agent de coder directement dans HA. Aveec tous les risques que ça suppose !
il y a aussi des mcp pour se coupler a frigate, ou a esphome, ce qui permet de centraliser au niveau du bot la cohérence du systeme et surtout de tester en temps réel les modifs et debugger !
Le JSON que vous avez collé est correct pour ha-mcp, pas d'inquiétude. La différence avec l'image vient en général d'une de ces trois choses :
HOMEASSISTANT_URL doit être l'URL complète avec le protocole et le port, par ex. http://192.168.x.x:8123 (et non juste l'IP).
HOMEASSISTANT_TOKEN doit être un "jeton d'accès longue durée" généré depuis votre profil HA (en bas de la page profil), pas la clé d'une autre intégration.
Après modification du fichier, il faut quitter complètement Claude Desktop (pas juste fermer la fenêtre) et le relancer pour que le serveur MCP soit pris en compte.
Pouvez-vous préciser ce qui diffère exactement entre votre fichier et la capture ? (nom de la clé, structure, ou juste l'affichage côté Claude). Ça m'aidera à cibler.
Tout à fait d'accord sur le constat : ce MCP donne une surface très large, jusqu'à l'écriture directe dans les YAML. C'est ce qui le rend puissant pour itérer vite, mais c'est aussi pour ça que chez moi je ne laisse pas l'agent écrire en direct dans HA. Le bot propose, HA garde le dernier mot, et tout passe par une couche de validation + journalisation. L'accès « code direct » je le réserve à un dépôt versionné, pas à la config live.
Pour Frigate et ESPHome je suis preneur de ton retour : tu les branches en MCP séparés ou via un seul agent qui orchestre ? L'idée de tester/débugger en temps réel m'intéresse, mais je me demande comment tu bornes le rayon d'action quand plusieurs intégrations deviennent modifiables par le même bot.
j'ai interdit l'usage de certains tools dans le mcp de ha, dans nanobot il y a un filtre inclus qui permet de le faire, sinon apres j'ai des rules / skills pour demander en fonction du niveau d'edition, et par proncipe des regles pour backup avant de modifier (sans compter les synchro/versionning que je gere avec syncthing)
pour le debug/test avancés je fais avec le bot, ou je travaille sous opencode suivant le cas, avec les mêmes mcp, il cree ses code les injecte et gere les logs, le debug et les reload /redmemarrage de homeassistant (je suis sous docker ça simplifie la vie). J'ai une memoire vectorielle semantique qui retiens les souvenirs pour capitaliser les connaissances
Merci pour le lien vers frigate-mcp, je regarde ça en attendant l'officiel.
On est sur la même logique côté garde-fous. Chez moi le filtrage ne se fait pas dans le MCP lui-même mais en amont : un agent orchestrateur unique n'expose que les actions autorisées selon le contexte, avec backup systématique avant toute écriture. Le versionning je le gère en dépôt git classique plutôt qu'en syncthing, mais l'idée est la même : pouvoir revenir en arrière.
Pour ESPHome tu passes aussi par un MCP dédié, ou tu restes sur l'édition directe ?
merci pour cette idée. Je n'y aurais pas pensé et en l'interrogeant, pas à pas il a pu me faire une proposition de correction du fichier de configuration (c'était le chemin d'accès qui était incorrect entre autre).
