What I'm Doing Next — Five Months In, Winter Coming

• ~92 %self-sufficiency of everything on the battery side, cooker carved out
• 2,098relay switches in half an hour from a flickering hot-water sensor
• 5things on the worklist before winter

Everything in this series comes from one system: a 19.38 kW solar array and a 48.36 kWh battery on a brick-veneer house in suburban Melbourne, on a wholesale-passthrough plan, instrumented to within an inch of its life. Personal optimisation, one household, one dataset. None of it is a comment on the wider energy market or on anyone else’s choices.

---

I assumed the closing post would be about the panels and the battery: capacity, output, payback. It isn’t. Five months in, what interests me most is the data layer, and the bit of it still missing. So this is a stocktake: what surprised me, what I got wrong, and what I’ll do before winter.

What surprised me

The data was worth more than the hardware. Self-sufficiency over the first five months is around 92 per cent for everything on the battery side (about 89 per cent with the grid-side cooker counted), which sounds heroic and is mostly a large array and a large battery in a Melbourne summer. What changes behaviour week to week is the data: half-hourly prices, on-roof irradiance, tank temperatures, state-of-charge histories. Without it the hardware runs on defaults. With it, on intent.

The forecast was not lying. I was throttling the inverter. I spent weeks convinced the commercial solar forecast overestimated cloudy days by 100 to 400 per cent. The comparison was wrong. I was measuring it against what the inverter produced, and the inverter was held back for hours whenever the battery was full. Against what the panels could have made, the forecast error collapses to about +14 per cent on clear days, +8 on mixed and +39 on the handful of cloudy days I have. On a sunny summer day the panels could have made about 63 kWh more, with nowhere to put it. Any “forecast versus actual” on a system that curtails is really the weather service against your own controller.

The failures taught me more than the smooth weeks. A hot water unit fired its relay 2,098 times in half an hour because a binary “exporting” sensor flickered on near-zero power. A stratified tank fooled its own thermostat with cold water under a warm probe. A restart exported about 8.7 kWh into a negative price one Sunday because a threshold trigger never re-evaluated. Each produced a fix, a pattern I now apply to every new automation, and a healthy distrust of any subsystem that looks perfect.

What I would do differently

I would put the cooker behind the battery on day one. About 90 per cent of what I import in the 3 to 9 pm peak is the induction range, on the grid side of the meter where the inverter can’t see it. Every evening it pulls two or three kilowatts at peak prices while the battery, three metres away in the garage, has plenty to spare. That’s a sparky job to undo now. If you have a serious induction cooker, have it wired behind the inverter.

I would have Home Assistant and the data stack running before the panels went up. I lost most of the first month of high-resolution data because monitoring wasn’t connected until after commissioning. That month is the baseline, and you can’t retrofit it.

And I would write the automation design before the YAML. My first automations were reactive: see a problem, write a fix, move on. Two weeks later I couldn’t remember what each did, and several contradicted each other. Priorities, safety conditions and restart behaviour should have been the starting point.

What I’m optimising for

Four tiers sit under every automation decision. First, cover the household load from on-site generation and storage. Second, cover the fixed monthly costs, roughly fifty dollars, from net export earnings. In summer that’s comfortable; in winter it’s the question. Third, exports must clear the per-cycle cost of the battery before I count them as profit. Fourth, whatever’s left.

Writing it down stops me optimising for whichever number is most flattering on the day.

Five months of receipts

Four invoices: $157.47 earned, reconciled to the cent. About 62 per cent of it came from 205 half-hours when I exported at a feed-in rate above ten cents. The curtailment automation that holds exports back in negative prices cost a net dollar or so. Almost exactly break-even, which is what break-even on a safety rule should look like.

I missed one big one. On 27 January the feed-in rate ran to about 186 cents for a single half hour and my system wasn’t set up to catch it. That’s a known gap and a future target, and I’d rather have it on the record.

The restart that exported into a negative price

On a Sunday in April, after a Home Assistant restart, the curtailment rule didn’t re-fire. The trigger only evaluates on a state change, and the sensor came back already below zero. About 8.7 kWh went out at between −4 and −8 cents a kilowatt-hour over an hour. Cost: about fifty cents. Trivial in dollars, and a perfect example of a failure anyone building threshold-driven automations will meet.

The fix is a re-evaluation after every restart, plus an independent five-minute polling fallback.

What I’m doing next

Winter is the test. Solar falls to roughly 30 to 40 per cent of its summer peak, the battery won’t fill from solar on most days, and six zones of heating run for hours. The question summer never made me answer becomes unavoidable: when do I buy from the grid to charge the battery, and how much of that is real margin once I price the cycle?

Five things are on the worklist for the next three months.

Winter scenario modelling. Re-running the dispatch model against four winter scenarios: do nothing, schedule the heating, add an off-peak battery top-up, add slab pre-heating. On a first pass, the do-nothing scenario empties the battery. I want the thresholds reworked and tested before a frosty week in July.

Irradiance cross-calibration. Replacing the blanket damping setting on the solar forecast with a calibration curve fitted to the on-roof pyranometer. I expect it to move day-to-day dispatch most, because every rule downstream of the forecast inherits its errors.

A model-predictive control dry-run. My automations are rule-based: a condition, an action, ship it. Next is an optimiser that takes price forecasts, solar forecasts, load predictions and battery state and produces a dispatch schedule over a rolling horizon, using the open-source EMHASS. I’ll run it in shadow mode through winter, compare its dispatch with what the rules did, and promote it only if the gain justifies the extra moving parts.

Double glazing, in two stages. The biggest single change to the house this winter, and not a software one. It’s mid-1990s brick veneer with single-glazed aluminium windows, and the heating load shows it. Stage one goes in late April: the open-plan living area and two bedrooms, four conditioned zones. The other two bedrooms follow by Christmas. Either side of the install I’ll run a slab-decay test: pre-heat all six zones to set-point plus two, switch the heating off at half-past one, log temperatures every five minutes, and use the unchanged master bedroom as the control. I’ll report the before and after honestly, including the uncomfortably long payback.

Closing out the restart family. One sibling rule still lacks the independent polling fallback, and one more automation family needs auditing. Both will be done before winter.

Other things are developing in the background and will be their own series: a local AI integration, a study of the cooker load once it’s rewired, and the second phase of the renovation.

Measure everything. Trust the data over the intuition. Automate what can be automated. Be honest about what you don’t yet know. The most interesting season, where the comfortable summer story meets a Melbourne winter, starts in about six weeks. I’ll let you know how it goes.

This is the final post in this series. There will be more, almost certainly a winter update, and probably a separate thread on model-predictive control.