Whole-home audio control

Origin

Whole-home audio installations are sold as integrated systems and shipped as a fragmented mess. Each vendor has its own app, each app handles a different layer of the stack, and to play a specific track in a specific room you open three apps and curse the vendor UX. Everyone with one of these systems eventually has the same realization: the substrate is good, the interface is unusable.

Problem

The right interface is one message. 'Play Cohen in the kitchen' should be one line, one process, one protocol call. The vendor apps are the wrong abstraction; the protocols underneath are correct.

Approach

A bridge that speaks the proprietary binary control protocol on one side and standard HTTP control on the other. A small natural-language layer translates room + content into protocol calls. Telegram is the primary front-end; chat is the right interface for this. The bridge runs as a long-lived process on the same sovereign stack that runs the rest of the personal infrastructure.

Methodology

Sovereign — runs locally, never leaves the LAN unless explicitly asked to. The proprietary binary protocol was learned by inspection rather than from a vendor SDK (there isn't one). The bridge has no cloud dependency; if the upstream vendor cloud goes down, the bridge keeps working.

Selected milestones

• Proprietary binary protocol learned from inspection
• Standard HTTP control implemented end-to-end
• Chat integration in active daily use

Open questions

• Whether to add a HomeKit gateway for Apple-ecosystem control
• How to surface multi-zone scenes ('the whole house') without a UI

Ask me about

• How a proprietary binary protocol gets learned without a vendor SDK
• Why the bridge runs locally rather than as a cloud service
• What the right interface is for whole-home audio

Stack