Adding SPH/MIX to Growatt V1 api (Type 5)

[GraemeDBlue]

Hi , I'm looking to add the SPH/MIX variant, I've already managed to get the basic /v1/device/mix/mix_last_data endpoint to return values, just wondering if there is anyone one else working on this and if not if there are any testers to test once I am done?

[GraemeDBlue]

I've made a start https://github.com/GraemeDBlue/PyPi_GrowattServer

[GraemeDBlue]

@indykoning @johanzander Hi Both, wasn't sure how to contact you both but I have been trying to add in my MIX/SPH system and have started on a refactor of the V1 class and would like your input as to whether this is a good path and is acceptable ? my idea is to make the methods as generic as possible using constants to map the system types. This is far from complete but would rather get your input now before I even try commit a PR see master...GraemeDBlue:PyPi_GrowattServer:master

[johanzander]

Review Feedback

🌟 Strong Foundation

This is excellent work and exactly the right architectural approach! The implementation demonstrates
several best practices:

• Scalable Design: The DeviceType and ApiDataType enums combined with the DEVICE_ENDPOINTS
  mapping create a clean, maintainable structure that makes adding new inverter types trivial.
• 100% Backwards Compatible: Preserving all existing min_* methods ensures no breaking changes for
  existing users.
• DRY Implementation: The generic device_* methods eliminate code duplication - a single
  implementation handles all device types.
• Smart Dynamic Handling: Using f"{url_prefix}_sn" for parameter names elegantly handles the API's
  different naming conventions.

The fact that you've proven MIN/TLX and MIX/SPH share identical API patterns is a significant achievement!

🤔 Design Consideration: Repetitive device_type Parameter

One concern: requiring users to pass device_type on every method call is repetitive and error-prone.
Since device_list() already returns the device type, users shouldn't need to repeat it:

# Current approach - device_type passed 4 times
for device in devices['devices']:
    device_type = device['device_type']
    details = api.device_details(device_sn, device_type)
    energy = api.device_energy(device_sn, device_type)
    settings = api.device_settings(device_sn, device_type)
    history = api.device_energy_history(device_sn, device_type, ...)

💡 Suggested Enhancement: Device Wrapper Class

Consider adding a GrowattDevice class that encapsulates device_sn and device_type:

class GrowattDevice:
    """Represents a Growatt device with automatic type handling."""

    def __init__(self, api, device_data):
        self._api = api
        self.device_sn = device_data['device_sn']
        self.device_type = device_data['device_type']
        self.model = device_data.get('model')
        self.status = device_data.get('status')
        # Store other device metadata...

    def details(self):
        """Get detailed device data."""
        return self._api.device_details(self.device_sn, self.device_type)

    def energy(self):
        """Get current energy data."""
        return self._api.device_energy(self.device_sn, self.device_type)

    def settings(self):
        """Get device settings."""
        return self._api.device_settings(self.device_sn, self.device_type)

    def energy_history(self, start_date=None, end_date=None, **kwargs):
        """Get energy history data."""
        return self._api.device_energy_history(
            self.device_sn, self.device_type, start_date, end_date, **kwargs
        )

    def read_time_segments(self, settings_data=None):
        """Read TOU time segments."""
        return self._api.read_time_segments(
            self.device_sn, self.device_type, settings_data
        )

Then add a convenience method:

def get_devices(self, plant_id):
    """Get devices as GrowattDevice objects for easier use."""
    data = self.device_list(plant_id)
    return [GrowattDevice(self, device) for device in data['devices']]

Usage becomes much cleaner:

# Proposed approach - device_type specified once
api = OpenApiV1(token)
devices = api.get_devices(plant_id)

for device in devices:
    # Works automatically for MIN, MIX, or any future device type!
    details = device.details()
    energy = device.energy()
    settings = device.settings()
    history = device.energy_history(start_date=today)

Benefits:

- ✅ DRY: Device type specified once at creation
- ✅ Auto-discovery: Works with any device type from the plant
- ✅ Type-safe: Device object encapsulates device_sn and device_type
- ✅ Backwards compatible: Low-level device_* methods remain available
- ✅ Future-proof: New device types require zero client code changes

🐛 Minor Issues to Fix

1. Debug code (lines 116-117): Remove the json.dump to raw_response_data.json
2. Print statement (line 349): Remove print(data) in device_list()
3. Typo (line 388): min_detailt should be min_detail
4. Malformed docstring (line 417): min_energy() docstring has implementation code mixed in

---
Note: I'm not a maintainer of this project, just offering suggestions based on reviewing the
implementation. The core architecture is solid - these are just refinement ideas to consider. Great work
overall! 👏

[GraemeDBlue]

@johanzander Thanks for the AI feedback, but it does touch on some great points, I will look to address those , I've also started on the growwate_server side, but having major problems matching up ShinePhoneApi field names to V1, esp when the values don't even seem to correlate