Skip to content

Local AI server

Follow a local inference server — Ollama, llama.cpp (llama-server) or LM Studio — from Home Assistant, and put its numbers on the tablet's Tracking window. Nothing changes in the firmware: the tab5_llm.yaml package creates the sensors, Home Assistant reads the server, the tablet only receives what the Tracking window already pushes.

Setting up

  1. Copy HomeAssistant_Config/packages/tab5_llm.yaml with the other packages (step 1 of the installation) and reload, or restart Home Assistant.
  2. In Settings → Devices & services → Entities, search « Tab5 · » and set:
    • « Tab5 · type de serveur IA · AI server type »: Ollama, llama.cpp or LM Studio. « Aucun » (the default) sends no request at all and leaves the sensors unavailable.
    • « Tab5 · adresse du serveur IA · AI server address »: http://host:port of the server, without a path. Default ports: 11434 (Ollama), 8080 for llama-server (9931 on recent builds: its port is changing, give it --port to be sure), 1234 (LM Studio). Without http://, it is added.
  3. Home Assistant must reach the server over the network: see Server side.
  4. To see a number on the tablet, pick its sensor in « Tab5 · capteurs suivis · tracked sensors ».

Every 30 seconds, and only when a server is chosen, Home Assistant asks the server (5 s at most per request). The tablet asks nothing: it stays push-only.

The sensors

Sensor Ollama llama.cpp LM Studio
binary_sensor.tab5_serveur_ia_en_ligne — online /api/ps answers /health answers 200, or 503 while the model loads /api/v1/models answers
sensor.tab5_serveur_ia_modele — loaded model(s), « aucun » when none names from /api/ps file name of model_path (/props) display_name of the models with a loaded instance
sensor.tab5_serveur_ia_vram — VRAM used, GiB sum of size_vram — —
sensor.tab5_serveur_ia_vitesse — generation speed, tokens/s — with --metrics —
sensor.tab5_serveur_ia_requetes — requests in progress — requests_processing (/metrics), else the busy slots of /slots —

« — » means the server does not give it: the sensor stays unavailable rather than showing an invented number.

  • Ollama has no global tokens/s counter: its speed only exists in the answer to one request (eval_count / eval_duration). Measuring it would mean sending requests to the server, which this package never does.
  • LM Studio (0.4 or later for /api/v1) lists the loaded models but gives neither memory nor speed outside an answer.
  • llama.cpp speed: the tokens generated between two readings divided by the time spent generating them (counters llamacpp:tokens_predicted_total and llamacpp:tokens_predicted_seconds_total). When nothing was generated since the last reading, the last speed stays. After a restart of the server, the sensor waits for a generation.
  • sensor.tab5_serveur_ia_releve holds everything read (state ok, chargement, hors_ligne, erreur or aucun, the reason in its raison attribute, the raw values in its other attributes): look there first when a sensor stays unavailable.

The three measures (VRAM, speed, requests) have state_class: measurement, so they are offered in « Tab5 · capteurs suivis » and Home Assistant keeps their statistics.

On the tablet: what the Tracking window can and cannot do

The Tracking window shows a trend, not a live meter:

  • Home Assistant pushes a change at once, then at most once every five minutes, and every hour. A speed that changes every second shows as its value at those moments.
  • The curve is the hourly means of the last 24 hours, scaled between their lowest and highest values: it shows whether the VRAM or the speed went up or down, not its absolute level.
  • Six sensors at most, shared with whatever else you track.

That suits temperatures, VRAM and RAM over a day. A live view (tokens/s every second or two, the loaded model, the queue) needs a dedicated window and a faster push: it is not part of this package, it is the AI server window's, fed by packages/tab5_serveur_ia.yaml — pick these sensors in its « Tab5 · serveur IA, … » lists.

Hardware: GPU, CPU, RAM, power

This package creates no hardware sensor. Use a Home Assistant integration made for that and pick its sensors in « Tab5 · capteurs suivis »:

  • Glances (Glances running in web server mode on the AI machine, its REST API not exposed outside your network): CPU and RAM use, disks, temperatures, and for an NVIDIA GPU (py3nvml package on that machine) its memory use (VRAM, %), load, temperature and fan. These sensors have state_class: measurement, so they are offered in the list.
  • System Monitor: only the machine Home Assistant runs on — useful when the AI server is that same machine. Its entities are disabled by default: enable the ones you want first.
  • A smart plug with power measurement gives the machine's power in W.

Server side

  • The server must listen on the network, not only on 127.0.0.1, and Home Assistant must reach its port. Ollama and llama-server listen on 127.0.0.1 by default: set the OLLAMA_HOST environment variable (for example 0.0.0.0:11434) or start llama-server with --host 0.0.0.0. LM Studio: turn on « Serve on Local Network » in the server settings.
  • Server protected by an API key: not supported (LM Studio: leave « Require Authentication » off). A public package holds no key. llama-server answers /health without its key, so the « online » sensor works, but /props, /metrics and /slots refuse the request.
  • llama.cpp: start llama-server with --metrics for the speed and the requests. In router mode (several models), /props and /metrics need a model name: not supported, only « online » works.
  • Requests go over plain http:// by default; an https:// address with a valid certificate works too.

Actions from the tablet

The AI server window can show three buttons (ADR-0060). Each one appears only once it is set up here; with nothing set up, the window has no button.

Button Set up Greyed when What Home Assistant does
« Décharger » — unload the model server type Ollama or LM Studio, with an address no model is loaded, or the last reading is not ok Ollama: POST /api/generate with {"model": …, "keep_alive": 0} for each model of /api/ps. LM Studio: POST /api/v1/models/unload with {"instance_id": …} for each loaded instance of /api/v1/models. Eight at most.
« Réveiller » — wake the PC a MAC address in « Tab5 · adresse MAC du serveur IA · AI server MAC address » (AA:BB:CC:DD:EE:FF) the server answers (ok or chargement) wake_on_lan.send_magic_packet to that address
« Redémarrer » — restart the service a script or a button picked in « Tab5 · serveur IA, redémarrage · AI server, restart » never script.turn_on or button.press on it
  • Nothing with the server type « Aucun ». The list of what is offered is sensor.tab5_serveur_ia_actions (decharger, -reveiller… — a - means greyed): look there first when a button is missing.
  • llama.cpp: no « Décharger ». A single-model llama-server cannot unload its model without stopping; its /models/unload exists only in router mode, which this package does not support. « Réveiller » and « Redémarrer » work with any type.
  • Restart: you bring the command. No server has an endpoint to restart itself. Write a Home Assistant script that does it in your home — a shell_command or SSH command restarting a systemd unit, the restart button of a Docker or add-on integration, a smart plug turned off and on — and pick it in the list. The list offers every script and button except the project's own (script.tab5_*) and the tablet's.
  • Wake-on-LAN: the package loads the Wake on LAN integration (an empty wake_on_lan: key; one already in configuration.yaml is no duplicate). A new integration is not loaded by a YAML reload: restart Home Assistant once, unless wake_on_lan: was already there or the « Tab5 » integration installed the files (it loads it at once). The PC must allow it (BIOS / UEFI and network card settings) and be on the same network segment as Home Assistant: the magic packet goes out as a broadcast, which a router does not pass on.
  • Unloading cuts an answer in progress, and so does a restart: on the tablet, both ask a second tap (« Confirmer ? », 4 s).
  • The tablet sends only the event esphome.tab5_serveur_ia_action with action = decharger, reveiller or redemarrer. script.tab5_serveur_ia_action runs it only if sensor.tab5_serveur_ia_actions offers it as active at that moment, takes the model names, address, MAC and target from Home Assistant (never from the tablet), then waits 5 s: one action every 5 s at most, the others are ignored. You can also run the script by hand (Developer tools → Actions, field « Action »). A server that does not answer is not an error: the script's trace keeps the answer.
  • After an action, the reading starts again at once (event tab5_serveur_ia_relever): an unloaded model leaves the window within a few seconds.

What was tested

  • The templates of the package are rendered by tests/test_serveur_ia.py on simulated answers of the three servers (shapes from their official documentation) and compared to a separate Python calculation; on the author's Home Assistant, the same templates were rendered by its template engine.
  • Real servers: the answer of /api/ps of a real Ollama 0.30.6 (no model loaded at that time) was read. llama.cpp and LM Studio were not tested against a real server. The package itself had not yet run in a Home Assistant talking to a server when it was published.
  • Actions: the offered buttons and the script are checked by tests/test_serveur_ia_actions.py (rendered on simulated states, only the allowed actions called, guard and 5 s cadence). No action was sent to a real server when they were written: no model unloaded, no magic packet sent, no restart. Ollama's keep_alive: 0 and LM Studio's unload follow their official documentation.