Power-House started as a personal itch: our house produces solar power, stores it in a battery, charges an EV and feeds the grid — but the vendor apps each showed only their own little slice, each in its own cloud. We wanted one local, self-hosted view of every energy flow, with years of history and full drill-down. This page walks through what we built, which components we used, how they connect, and how you can rebuild the whole thing from our open-source repository — a tutorial based on our own interests and requirements, shared in the hope it saves you the detours we took.

What we wanted to achieve

Components we used

These are our devices — the architecture doesn't depend on any of them. The repository's adaptation guide lists drop-in alternatives for every row.

How it is wired — the architecture

The design boils down to three rules. One: Home Assistant is the single integration hub — every device is integrated exactly once, there; storage and dashboards only ever see generic power/energy entities. Two: only a tiny modbus-proxy talks to the inverter, because many inverter interfaces (like Sungrow's WiNet-S dongle) accept just one Modbus client — the proxy multiplexes Home Assistant and evcc onto that single connection and makes the inverter endpoint a one-line config change. Three: everything site-specific (IPs, credentials, entity ids) lives in gitignored files with committed .example twins, so the public repo is fully generic and parameterizable.

Every entity that Home Assistant knows flows automatically into InfluxDB (state-change based, so flat periods cost nothing). Grafana reads InfluxDB for six dashboards — flow overview, drill-down, battery, EV charging, autarky and circuits. evcc taps the same modbus-proxy for its beautiful live flow view and is ready for PV-surplus EV charging. Home Assistant itself keeps the daily-driver views: its native Energy Dashboard, a mobile live dashboard, and — after losing days of data to silent failures twice — a watchdog that pushes a phone notification whenever a data source goes quiet for 15 minutes.

"Isn't there already an integration for that?"

Yes — and it's great. The mkaiser Sungrow-SHx integration gives Home Assistant the inverter's full Modbus register set and is exactly what runs inside our Home Assistant. So this was never an either/or decision: the integration answers "how do I talk to my inverter?", while our stack answers "how do I turn that (and every other device) into insight I can still query in three years?" Here is what each layer covers:

We didn't replace the integration — we built the house around it. If all you want is inverter data in Home Assistant, start (and maybe stop) with mkaiser's project. It's excellent.

Rebuild it yourself

The repository is deliberately cut so that nothing in it is specific to our house — all our IPs, credentials and entity ids live in gitignored files, and each one has a committed .example twin that documents the format. Rebuilding is roughly an afternoon:

Different hardware? The adaptation guide maps each role to alternatives — the whole point of the single-hub design is that swapping a brand touches one integration and nothing else.

Lessons we learned the slow way

The project is MIT-licensed and everything — architecture decision record, deployment runbook, dashboards, tooling — is in the repository. If you rebuild it, adapt it to different hardware or spot something to improve, we'd genuinely like to hear about it.