HomeKeeper

Inspiration

Every home is full of things you're supposed to remember — and don't. The HVAC filter that was due two weeks ago. The water heater warranty quietly expiring. The safety recall you never heard about until it was too late. Appliances don't remind you, and the cost of forgetting is real: breakdowns, voided warranties, safety risks. I wanted a home assistant that doesn't wait to be asked — one that already knows what needs attention and tells you before it becomes a problem.

What it does

HomeKeeper is a proactive home-appliance manager for the Alexa+ track. It remembers every appliance's model, maintenance schedule, warranty, and recall status — and surfaces what needs attention in a morning briefing. Report a symptom ("the water heater is making a strange noise") and it triages: warranty status, maintenance history, knowledge-base guidance. Photograph an appliance nameplate and Bedrock vision reads the brand, model, and serial automatically. The safety recall in the demo is real — pulled live from the U.S. CPSC feed (Galanz #10885).

How I built it

The backend is a self-hosted MCP server (FastMCP, spec 2025-11-25, Streamable HTTP) on AWS Lambda behind API Gateway, with DynamoDB as the store and seven MCP tools: get_home_briefing, get_appliance, add_appliance, start_photo_onboarding, log_maintenance, get_reorder_options, report_issue. The architecture splits into a hot path and a cold path: every user interaction runs Lambda → DynamoDB with no LLM involved (warm latency 13–76 ms, target under 500 ms). Amazon Bedrock (Claude) works off the hot path for free-ask chat with MCP tool use and nameplate vision extraction. An EventBridge schedule runs a daily 6 AM CT scan that pulls the live CPSC recall feed into DynamoDB. The frontend is a high-fidelity simulated Echo Show (the Alexa AI toolchain is partner-gated), and every card it renders comes from a live MCP tool call.

Challenges I faced

The biggest one: the Alexa AI CLI path was completely gated — our account's sts:AssumeRole for Amazon's CodeArtifact role is denied by an allowlist with no self-serve access request. I burned half a day proving the negative before pivoting to the self-hosted MCP + simulator route the track rules explicitly allow. Then Lambda Function URLs returned 403 on every request account-wide (even on a hello-world function, in two regions) — root cause unknown — so I migrated all browser traffic to API Gateway. FastMCP 4.x fought back too: its DNS-rebinding guard rejects Lambda hostnames, and its session manager only initializes inside the ASGI lifespan. I also tried migrating chat to a Strands agent on AgentCore Runtime via the Docker-less code deploy — the runtime reached READY, but every invocation timed out in platform initialization, even for a hello-world agent. The working Lambda chat stayed.

What I learned

Latency is an architecture decision, not an optimization: the only way to guarantee sub-500 ms is to keep every model call off the request path. A static appliance catalog — not the LLM — must be the source of maintenance schedules; that's the hallucination guard. Coarse-grained, intent-based MCP tools let a conversational frontend pick the right one without chaining. And honest friction logs are a feature: every workaround above is documented in the repo's FRICTION_LOG.md, which became the product-feedback submission.

Built With

• alexa+
• amazon-bedrock
• api-gateway
• aws-lambda
• cloudfront
• dynamodb
• eventbridge
• javascript
• mcp
• python
• s3