VPP remote power control works on MOD TL3-XH (DTC 5400) — the WIT-only gate in select.py excludes a family that supports it

[KevlarD-67]

Summary

select.py:51 gates all VPP control entities behind a hardcoded register-map name
check:

is_wit = str(register_map_name).upper() in ("WIT_4000_15000TL3", "WIT_29900_50000TL3_XHU")

A MOD 10KTL3-XH (MOD_6000_15000TL3_XH) therefore gets no VPP controls.
Measured on hardware: this inverter does support remote power control. #143
describes the WIT gate as a conservative choice to avoid regressions elsewhere; it
contains no evidence that other families lack the capability.

30407 alone does nothing

With 30409=5, 30408=2, 30407=1 but 30100=0: battery charge power did not
move for three minutes (2600 W, flat), and the duration timer did not run (30407
still 1 after 180 s). This is presumably why the capability is easy to miss.

With control_authority it works

Write order 30409 → 30408 → 30407=1 → 30100=1, so the documented hazard state
(30100 enabled without 30407) never occurs:

12:22   charge 2608 W   to grid 1117 W    before
12:23   charge  303 W   to grid 3452 W    VPP active (5 %)
12:24   charge  302 W   to grid 3461 W
12:25   charge 2609 W   to grid 1149 W    after disabling

Transfer function is linear

Three points, each held ~90 s:

30409	battery charge power
5 %	302 W
10 %	700 W
20 %	1466 W

77.6 W per percentage point, offset −86 W. Predicting 20 % from the first two
points gave 1496 W against a measured 1466 W.

The reference is the battery, not a setting. Raising 3311
(uw_ac_charging_max_power_limit) from 7.5 kW to 15.0 kW left the 20 % result
unchanged (1466 → 1463 W). Full scale is ≈7.25 kW, consistent with a 15 kWh
battery at 0.5C and with the highest charge power ever recorded on this system
(7247 W, when the classic charge power rate was set to 100 %).

Three findings that belong in any implementation

1. ⚠️ The power command is a target, not a limit — and it overrides
allow_grid_charge. At 30409=100 with insufficient PV:

+0s   charge 2592 W   from grid   0 W
+5s   charge 4767 W   from grid 912 W   <<< aborted by our safety threshold

The inverter actively climbed toward the commanded power and imported from the
grid while allow_grid_charge (3049) was 0. At 5/10/20 % only downward
limiting is visible, which gives a misleading impression of a cap. An
implementation should bound the commanded percentage against available PV unless
grid import is explicitly intended.

2. The duration expires but the registers do not clear. With 30408=2
(minutes), the power constraint released after ~128 s and normal self-consumption
resumed — but 30407, 30409 and 30100 all remained set for the full 240 s
observation window. Active/inactive cannot be inferred from the register
values.

3. Register 30474 mirrors the last commanded setpoint. It tracked 5 → 10 → 20
→ 100 across four runs, does not revert on disable, and a direct write is accepted
but ignored (echo returns the written value, read-back keeps the old one). It was
the only unexpected change in a full 1150-register before/after snapshot.

Suggested change

Replace the hardcoded name check with a capability probe, or extend the list to
MOD. A safe probe exists: FC6 to 30408 with its own current value returns
exception 2 on inverters that lack the address space — verified, since this
inverter answers exception 2 for genuinely unimplemented addresses such as 1090
and 1092 — and succeeds where the range is present.

Given finding 1, MOD support should ship with a guard against commanding more
power than PV can supply, unless the user opts into grid import.

Offer

Happy to run further measurements. The harness used here has an explicit
allowlist, a hard deny list on 30100/30407/30410, abort thresholds on grid import,
and full-register before/after snapshots — the 30474 side effect was only found
because of the snapshot diff.

Environment

Integration	v1.5.4
Inverter	Growatt MOD 10KTL3-XH (3-phase hybrid, backup box, 15 kWh battery)
DTC	5400 (VPP reg 30000 and legacy reg 43)
Protocol	V2.02
Firmware	DN1.0
Detected profile	mod_6000_15000tl3_xh_v201 (auto-detection, accepted, "Very High" confidence)
Transport	Elfin EW41 RS485→WiFi gateway, Modbus gateway mode, TCP 502, 9600 8N1

Measurements were made with a standalone zero-dependency MBAP client using the
same framing as pymodbus, to rule out integration-side handling. Diagnostics file
and Universal Register Scanner CSVs available on request.

[KevlarD-67]

Adding the two artifacts the issue guide asks for — the original report said they were "available on request", which is not what the guide asks for — plus the Home Assistant version, which was missing from the environment table above.

Environment

Home Assistant Core	2026.8.1 (HAOS 18.2, Supervisor 2026.07.5)
Integration	v1.5.5 (issue was filed on v1.5.4)
Inverter	Growatt MOD 10KTL3-XH
DTC	5400
Firmware	DN1.0

Attachments

Both files are too large to inline, so they are in a gist:
https://gist.github.com/KevlarD-67/34d22d8a0acaa4b79ce55f624ec47809

• growatt_modbus_diagnostics_v1.5.5_MOD-TL3-XH.json — Download diagnostics
• growatt_register_scan_v1.5.5_MOD-TL3-XH.csv — Universal Register Scanner (export_register_dump), run on v1.5.5

Two notes on the files. The scanner CSV is not redacted the way the diagnostics file is: it wrote the gateway IP into SCAN METADATA (line 4) and the serial into the entity value list, so both were replaced with **REDACTED** by hand before upload. And in the diagnostics file the custom_components list was trimmed to growatt_modbus only (noted in a _note key); nothing else was altered.

Re-verified on v1.5.5

v1.5.5 changes how these registers are retried, so the measurements were repeated. All of it is the standalone MBAP client rather than the integration, so the retry change does not affect the readings.

1. The address space is present. Using exactly the probe suggested at the end of this issue — FC6 with each register's own current value, so nothing changes:

FC6 30100 = 0      -> accepted     FC6 30408 = 0   -> accepted
FC6 30200 = 0      -> accepted     FC6 30409 = 0   -> accepted
FC6 30201 = 0      -> accepted     FC6 30410 = 0   -> accepted
FC6 30407 = 0      -> accepted     FC6 30474 = 100 -> accepted
FC6 39999 = 0      -> exception 2  (control)

In the attached CSV these are the sections VPP System Control 30100-30129, VPP AC Control 30150-30216 and VPP Battery Control 30300-30424 / 30425-30499, all Read OK. The RANGE SUMMARY block lists each of those ranges as ✓ Responding.

2. The gate is unchanged. select.py:51 in v1.5.5:

is_wit = str(register_map_name).upper() in ("WIT_4000_15000TL3", "WIT_29900_50000TL3_XHU")

3. It still actuates. Repeated in the discharge direction this time (night, PV = 0, so a discharge command only does what the battery was already doing — a charge command would have imported from the grid, per finding 1 above). Same write order, then cleared manually:

baseline           battery discharge   996 W
30409 = -20 (0xFFEC), 30408 = 5, 30407 = 1, 30100 = 1
t+10s              battery discharge  1588 W
t+20s              battery discharge  1612 W
cleared 30100 -> 30407 -> 30409 -> 30408
after              battery discharge   964 W

The run was cut short at t+20s by our own abort threshold on grid import; a ~1.6 kW household load switched on during the test, which is unrelated to the command. Register values after clearing: 30100/30407/30408/30409/30410 all 0.

4. 30474 mirroring, visible in the attachment. The scan ran a few minutes after that test and captured it:

H30474,0x770A,65516,6551.6,655.16,-20,,,,Read OK

65516 = signed −20, i.e. the last commanded setpoint, still there after the control registers had been cleared. That matches finding 3 in the original report.

[0xAHA]

You are right that MOD supports this, and v1.6.0 acts on it — but read-only for now, and I want to be straight about why, because it is not a hedge against your evidence.

In: the state, as disabled-by-default diagnostic sensors

30100, 30407, 30408, 30409, 30410 and 30474 are now in the MOD profile as RO, surfacing four sensors: VPP Control Authority, VPP Remote Power Control, VPP Commanded Power and VPP Last Setpoint.

Almost no new code was needed, which is itself worth reporting. The read path already probes anchors 30100 and 30407 behind if <addr> in holding_map — so the capability check you asked about exists and works for non-WIT profiles; MOD simply never had the registers in its map to trigger it. Adding them activates the existing path, including the 300 s retry added in #370 after a single dropped frame latched a WIT user's control authority to Disabled for six hours.

Only 30474 needed new handling, as it sits outside that block.

Out: writable controls, because of your finding 1

This is the decisive one:

The inverter actively climbed toward the commanded power and imported from the grid while allow_grid_charge (3049) was 0.

A user who has explicitly disabled grid charging, and then uses a VPP control, would import from the grid. Ship that as a number entity and someone automates against it at 100% on a cloudy afternoon.

Your own recommendation was that MOD support ship with a guard bounding the commanded percentage against available PV. I agree, and I did not want to bolt that on in the same change as the profile work — a clamp needs its own design, its own tests, and a decision about the opt-in for people who do want grid import. So the registers are exposed for visibility, and the writable half stays here.

I deliberately did not extend the is_wit list, which was the other option you offered. Extending it would have created the writable controls immediately — the gate is what confines them. There is now a test that fails if that gate becomes a capability probe, so MOD cannot gain writable VPP controls as a side effect of refactoring:

If that gate becomes a capability probe, MOD gains writable VPP controls the moment its hardware answers — including the power setpoint that #373 measured importing from the grid to reach its target. That is the change to make deliberately, with a guard, not to arrive at by refactoring.

Findings 2 and 3 shaped what users see

Finding 2 — the duration expires but the registers do not clear — is why VPP Remote Power Control carries this in its description: "the duration can expire while this still reads Enabled — it does not indicate whether control is currently active." Without that the sensor would actively mislead, which is worse than not having it.

Finding 3 — 30407 alone does nothing without 30100 — is recorded in the profile as the likely reason this capability was assumed absent on non-WIT families for so long. Anyone testing 30407 in isolation would conclude the hardware does not support it.

30474 is mapped RO on your evidence that a write is accepted and ignored — the echo returns the written value while the read-back keeps the old one. That is precisely the shape that makes a control look functional while doing nothing, so it is a sensor.

All three findings, plus your transfer function (77.6 W per point, offset −86 W, full scale ≈7.25 kW) and the 3311 elimination test, are written up in protocol-vpp.md under a new field-established section. They are the most valuable part of this issue and would otherwise have stayed in a thread.

Leaving this open

This issue stays open for the writable half. When it is picked up it needs: the PV-bounded clamp, an explicit opt-in for intentional grid import, and a rewrite of the WIT gate into the capability probe you suggested — the current one returns early and bypasses the availability checks entirely, so it wants restructuring rather than extending.

On your offer

Yes, please. Two things would help most:

1. Confirm the four read-only sensors populate and match what you would expect on v1.6.0.
2. If you are willing to run the clamp design past your harness later, that would be genuinely valuable — an allowlist, a deny list on 30100/30407/30410, grid-import abort thresholds and full-register snapshots is a better test rig than anything here. The 30474 side effect only surfaced because of your snapshot diff, which is a good argument for the method.

[KevlarD-67]

Thanks — and the read-only-first call is the right one. Before I answer your two asks, I have to correct one of the findings you wrote into protocol-vpp.md, and add a second measurement that contradicts something I gave you as clean.

I put this whole report through an adversarial audit before replying, specifically looking for claims that were presented as measurements but were not. It found four. Two of them are in your docs now, so they come first.

---

Correction 1 — finding 2 is wrong as written, and it is my fault

What I sent you:

With 30408=2 (minutes), the power constraint released after ~128 s and normal self-consumption resumed.

That was the morning run. I repeated it the same afternoon at 30408=5 (300 s) and the constraint did not release at all:

baseline     charge 2607 W   from grid 1216 W
+  6s        charge    0 W   from grid    0 W
+301s        charge    0 W   from grid    0 W    <- past the configured duration
+390s        charge    0 W   from grid    0 W    <- still
after clear  charge 2609 W                       <- only when we zeroed 30407/30100

So the honest statement is not "the duration expires but the registers do not clear". It is:

The duration is not reliable in either direction. At 2 minutes the effect released at ~128 s. At 5 minutes it was still constrained at 390 s and only released when we wrote 30407/30100 back to 0 ourselves. In both runs 30407, 30409 and 30100 remained set throughout.

The part you built the sensor description on — "it does not indicate whether control is currently active" — is still exactly right, and if anything it is now better supported: the registers tell you nothing about activity in either direction. But an implementation must clear the registers itself and must not treat the timer as a safety net that will release the inverter on its own. If protocol-vpp.md currently says the duration expires, that sentence should go.

I withdrew this internally on the same day I sent it and then failed to send you the correction. Sorry.

Correction 2 — the transfer function has a sixth point that does not fit

You recorded 77.6 W per point, offset −86 W, full scale ≈7.25 kW. Those three points are real and repeatable. But the same afternoon run above is a repeat of the 20 % point, and it produced 0 W instead of ~1466 W: the battery went to zero and the PV surplus went to the grid instead.

Conditions differed:

	morning (1466 W)	afternoon (0 W)
PV	~4.9 kW	3.0 kW
house load	low, ample surplus	~1.9 kW, barely any surplus
SoC	~60 %	83–84 %

Three candidate explanations — available PV surplus, SoC, or the morning reading meaning something other than what I assumed — and I have tested none of them. I am reporting it rather than sitting on it because a clamp design that assumes commanded power is delivered will meet this case. If the mechanism is "the setpoint is only honoured when there is surplus to move", that matters for the guard you are designing.

Also, for completeness: the discharge side of the transfer function (−10 % → 832 W, −20 % → 1569 W) is a two-point fit on two parameters, so it has no residual by construction. Treat it as indicative, not validated.

Precision on finding 1

The 912 W is a single sample at t+5 s from a run our own abort threshold stopped immediately. The inverter was still climbing (2592 → 4767 W of charge power in 5 seconds) when we cut it. The finding — it imports from the grid with allow_grid_charge at 0 — stands. The number is a point on a rising edge, so treat it as a lower bound rather than a characteristic value.

---

New: box_grid_power (3289/90) reads a constant zero on this model

Relevant to the clamp, so worth its own heading.

Over 2509 samples across two nights it never left 0.0 W. That includes 11 samples where the house meter showed real grid flow — up to 2064 W — and in those same samples to_user was 0 in all 11 and to_grid in 10 of 11.

What does work on this inverter: PV (1/2, 5/6, 9/10 — validated three ways in daylight: the value moves, 5/6 equals V×I to the tenth of a watt, and 1/2 equals PV1+PV2) and battery power (3178–3181).

The consequence for the guard you are designing:

• A PV-bounded clamp — "never command more than the array is producing" — is buildable from the inverter's own registers on MOD.
• A grid-bounded clamp — "never command anything that causes import" — is not. It needs an external meter, which on this system is a P1 reader.

If the opt-in for intentional grid import ends up being the design, that asymmetry decides what the default guard can actually enforce without extra hardware.

---

Your ask 1 — the four sensors populate on v1.6.1

Enabled and confirmed just now, after an integration reload:

entity	state	register
VPP Control Authority	Disabled	30100 = 0 ✓
VPP Remote Power Control	Disabled	30407 = 0 ✓
VPP Commanded Power	0	30409 = 0 ✓
VPP Last Setpoint	-33	30474 ✓

All four match what I read straight off the bus at the same moment. Two notes:

-33 is correct and is the interesting one. That is the last setpoint from an attended discharge run about ten hours earlier, and 30474 is still holding it with 30100/30407/30409 all at zero — so it does retain the last command after disable, and the integration decodes the two's complement correctly (the raw register holds 65503). Exactly the behaviour that makes it right as a sensor and wrong as a control.

One thing I told you earlier is not reproducing. I reported that 30474 returns to 100 on its own. It has not this time — ten hours on, it is still −33. I do not know whether the earlier observation was a different mechanism or a misread, so please do not rely on the self-return in the docs.

Your ask 2 — yes, and the harness is in better shape than it was

Two changes came out of the audit that matter for this:

1. Everything logs now. The measurements in this thread were taken with a script that never made it into version control and were transcribed by hand into notes — which is exactly how correction 1 above happened and then propagated into four places before anyone caught it. The probe now writes every observation to timestamped jsonl with the full register state and the reason for the run. Anything above can be traced back to raw samples if you want them.
2. Charging and daylight are now explicit opt-ins in the probe, precisely because the two unexplained results above both involve a charge command with limited surplus.

Happy to run a proposed clamp against it. The two experiments I would want to run first, since they bear directly on the design:

• Repeat the 20 % point at two clearly different PV-surplus and SoC combinations, to find out which variable the anomaly tracks.
• Write setpoint 0 with 30407 still enabled, to establish whether that pins the battery at 0 W and blocks PV charging. I believe it does from the mechanism, but I have not measured it and I am not going to claim it until I have.

One last thing about weighting all of this. Our own control loop on this path has run armed for four minutes total, and the current version of it — after the audit — has not run armed at all. These are measurements of what the inverter does, not experience of running it. Please weigh the observations and not my conclusions.

[0xAHA]

Both corrections are in — 25e1708 on main, in protocol-vpp.md and in the profile comment that carried a condensed copy.

Auditing your own report and coming back to withdraw two findings is a rarer thing than the original measurements were. Thank you.

Correction 1 — the duration

protocol-vpp.md now reads:

The duration is not reliable in either direction. With 30408 = 2 minutes the constraint released at ~128 s. With 30408 = 5 minutes it had not released at 390 s and only did so when 30407 and 30100 were written back to 0 by hand. In both runs 30407, 30409 and 30100 stayed set throughout.

You are right that it strengthens the sensor description rather than undermining it. "Does not indicate whether control is currently active" was a claim about one direction; it now holds in both, which is a stronger statement from the same text.

The consequence I have added explicitly, because it changes what an implementation owes: it must clear the registers itself and must not treat the timer as a release mechanism. That is a design requirement, not a note — an implementation that sets a duration and walks away could leave the inverter constrained indefinitely.

Correction 2 — the transfer function

Now stated as a fit that describes a regime rather than the device:

Three charge points fit a line […] and predicted a fourth within 2 %. A fifth measurement does not fit: a repeat of the 20 % point produced 0 W rather than ~1466 W […] Conditions differed on two axes at once (PV 4.9 → 3.0 kW, house load low → 1.9 kW, SoC ~60 → 83 %), and which of them matters has not been tested.

With the conclusion that matters: a clamp that assumes commanded power is delivered will meet the case where it is not. The discharge side is marked indicative, with your reasoning — two points fitted to two parameters has no residual by construction.

Your instinct to report the anomaly rather than sit on it was right. A guard designed against the clean linear fit would have been designed against a fiction.

Precision on 912 W

Recorded as a lower bound, with the reason:

a single sample five seconds in, from a run an abort threshold stopped immediately — charge power was still climbing, 2592 → 4767 W in those five seconds.

The finding was never about the magnitude, and it is undisturbed. If anything a rising edge cut short at 4767 W is a more alarming picture than a steady 912 W.

30474

The self-return claim is withdrawn from both files. What replaced it is better evidence, and it comes from your ask-1 confirmation: still −33 ten hours on, raw 65503, with 30100/30407/30409 all at zero. That confirms retention and the two's complement decode in one observation.

box_grid_power — recorded, not acted on

Noted against 3289/3290 in the profile, along with why I have not removed it: the box's other sensors report fine on your unit, and this is the box's view of the grid rather than the inverter's, which may legitimately read zero in whichever on-grid mode it sits in. 2509 samples is strong evidence that it does not populate for you, and weaker evidence about the register.

What would settle it is one pairing nobody has captured: box_work_mode (3282) during a sample with known grid flow. If it reads On-grid while box_grid_power reads zero, the register is not reporting. If it reads something else, the zero is explained.

Your asymmetry is recorded as the practical consequence, because it constrains the clamp directly:

a grid-bounded limit ("never command anything that causes import") is not buildable from this inverter's own registers on this model. A PV-bounded one is.

That is the single most useful sentence in this thread for the design that is still owed, and it would have been discovered late and expensively otherwise.

The two experiments

Both are the right ones, and I would take them in your order. The 20 % repeat across separated PV-surplus and SoC combinations is the one that decides whether a PV-bounded clamp is even meaningful — if the setpoint is only honoured when there is surplus to move, then the clamp and the mechanism are doing the same job and the design is simpler than I assumed.

The setpoint-0 test matters for a different reason: if it pins the battery at 0 W and blocks PV charging, then 0 is not a safe idle value and any implementation needs a distinct "release" path rather than "command zero". I appreciate you flagging that you believe it from the mechanism and have not measured it.

No rush on either. This is a deferred feature with no user waiting on it, and the cost of getting the clamp wrong is somebody importing from the grid while their dashboard says grid charging is off.

On your closing note

Please weigh the observations and not my conclusions.

Taken, and it is the right instruction — but the observations have been good and two of the corrections came from you rather than from anything failing in the field. Four minutes armed is exactly the right amount of caution for a control path that has already demonstrated it will pull from the grid when told not to.

[KevlarD-67]

Follow-up with the pairing you asked for, plus the loads behind the spikes.

The pairing: 3282 during known grid flow

Logged 2026-08-13, 637 samples at 5 s, 0 Modbus errors. Import was forced by charging an EV at full power, which exceeds what the hybrid can supply, so the house imports continuously instead of the inverter regulating P1 to zero.

box_work_mode (3282)	1 (On-grid) in every sample
box_grid_power (3289/90)	0.0 W in 632 of 632 paired samples
P1 (external meter)	2456 – 4661 W import, median 2585 W, uninterrupted
to_grid (3043/44)	0 throughout

The alternative you left open — that a zero might be legitimate in some other mode — does not survive this. The box reports On-grid, 2.5 to 4.7 kW flowed for an hour, and the register never left 0.0.

How this nearly went wrong: my first attempt logged 136 samples of 3282 = 1 with box_grid_power = 0.0 and looked like an answer. It wasn't — P1 sat between −96 and +58 W throughout and the energy registers moved 2 Wh. A register reading zero while zero flows proves nothing, so I waited for a load that guaranteed import.

The 2064 W sample, with the load identified

You have this from me as "11 samples where the house meter showed real grid flow — up to 2064 W". I asserted "real" without having verified it. Here is the largest one, resolved.

The load is a boiling-water tap with a 2.2 kW element, on its own power meter. It idles at 75 W and fires for about ten seconds. The 10 s energy-stack log across one such firing, with T = the sample where the element was already on:

T-22 s   P1 =   -30 W    battery discharge 1112 W
T-11 s   P1 =   -56 W    battery discharge 1065 W
T        P1 = +2055 W    battery discharge 3263 W    <- element on (2173 W)
T+12 s   P1 = -2064 W    battery discharge 1085 W    <- element off
T+23 s   P1 =   -37 W    battery discharge 1085 W

A 2.2 kW load step. The inverter ramps the battery 1065 → 3263 W but not instantly, so for one telegram the grid covers the gap; when the element stops, the still-elevated battery output goes the other way for one telegram. The near-symmetric +2055 / −2064 pair is two edges of one identified event, not a meter artefact — which is what I had assumed when I briefly withdrew this finding.

Through the whole event to_user, to_grid and box_grid_power all read 0.0. The inverter demonstrably saw the load — its own discharge register moved by 2.2 kW — while every grid-facing register reported nothing.

This is not one odd appliance. Of the eight night-time spikes in my logs, six coincide with a separately metered element load: the boiling-water tap (2173 W), an espresso machine (twice, 729 and 976 W), a macerating toilet (twice, ~660 W) and a fridge compressor (337 W). The remaining two have no metered candidate, but only about a hundred of the house's circuits are metered, so that is not evidence either way.

Note the magnitudes: the meter usually reads less than the appliance draws (441 W at the meter for a 976 W espresso machine). What lands on the grid is only the part the battery had not yet picked up during its response lag. Every home with a kettle, an espresso machine or a boiler produces this profile.

For provenance on the meter side: the house has two independent P1 readers on the same splitter, a Tibber Pulse (master) and a HomeWizard HWE-P1 (slave), decoding the same DSMR bytes separately. Logged at 0.5 s for 176 s they produce the same sequence of values — HomeWizard[i+1] == Tibber[i] for 18 of 18 consecutive pairs — with Tibber running 5–9 s ahead because it is pushed while the other is polled. They are never equal at the same instant, which is a polling artefact and not disagreement.

One precision I owe you. DSMR 4.2 reports instantaneous power once per 10 s, so 2064 W is a single sample of a ten-second event, not sustained import — the energy registers move about 1 Wh across it. The EV run above is the sustained case, and there it is unambiguous.

to_user (3041/42) does track the grid — which changes the clamp conclusion

In the 637 EV-charging samples:

to_user non-zero	632 of 632
to_user − P1	median −4 W
within 200 W of P1	618 of 632 = 98 %

That is the grid import, from the inverter's own register map, on a model where box_grid_power is dead.

Your conclusion in this thread is:

a grid-bounded limit ("never command anything that causes import") is not buildable from this inverter's own registers on this model. A PV-bounded one is.

For sustained import — what that guard actually protects against — 3041/42 looks like exactly the signal it needs. I think that sentence is stronger than the evidence now supports, and I would rather say so than let it stand because it happens to quote me.

The limitation is real, though, and now well evidenced. to_user read 0.0 through all eight transient events above, including the one where a confirmed 2.2 kW load ran for ten seconds and the inverter itself responded to it. So 3041/42 is trustworthy for sustained flow and blind to transients on this timescale. A clamp built on it will not catch a ten-second import — but it will catch the case where a command causes continuous import, which is the failure mode you described. Given that element loads are the normal domestic transient profile, that gap is worth stating in the design rather than discovering later.

Sample count

box_grid_power is now at 4430 consecutive samples across two nights, still zero non-zero readings, plus the 632 above under known import. The conclusion no longer depends on the spikes at all.

[0xAHA]

That is the pairing, and it settles it. The correction you asked for is in — 8b1d85d on main.

box_grid_power is not reporting on this model

On-grid in every sample, 2.5–4.7 kW flowing for an hour, and 3289/90 at 0.0 in 632 of 632. The alternative I left open was that a zero might be legitimate in whichever on-grid mode the box sat in. It does not survive this.

The detail that makes the result worth having is the attempt you threw away:

my first attempt logged 136 samples of 3282 = 1 with box_grid_power = 0.0 and looked like an answer. It wasn't — P1 sat between −96 and +58 W throughout and the energy registers moved 2 Wh.

A register reading zero while zero flows is exactly the trap, and it is one this project has fallen into before — "responds" and "reads OK" have been mistaken for "works" here more than once. You caught it in your own data before sending it.

The profile note now records 4430 consecutive zero samples and drops the transient spikes from the argument entirely, since the EV run carries it alone.

You were right about the clamp, and the note now says so

The sentence you objected to was mine, and it was too strong. Replaced with:

USE power_to_user (3041/3042) FOR GRID IMPORT ON THIS MODEL, not this register.

An earlier version of this note claimed a grid-bounded limit ("never command anything that causes import") was not buildable from this inverter's own registers. That was too strong, and the reporter said so rather than let it stand: across 637 samples during EV charging, power_to_user was non-zero in 632 of 632, with a median difference of −4 W against a P1 meter and 98 % of samples within 200 W.

Median −4 W against an independent meter is a better signal than I expected any register on this model to give.

The limitation, recorded as a design requirement rather than a caveat

This is the part I would have got wrong without the load identification:

power_to_user also read 0.0 through eight transient events, including a confirmed 2.2 kW load running for ten seconds while the inverter's own discharge register moved by 2.2 kW to meet it. So it is trustworthy for sustained flow and blind to transients on roughly that timescale — which is the normal profile of a kettle, an espresso machine or a boiler, so any design using it should expect to miss those.

Your T-22 … T+23 table is what makes that unarguable. The inverter demonstrably saw the load — its own discharge register moved 1065 → 3263 W — while every grid-facing register reported nothing. That is not a meter artefact and not an odd appliance; it is the ramp lag, twice, on the two edges of one event.

Worth noting for anyone reading later: you withdrew the 2064 W finding, then reinstated it once you had the element metered. Both moves were correct on the evidence you had at the time.

The DSMR precision is taken too — 2064 W is one instantaneous sample of a ten-second event, about 1 Wh, and the EV run is the sustained case. The two P1 readers agreeing value-for-value with a 5–9 s offset is a cleaner provenance check than most single-meter reports come with.

Where this leaves the writable half

Still owed, and your measurements have changed its design rather than just confirming it. The plan was a PV-bounded clamp precisely because I thought grid-bounded was impossible here. On your evidence a to_user-bounded clamp is the better primitive for the failure mode that actually matters — a command causing continuous import — with the ten-second blindness stated up front as a known gap rather than found later.

I have not started it. It is queued behind confirmation on the v1.6.1 pre-release, and I would rather not stack a new control path on top of a fix that has not been verified on hardware yet.

What would help most now

Whether v1.6.1 is behaving on your unit. It removed the five VPP controls v1.6.0 created — Control Authority, Remote Power Control, Remote Duration, Remote Charge/Discharge Power, VPP AC Charge Enable. They should be gone after upgrade, with the four VPP read-only sensors still reporting. That is the only thing blocking promotion to stable.

v1.6.2 is staged behind it and unrelated to this thread — two write-path fixes (#375, #331) plus this profile-note correction, documentation only. No entity changes for you.

No urgency on the clamp. Nobody is waiting on the feature, and the cost of getting it wrong is somebody importing from the grid while their dashboard says grid charging is off — which is precisely the case your logs have now characterised properly.

[KevlarD-67]

Answered on #374 rather than here, since that is where the ask was repeated: #374 (comment)

Short version — v1.6.1 has behaved for five days. The five controls are in the entity registry's deleted_entities list by name, so gone rather than unavailable; the 1090/1092 pair from #371 is in the same list; no disabled_by: user remains anywhere; and the four read-only sensors report. Nothing blocking stable from this unit.

The comment also carries a stronger replacement for finding 3 than the four runs in this issue: 230 setpoints written by an external Modbus controller in one day, mirrored one-for-one by 30474 with the sign intact, plus the semantics that 30409 returns to 0 on release while 30474 latches — the two sensors read as contradictory unless you know which one holds.

On the writable half: a to_user-bounded clamp instead of a PV-bounded one matches what the measurements actually support, and the ten-second blindness belongs in the design up front. No rush from here — nothing on my side depends on it, and I would rather it arrive after v1.6.x is stable than alongside it.