Sungrow SHx Modbus integration stays YAML while the inverter models multiply

The integration reads the inverter and writes to its EMS

The scope is narrow and worth stating precisely at the start. This integration lets you gather sensor data and control the EMS, the Energy Management System, of a wide range of Sungrow inverters. It is primary tested using a SH10RT attached via a LAN cable. Other inverter families, including SH*RS, SH*RT-V112 and SH*K-20, are supported partially, and the documentation is upfront that there might be sensors or controls that do not work. A battery is not required, but several sensors are not available without one, which is a practical constraint for anyone with a hybrid unit running without storage. The repository description names the covered families as the SH*RT series including SH10RT, the SHx.RS series including SH3.RS, the SH*K series including SH4K6 and the SxT-series including S20T. The author is also explicit that the author cannot test everything, for example backup capabilities, digital output related features and battery specific behaviour.

The LAN port beats the WiNet-S modules, and Sungrow limits what the Wi-Fi path exposes

The networking advice is concrete and comes with a caveat that is specific to this vendor. If available on your inverter, connect the inverter to the Home Assistant network using the inverters internal LAN port. The WiNet-S Ethernet port and the WiNet-S Wi-Fi also work, but are described as sometimes slightly slower and with some restrictions imposed by Sungrow on which data is available. That last clause is the one that catches people. A slower link is an inconvenience, but a vendor restriction on which registers are reachable over the wireless path is a functional difference, and no list of affected registers is given in the overview. The connection diagrams in the repository are drawn for both the SHxRT connection overview and the SHxRT LAN connection, so the physical route is documented even where the register availability is not.

The 2026 rebuild kept YAML but changed the base underneath it

On 2026-01-01 the project released version 2 of modbus_sungrow.yaml, and the reasoning is worth reading because it explains the shape of the repository today. After five years of continuous development with maintained backwards compatibility, the integration reached its limits, and with the help of several contributors it was rebased on a better and more flexible codebase. It still remains yaml-based and not a full Home Assistant integration, but it can now support different Sungrow models with their specific features, referred to as quirks. The old version was archived in a separate branch named 2025-legacy, and the dev branch that had been tested by several users became the main branch. The migration to the new version requires a few manual steps described in a migration guide, so an existing user on the old file is not upgraded by pulling, and the author states that as long as there is no real integration available, the new YAML file will continue to be maintained.

A new secrets.yaml parameter handles slow WiNet-S links

A separate small breaking change arrived on 2026-01-10, and it shows the kind of detail that separates a working installation from a flaky one. With the newest version you need to add sungrow_modbus_wait_milliseconds to your secrets.yaml. The guidance is to choose 5 ms for LAN, and 20 or higher for WiNet-S, with the expectation that this fixes some stability issues with WiNet-S connections. The author also notes, in the plainest possible terms, that the patch was forgotten to be migrated from the old version. The parameter is a read delay inserted into the Modbus request cycle, so it trades polling speed for reliability. On a LAN the faster value is fine, while on a wireless dongle the slower value reduces the chance of a request colliding with the inverter's own processing.

Register mapping comes from Sungrow protocol PDFs that are rarely updated

The accuracy of every sensor reading and every control depends on a document the project does not own. The Modbus register mapping is based on Sungrow's official Modbus communication protocol specification, and those documents are available from Sungrow support. The documentation is candid that they are only updated sporadically, and the author asks users with a newer version to say so in the GitHub discussions. Two specification files are named in the repository:

TI_20251119_Communication_Protocol_of_Residential_Hybrid_Inverter_V1.1.11_EN.pdf
TI_20230117_Communication.Protocol.of.Residential.and.Commerical.PV.Grid-connected.Inverter_V1.1.53_EN.pdf

That is the practical maintenance surface of this project. A new inverter firmware can introduce a register whose meaning differs from the mapping, and the mapping is only corrected when someone notices and reports it. The reference configuration therefore describes a moving target rather than a fixed one.

Multiple inverter setups ship as separate YAML files

The top level of the repository shows how the configuration scales. There is a main modbus_sungrow.yaml, and then three additional files, modbus_sungrow_multiple_inverters_1.yaml, modbus_sungrow_multiple_inverters_2.yaml and modbus_sungrow_multiple_inverters_3.yaml, which are variations for larger systems. Beyond the YAML there are additional_sensors/ for entities beyond the core set, dashboards/ for the three default dashboard tabs named Overview, Detail and EMS control, debug/ for troubleshooting output, scripts/ for helper routines, a doc/ directory holding the installation, migration, changelog, usage and FAQ pages, and a secrets.yaml at the top level where credentials and the wait parameter live. The documentation also points at the Home Assistant built-in Energy Dashboard, so the project is not trying to replace that and instead aims to feed it.

A single maintainer with limited time runs the support channel

The support section is candid in a way that is worth factoring into any adoption decision. The author states that personal time is quite limited, but that there are several nice people in the community who like to help. Three routes are offered: the GitHub discussions, the Discord server, and, only if the issue is code related such as a bug or a contribution, a GitHub issue or a pull request. The release history is consistent with that. The three most recent tags are all alpha builds, v0.1.0a17 on 2026-10-17, v0.1.0a16 on 2026-10-16 and v0.1.0a15 on 2026-10-16, and the last push was on 2026-10-19. The project is not archived and the licence is MIT, so reuse and modification are unencumbered, but an alpha version number signals that the configuration format may still move. The contribution invitation is open and low threshold, with a Discord invitation offered as the easiest entry point.

Where this integration is the wrong tool

The documentation names the alternative itself. This is meant to be a simple, straight-forward YAML-based integration, and if you need more than that, the author recommends looking at other projects, pointing at ha-modbus-manager and at the document collections by bohdan-s. The related work list adds a Sungrow Wallbox integration, a Sungrow Logger 1000a Modbus project, a Chint DTSU666 Modbus integration, EVCC and further document collections. The difference is scope and mechanism. This project writes one large YAML file that maps a specific inverter family's registers into Home Assistant entities, and it is tied to the Sungrow protocol documents. A general Modbus manager is a tool for arbitrary registers and arbitrary devices, which is what you want if you are reading a meter or a battery that has nothing to do with Sungrow. Two further limits apply. The partial support for SH*RS, SH*RT-V112 and SH*K-20 means an unsupported entity is a realistic outcome, and the reliance on vendor protocol PDFs that are only updated sporadically means an entity can stop reporting correctly after a firmware update without any change on the integration side.

Editorial conclusion

Adopt this integration when you own a supported Sungrow SHx family inverter, can reach its Modbus port over the internal LAN, and want energy data and EMS control inside Home Assistant without a cloud round trip. Skip it if you need a general Modbus solution or a different inverter brand. Verify first that your exact model is in the partially supported list, that the inverter firmware matches the register mapping you rely on, and that the wait milliseconds value in secrets.yaml matches your link, LAN or WiNet-S, before you start changing EMS settings.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant on GitHub
4. README
5. Releases