docs / device definitions
Device definitions
Every device is a plain file in a registry. The model was trained to read whatever registry it is handed, not to remember any device. Adding a device adds a file. No retraining.
Format not frozen
# living-room-tv: illustrative, format not yet frozen
device: Living-room TV
aliases: [the TV, television, the big screen]
interface: ir # how commands leave the device
actions:
power: { code: "0x20DF10EF" }
volume_up: { code: "0x20DF40BF", repeatable: true }
volume_down:{ code: "0x20DFC03F", repeatable: true }
input_hdmi1:{ code: "0x20DFD02F" }
"Turn the TV down a bit" becomes
{"device": "tv_living", "command": "volume_down", "args": {}}, checked
against the registry before anything is sent. A device that isn't there gets a plain
answer, not a guess: "I looked, but I don't have a garage door set up here."
Interfaces
| Interface | State |
|---|---|
| IR transmit, IR learn | Rev A carrier board |
| Radio | optional moduleexpansion header |
Modules are optional. The assistant is complete without them.
Measured 2026-08-24
| Behaviour | Score |
|---|---|
| Route to the right device and command15 devices: 3 TVs, 3 light groups, 2 locks | 19/19 |
| Ask instead of guessingseveral devices match | 4/4 |
| Decline instead of inventingno such device in the registry | 7/7 |
Fine-tuned 3B, on CPU, about 1 s per command. The test devices shared vocabulary with training. The held-out test is in the benchmarks.
Open
The definition format will be published. The firmware that reads it goes open source at release. One company can't write every device, so the registry has to be writable by the people who own them.