AI Solar Panel
028 AI Tools, Prompts and Data Pipelines 1,231 words · 6 min

Local LLMs vs Cloud for Your Household Energy Data

Your half-hourly meter data is not really energy data. It is a diary of who is home.

Look at a week of 48-slot readings and you can read it like a rota. A flat 0.12 kWh overnight baseline, a kettle spike at 06:45, nothing between 08:30 and 17:15, then the oven. A cluster of zeros for ten days in August is a holiday. A baseline that jumps from 0.12 to 0.35 kWh per slot suggests someone new has moved in, or someone is working from home. Anyone who sees that file can infer when your house is empty. That is the reason to care about local LLM data analysis privacy, and it is a sharper reason than the usual vague unease about “AI and data”.

My position: keep the raw half-hourly file at home, always. Send the cloud only what it needs, which is almost never the raw file. Below is how I’d split the work, with numbers.

What is actually in the file

A year of half-hourly import data is 17,520 rows. Add export, and a battery’s state of charge if your inverter logs it, and you have maybe 50,000 data points. Octopus’s API, a Hildebrand Glow or Bright CAD, Home Assistant’s energy dashboard and a SolaX or Givenergy export will all give you this.

A quick test of what it leaks. Take the rows for one year and compute, for each hour, the median usage on weekdays:

hour   weekday_median_kWh
02:00  0.11
07:00  0.58
10:00  0.14
13:00  0.13
18:00  0.91
23:00  0.22

Hour 10:00 to 13:00 sits at near baseline. That tells a stranger the house is empty on weekday daytimes. Combine it with a postcode in a prompt (“my house in BS6…”) and you have a burglar’s briefing. I’m not saying a cloud provider would do this. I’m saying you cannot un-send it, and retention policies, training opt-outs and breach history vary by product and change without you noticing.

What local models can and can’t do on tables

I’ve been running models through Ollama and LM Studio on a 16 GB RAM Mac mini and, separately, a desktop with an RTX 3060 (12 GB). Realistic choices at this size: Qwen 2.5 14B or Llama 3.1 8B quantised to 4 bits, which take roughly 9 GB and 5 GB.

Here is the honest result, and it is not “local is just as good”.

Local models are poor at arithmetic over many rows. Paste 2,000 rows into an 8B model and ask for total export in March. It will give you a confident number that is out by 5 to 15 per cent. Cloud frontier models are better but also not reliable at summing long columns in their head. Both are bad at the wrong job.

Both are good at writing code that does the arithmetic. This is the whole trick. Ask for a pandas script, run it yourself, and the model’s size matters far less. On my own tests, a 14B model wrote a correct monthly-aggregation script for a Glow CSV on the first try in 8 of 10 attempts, and the other two were fixed by pasting back the error. A frontier cloud model managed 10 of 10. That gap is real but small, and it costs you a retry, not your privacy.

Where cloud clearly wins is messy reasoning: “my tariff changed on 14 June, the inverter clock drifts, and export is sometimes negative, so how do I reconcile?” There the larger models hold more context and make fewer silly assumptions. That’s a reason to ask the cloud questions, not to hand it your data.

The hybrid split

Three rules.

  1. Raw data never leaves the machine. Local model or plain Python only.
  2. Schema and synthetic rows go to the cloud. Column names, types, ten fake rows.
  3. Aggregates go to the cloud for judgement. Monthly totals, not half-hours.

Worked example. You want a payback estimate for a 5 kWh battery on Octopus Intelligent Go (about 7p/kWh off-peak, roughly 25p peak, check your current rates).

Step 1, to the cloud model, with no real data:

I have a CSV with columns: timestamp (UTC, ISO8601), import_kwh,
export_kwh, one row per 30 minutes. Write a pandas script that
simulates a 5 kWh battery (90% round trip, 2.5 kW max rate) charging
in 23:30-05:30 and discharging to cover import otherwise.
Output monthly savings in pounds at 7p off-peak, 25p peak.

Step 2, run the script locally on the real file. Output:

month    import_kWh  shifted_kWh  saving_£
2025-10      312        118        19.87
2025-11      401        132        22.28
2025-12      456        141        23.80
...
annual                           ~£228

Step 3, send only that table to the cloud and ask: at £3,200 installed, what is the simple payback, and what happens if the peak rate falls to 20p? Simple payback is 3,200 / 228 = 14 years. At 20p peak, savings drop to roughly £185, and payback stretches to about 17 years. Those numbers came from a 12-row table, which is the only thing the cloud ever saw.

You get frontier-quality reasoning about a decision, and the occupancy pattern stayed on your disk.

Making the aggregates safe too

Aggregates leak less, but not nothing. A few habits:

  • Round to the nearest 5 kWh in what you paste.
  • Strip the postcode, MPAN and serial numbers. An MPAN is a 13-digit identifier that points at your exact meter.
  • Use monthly or daily totals, never hourly profiles. A daily total shows you used 9 kWh. It doesn’t show when.
  • Rename the dates if you’re being strict: “Month 1 to Month 12”.

If you use a cloud tool’s file upload, remember the file is the product of your own pipeline. Check what it contains before you drag it in.

When fully local is worth the effort

If you want the model to chat over the data itself (anomaly explanation, “why was Tuesday so high?”), keep that local too. Home Assistant can feed Ollama through its Assist integration, and a 14B model handles “what drew power at 03:00 last Tuesday?” when you give it the pre-filtered rows for that window, say 20 rows rather than the full year. Retrieval first, then reasoning, is how small models stay accurate.

Budget about £0 if you already own a recent laptop, or around £250 for a used GPU. Running costs are small: a 3060 under load draws roughly 150 W, so an hour of heavy use costs about 4p at 28p/kWh. Compare that with a cloud subscription at £15 to £20 a month and the local setup pays for the GPU in about a year, if you’d have subscribed anyway.

What I’d do this weekend

Export a year of data from your supplier or Glow. Install Ollama, pull qwen2.5:14b (or llama3.1:8b on a smaller machine), and ask it to write you a pandas summary script using only the column names. Run the script. Look at the output and decide which two or three tables you’d be happy to show a stranger. Those are your cloud-safe tables.

The wider toolkit for this, including prompt templates and pipelines that automate the split, is in the AI Tools, Prompts and Data Pipelines guide.

One last check before you paste anything anywhere: could someone read when you’re out from it? If yes, it stays home.