Serveur IA local¶

Suivre un serveur d'inférence local — Ollama, llama.cpp (llama-server) ou LM Studio — depuis Home Assistant, et mettre ses chiffres dans la fenêtre Suivi de la tablette. Rien ne change dans le firmware : le package tab5_llm.yaml crée les capteurs, Home Assistant interroge le serveur, la tablette reçoit seulement ce que la fenêtre Suivi pousse déjà.

Mise en place¶

Copier HomeAssistant_Config/packages/tab5_llm.yaml avec les autres packages (étape 1 de l'installation) et recharger, ou redémarrer Home Assistant.
Dans Paramètres → Appareils et services → Entités, chercher « Tab5 · » et régler :
- « Tab5 · type de serveur IA · AI server type » : Ollama, llama.cpp ou LM Studio. « Aucun » (le choix par défaut) n'envoie aucune requête et laisse les capteurs indisponibles.
- « Tab5 · adresse du serveur IA · AI server address » : http://hôte:port du serveur, sans chemin. Ports par défaut : 11434 (Ollama), 8080 pour llama-server (9931 sur les versions récentes : son port change, lui donner --port pour être sûr), 1234 (LM Studio). Sans http://, il est ajouté.
Home Assistant doit joindre le serveur sur le réseau : voir Côté serveur.
Pour voir une valeur sur la tablette, choisir son capteur dans « Tab5 · capteurs suivis · tracked sensors ».

Toutes les 30 secondes, et seulement quand un serveur est choisi, Home Assistant interroge le serveur (5 s au plus par requête). La tablette ne demande rien : elle reste en push-only.

Les capteurs¶

Capteur	Ollama	llama.cpp	LM Studio
`binary_sensor.tab5_serveur_ia_en_ligne` — en ligne	`/api/ps` répond	`/health` répond 200, ou 503 pendant le chargement du modèle	`/api/v1/models` répond
`sensor.tab5_serveur_ia_modele` — modèle(s) chargé(s), « aucun » sinon	noms de `/api/ps`	nom du fichier de `model_path` (`/props`)	`display_name` des modèles qui ont une instance chargée
`sensor.tab5_serveur_ia_vram` — VRAM utilisée, Gio	somme des `size_vram`	—	—
`sensor.tab5_serveur_ia_vitesse` — vitesse de génération, tokens/s	—	avec `--metrics`	—
`sensor.tab5_serveur_ia_requetes` — requêtes en cours	—	`requests_processing` (`/metrics`), sinon les slots occupés de `/slots`	—

« — » : le serveur ne le donne pas ; le capteur reste indisponible plutôt que d'afficher un chiffre inventé.

Ollama n'a pas de compteur global de tokens/s : sa vitesse n'existe que dans la réponse à une requête (eval_count / eval_duration). La mesurer obligerait à envoyer des requêtes au serveur, ce que ce package ne fait jamais.
LM Studio (0.4 et plus pour /api/v1) liste les modèles chargés mais ne donne ni la mémoire ni la vitesse hors d'une réponse.
Vitesse de llama.cpp : les tokens générés entre deux relevés divisés par le temps passé à les générer (compteurs llamacpp:tokens_predicted_total et llamacpp:tokens_predicted_seconds_total). Sans génération depuis le relevé précédent, la dernière vitesse reste. Après un redémarrage du serveur, le capteur attend une génération.
sensor.tab5_serveur_ia_releve garde tout ce qui a été lu (état ok, chargement, hors_ligne, erreur ou aucun, la raison dans son attribut raison, les valeurs brutes dans ses autres attributs) : le regarder d'abord quand un capteur reste indisponible.

Les trois mesures (VRAM, vitesse, requêtes) ont state_class: measurement : elles sont proposées dans « Tab5 · capteurs suivis » et Home Assistant garde leurs statistiques.

Sur la tablette : ce que la fenêtre Suivi sait faire, et ce qu'elle ne sait pas¶

La fenêtre Suivi montre une tendance, pas un compteur en direct :

Home Assistant pousse un changement tout de suite, puis au plus une fois toutes les cinq minutes, et toutes les heures. Une vitesse qui change chaque seconde s'y voit à ces instants seulement.
La courbe est faite des moyennes horaires des 24 dernières heures, ramenées entre leur plus petite et leur plus grande valeur : elle dit si la VRAM ou la vitesse a monté ou baissé, pas son niveau absolu.
Six capteurs au plus, partagés avec tout ce que vous suivez d'autre.

Cela convient aux températures, à la VRAM et à la RAM sur une journée. Une vue en direct (tokens/s toutes les une ou deux secondes, modèle chargé, file d'attente) demande une fenêtre à elle et une poussée plus rapide : ce n'est pas l'objet de ce package, c'est celui de la fenêtre Serveur IA, nourrie par packages/tab5_serveur_ia.yaml — choisir ces capteurs dans ses listes « Tab5 · serveur IA, … ».

Matériel : GPU, processeur, RAM, puissance¶

Ce package ne crée aucun capteur matériel. Prendre une intégration de Home Assistant faite pour cela et choisir ses capteurs dans « Tab5 · capteurs suivis » :

Glances (Glances lancé en mode serveur web sur la machine IA, son API REST non exposée hors de votre réseau) : processeur et RAM utilisés, disques, températures et, pour un GPU NVIDIA (paquet py3nvml sur cette machine), sa mémoire utilisée (VRAM, %), sa charge, sa température et son ventilateur. Ces capteurs ont state_class: measurement : ils sont proposés dans la liste.
System Monitor : seulement la machine où tourne Home Assistant — utile quand le serveur IA est cette même machine. Ses entités sont désactivées par défaut : activer d'abord celles que l'on veut.
Une prise connectée qui mesure la puissance donne celle de la machine, en W.

Côté serveur¶

Le serveur doit écouter sur le réseau, pas seulement sur 127.0.0.1, et Home Assistant doit joindre son port. Ollama et llama-server écoutent sur 127.0.0.1 par défaut : régler la variable d'environnement OLLAMA_HOST (par exemple 0.0.0.0:11434) ou lancer llama-server avec --host 0.0.0.0. LM Studio : activer « Serve on Local Network » dans les réglages du serveur.
Serveur protégé par une clé d'API : non pris en charge (LM Studio : laisser « Require Authentication » désactivé). Un package public ne contient aucune clé. llama-server répond à /health sans sa clé, donc le capteur « en ligne » marche, mais /props, /metrics et /slots refusent la requête.
llama.cpp : lancer llama-server avec --metrics pour la vitesse et les requêtes. En mode routeur (plusieurs modèles), /props et /metrics demandent un nom de modèle : non pris en charge, seul « en ligne » marche.
Les requêtes partent en http:// simple par défaut ; une adresse https:// avec un certificat valide marche aussi.

Actions depuis la tablette¶

La fenêtre Serveur IA peut montrer trois boutons (ADR-0060). Chacun n'apparaît qu'une fois réglé ici ; sans aucun réglage, la fenêtre n'a pas de bouton.

Bouton	Réglage	Grisé quand	Ce que fait Home Assistant
« Décharger » — décharger le modèle	type de serveur Ollama ou LM Studio, avec une adresse	aucun modèle chargé, ou le dernier relevé n'est pas `ok`	Ollama : `POST /api/generate` avec `{"model": …, "keep_alive": 0}` pour chaque modèle de `/api/ps`. LM Studio : `POST /api/v1/models/unload` avec `{"instance_id": …}` pour chaque instance chargée de `/api/v1/models`. Huit au plus.
« Réveiller » — réveiller le PC	une adresse MAC dans « Tab5 · adresse MAC du serveur IA · AI server MAC address » (`AA:BB:CC:DD:EE:FF`)	le serveur répond (`ok` ou `chargement`)	`wake_on_lan.send_magic_packet` vers cette adresse
« Redémarrer » — redémarrer le service	un script ou un bouton choisi dans « Tab5 · serveur IA, redémarrage · AI server, restart »	jamais	`script.turn_on` ou `button.press` dessus

Rien avec le type de serveur « Aucun ». La liste de ce qui est offert est sensor.tab5_serveur_ia_actions (decharger, -reveiller… — un - veut dire grisé) : le regarder d'abord quand un bouton manque.
llama.cpp : pas de « Décharger ». Un llama-server à un seul modèle ne peut pas décharger son modèle sans s'arrêter ; son /models/unload n'existe qu'en mode routeur, que ce package ne prend pas en charge. « Réveiller » et « Redémarrer » marchent avec tous les types.
Redémarrer : la commande, c'est vous qui l'apportez. Aucun serveur n'a d'adresse pour se redémarrer. Écrire un script Home Assistant qui le fait chez vous — un shell_command ou une commande SSH qui redémarre un service systemd, le bouton de redémarrage d'une intégration Docker ou d'un add-on, une prise coupée puis rallumée — et le choisir dans la liste. La liste propose tous les scripts et boutons, sauf ceux du projet (script.tab5_*) et ceux de la tablette.
Wake-on-LAN : le package charge l'intégration Wake on LAN (une clé vide wake_on_lan: ; une autre déjà dans configuration.yaml ne fait pas doublon). Une nouvelle intégration ne se charge pas par un rechargement du YAML : redémarrer Home Assistant une fois, sauf si wake_on_lan: y était déjà ou si l'intégration « Tab5 » a posé les fichiers (elle le charge tout de suite). Le PC doit l'autoriser (réglages du BIOS / UEFI et de la carte réseau) et être sur le même segment de réseau que Home Assistant : le paquet magique part en diffusion (broadcast), qu'un routeur ne fait pas suivre.
Décharger coupe une réponse en cours, redémarrer aussi : sur la tablette, les deux demandent un second tap (« Confirmer ? », 4 s).
La tablette n'envoie que l'événement esphome.tab5_serveur_ia_action avec action = decharger, reveiller ou redemarrer. script.tab5_serveur_ia_action ne l'exécute que si sensor.tab5_serveur_ia_actions l'offre comme active à cet instant, prend les noms des modèles, l'adresse, la MAC et la cible dans Home Assistant (jamais dans la tablette), puis attend 5 s : une action toutes les 5 s au plus, les autres sont ignorées. On peut aussi lancer le script à la main (Outils de développement → Actions, champ « Action »). Un serveur qui ne répond pas n'est pas une erreur : la trace du script garde la réponse.
Après une action, le relevé repart tout de suite (événement tab5_serveur_ia_relever) : un modèle déchargé quitte la fenêtre en quelques secondes.

Ce qui a été testé¶

Les modèles du package sont rendus par tests/test_serveur_ia.py sur des réponses simulées des trois serveurs (formes de leur documentation officielle) et comparés à un calcul Python écrit à part ; sur le Home Assistant de l'auteur, les mêmes modèles ont été rendus par son moteur de modèles.
Vrais serveurs : la réponse de /api/ps d'un vrai Ollama 0.30.6 (aucun modèle chargé à ce moment-là) a été lue. llama.cpp et LM Studio n'ont pas été testés contre un vrai serveur. Le package lui-même n'avait pas encore tourné dans un Home Assistant relié à un serveur au moment de sa publication.
Actions : les boutons offerts et le script sont vérifiés par tests/test_serveur_ia_actions.py (rendus sur des états simulés, seules les actions permises appelées, garde et cadence de 5 s). Aucune action n'a été envoyée à un vrai serveur au moment de leur écriture : aucun modèle déchargé, aucun paquet magique envoyé, aucun redémarrage. Le keep_alive: 0 d'Ollama et le déchargement de LM Studio suivent leur documentation officielle.