SPH read? (WIT inverter)

[tissson]

bess-debug-2026-08-17-191722.md

What happened

It seems Bess Manager have automatically chosen SPH even though I am using a Growatt WIT (low voltage) hybrid inverter. I have added all the necessary sensors manually and it seems to work except for the dashboard triggering errors (growatt server read ac charge times) and (critical system issues deteced, system health check)

Growatt WIT detected as growatt_server_sph

BESS auto-detects my Growatt WIT as MIX/SPA/SPH (DC-coupled).

All sensors are detected correctly:

• SOC
• Charge power
• Discharge power
• Battery capacity
• PV
• Grid

But BESS repeatedly calls:

growatt_server.read_ac_charge_times

which returns:

500 Server Error

Demo Mode works fine but no schedule is created.

Is WIT currently supported or should another platform be selected?

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

This report bundles four distinct issues under one symptom ("dashboard shows errors, no schedule created"). Only the first is what the reporter suspected; the other three are independent bugs/config gaps that happen to be active in the same session.

1. Platform misdetection (confirmed, matches reporter's report). The Growatt WIT is a hybrid inverter controlled locally via a growatt_modbus HA integration entry (device model "WIT 4-15kW Hybrid"). BESS Manager's discovery logic only ever inspects the growatt_server (cloud) config entry, and uses elimination logic — "no -tlx_ unique_id marker found → must be SPH" — rather than positive identification. Since the WIT's real entities live entirely under growatt_modbus, which discovery never looks at, growatt_server here only sees one, unrelated portal/plant-level device ("Malax Total", total_energy_today etc.), and defaults to growatt_server_sph. WIT is not currently a supported platform in this codebase — it isn't silently aliased to SPH by design, it simply never enters the detection logic.

2. The 500 error is real, but does not itself block schedule generation. With platform growatt_server_sph, the SPH control path calls growatt_server.read_ac_charge_times against the resolved device (the wrong one — "Malax Total", not the WIT), which the HA growatt_server integration returns 500 Server Error for. This call is only used for the periodic health-check probe and for startup hardware sync — both already tolerate failure and don't abort the optimizer.

3. "No schedule is created" has two separate, unrelated causes active in this bundle, neither is the 500 error:

• Earlier in the session (17:28–18:45), the official Nordpool price fetch returned 400 Client Error, which aborts update_battery_schedule immediately ("No price data available").
• At the two most recent cycles before export (19:00:58, 19:15:00), home.consumption_strategy = "sensor" but sensors.shared.48h_avg_grid_import is unconfigured (""), so get_estimated_consumption() raises SystemConfigurationError("48h_avg_grid_import sensor not available"), aborting the schedule build.

The "No strategic intents available" errors (×120) are a downstream dashboard-polling symptom of "no schedule has ever successfully built this session" — not a separate root cause.

4. "Critical system issues detected" is a genuine, previously-unreported bug, and is a better explanation for that specific banner than the 500 error alone. growatt_sph_controller.check_health() returns its per-check dict with keys component/status/message, but BatterySystemManager._run_health_check()'s logging loop unconditionally indexes check['name'] and check['error'] — keys that dict doesn't have. Whenever the SPH check is not OK (i.e. exactly when the 500 error is present), this raises KeyError('name'), which is caught by the outer except, logged as Health check failed: 'name', and discards the entire health-check result, replacing it with {"status": "ERROR", "checks": []}. This matches the bundle's repeated log line exactly (str(KeyError('name')) == "'name'") and explains why the dashboard shows a blanket "critical system issues" state rather than a specific per-component error.

Evidence

• core/bess/ha_api_controller.py:3120-3128 — elimination-based platform detection:

  has_tlx = any(
      entry.get("platform") == "growatt_server"
      and "-tlx_" in str(entry.get("unique_id", ""))
      for entry in entity_registry_result
  )
  detected_platforms.append(
      "growatt_server_min" if has_tlx else "growatt_server_sph"
  )

  No code path anywhere in core/bess/*.py inspects the growatt_modbus domain.
• Bundle: "detected_platforms": ["growatt_server_sph"], "growatt_device_id": "749316cd4ca78f37fd8e7f2b25427fa1" resolves to device "Malax Total" (growatt_server domain), while the actual hardware — "model": "WIT 4-15kW Hybrid" — lives under a separate device (5457717ddc3a3dce6539283321a3a6ed) on the growatt_modbus domain.
• 500 error, live for the whole session: 2026-08-17 17:28:46 | ERROR | core.bess.ha_api_controller:1050 - API request to .../growatt_server/read_ac_charge_times ... failed on final attempt 4/4: 500 Server Error.
• read_ac_charge_times callers are health-check/startup only (core/bess/growatt_sph_controller.py:267, 331, 505) — the DP schedule pipeline never calls it.
• Schedule blocker . #1: 2026-08-17 17:28:32 | WARNING | core.bess.battery_system_manager:637 - Schedule update aborted: No price data available, preceded by battery_system_manager:1513 - Failed to fetch price data: ... Failed to get prices from official integration ...: 400 Client Error.
• Schedule blocker Growatt integration #2 (active at export time): 2026-08-17 19:00:58 | ERROR | core.bess.battery_system_manager:740 - Failed to update battery schedule: Configuration error in 48h_avg_grid_import sensor not available (also at 19:15:00). Code: core/bess/ha_api_controller.py:1449-1463:

  raw_value = self._get_sensor_value("48h_avg_grid_import")
  if raw_value is None:
      raise SystemConfigurationError("48h_avg_grid_import sensor not available")

  Config: bundle shows "consumption_strategy": "sensor" with "48h_avg_grid_import": "".
• Health-check crash: core/bess/growatt_sph_controller.py:507-533 returns check = {"component": ..., "status": ..., "message": ...} inside "checks": [check], while core/bess/battery_system_manager.py:3117-3128's logging loop does:

  entity_str = f" ({check['entity_id']})" if check.get("entity_id") else ""
  logger.info(f"  - {check['name']}{entity_str}: {check['status']} - {check['error'] or 'No specific error'}")

  raising KeyError('name'), caught by the outer except at battery_system_manager.py:3160-3165, which logs Health check failed: {e} and returns {"status": "ERROR", "checks": []} — matching the bundle's Health check failed: 'name' (×25, in lockstep with every cycle where the SPH check is non-OK).

Proposed fix

Three independent changes are needed:

1. Fix the health-check logging crash in _run_health_check (battery_system_manager.py) to read the SPH check's actual keys (component/message) instead of assuming the generic perform_health_check() shape (name/entity_id/error) — either normalize the SPH controller's check_health() output to the generic shape, or make the logging loop tolerant of both. This is a standalone bug fix regardless of the WIT question.
2. WIT support is a platform-support gap, not a quick fix: it needs discovery logic that recognizes the growatt_modbus domain (or whichever integration the community uses for WIT) and a corresponding control path, since WIT is a distinct hardware generation, not just an SPH variant. This is scoping work, not something to bolt onto the existing SPH elimination logic.
3. The two schedule-blocking issues (price fetch 400, unconfigured consumption sensor) are configuration/environment issues for this reporter, not code bugs — but they explain "no schedule is created" far better than the WIT/500 issue does, and should be pointed out to the reporter directly so they don't chase the wrong problem.

Risks / open questions

• Whether growatt_modbus is a specific, identifiable open-source HACS component that BESS could add discovery/control support for was not investigated — that's scoping work for a WIT-support feature.
• Could not confirm from the bundle alone whether the Nordpool 400 errors reflect a genuine misconfiguration or a temporary official-API issue, or whether the reporter switched providers mid-session (the errors stop at 18:45:14 while the exported config shows nordpool_hacs as active provider).
• Given the scope split above (a real standalone bug fix + a config/environment issue + a platform-support feature), this issue may be better handled as: fix the health-check crash now, and treat "add WIT support" as a separate feature request if the reporter wants to pursue it.

---

Reply @claude-bot fix to implement and open a draft PR.

[bess-product-owner]

Thanks for the bundle — it was detailed enough to separate four different things that were all firing at once here. The short version is that the SPH/WIT detection you spotted is real, but it is not what is stopping your schedule from being created.

What is actually blocking the schedule — these two are configuration, and you can act on them now:

1. Price fetching is failing (Nordpool 400). Your exported config has nordpool_hacs as the active provider. Worth re-checking that setting, and whether the HACS Nordpool integration is healthy on your side. Without prices there is nothing to optimise, so no schedule is produced.
2. The consumption sensor is not configured. The optimizer needs a consumption forecast; with no sensor it cannot build one.

Fix those two and you should get a schedule, independently of everything below.

The growatt_server read_ac_charge_times 500 error is real but harmless here — it is only used by the periodic health probe and the startup hardware sync, both of which already tolerate failure. It is noisy, not blocking. It happens because detection picked the wrong device (your portal-level "Malax Total" entry rather than the inverter).

On the WIT itself: you are right that it was misdetected. Your WIT is controlled locally through a growatt_modbus integration entry, and our discovery only ever inspects the growatt_server (cloud) entry — then uses elimination ("no TLX marker, so it must be SPH") rather than positive identification. So it never sees your WIT at all and falls back to SPH. WIT is not a supported platform today — it was not silently aliased to SPH by design, it simply never enters the detection logic. Adding it is a real piece of work, not a config toggle, because the WIT is a distinct hardware generation rather than an SPH variant.

We are splitting this up so the parts can move at their own pace:

• a standalone bug fix for a health-check logging crash the bundle also exposed (unrelated to your inverter, but your log is what surfaced it)
• a separate scoping question for WIT support

I will link those here once they are filed. Would you be willing to say a bit more about your setup for the WIT side — specifically which growatt_modbus integration you installed (repo/HACS link), and whether it exposes battery SOC, charge/discharge control and power sensors? That is the information that decides how much work WIT support actually is.

[tissson]

I got the nordpool fixed using the own sensor ID, so that error is resolved.

The required sensors do exist in Home Assistant (SOC, charge/discharge power, solar power, grid import/export power, lifetime energy counters etc.), but they were not automatically detected.
I have a Growatt WIT inverter. The BESS auto-discovery did not detect the required sensors automatically, so I manually mapped all battery, grid, solar and lifetime energy sensors - but they are working fine and I can see the data both under inverter etc.

I'm currently using the Growatt Server cloud integration. I am not using a local growatt_modbus integration at this time.

I have not yet verified whether local Modbus control for WIT exposes charge/discharge control entities or TOU schedule controls.

I have been using Predbat before hence also my interest in BESS Manager (since it's focused on Growatt, which Predbat wasnt..but seems it didnt cover all Growatt models ;) )

[tissson]

I got the schedules up and running now (though the varnings are still there), but since Nordpool and the consumption sensors was created it got fixed.

[bess-product-owner]

Thanks — good news on the Nordpool fix.

One correction that changes your options: your bundle does show a local Modbus integration loaded. There's a growatt_modbus config entry in state: "loaded", the device carrying "model": "WIT 4-15kW Hybrid" belongs to it, and every sensor you mapped by hand (sensor.growatt_battery_battery_soc, sensor.growatt_grid_grid_import_power, sensor.growatt_solar_solar_total_power, …) is one of its entities. That's 0xAHA/Growatt_ModbusTCP, installed via HACS. Your growatt_server cloud entry only carries the plant-level "Malax Total" device — which is exactly what BESS latched onto, and why read_ac_charge_times returns 500.

So your data is already local. It's only the control path that's missing.

We've opened #632 for WIT support, and it may be a shorter road than we first said. A different integration — wills106/homeassistant-solax-modbus — classifies WIT as GEN4, and BESS already supports GEN4 Growatt over that integration, including the VPP control path. On paper your WIT should be auto-detected with no code change from us.

If you're willing to test, that would settle it: install solax_modbus alongside what you have, point it at the WIT, and re-run the BESS wizard. Three questions — (1) does "Growatt MIN/GEN4" show green with sensors filled in, (2) with control_mode: tou, does a TOU slot write actually change anything on the inverter, and (3) with control_mode: vpp, do charge and discharge commands take effect? We suspect TOU is read-only on WIT and VPP is the working path, but nobody here has the hardware to check.

Separately: 48h_avg_grid_import is still unset in your config, and that alone aborts the schedule build every cycle. Worth fixing regardless of the above.

On timing — there are a lot of open issues ahead of this one, and #632 is blocked on hardware nobody on the project has, so it may well sit for a while before anything moves. Your test results would be the thing that unblocks it, but there's no promise of a quick turnaround either way.

[tissson]

I am not successful getting the solax modbus connecting to my Growatt for some reason.
It will not detect anything.

Log details (ERROR)

This error originated from a custom integration.

Logger: custom_components.solax_modbus
Source: custom_components/solax_modbus/init.py:447
Integration: SolaX Inverter Modbus (documentation, issues)
First occurred: 11:01:34 PM (1 occurrence)
Last logged: 11:01:34 PM
Growatt GEN4: platform unload returned False