Grid device readings broken (energy totals stuck at 0, connection status "Unknown") — possible regression since v1.6.7

[Vict20]

Growatt SPH3600, firmware RAAA191904/ZCBA-0004 (same unit as #386).

Several Grid sub-device readings are currently broken:

sensor.growatt_grid_grid_import_energy_today = 0.0
sensor.growatt_grid_grid_import_energy_total = 0.0 (lifetime — should never be zero on a 4-year-old unit)
sensor.growatt_grid_grid_energy_today = 0.0
sensor.growatt_grid_grid_energy_total = 0.0
sensor.growatt_grid_grid_connection_status = Unknown

Meanwhile grid_export_power (live reading, not a total) shows a real value (10W), so the Grid device isn't fully unreachable — just these specific fields.
I directly confirmed grid import happened overnight (battery charged 12%→80% via grid, verified against the Growatt app's own daily chart, which shows ~1.8kWh under "Imported from Grid" for house load alone, on top of visible grid-sourced battery charging in the chart itself).

I believe these totals were showing correctly before I updated to the v1.6.7 beta (which included the #377 battery energy register fix). Given that fix moved battery energy counters onto the 1000-range registers, wondering if the same profile change affected the grid energy/status register mapping.

Happy to run another register scan around the grid energy addresses if that would help narrow it down, same approach as #386.

Want me to adjust anything before you post it, or run a register scan first (like we did for #386) to have hard register-level evidence ready alongside the report?

[0xAHA]

Diagnosed, and it is not a regression — but your instinct about #377 pointed at exactly the right place.

What is actually wrong

Those sensors have never had registers behind them on your profile. They are declared in the profile's sensor set, so Home Assistant creates them, and nothing ever writes a value — so they publish the dataclass default, 0.0, forever. Nothing errors and nothing warns. Grid Connection Status showing Unknown is the same gap surfacing differently, because it is calculated from those same missing values.

grid_export_power works because it is mapped (register 1029/1030). Live power and energy totals come from completely different registers, which is why one is fine and the others are flat.

Why #377 is relevant after all

The grid energy registers are 1044-1051, immediately before the 1052-1063 battery block that #377 added. So that change landed right next door.

And it was not an oversight. There is a comment in the profile, written at the time:

NOT added here: 1044-1051 (Etouser / Etogrid). They read plausibly on the same device, but the export lifetime total disagreed with the portal (7561.0 kWh against 6362), so they want their own evidence rather than riding along on this.

So they were deliberately held back because one of the four pairs did not reconcile against the Growatt portal. Mapping a register that reads plausibly but wrongly is worse than leaving the sensor at zero — a wrong lifetime total goes into your statistics permanently.

The odd part, and your quickest route

Your model has two register maps: a legacy one and a V2.01 one. The V2.01 map already includes 1044-1051. Only the two legacy profiles (SPH 3-6kW and SPH 7-10kW) are missing them — every sibling, including SPH HU, SPH-TL3 and SPA, has had them all along.

You are on the legacy map. So it is worth trying this first, before any scanning:

Settings -> Devices & Services -> Growatt Modbus -> Configure -> Protocol variant -> V2.01

If your inverter answers on the V2.01 map, all four totals should populate immediately. If it does not respond well, switch back to Auto — nothing is written to the inverter, it only changes which registers we read.

What I need either way

This doubles as the evidence that settles the original doubt, so it is worth doing carefully. Whether you switch variants or run a scan, please capture at the same moment:

From the integration	From the Growatt portal / app
Grid Import Energy Today	Imported from Grid, today
Grid Import Energy Total	Imported from Grid, lifetime
Energy to Grid Today	Exported to Grid, today
Energy to Grid Total	Exported to Grid, lifetime

The lifetime export figure is the one that failed to reconcile last time, so that is the number that matters most. Your overnight measurement — ~1.8 kWh imported for house load, on top of the 12%->80% battery charge — is exactly the right kind of check, and if the import registers land near that, import is confirmed.

If import reconciles and export does not, I will map the import pair and leave export alone rather than ship all four on the strength of two.

A register scan is welcome too if you would rather go straight there, same as #386 — but the portal comparison is the part that decides this, not the raw values.

One correction to your report

I believe these totals were showing correctly before I updated to the v1.6.7 beta

They were not — there is no version in which the legacy SPH profile mapped these. Most likely you were reading the Growatt app rather than the HA sensors, or comparing against a different entity. I mention it only so we do not spend time bisecting releases for a change that never happened.

[Vict20]

### Update:
I'm unable to reproduce the zero values from last night. I've now tried both Protocol variant settings (legacy/V1.39 and V2.01) and both give sensible, non-zero figures for all four totals, matching the Growatt app closely.

I don't have a clean explanation for what I saw last night — possibly a transient issue on the Home Assistant side (browser cache, a stale entity state that hadn't refreshed) rather than anything wrong with the integration or register mapping itself. Apologies for the false alarm — better to report the correction than leave it hanging.

### Follow up:

Found the likely correct register for ac_discharge_energy_total

Separate from the grid import discussion above — noticed sensor.growatt_battery_ac_discharge_energy_total (both legacy and VPP variants ) is showing 21,069,824 kWh, which is obviously wrong (physically impossible for a 12kWh residential battery). For comparison, ac_charge_energy_total is showing correctly at 13820.7 kWh.

I ran a fresh register scan (attached) and claude cross-checked against the app's live figures:

Charge total (currently correct): input register 115 (0x0073) — the scan tool's own built-in annotation already labels this "13820.7 kWh," an exact match to the working entity value. Confirms this register is right.
Discharge total (currently broken): app shows 12009 kWh lifetime discharge right now. Holding registers 1054/1055 (0x041E/0x041F) combine as a 32-bit value (high×65536+low = 1×65536+54557 = 120093), and at the same ×0.1 scale used elsewhere, that's 12009.3 kWh — matching the app almost exactly.

Looks like ac_discharge_energy_total may currently be pointed at the wrong register(s) entirely, rather than a scaling problem on the correct one. Registers 1054/1055 (×0.1) look like the right pair based on this comparison.

growatt_register_scan_20260822_140903.csv

[0xAHA]

Thank you for coming back to correct the first report — that saved real work, and the follow-up you attached turned out to be the more valuable half.

Your scan found three separate defects. The fix is written and tested but deliberately not released, because it changes a lifetime energy total and I want one number from you first.

Where your 21,069,824 kWh came from

You were right that it is impossible, and right that something was pointed at the wrong place — but not at a register. There is no AC-discharge register at all. Protocol V1.39 has EACharge_Total but no EADischarge anywhere in the input table; only the off-grid protocol (SPF, SPE) defines one.

So the sensor had nothing behind it on your model. It read 0.0 every poll, and the coordinator's lifetime-total protection — which restores the last real value whenever a total reads 0, to stop dormant inverters spiking the energy dashboard — latched a single corrupt frame and restored it forever after. 21069824 × 10 = 3215 × 65536 exactly, i.e. a 32-bit pair with high word 3215 and low word 0. One bad frame, made permanent by a safety net.

It is removed on upgrade. Battery Discharge Total is the sensor you want — and your 1054/1055 reading of 12009.3 kWh is exactly what it already shows, because that is what those registers are (Edischarge1_total). Your arithmetic was right; the registers were simply already mapped, under their correct name.

The one that needs your confirmation

Checking that led to a real mapping bug in AC Charge Energy Total.

Protocol V1.39 gives input registers 112–115 two meanings, chosen by device class:

Reg	MAX-class string inverter	Storage Power (SPH)
112	Warn Maincode	EACharge_Today_H
113	real Power Percent	EACharge_Today_L
114	inv start delay time	EACharge_Total_H
115	bINVAllFaultCode	EACharge_Total_L

We were reading both interpretations at once — 112 as a warning code and 115 as energy — and 115 alone, without its high word, which caps the total at 6553.5 kWh.

From your scan:

114 = 1
115 = 5462     →  (1 << 16) | 5462 = 70998  ×0.1 = 7099.8 kWh

Your entity shows 13820.7, which is registers 1058/1059 — battery charge total, copied over the top by a decode path meant only for off-grid models. Those are genuinely different quantities on a grid-tied hybrid:

Sensor	Registers	Means
Battery Charge Total	1058/1059	13820.8 kWh — all charging, PV and grid
AC Charge Energy Total	114/115	7099.8 kWh — grid→battery only

The difference, ~6,721 kWh, would be what your panels put in. That is a plausible split, which is why I want it checked rather than assumed.

Could you compare 7099.8 against your Growatt portal's grid-charge figure? In ShinePhone this is usually shown as energy charged from the grid, or "AC charge", on the statistics page. If it lands near 7099.8 the mapping is confirmed and I release it.

Why I am holding the release

Changing this moves AC Charge Energy Total from 13820.7 down to 7099.8, and Home Assistant's long-term statistics will record that step. It is the correct value, but it is not reversible in history, so I would rather have your portal figure than ship on my own arithmetic.

Also changing when it goes out: SPH gains AC Charge Energy Today (registers 112/113 — your scan reads 5.0 kWh, consistent with the overnight grid charge you described), and loses its Warning Code sensor, which was reading an energy high word all along and has therefore only ever reported 0.

Scope is SPH only. MIN, MID, MOD, MIC and TL-XH also map 112 as a warning code, and for the MAX-class ones that is correct — I am not touching the hybrids without evidence of which side of that table they fall on.

[Vict20]

Confirmed — ShinePhone's raw device page attached image

(not the summary dashboard) has an "EAC Total" field showing 7100.1 kWh, matching your calculated 7099.8 kWh almost exactly (0.3 kWh difference, consistent with normal timing drift between the reading and your calculation).
Mapping confirmed — good to release whenever you're ready.
For reference, the full raw device page also shows some other useful confirmations while I'm here:
EAC Today: 5.3 kWh (matches your prediction of ~5.0 kWh from registers 112/113 almost exactly)
EBatDischarge Today: 12015.8 kWh — interesting, this is a lifetime figure despite the "Today" label in the app's own field name, worth noting as a possible app-side (not integration-side) labeling quirk, unrelated to your fix.

[0xAHA]

Confirmed and released as v1.7.6. Thank you — that screenshot is the best single piece of evidence this issue produced, and it corroborates more than you flagged.

The match

Growatt app (raw device page)	Registers	Our value
EAC Total — 7100.1 kWh	114/115	7099.8
EAC Today — 5.3 kWh	112/113	5.0

Both within timing drift. The mapping is right.

Your labelling observation generalises

You spotted it on one field; the page does it at least twice.

EBatDischarge Today: 12015.8 kWh — interesting, this is a lifetime figure despite the "Today" label

Correct — that is registers 1054/1055, Edischarge1_total, which we read as 12009.3 kWh and expose as Battery Discharge Total.

And look again at your own screenshot: there are two fields both labelled "EAC Today". One shows 5.3 kWh (genuinely today). The other shows 13821.2 kWh — which is registers 1058/1059, battery charge total, and is exactly the number your AC Charge Energy Total entity was showing.

So the app labels at least three lifetime counters as daily ones, and duplicates a label across two different quantities. That is app-side and nothing we can fix, but it explains why the wrong value looked plausible for so long: 13820.7 appears on the app too, under a name that invites the wrong reading.

What changes when you update

• AC Charge Energy Total: 13820.7 → 7099.8 kWh. Your long-term statistics will record the step. The new figure is the correct one.
• AC Charge Energy Today appears, reading from 112/113.
• Warning Code disappears. On SPH that register holds the AC-charge-today high word, not a fault code — it has only ever reported 0.
• AC Discharge Energy Total disappears, along with its 21,069,824 kWh. Protocol V1.39 has no AC-discharge counter for grid-tied models; there was never a register behind it. Battery Discharge Total is the sensor you want, and it already reads 12009.3 kWh.

Scope is SPH only. MIN, MID, MOD, MIC and TL-XH also map register 112 as a warning code, and for the MAX-class models that is correct — I have not touched the hybrids without evidence of which interpretation their firmware uses.

Two loose ends

The original grid-import question is resolved as a false alarm, per your earlier update — both protocol variants give sensible values and you could not reproduce the zeros. I am leaving those registers alone.

Your EpvTotal reading of 23501.4 kWh is a useful third data point for #381, where your unit is currently the evidence that the PV-total anomaly is one device rather than the SPH family. If you get a moment to enable the disabled-by-default PV1/PV2 Energy Total entities mentioned there, that would close it out.

Happy to close this once you have confirmed v1.7.6 reads as expected.

[Vict20]

Confirmed v1.7.6 loaded and working correctly — AC Charge Energy Total (7100.4) and AC Charge Energy Today (5.7) both check out.

Warning Code behaved as expected — still integration-managed, disabled cleanly through the normal entity popup.

ac_discharge_energy_total is a genuine orphan though: it no longer appears in the integration's own entity list at all, but persists in Home Assistant's global entity registry, frozen at its old corrupt value (21069824), with no way to remove it through the UI that I can find — no delete option in its popup, doesn't respond to reloading the integration, and there's no checkbox/bulk-select option available on the entities page for it either. Happy to try anything else if you have a suggestion, otherwise this might need a one-off cleanup step in a future release for anyone else who hits it after updating.

[0xAHA]

Good — 7100.4 and 5.7 against the app's 7100.1 and 5.3 is the mapping working exactly as intended. Thank you for closing the loop on it.

The orphan is worth pinning down properly, because your symptoms do not match a normal stale entity and that changes what the fix is.

The symptom does not fit the entity registry

no delete option in its popup, doesn't respond to reloading the integration, and there's no checkbox/bulk-select option

Home Assistant does offer a delete button for an entity whose integration no longer provides it. If it is refusing to offer one, HA does not think it is looking at an orphaned entity.

Combined with "frozen at its old corrupt value" and "no longer appears in the integration's own entity list", this looks much more like long-term statistics than a registry entry. Statistics survive independently: when an entity is removed, its recorded history stays in the recorder database and keeps showing the last value it had. That is why 21069824 is still visible and why reloading the integration does nothing — the integration is not involved any more.

The test that settles it

Developer Tools → States, search ac_discharge_energy_total.

• Not listed → the entity is genuinely gone. Our cleanup worked, and what you are seeing is leftover statistics. Fix below.
• Listed, with a state → the registry entry survived and our automatic removal did not fire, which is our bug and I will want your entity ID and the growatt_modbus lines from the log at startup.

If it is statistics (my expectation)

Developer Tools → Statistics, search ac_discharge_energy_total. Orphaned entries appear with a warning icon and a Fix issue action offering to delete the long-term statistics. That removes it for good.

Worth saying plainly: if it is statistics, no future release can clean it up for you. Deleting recorder statistics is a user action through that screen; an integration has no supported way to reach into another component's database and remove them. What we can do is document the step, which I will, so the next person finds it without asking.

If the entity really did survive

Then I have a genuine bug, because the removal is not bespoke — since v1.5.4 there has been a blanket rule that drops any registry entry for a sensor the active profile no longer lists, and ac_discharge_energy_total left the SPH sensor set in v1.7.6. I have checked that no other code path recreates it and that the unique ID format matches what the cleanup looks up, so on paper it should have gone.

If Developer Tools → States shows it, please send:

1. The full entity ID
2. Any custom_components.growatt_modbus lines mentioning "Removing" from your log after the v1.7.6 restart

That tells me whether the cleanup ran and missed it, or never ran at all.

Either way

Use Battery Discharge Total as the replacement — 12009.3 kWh on your system, which is the real figure and matches the app's mislabelled "EBatDischarge Today".

And thank you for pushing on this rather than just hiding the entity. The register mapping was the visible bug; the fact that a bad reading could be latched permanently by our own retention logic is the more interesting one, and it would not have surfaced without your scan.