Home Command Center

Smart plugs say "on" while nothing runs. This MCP server checks real behaviour, explains faults, and controls a real ESP32 from Alexa voice, a Fire TV dashboard and a web assistant.

Comment

Inspiration

A smart plug that powered a water pump kept switching itself off about ten minutes after every start, while the app still showed it as "on". There was no alert, no explanation, and the built-in timer was unreliable. Apps tell you what a device was told to do, not whether it is really doing it. I wanted a layer that checks real behaviour and explains problems in plain words.

What it does

Home Command Center is a self-hosted MCP server that gives an assistant seven smart-home tools: list devices, read one device's status, read recent alerts, switch a device on or off, run a device for N minutes, add a note and list notes. Replies are written to be read aloud, spoken device names are matched loosely ("the pump plug"), and a timed run on a faulty device is refused. A web assistant is a real MCP client. It links with the same OAuth 2.1 + PKCE flow Alexa+ uses, and it shows every step: request, chosen tool, reply.

The same backend feeds a native Fire TV (Vega OS) dashboard running on a real Fire TV Stick: device cards marked LIVE or SIMULATED, alerts with plain-language explanations, notes, and a live panel of what the assistant just did.

A real ESP32-S3 appears on that dashboard as two live devices, a relay output and its onboard LED. It reports every second and obeys on/off commands from the TV, from the web assistant, and from Alexa by voice. The board is paired with an Echo over Matter, so "Alexa, turn on the ESP32 LED" works without a cloud skill.

Fault detection works on measured behaviour, not on what a device claims: "switched on but not running" and "went silent" (no report for 10 seconds). Timed runs are enforced by the backend, which reports a failure if the device stops early.

How I built it

  • MCP server: TypeScript, official MCP SDK (spec 2025-11-25), stateless Streamable HTTP, Origin validation, signed Mcp-Session-Id, refusal of JSON-RPC batches and query-string tokens, and a hand-written OAuth 2.1 authorization server (PKCE S256, resource indicator, refresh tokens, hashed token storage, passcode lockout).
  • Backend: Express, anomaly detection, a timed-run engine, an activity log, and a live-node API for hardware (device key, desired-state queue).
  • Web assistant: a local server plus React UI. Offline mode needs no AWS. An AWS mode (Amazon Translate, Transcribe, Bedrock tool use) is built and tested against fakes.
  • Fire TV: React Native for Vega OS, built and run on a real Fire TV Stick 4K Select.
  • ESP32-S3: Arduino firmware with a relay output, an MPU6050 vibration reader and two Matter on/off plugs.
  • Quality: 135 automated tests across five packages, including a real MCP client over HTTP and OAuth attack cases. The MCP server also passes the third-party alexa-plus-mcp-checks tool (11 pass, 2 skipped because they cover an optional Echo Show feature), and the Hearsay voice-readiness lint reports no findings. The outputs are in the evidence folder of the repo.

Challenges

Alexa+ add-on tools are in preview for select partners only, so I built and tested a self-hosted MCP server and an MCP client web page, as the rules allow. Getting a Vega app onto a real Stick took several undocumented workarounds, all recorded in the friction log. Running the third-party MCP checker found five real gaps in my first version (Origin validation, batch and query-token refusal, session ids, and a metadata mismatch), which are now fixed and covered by tests. A new AWS Free-plan account blocked Translate, Bedrock and credit redemption, so the Tamil and voice mode could not be verified live.

Accomplishments

A complete, tested MCP + OAuth implementation; a native app on real Fire TV hardware; a real ESP32 on the same dashboard as simulated devices, controllable from the TV, a web assistant and Alexa voice; and a friction log with 12 concrete developer-experience findings.

What I learned

Silent failures need measurement, not status flags. Voice-assistant auth is mostly about getting exact OAuth details right. And developer tooling for new platforms lives or dies on its error messages.

What's next

Verifying the Tamil and voice mode live once the AWS account is activated, sensor-based fault detection on the real motor, tank-level cut-off and dry-run protection for pumps, and a confirmation step before long timed runs.

Honest limitations

  • Devices other than the ESP32 are simulated (fictional brands), because Alexa gives third-party apps no way to read a customer's device state.
  • A real Alexa+ device does not call this MCP server, since add-on tools are preview-only. The Alexa+ experience is shown through the MCP server and a web MCP client. Alexa voice control of the ESP32 is a separate path, over Matter.
  • Matter pairing uses the library's test credentials, so the Alexa app asks you to confirm the device is not Matter certified.
  • The relay switches only the low-voltage side; nothing is connected to mains.
  • Tamil, voice and Bedrock routing are built and tested against fakes, but were not verified live.
  • The MPU6050 fault detection is verified in backend tests, not on the real motor.

Built With

Share this project:

Updates

Submission history