DEV Community

Cover image for I Built a Local AI Electricity Investigator — Because AI Should Explain the Numbers, Not Invent Them ⚡
Padma Lochini
Padma Lochini

Posted on

I Built a Local AI Electricity Investigator — Because AI Should Explain the Numbers, Not Invent Them ⚡

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

I Built a Local AI Electricity Investigator — Because AI Should Explain the Numbers, Not Invent Them ⚡

What if a household electricity bill could become the starting point for an investigation, rather than just another amount to pay?

Imagine opening your electricity bill and noticing that your consumption seems unusually high. You know you use an air conditioner, a refrigerator, fans, lights, and a laptop. But which appliances contribute the most to your estimated energy use? How much might they cost over a month? And what should you investigate first?

A generic chatbot might give you a list of energy-saving tips. A calculator can give you a number.

I wanted to bring those two capabilities together: reliable calculations and understandable, locally generated explanations.

That idea became LeakLedger AI, my project for the Hacktoberfest 2026 Open-Source AI Challenge — Week 2: Side Hustle.

🔗 GitHub repository: https://github.com/padmalochini27-del/LeakLedgerAI

1. The problem isn't just calculating electricity consumption

Electricity consumption is measurable, but turning appliance information into a useful household decision can be confusing.

A user may know that an appliance consumes a certain number of watts, but watts alone do not tell the whole story. Usage duration matters. The electricity tariff matters. The number of days matters, too.

The basic calculation is straightforward:

Energy consumed (kWh) = Power (watts) × Usage hours ÷ 1,000

For a billing period, we multiply daily consumption by the number of days. Estimated cost is then calculated from energy consumption and the entered tariff.

But a useful tool should do more than display formulas. It should help people interpret the results, compare appliances, and identify sensible next steps.

That's the gap LeakLedger AI is designed to address.

2. Meet LeakLedger AI

LeakLedger AI is a local-first household electricity consumption investigation assistant built with Python, Streamlit, and Gemma running through Ollama.

Users can enter appliance details, estimate consumption and electricity costs over a selected period, compare appliance-level usage, and ask a local AI model to explain the results.

The application brings together five capabilities:

  • Calculate: Estimate energy consumption and cost from user-provided appliance data.
  • Compare: Break down estimated consumption by appliance.
  • Visualize: Present the results through dashboard metrics, a table, and a chart.
  • Explain: Use a locally running language model to generate a plain-language interpretation.
  • Investigate: Offer a checklist of practical steps to examine unexpectedly high consumption.

It also supports exporting the appliance breakdown to CSV for further analysis.

The goal is not to pretend that a simple dashboard can diagnose every electrical problem. It is to give users a clearer starting point for understanding their consumption.

3. The most important design decision: code calculates; AI explains

One of the most important lessons from building this project was deciding what the language model should—and should not—be responsible for.

Language models can produce fluent explanations, but fluency is not the same as numerical reliability. A response can sound convincing and still misstate a value, misunderstand a time period, or confuse watts with kilowatt-hours.

That matters when a user is trying to understand a bill.

So LeakLedger AI separates the two responsibilities.

Python is responsible for the calculations. Gemma is responsible for helping explain the results.

The application calculates consumption and estimated cost using explicit formulas. The AI receives the calculated information and is instructed to use those values when generating its explanation.

This separation is intentional: the model should not be treated as the source of truth for arithmetic.

It does not eliminate every possibility of an incorrect AI explanation. The model can still make mistakes, so its narrative should be checked against the displayed calculations.

I see this as an important principle for practical AI development: use generative AI where language and interpretation help, and deterministic code where the result must be calculated explicitly.

4. Why use open-weight AI locally?

For this project, I used Gemma 3 1B through Ollama.

That choice was not simply about adding an AI label to an application. Local inference changes how the application can be used.

More control over personal data

Household appliance information and consumption estimates can reveal patterns about someone's daily life.

With local inference, the AI explanation can be generated on the user's own computer rather than requiring a hosted language-model API. This reduces the need to send that information to an external AI provider.

Local inference alone does not guarantee complete privacy: the application, dependencies, operating system, and any future integrations still need to be considered.

Fewer dependencies on hosted AI services

A locally running model avoids per-request fees charged by a hosted AI API. The user still needs to download the model and software, and local computation consumes hardware resources and electricity.

For a small utility, that trade-off is worth exploring.

More freedom to experiment

An open-weight model can be run and evaluated locally. Developers can experiment with different models and change the surrounding application without making every AI interaction dependent on one hosted provider.

For me, the value of open innovation is not simply that a model is available. It is that developers have more control over where inference happens, how it is integrated, and how the application evolves.

The open model is part of the application's architecture—not just a feature mentioned in its description.

5. What happens inside the application?

The workflow is deliberately simple:

  1. The user enters appliance power, usage duration, tariff, and the relevant number of days.
  2. Python calculates estimated energy consumption and cost.
  3. Streamlit displays the results, appliance breakdown, and chart.
  4. The application passes the calculated information to the local Gemma model for an explanation.
  5. The user reviews the explanation and uses the investigation checklist to decide what to examine next.

The main technologies are:

  • Python for calculation logic.
  • Streamlit for the interactive application.
  • Pandas for tabular data handling.
  • Ollama for running the language model locally.
  • Gemma 3 1B for AI-generated explanations.

This is a small application, but it demonstrates a design pattern I want to keep exploring: combine transparent computation with local generative AI, and give each component a clearly defined job.

6. A look at the working application

Dashboard overview

[
LeakLedger AI dashboard showing estimated household electricity consumption, daily usage, and estimated electricity cost.]

Appliance consumption breakdown

[
LeakLedger AI appliance breakdown showing estimated electricity consumption by household appliance in a table and chart.]

Local AI explanation

[
LeakLedger AI displaying a locally generated Gemma explanation and a checklist for investigating household electricity consumption.]

Explore the code: https://github.com/padmalochini27-del/LeakLedgerAI

The repository contains the application code and setup instructions. The project currently runs locally rather than being presented as a publicly hosted service.

7. Could this become a side hustle?

I built LeakLedger AI as a prototype, but I designed it around a problem that households and small organizations may find worth solving.

Potential users include:

  • Households that want a clearer picture of estimated appliance-level consumption.
  • Renters and students who want to understand how their usage affects electricity costs.
  • Small offices that want a simple way to explore appliance energy estimates.
  • Energy-conscious users who want to compare different usage scenarios before changing their habits.

A future version could let users save appliance profiles, compare estimates with actual electricity bills, and maintain consumption records over time.

A possible business model would be a low-cost desktop utility or a paid version with saved profiles, reports, and historical comparisons. That is a hypothesis to validate, not a claim that customers are already paying.

The next meaningful test would be to put the tool in front of actual users, observe how they use it, and find out whether the results help them make decisions they value enough to pay for.

I would also want to test the estimates against real bills and improve how the AI explanation stays grounded in the calculated data.

8. What LeakLedger AI does not claim to do

Trust is important for an application that discusses electricity usage.

LeakLedger AI estimates consumption using the values entered by the user. It does not directly read a smart meter, verify an electricity bill, detect a physical electrical fault, or guarantee that a particular appliance is responsible for high consumption.

The quality of the estimate depends on the accuracy of the inputs and the assumptions used.

Likewise, Gemma's explanation is not an electrical diagnosis. Users should verify numerical values against the dashboard and consult a qualified electrician when they suspect an electrical fault.

These limitations define the current scope of the project and the work that remains.

9. What I learned from building it

This project reinforced an idea that is easy to overlook when building AI applications: choosing a model is only one part of the design.

The surrounding software matters just as much.

A useful AI application needs a clear problem, dependable calculations, an appropriate role for the model, understandable results, and honest boundaries around what it can do.

Open-weight models and local inference make it possible to explore those ideas without making a hosted AI service the center of every interaction.

LeakLedger AI is an early prototype, not a finished energy-management platform. But it is a working step toward a more transparent, local-first approach to everyday utility software.

Your turn

If you were using LeakLedger AI, what would make it genuinely useful?

Would you want to compare estimated consumption against actual bills, track appliance usage over time, or receive more detailed recommendations for investigating high consumption?

I'd love to hear your thoughts, especially from developers building practical applications with open-weight models and local AI.

Built for Hacktoberfest 2026 — Open-Source AI Challenge, Week 2: Side Hustle.

Top comments (0)