Validate Support for coupled SB2 + SB1 Systems

[thomluther]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

In December 2024 Anker supports the SB1 in SB2 systems with SB2 Pro and SB2 Plus models (not with new SB2 AC models)
This HA integration supports both devices independently with all possible schedule settings, however it is not clear if all SB2 and SB1 device settings still work when they are coupled in a single system.

Describe the solution you'd like

To be verified by the community with such system type in use:

1. Can SB1 and SB2 schedule services be used independently since both use the same target system
2. Can schedule related entity be changed independently since they must modify correct slot of different rate plan for same system?
3. Are all device ans system related sensors for solarbank values still correct and reflect same values as in mobile App?

Describe alternatives you've considered

Api exports are required when discrepancies are found that show the incorrect values. You must document what values are expected or shown in the App.
Exports from HA should always be done when using the integration as account owner to get all required API responses.

Additional context

New feature that cannot be validated by the developer.

[thomluther]

It appears that a new schedule type was implemented with coupled system support.
This new schedule is a minimal SB1 schedule that will get enforced by SB2 when running Manual mode.
This new schedule can be queried with get_device_parm using the param_type "9". Normal SB1 schedules are managed with param_type "4".

The Api library uses another Api call to get the active SB1 schedule, which is get_device_load. This returns the active plan, so either type "4" or type "9". (This Api call does not work for SB2 schedules, since it only returns SB1 schedule format.

The App does not allow to modify SB1 schedule when SB2 is in manual mode (then SB1 schedule type "9" is applied.
When SB2 is in other automated modes (smartmeter or smart plug), the normal SB1 schedule type "4" is applied.

Changes must be implemented to make the SB1 schedule entities and actions unavailable while enforced SB1 schedule type "9" is active.
SB2 schedule entities and actions may always be usable and changeable, they are just not used by the SB2 appliance while not switched to manual mode.

Example format:

{
  "ranges": [
    {
      "id": 0,
      "start_time": "00:00",
      "end_time": "24:00",
      "turn_on": null,
      "appliance_loads": [
        {
          "id": 0,
          "name": "Custom",
          "power": 0,
          "number": 1
        }
      ],
      "charge_priority": 0,
      "power_setting_mode": null,
      "device_power_loads": null,
      "priority_discharge_switch": 0
    }
  ],
  "min_load": 0,
  "max_load": 800,
  "step": 0,
  "is_charge_priority": 0,
  "default_charge_priority": 0,
  "is_zero_output_tips": 0,
  "display_advanced_mode": 0,
  "advanced_mode_min_load": 0,
  "is_show_install_mode": 1,
  "display_priority_discharge_tips": 0,
  "priority_discharge_upgrade_devices": "",
  "default_home_load": 200,
  "is_show_priority_discharge": 0
}

To recognize which plan type is active, the turn_on field value can be used. This was always a boolean since the SB1 introduction, but seems to be empty for the enforced SB1 plan, most likely since the output power is completely supported by 0W power field (which was not supported in normal SB1 schedules.
Optionally the min_load field can distinguish the plan types, since this was never 0 but 100 or 150 depending on configured Inverter type.