Control a Smart TV with Hermes and Ollama: Setup Guide

Hermes and Ollama can supply the agent and local inference for a TV-control workflow, but a device adapter must perform the commands. One documented option, local-device-bridge, provides Samsung remote controls and Roku ECP access. Its current support matrix gives LG and Sony identification and guidance rather than a universal remote.

That makes the TV’s capability record the first useful check. A model can understand “mute the living-room TV” while the chosen bridge still lacks a way to execute it. Adding a more capable language model cannot fill in a missing device protocol.

Separate inference from device control

The workflow has three parts. Ollama serves the model, Hermes interprets the request and invokes an available tool, and a bridge translates that tool action into the device’s protocol. Each part can work while another fails.

Ollama’s Hermes integration offers this entry point after Ollama is installed:

ollama launch hermes

The launcher can prompt to install Hermes, choose a model and configure the endpoint. The selector includes local and cloud models. For local inference, choose a downloaded local model and verify the resulting provider configuration. A localhost API address alone does not prove that the selected model executes on the same computer.

Messaging integrations are optional. A terminal session is enough for initial setup, and removes another component from early troubleshooting. After confirming the endpoint and model, make an ordinary text request before introducing device tools.

Confirm that the bridge supports the TV

The local-device-bridge support matrix distinguishes command support from discovery:

These are the project’s documented capabilities, not EyesTech hardware tests. Check the actual model and firmware against the device guide. Discovering an address or recognizing a manufacturer is insufficient evidence that pairing or remote commands are implemented.

Install a published bridge release using its repository’s instructions, then run the CLI setup wizard with local-device-bridge setup. The project documents self-contained binaries, with Go needed only for source builds. Keep the host on the trusted LAN with the TV, then discover and list devices:

local-device-bridge discover
local-device-bridge devices list

Start with the television awake. A new bridge cannot identify a powered-off device that has never advertised a supported service. Guest Wi-Fi, client isolation and separate network segments can also prevent discovery. Resolve that layer before changing the model or asking the agent to guess an IP address.

For Samsung, follow the model-specific network-remote settings and accept the permission prompt on the TV. Roku instead uses its Control by mobile apps setting. Applying Samsung’s pairing instructions to Roku would diagnose the wrong mechanism.

Connect Hermes through the bridge CLI

For a same-computer installation, Hermes can use its terminal toolset to invoke the bridge’s documented CLI. The executable must be available inside the terminal environment Hermes actually uses. A Docker or remote backend has its own filesystem and network path; installing the bridge on the laptop does not put it inside that environment.

After confirming the local model selection, start a Hermes chat with terminal and skill access:

hermes chat --toolsets terminal,skills,web

Hermes documents a /learn command that turns supplied documentation into a reusable skill. In that chat, submit /learn https://github.com/henry-peters/local-device-bridge/blob/main/docs/cli.md, then review the generated procedure. Learning the documentation does not install an adapter or prove device access.

Ask Hermes to use the installed bridge CLI to list devices, read the selected device’s guide and report its capabilities. Keep pairing as an explicit action while the TV is visible. With a confirmed device ID, these are the project’s documented CLI forms; replace TV_ID with that actual identifier:

local-device-bridge agent guide TV_ID
local-device-bridge pair TV_ID
local-device-bridge device TV_ID status

Use the guide to determine whether pairing applies; Roku follows its own access setting. The terminal route uses the bridge host’s existing CLI environment. It does not require pasting an agent bearer token into the model conversation.

For a separate agent host, the agent integration guide instead describes an authenticated HTTP/OpenAPI interface. Generate its token, manifest and schema with local-device-bridge agent token, agent manifest and agent openapi on the bridge computer. Store the token in private connector settings, and configure an HTTP/OpenAPI-capable integration using the generated contract. An Ollama connection alone does not perform that step; an OpenAPI document is not automatically an MCP server.

Verify an action at the device

For an initial check, choose a reversible action with an obvious result, such as muting a TV while its screen and current state are visible. Record the requested action, selected device, bridge response and observed state. Sending a request establishes an attempt; an acknowledgment should not silently become a claim that the physical action occurred.

Use an explicit target name if the house has several displays. “The TV” becomes ambiguous as soon as discovery returns more than one candidate. Save a friendly alias only after confirming its mapping to the intended device.

Power control deserves a separate check. A TV that accepts power-off may become unreachable afterwards, while waking can depend on a retained MAC address and network settings. Do not infer that wake works merely because mute does.

For diagnosis, preserve the layer where the failure occurs. No device listing points toward discovery. A denied pairing points toward device authorization. A valid bridge call with a wrong target points toward naming or agent selection. An invented command points toward tool grounding. Those cases call for different fixes.

What local and free mean here

Local inference can remove a hosted model’s per-token bill, while still using the computer’s memory, electricity and processing time. A cloud model or external messaging service adds its own data path. Inspect the selected components rather than assigning a privacy or cost property to the whole setup from the Ollama name alone.

The bridge’s LAN API is intended for a trusted home network. Keep its credentials private and follow its documented access controls. A phone dashboard is also a useful fallback: basic TV control can remain available when the agent misunderstands a request or the model server is down.

This is a practical arrangement for supported devices with a functioning adapter. The useful acceptance test is whether the intended command reaches the correct TV and produces the observed result. Language understanding is one dependency in that chain, alongside pairing, protocol support and accurate state reporting.