Add device-gated "Cut PV generation" switch for SH-RT inverters (reg 31211)

[sebastian-tennant]

Summary

Adds a Cut PV generation switch that actually works on the SH-RT inverter family.

The datasheet "PV power limitation" register 13018 is marked "Only SHT supported" and silently fails on SH-RT inverters — it reads back 0xFFFF and writes are ignored, with no effect on PV output. iSolarCloud instead uses register 31211 (HA holding address 31210) to stop PV production on RT inverters:

• 0xAA = cut PV
• 0x55 = allow PV (normal)

Confirmed working live on an SH10RT, firmware SAPPHIRE-H 95.12: writing 0xAA drove total DC power from ~5.4 kW to 0 W in ~10 s; writing 0x55 restored PV.

Implementation

Rather than a raw modbus switch (which would be writable on every model regardless of support), this is implemented as a template switch so it can be gated:

availability: >-
  {{ states('sensor.cut_pv_generation_raw') | is_number
     and 'RT' in states('sensor.sungrow_device_type') }}

• On non-RT inverters the switch is unavailable, so the modbus.write_register path is never reachable — no risk of writing 0xAA into reg 31211 on a model where its meaning is unconfirmed.
• A small backing Cut PV generation raw modbus sensor reads the register; reads are harmless on any model.
• Owners of other models who confirm the same register can simply widen the availability check.

Use case

Cut solar during negative grid import prices (e.g. Amber in Australia) so the home battery charges purely from the paid grid.

Testing

• YAML validated.
• Switch toggled both directions on an SH10RT — PV cut to 0 W and restored, is_on state tracked the register correctly.
• availability evaluates to unavailable when sensor.sungrow_device_type is non-RT.

[sebastian-tennant]

Pushed a fix: the template switch must use state:, not is_on: (the latter is an invalid option for a template switch and HA silently fails to register the entity). Now verified end-to-end on an SH10RT — toggling the switch drove sensor.total_dc_power 1544 W -> 0 W (write 0xAA) and back (write 0x55), with sensor.cut_pv_generation_raw reading 170/85 respectively.

[Gnarfoz]

Interesting! Which option in iSolarCloud does this correspond to?

[sebastian-tennant]

Thanks for the question - I think my assistant assumed a few things.

Register 31211 was not found via a named iSolarCloud option. It was identified by @theunknown86 in issue #554 (December 2025) through Modbus traffic analysis: they monitored which registers the iSolarCloud app wrote to the inverter while controlling PV on their SH10RS. There is no visible toggle or slider in iSolarCloud that a user would recognise as "cut PV generation" on RT inverters — the app writes the register internally without surfacing it as a named control.

The documented equivalent (register 13018, "PV power limitation" in Modbus spec v1.1.11) is explicitly marked "Only SHT supported" and returns 0xFFFF on SH-RT hardware.

Empirical confirmation on SH10RT (firmware SAPPHIRE-H 95.12):

• sensor.cut_pv_generation_raw (reg 31211) reads 85 (0x55) at rest — PV running normally
• Writing 0xAA → sensor.total_dc_power 1544 W → 0 W in ~10 seconds
• Writing 0x55 → PV restores to ~1373 W after MPPT restart (~30–60 s)

Because the register is not in the public Modbus spec and was found on SH10RS/SH10RT only, the availability gate ('RT' in states('sensor.sungrow_device_type')) is there so owners of other model families do not accidentally write a register whose meaning is unconfirmed on their hardware. Anyone who verifies the same behaviour on RS or T models can widen that condition.

I have pushed a small docs-only commit to this PR correcting the YAML comments to accurately describe the origin.