Claude to build a home-energy controller
Simon Monk used Claude Code across more than ninety development sessions to build a controller for his Sydney home's solar panels, Powerwall battery and electric vehicle. The system began on a Mac Studio and moved to a Raspberry Pi connected to Home Assistant.
linkedin.com
Original prompt
Shared by the source author. See source notes for context.
why is it doing this when as a human I'd do that?
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Simon Monk
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- A working rules-based home controller; Monk reports demand charges falling from $88 to $6.
- Human involvement
- Monk questioned observed decisions and investigated a flawed shadow-model comparison.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Build and inspect an energy-control system with Claude Code.
- Move unreliable LLM actuation into deterministic Python rules.
- Compare experimental control in shadow mode and investigate missing data.
Simon Monk used Claude Code across more than ninety development sessions to build a controller for his Sydney home's solar panels, Powerwall battery and electric vehicle. The system began on a Mac Studio and moved to a Raspberry Pi connected to Home Assistant.
A crucial design change came from observed failures. The early language-model controller had about ten rules but invented prices and made inconsistent decisions. Monk moved the actual control into deterministic Python rules, running every thirty minutes. Claude Code remained the tool used to build and debug the system; it should not be confused with an LLM autonomously choosing the current charging actions.
The project also gained a forecast that calibrated hourly bias using previous observations. A more sophisticated optimization model ran in shadow mode, allowing comparison without handing it control. That comparison later proved unreliable: two Home Assistant configuration instances had diverged, leaving the shadow model without battery state-of-charge data for seven weeks.
Monk reports that monthly demand charges fell from $88 to $6, but that is his account of this installation, not independently verified savings or a result transferable to every tariff. The useful lesson is operational: check decisions against observed data, keep experimental control in shadow mode, and investigate configuration consistency before trusting a comparison.
Prompt
Original prompt
Source: www.linkedin.com · Simon Monk
Frequently asked questions
Did the LLM retain control of charging?
No. Unreliable LLM decisions led Monk to deterministic Python control.
Why was the shadow comparison invalid?
Divergent Home Assistant configurations hid battery state-of-charge data for seven weeks.
Are the bill savings independently verified?
No. The $88-to-$6 reduction is the author's reported result for his installation.
More details
About this account
Claude Code built and debugged the controller; deterministic Python performed recurring control.
Firsthand source opened and read. Prompt is a verbatim excerpt of the published original instruction. The excerpt is the published diagnostic question, not the full private controller-build instruction.
Credit: Simon Monk
Source published
Added to Agents In Use
Source checked
Tools and topics
Claude Code · Home Assistant · Python · Powerwall · Raspberry Pi
Home energy · Battery control · Demand charges
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.