Add support for SPH inverters using V1 API

[johanzander]

Overview

Adds complete V1 API support for SPH (type 5) hybrid inverters

Design Rationale (per indykoning#125 discussion)

• Zero breaking changes - all existing min_* methods unchanged, backward compatible
• Follows the perfect PR recommendations
• Follows existing architectural patterns - sph_* methods mirror min_* structure exactly
• Potential improvements can be done in subsequent PRs

What's Included

10 new SPH methods:

  api.sph_detail(device_sn)                    # Device details
  api.sph_energy(device_sn)                    # Current energy
  api.sph_energy_history(...)                  # History (7-day max)
  api.sph_settings(device_sn)                  # All settings
  api.sph_read_parameter(...)                  # Read parameter
  api.sph_write_parameter(...)                 # Write parameter
  api.sph_write_ac_charge_time(...)            # AC charge periods (1-3)
  api.sph_write_ac_discharge_time(...)         # AC discharge periods (1-3)
  api.sph_read_ac_charge_times(...)            # Read charge periods
  api.sph_read_ac_discharge_times(...)         # Read discharge periods

  DeviceType enum:
  from growattServer import DeviceType  # SPH=5, MIN=7, etc.

Documentation:

• README updates with all method signatures
• Example script (examples/sph_example.py)

Technical Details

• Endpoints: device/mix/*, mixSet, readMixParam (SPH uses MIX endpoints)
• Time Periods: 3 AC charge + 3 AC discharge periods per API specification
• Review: Parameter ranges match official Growatt V1 API docs

Testing

• All methods verified against https://www.showdoc.com.cn/262556420217021
• Parameter structures match API spec tables
• Zero impact on existing MIN implementation
• NO verification agains real hardware

---

[johanzander]

Hi @GraemeDBlue - please have a look at this and let me know what you think. I think this minimal approach as layed out in the design rationale would be approved quite easily by the maintainer.
Would be great if you could test it as I dont have an SPH device.

[GraemeDBlue]

Hi @GraemeDBlue - please have a look at this and let me know what you think. I think this minimal approach as layed out in the design rationale would be approved quite easily by the maintainer. Would be great if you could test it as I dont have an SPH device.

@johanzander right, so bit confused then as you said "Keep your internal implementation work (which is solid)" , but none of my work is retained at all anyway, are you only needing me as i have an SPH device?

[johanzander]

To be honest, I gave instructions to AI agent to align implementation to current python library architecture and keep changes to minimum in initial PR.

Doing large refactoring and feature development in same PR makes it very hard to review test and approve.

[GraemeDBlue]

To be honest, I gave instructions to AI agent to align implementation to current python library architecture and keep changes to minimum in initial PR.

Doing large refactoring and feature development in same PR makes it very hard to review test and approve.

How do you want to handle the conflicts then ?

[johanzander]

I follow the principles in the Perfect PR recommendation:

_Make your PRs as small as possible. A PR should only refactor one thing, fix one thing, add one feature, or adjust a single subject in the documentation. If you want to change multiple things, please create multiple PRs. Smaller PRs have a smaller scope, need less time to review, conflict less often, and generally need fewer review iterations.

Only change one thing at a time. This is the same as the previous point but a bit more specific. It is tempting to improve those one or two lines you've noticed nearby, but please don't. Put those in a separate PR. Unrelated changes in your PR are distracting and often lead to questions. In contrast, in an independent PR, it would be a quick and simple review and merge._

Hence, my recommendation is that you review/test this small PR, create a new PR to get this in. There shouldn't be any merge conflicts towards the master 1.7.1 version.

then for each improvement you want to commit to the library, you create a new PR, cherry picking the change from your own "upstream" version. This is exactly how I work with the Home Assistant integration, one small increment at a time, based on my now upstream version. This can be frustrating and I know the feeling when done a lot of work - my first PR to the HA Growatt integration was a huge refactoring and lots of features that got rejected immediately and I got asked to break it down into many smaller PRs.