Early on, the dashboard opened its own Telnet session to the Lutron HomeWorks processor. It seemed reasonable: Crestron already had a connection, the processor accepts more than one, and reading lighting levels directly is faster than asking Crestron.

It worked for a few days. Then the processor wedged under the combined load, and lighting stopped responding for the whole house. It wasn't the dashboard alone, and it wasn't Crestron alone. It was two controllers polling and commanding the same processor at once.

The fix

Sentinel's direct Lutron module was removed. All lighting now goes Sentinel → Crestron → Lutron, over a single line-based TCP protocol into a SIMPL+ module I wrote for the purpose:

CMD|kitchen|light|2|75
EVT|kitchen|light|2|75
QUERY|kitchen|light

Takeaway: in a building with an established control system, give each subsystem exactly one owner. Everything else asks that owner. It's the same rule you'd apply to a BMS with an HLI to a third party.

The Kenwood TS-2000 is on the network through an IP-to-serial bridge. Tuning, mode changes and reading the meters all worked. The one command that mattered most, PS1; (power on), did nothing.

The cause was hardware flow control. In standby the rig stops asserting CTS, and with RTS/CTS enabled the bridge obediently holds the command until the radio says it's ready. A radio that is off never says it's ready.

What works

• 9600 baud, 8N1, flow control off on the bridge (and the rig's menu set to match).
• A fully-wired straight-through DB9 F-F cable. The bridge is DTE and the rig is DCE, so a null-modem cable is wrong here.

Takeaway: when "everything works except waking the device", suspect the handshake first. Flow control assumes the other end is awake.

You can dial *99 from any phone on the house PBX and talk to Jarvis. Every turn is a relay: speech-to-text (Whisper), then the language model with its tools, then text-to-speech (Kokoro), then back down the line. Each stage adds delay, and people notice after about a second.

What helped

• Split the model by channel. Chat and the dashboard use the most capable model with extended thinking, because depth matters there. The voice path uses a faster model at low effort with no thinking, because a pause on the phone feels broken.
• Stream sentence by sentence. The first sentence is synthesised and played while the rest is still being generated.
• Cap reply length for voice. A good spoken answer is much shorter than a good written one.

What didn't

Quantising the speech models to int8 made them slower. The host is a 2013 Haswell CPU without the VNNI instructions that make int8 fast. The real fix is hardware, which is why a new compute node is at the top of the roadmap.

Takeaway: measure each stage separately. The model is rarely the slowest part.

Everything in Sentinel is published on MQTT, and for a while that felt like enough. Then I asked Jarvis how many times the hot water had run that day, and it had no idea. That information had been on the bus all day and been thrown away each time.

MQTT is the live plane: instant and ephemeral. Prometheus is the historic plane: scraped, stored and queryable. They answer different questions, and a signal only has a history if something exposes it as a metric.

The pattern

• The hub subscribes to the bus and exposes a metric for everything that matters, such as zigbee_temperature_celsius, bms_state{point=…} and detection counters by camera and zone.
• Jarvis has a tool that runs arbitrary PromQL, plus a helper that turns on/off state ranges into "ran at 06:10, 07:45 and 11:30".
• Retention sets the limit on what the assistant can reason about. Fifteen days is short; the cardinality here is small enough to keep a year.

Takeaway: when you add a sensor, decide on day one whether it needs a history. If it does, make it a metric.

Frigate's object detection and its face-recognition embeddings run as separate processes. The embeddings process can wedge while detection carries on perfectly well. Cameras stay green and events keep coming in, but none of them carry a name any more.

Nothing errors. The symptom is an absence: events lose their sub_label. A restart fixes it, provided you notice.

Also worth knowing

• Recognition on low-resolution sub-streams is marginal at a strict threshold. Choose your trade-off between false matches and missed ones deliberately.
• After changing detect resolution, clear the stale frame buffers in shared memory, or you'll get strange results.
• In an LXC install, a service-level restart is more reliable than the API restart.

Takeaway: monitor for missing outputs, not just crashed processes. "Recognised faces per hour dropped to zero while person detections continued" is an alert worth having.

Sentinel sends push notifications in two tiers, critical and informational, and announces events on the Echo speakers. But notifications get silenced and speakers get ignored. For smoke, water, a room over 29 °C or an intruder, I wanted something that insists.

How it works

• An Asterisk PBX runs in its own container, with a small Node application on the Asterisk REST Interface (ARI).
• The hub posts a critical alert. The app calls the first person on the list and speaks the alert with local TTS.
• Press 1 to acknowledge and the escalation stops. Press 2 to snooze. No answer, and it moves on to the next person, round and round, until somebody takes responsibility.
• Every stage is published back to MQTT, so the dashboard shows who was called and who acknowledged.

A small gotcha: Asterisk wants 8 kHz mono WAV for playback. Feed it anything else and the call connects in silence.

Takeaway: for life-safety alerts, design for acknowledgement rather than delivery. "The message was sent" and "someone knows" are very different outcomes.