We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

VOLT — Autonomous Household Energy Agent

An AI agent that manages EV charging, battery, and solar around goals you set — not a schedule — replanning on its own as prices and conditions change.

Comment

Inspiration

I have an EV, home solar, and a battery — and I was tired of manually timing when things charged. Every system optimizes itself independently: the EV wants to charge, the battery wants to discharge, the price changes every hour, and none of them talk to each other. I didn't want another dashboard telling me numbers I'd still have to act on manually. I wanted to tell a system what I actually cared about — EV ready by a certain time, battery never below a safety margin, minimize cost — and have it handle the coordination. That's VOLT.

What it does

VOLT is an autonomous household resource operator. You give it outcomes and constraints, not a schedule: "EV at 80% by 7am, battery never below 30% reserve, minimize cost." A Strands agent continuously observes household state, decides when re-planning is needed, calls a constrained optimizer to generate a feasible schedule, applies the near-term action through a device adapter, and verifies the action actually happened rather than assuming success. When something makes the objective genuinely infeasible — a charger failure, a moved-up deadline — it escalates to the user with real options instead of silently missing the target or faking success.

How we built it

I built it in layers, deliberately keeping the LLM out of safety-critical control: a domain model for the household's authoritative state, a deterministic household simulator (solar/battery/EV/grid/appliances with real physical constraints — SOC bounds, charge-rate limits), a constrained optimizer that does deadline-aware scheduling and correctly flags infeasible objectives instead of hallucinating success, and a Strands agent layer with real @tool-decorated functions (get_household_state, run_optimizer_tool, apply_device_action, verify_device_state, request_human_decision) that never touch a device directly — every device sits behind a DeviceAdapter interface instead. I tested the full loop against ten scenarios (price spikes, solar forecast collapse, device failure, impossible objectives, mid-run preference changes) before ever touching AWS, then wired build_strands_agent() to a real Bedrock model and verified the pipeline live — it authenticated and the model started responding before hitting a token-throttling limit on a fresh AWS account, which was honestly a good sign: the whole chain worked end to end. Alongside the backend, I built a standalone interactive control-center UI (no server, no AWS needed) so the demo is reliable regardless of network conditions on presentation day.

Challenges we ran into

The biggest one: my own EV doesn't have an official public API. Tesla has a documented Fleet API; mine doesn't. That forced me to actually design the adapter layer properly instead of assuming one vendor pattern fits everyone — I ended up documenting three real integration paths (an unofficial reverse-engineered my EV app API, an OBD-II telemetry dongle, and metering/controlling at the charger itself via OCPP, which turned out to be the most robust option since it doesn't depend on any single car vendor's API staying stable). A "dumb" non-smart AC unit posed a similar problem — it can't report anything about itself, so the real answer is a clamp-on current-transformer energy monitor on its circuit, not a smart-device integration at all. I also hit a fresh-AWS-account token throttling limit during live testing, and a few rounds of git/venv friction (activating a virtualenv doesn't persist across terminal sessions, and a bad unzip nested the whole repo one folder too deep, which silently broke GitHub's automatic license detection until I caught and fixed it).

Accomplishments that we're proud of

Every one of the ten required scenario types — normal operation, price spike, solar collapse, early EV arrival, moved-up deadline, reserve change, device failure, an outright impossible objective, a mid-run preference change, and post-action verification catching a failure — runs correctly against the real optimizer and agent tool stack, not a scripted demo. The infeasible cases correctly escalate instead of faking success, which was a hard requirement I didn't want to compromise on. And the architecture is honest: everything simulated is clearly labeled as such, and the device adapter layer is real, documented code with actual API shapes for Tesla, Home Assistant, and SolarEdge — not just a diagram claiming it's possible.

What we learned

That the interesting engineering problem in "AI home energy management" isn't the AI part — it's the integration layer. Car and inverter APIs are inconsistent, sometimes nonexistent, and often unreliable, so a resilient design has to plan for multiple integration paths per device category and keep the LLM's job scoped to orchestration and judgment calls, never direct hardware control. I also learned, the hard way, that fresh AWS accounts have very low default Bedrock token quotas — worth requesting an increase well before you need it, not during a demo.

What's next for VOLT — Autonomous Household Energy Agent

Wiring a real adapter live — starting with OCPP-based charger metering since it's the most vendor-agnostic — deploying with Bedrock AgentCore for persistent always-on operation, replacing the greedy optimizer with a proper MILP solver for harder multi-appliance scheduling problems, and eventually expanding past energy into the broader "personal infrastructure agent" idea: water, heating, and other household systems people currently have to coordinate by hand.

Built With

Share this project:

Updates

Submission history