TV Remote Control Surface

Overview

A small self-hosted web application that replaces the physical remotes for the televisions in my house. It presents one interface in a browser and speaks two entirely different protocols behind it: Vizio’s SmartCast HTTP API for the TVs, and Android Debug Bridge keycodes for Fire TV devices.

Unlike the other work in this section, this project runs no model and performs no inference. It is here because of how it was built: I designed it and directed AI coding tools through the implementation. That is a distinct skill from writing the code myself, and it is worth being precise about which one a project demonstrates.

The problem

Two manufacturers, two remotes, two mental models, and neither remote works from a phone already in your hand. Vizio exposes an authenticated local HTTP API with a pairing token. Fire TV exposes nothing comparable, but it will accept ADB keycodes over the network.

The interesting constraint was that these are not the same kind of interface at all. One is a documented request/response API; the other is synthetic key events aimed at an Android device.

Architecture

The design keeps that difference in one place. Each device type is an adapter: a module that knows how to talk to one protocol and exposes the same small vocabulary to the rest of the application. Express serves the interface and routes a request to whichever adapter the target device is registered under.

Devices live in a small JSON store: an id, a type, a label, an address, and a pairing token where one is needed. Adding a Fire TV alongside a Vizio requires no change to the interface, because the interface never learns what protocol anything speaks.

The Vizio adapter handles pairing and issues authenticated SmartCast calls. The Fire TV adapter maps the same vocabulary onto Android keycodes (ok to 23, back to 4, home to 3) and launches apps by package name, with fallbacks where a service ships more than one.

The whole thing runs in a container on the home server and is reachable only on the LAN.

Working through AI tools

Directing a model through a build like this is not dictation. The parts that determined whether the result was any good were architectural: choosing the adapter boundary before any protocol code was written, deciding that the device store should be data rather than configuration, and insisting the interface stay ignorant of device types.

The work that followed was iterative: describing intent, reading what came back, and rejecting implementations that leaked one protocol’s assumptions into the shared layer. The clearest lesson was that a model will happily produce something that works for the case in front of it and generalizes badly, and that catching this is a design review rather than a code review.

An earlier single-protocol version is preserved alongside the current one, and a small migration promotes the original TV-only store into the current device format.

Result

One browser interface controls every television and streaming device in the house, including power, navigation, playback, volume, and direct app launching. It runs continuously on the home server. The source is private.

What I learned

This project is the clearest example I have of the difference between generating code and engineering a system. The implementation came quickly. Its quality was decided almost entirely by boundaries drawn before the model wrote anything, and by being willing to throw out plausible output that would have made the second device type painful to add.