Home Assistant ships an Energy dashboard, and for a while mine was mostly empty grey bars. Real energy management here — a roughly 9 kWp PV system, a Huawei SUN2000 inverter, a my-PV AC·THOR 9s diverting surplus into hot water, and a scatter of Shelly relays — needed more than the built-in dashboard could give me. This is the map of what I actually built, in the order the problems showed up: first get the inverter's data into Home Assistant at all, then make it trustworthy, then act on it.
Reading the inverter — the Modbus foundation
The Huawei SDongle behind my inverter has one very inconvenient property: it accepts exactly one Modbus TCP connection at a time. The moment a second client — Home Assistant, a second tool, whatever — tries to talk to it, the first one gets disconnected. That single fact shaped almost everything below it.
I first solved this narrowly, for my own SUN2000 setup, with a small caching proxy that owns the one connection and serves everyone else from a shared cache, then rewrote the same idea as a standalone asyncio service anyone can adapt to a different inverter, and separately documented the actual SUN2000 register map for reading it with Home Assistant's built-in modbus platform, no custom integration at all.
A caching proxy that only serves reads is half the job — I added a write-through path so the same proxy also forwards register writes (like changing a charge target) straight to the inverter or battery on demand. And because a proxy that quietly goes stale is worse than no proxy at all, the reconnect and stale-cache-detection layer got its own post — the failure-mode playbook for the night the SDongle reboots or the network blips.
Watching the numbers — turning raw registers into answers
Getting the registers into Home Assistant is only step one. The number I actually watch daily is self-consumption and autarky, which the inverter's own cloud shows me as pretty graphs but Home Assistant hands you as raw counters. Rebuilding those two percentages as real template sensors is what turned the dashboard from decoration into something I check every evening.
The other thing worth watching for is a string quietly underperforming — shading from a tree that grew taller, a dead module, a loose MC4 connector. An automation that compares the two MPPT strings and flags the moment one starts drifting catches exactly that, months before it would otherwise show up as "huh, that's odd" on the annual statement.
Acting on it — surplus, control, switching
None of this matters if the numbers just sit there. The most useful thing I built with them is dumping PV surplus into the hot-water tank through the AC·THOR 9s — which sounded trivial until the device flatly refused every Modbus write while reads worked fine. The fix was routing control through the vendor's undocumented Cloud API instead, read local, write cloud, split-brain but honest about why.
The newest piece is lower-tech on purpose: Shelly Plus 1PM/2PM relays behind the wall switches that switch a circuit locally and meter its energy at the same time, no cloud dependency, no Modbus at all — proof that not every problem here needs the heavy machinery above.
Frequently asked questions
What's actually missing from Home Assistant's built-in Energy dashboard?
Nothing is broken about it - it's just generic. It tracks grid import/export and, if you add a solar sensor, production. It has no concept of per-string health, of a device that blocks writes but allows reads, or of turning a self-consumption percentage into something you'd actually trust enough to act on. Those gaps are exactly what the posts above fill in, one real failure at a time.
Do I need this exact hardware (Huawei SUN2000, my-PV AC·THOR) to use any of this?
No. The single-Modbus-connection problem is generic to a lot of inverters, not just Huawei's - the caching-proxy pattern applies wherever a device only tolerates one client. The AC·THOR's Cloud-API pivot is specific to that device, but the underlying lesson (read local, write wherever the vendor actually allows writes) generalizes to plenty of other stubborn hardware.
Which piece should I build first?
Whichever failure you're actually hitting. If a second Modbus client keeps kicking your first one off, start with the caching proxy. If you don't trust the self-consumption number your inverter's app shows you, start with the template sensors. If you already have good data but nothing acts on it, skip straight to the AC·THOR or Shelly posts.
Is this a one-time build or does it keep changing?
It keeps changing. This hub gets a new section whenever a new piece of the setup earns its own post - the Shelly relays are the newest addition as of this writing.
This isn't a finished system, it's a running log of a real ~9 kWp setup, and it keeps growing whenever the next real problem shows up. If you're building something similar, start with whichever piece matches the failure mode you're actually hitting — the inverter's connection limit, the trust gap between raw registers and real percentages, or getting Home Assistant to actually act on a surplus instead of just charting it.
