Fig 1: HEMS’s device front and back and software dashboard views.

From Monitoring to Control

A key part of the project lies in the jump from monitoring to control. The report sets out three operating modes. Normal mode clears prior programmed settings and leaves the system on standby. Blackout mode prepares the house for an outage by turning off non-essential loads and charging the battery as fast as the inverter settings permit. Automated mode handles day-to-day decision-making. In that mode, the controller checks battery state of charge, solar generation, household load, weather data, and load-shedding schedules, then decides how to prepare the system for the hours ahead.

That decision-making process includes two practical tasks. First, the HEMS plans battery charging ahead of scheduled outages. Second, it looks for periods when solar generation exceeds the home’s needs and switches selected loads on so that surplus solar power gets used inside the home. In the project demonstration, that logic controlled a pool-pump circuit through a Sonoff switch. The report’s control flowchart on page 25 shows how the system checks these conditions during each cycle and then commits any inverter changes as one settings transaction.

Using Prediction in a Practical Way

The project’s prediction layer uses a LightGBM regression model trained on historical load and weather data stored in a local SQLite database. Instead of treating household demand as a flat average, the model uses time-based features, weather inputs, weekend and holiday flags, lag values from earlier days, and rolling averages. In plain terms, it learns the household’s habits from historical data, then uses that pattern to estimate future demand during a scheduled outage window.

The same control cycle includes a solar estimate. The report uses the PVlib Python library with the home’s coordinates, sun position, cloud cover, and panel capacity to estimate likely PV output over the same period. The controller then combines predicted load and estimated solar generation to calculate how much battery charge the house may need before load-shedding starts. That turns the HEMS into a planning tool, not only a live monitor.

What the Testing Showed

The report gives the system a solid round of validation. It checked that the screens matched their live data sources, that the inverter data plotted correctly over time, and that screen switching stayed smooth. The inverter data pipeline polled for new values every 15 seconds and stored them in SQLite, allowing the system to display up to seven days of historical energy flow rather than only the current inverter state. On the energy flow graph, the report identifies grid usage, battery charging, battery discharge, the start of PV generation, and morning load spikes.

The machine learning model was tested on unseen data and recorded a validation RMSE of 412.43 W and a validation MAE of 218.83 W. The report states an average prediction accuracy of 79.85% across a 30-day simulated period. A separate charge-plan test over 15 simulated days recorded an average planning error of 6.05 kWh for a 10 kWh battery system. 

Operation tests then checked that the controller carried those decisions through in practice. In Blackout mode, the system switched off the pool pump and prepared the battery for an outage. In Automated mode, it started charging at the planned time in one test case and turned on a demonstration load in another when solar production exceeded household demand.

That said, a project like this only works if it can stay up for long periods without freezing or leaking memory. The report spends useful time on that side of the job. The system uses background threads for data collection, then schedules interface updates on the main UI thread so the dashboard stays responsive. A separate resource manager tracks graph objects and clears them when screens change. 

In testing, memory use settled at about 242 MB and ended a 48-hour run at 245 MB, which pointed to steady operation rather than a growing leak. Peer testing added one more layer by checking whether people with no prior knowledge could use the interface without breaking it.

Final Thoughts

What lifts the project above a basic dashboard is its mix of software, control logic, and local use. It doesn’t stop at showing graphs. It tries to make a home energy system act earlier, using the data already available to it. The report’s preliminary cost section puts the hardware at about R3,650 and sketches a possible payback period of roughly 10 months under a narrow pool-pump scenario. That figure depends on the stated assumptions, so it shouldn’t be read as a blanket savings claim. Even so, the project makes a clear case for a small, local controller that gives households a closer grip on battery use, solar timing, and outage preparation.