Knowledge Base

How I Made a Blind Solar Inverter See My House

18 August 2026 · Niko Moustoukas

A solar installer working on a wall-mounted hybrid inverter and PV isolator

My new Growatt hybrid inverter was generating solar fine but sat in "Bypass" reading 0 W of house load. It was blind to what the house was using, so it couldn't do smart self-consumption. Instead of running Growatt's proprietary meter on a long cable, I used a Shelly EM (a WiFi energy monitor) at the consumer unit and a £6 Raspberry Pi Pico to emulate an Eastron SDM230 Modbus meter on the inverter's RS485 port. The Pico polls the Shelly over WiFi and hands the readings to the Growatt as if it were the wired meter. The big lesson: once the meter can see the inverter's own output, the update rate is everything. At 10 seconds it oscillated wildly; at 1 second it pinned the grid to roughly zero and held rock-steady.

In August 2026 I finally had my off-grid-ish setup commissioned: a Growatt SPH3000TL BL-UP hybrid inverter in the garden room, ten JA Solar 460 W all-black panels on the roof for about 4.6 kW at peak, and a 32 kWh battery bank (two 16 kWh modules). On paper it was everything I wanted. In practice, it had one embarrassing problem: it had no idea my house existed.

The inverter powered up, tracked the panels, charged the battery overnight on cheap electricity, and then just sat there in a state the Growatt calls "Bypass", reporting 0 W of household load. It was generating and storing energy, but it couldn't see a single watt of what the house was actually drawing. This is the story of how I fixed that with a couple of off-the-shelf parts and a lot of very specific debugging.

Why a blind inverter is worse than it sounds

A hybrid inverter's whole selling point is self-consumption: when your house is drawing power, it discharges the battery to cover that load instead of importing from the grid. When you're generating more than you use, it charges the battery or exports the surplus. To do any of that intelligently, it has to know which way the electricity is flowing at your grid connection. Are you importing right now, or exporting?

That measurement doesn't happen inside the inverter. It happens at your consumer unit (the fuse board), where an external meter watches the main grid feed. Without that meter, the inverter is flying blind. Mine defaulted to Bypass and left the house running entirely on grid import while a fully charged 32 kWh battery sat there doing nothing. Expensive furniture.

The financial side made it more annoying. I'm on Fuse's tariff, which has a cheap off-peak window from 01:30 to 08:30 at £0.1761/kWh and a peak rate of £0.2821/kWh. My plan was the obvious one: set the inverter to "Battery First", AC-charge the battery only during the cheap window, then run the house off that stored energy through the expensive daytime hours. But "run the house off the battery" requires the inverter to see the house load. No meter, no plan.

The official fix, and why it didn't fit

Growatt's supported answer is their own meter with a CT clamp, wired back to the inverter's RS485 "meter" port. A CT clamp (current transformer) is a split ring you close around a live cable; it measures the current flowing through without any direct electrical connection, a bit like a stethoscope for wires. RS485 is a simple, robust two-wire serial bus that's been standard in industrial kit for decades, and the meter talks to the inverter over it using Modbus, an old, dead-simple protocol where one device (the inverter) asks "what are your readings?" and the other (the meter) answers with numbers from a fixed set of registers.

All perfectly sensible, except my consumer unit is in the house and the inverter is out in the garden room. Running the Growatt meter meant pulling a long RS485 cable across the garden, and it locked me into a proprietary meter I couldn't easily read from anything else. I wanted the grid data available to my own dashboards too, not trapped on a single wire into the inverter.

The idea: fake the meter

Here's the thing about Modbus: the inverter doesn't care what is on the other end of the RS485 bus. It just sends its polite little "give me your registers" request and trusts whatever answers in the right format. So if I could build something that spoke like an Eastron SDM230 (a common DIN-rail energy meter the Growatt already knows how to read), the inverter would never know the difference.

That's "meter emulation": pretending to be the wired meter the inverter expects, while actually relaying readings from somewhere else. My somewhere-else was a Shelly EM, a small WiFi energy monitor. It has its own CT clamps that go around the cables at the consumer unit, it measures real grid import and export, and, crucially, it publishes those readings on my home network through a local HTTP API. Ask it for a URL and it hands back a little blob of JSON with the live power figures. No cloud round-trip, no cable across the garden.

So the plan became a two-hop relay:

House CT clamps → Shelly EM (WiFi) → Raspberry Pi Pico (translator) → Growatt (RS485 Modbus).

The translator is a Raspberry Pi Pico 2 W, a microcontroller that costs about £6, with a cheap RS485 module bolted on. Its whole job is to poll the Shelly over WiFi, take the grid power number, and present it on the RS485 bus in exactly the register layout an SDM230 uses. To the Growatt, it is the meter. A second Pico runs a little live dashboard so I can watch what's happening. And because the Shelly keeps doing its normal thing, the Shelly app on my phone still works too. Nothing about the emulation breaks the off-the-shelf product.

The clamps at the consumer unit, I should say clearly, were fitted by a qualified electrician. Everything downstream of the Shelly is low-voltage hobbyist tinkering; the bit that touches mains is not, and shouldn't be treated as such.

The build, and everything that went wrong

The concept is tidy. Getting it working was a sequence of small, instructive faceplants.

1. Finding the Shelly

First I had to actually locate the Shelly on my network. A quick scan turned it up, and hitting its /shelly endpoint confirmed what it was: a Gen1 device identifying itself as an "SHEM". Simple enough, but it set up the next problem nicely.

2. The DHCP drift trap

Every time the power blipped, both the Shelly and the inverter's own datalogger came back with different IP addresses, handed out fresh by the router. My code had the old addresses hardcoded, so the whole relay quietly died until I noticed. This bit me more than once before the penny dropped.

The fix is a DHCP reservation: you tell the router "this specific device always gets this specific address", pinning it by the device's hardware MAC. If you're going to talk to something programmatically, reserve its IP first. I now consider this step non-optional for anything in an automation chain.

3. Which channel is which?

The Shelly EM has two CT channels. One clamp was meant to be on the whole-house grid feed, the other on the garden-room circuit. During install they kept getting swapped, so I'd be reading the wrong one and getting thoroughly confused about why the numbers made no sense. There's also a lovely off-by-one trap here: the code numbers the channels from zero, but the Shelly app numbers them from one, so "Channel 0" in my script is "Channel 1" in the app. Worth writing on a sticky note.

4. The K and L clamp direction

CT clamps have a direction. They're marked K and L (an old convention for current in and current out), and if you clip one on backwards, it reads the current as flowing the opposite way. In practice that means import looks like export and export looks like import, so the inverter, trying to help, would do the exact opposite of what I wanted, dumping power to the grid when it should have been covering the house. Mine went on reversed at first; the electrician flipped them and the signs came good.

5. First proof of life

Before trusting the whole chain, I bench-tested it: fed real Shelly readings into the Pico by hand and watched the inverter. The moment it worked is one I won't forget: the Growatt dropped out of Bypass, switched to a "PV + Battery" state, and started discharging the battery to cover the house load with zero grid draw. After weeks of a blind inverter, seeing it actually respond to the house felt slightly magical.

6. The finding that mattered most: update rate

Then I hit the real lesson of the whole project, and it's a subtle one.

Once the grid clamp is correctly placed, it doesn't just see the house. It also sees the inverter's own output feeding into that same connection. That closes a feedback loop: the inverter reacts to a reading that is itself partly caused by the inverter. And feedback loops are fussy about timing.

At a 10-second update rate, the thing went haywire. It would overshoot into importing about 1,030 W, over-correct into exporting around 1,740 W, then swing back again, hunting up and down every single cycle, never settling. Each reading was already stale by the time the inverter acted on it, so it was permanently chasing its own tail.

Dropping the update rate to 1 second transformed it. The loop converged almost immediately and pinned the grid to roughly 0 W, holding within about ±30 W. Same hardware, same code, one changed number, and it went from chaos to rock-steady. If you take one thing from this post, take that: when your meter can see the inverter's output, your control loop's update rate is the ballgame.

7. Why 1 second, and not faster

Naturally I wondered whether faster would be better still, so I measured. The Growatt polls the meter roughly every 560 milliseconds, call it 1.8 times a second. But the Shelly's reading only refreshes about once per second; the HTTP endpoint answers instantly, but the underlying sensor value only updates at 1 Hz. So polling the Shelly faster than once a second just hands back the same number twice. One second is the genuine data floor here, set by the sensor, not the network. That's why 1 second is both fast enough and as fast as it's worth going.

For what it's worth, the Modbus side was flawless throughout: thousands of requests during testing with zero CRC errors, which is more than I expected from a £6 board and a hand-rolled register map.

8. Why I skipped MQTT

People often reach for MQTT (a lightweight publish/subscribe messaging system) for this kind of thing, and the Shelly does support it. But enabling MQTT on a Gen1 Shelly severs its cloud link and kills the Shelly app, and I wanted to keep the app working. I also had no MQTT broker running, so I'd have had to stand one up just for this. The local HTTP API needs no broker and no extra infrastructure: my Pico simply pulls the reading when it wants it. This is the pull-versus-push trade-off in miniature. Push (MQTT) is great when many things need updates the instant they change; pull (HTTP) is simpler when one thing wants the latest value on its own schedule. For one Pico polling once a second, pull won easily.

The payoff

With the clamps the right way round, the channels straight, the IPs pinned and the update rate at 1 second, the system finally does what I bought it to do. The battery charges on cheap overnight electricity in the 01:30 to 08:30 window, then carries the house through the pricey daytime hours, with the grid sitting near zero because the inverter is now matching supply to demand in real time. A £6 microcontroller is standing in for a proprietary meter and, honestly, doing it better, because the same grid data now also feeds my own dashboard instead of vanishing down a single cable.

Lessons I'm keeping

  • Meter emulation is a legitimate, cheap alternative to a proprietary CT/meter when the cabling is awkward. A microcontroller that can speak the inverter's Modbus dialect costs a few pounds.
  • Set DHCP reservations for every device in an automation chain, before you write a line of code that talks to them.
  • Clamp orientation and channel identity are the two easiest things to get wrong, and both make the numbers lie in confusing ways. Check the K→L direction and confirm which channel is which before you trust anything.
  • Control-loop update rate is critical once the meter sees the inverter's own output. Match the meter's real refresh rate, about 1 second here, and no faster.
  • Prefer the simplest transport that works. Local HTTP beat MQTT for real reasons, not dogma.

What's next, and a few honest caveats

Right now this is a proven prototype rather than a finished appliance. The final jobs are to run the emulator standalone on the Pico itself, rather than with a laptop in the loop, and to make sure every device's IP is properly reserved so a power cut can't quietly break the chain again.

Two things to be clear about. First, safety: the CT clamps at the consumer unit were fitted by a qualified electrician, and mains work is not something to have a go at yourself. Second, this is a DIY, unofficial configuration. It is not a Growatt-supported setup, and results will vary with inverter firmware, model, and which meter profile your unit expects. Treat it as a hobbyist project that happens to work well for me, not a recommendation to void your warranty.

If there's interest, I'll write a follow-up with a proper parts list and the sanitised code on GitHub. And if you're running a Growatt with a Shelly and have gone down a similar rabbit hole, I'd genuinely like to hear how you solved the update-rate problem, so drop a note and compare setups.

Your Cart

Your cart is empty

Looks like you haven't added anything yet.