Guidance for Claude Code (or any agent) working in this repository.
growatt_server_upstream is a HACS custom-component distribution of an
enhanced Growatt Server integration for Home Assistant. It started as a copy
of home-assistant/core's homeassistant/components/growatt_server/
directory and has since diverged significantly with real feature work never
contributed upstream: SPH sensor support (sensor/sph.py), a persistent
API-rate-limit guard (throttle.py), and various fixes. It has its own
independent git history — it is not a fork of home-assistant/core and
shares no commit ancestry with it.
Domain: growatt_server (same as core — remove HA's built-in integration
before installing this one, per the README).
../core— the user's fork ofhome-assistant/core(origin=johanzander/core,upstream=home-assistant/core). Used as the source of truth for "what does current upstream core actually look like" when refreshingvendor-sync(see below). Its localdevbranch can be very stale — alwaysgit fetch upstream devthere before trusting it as current.../PyPi_GrowattServer— thegrowattServerPython library this integration depends on (manifest.json'srequirements). The user is a contributor there too; library-level fixes (e.g. surfacing API error codes, client-side rate-limit handling) belong in that repo, not here. See its issues/PRs for in-flight work relevant to this integration (e.g. indykoning/PyPi_GrowattServer#154, #155, #156).bess-manager— a Home Assistant add-on that is a consumer of this integration's sensors/services (battery scheduling). Debugging a bess-manager report often traces back here or intogrowattServer.
Two branches, two different jobs. Do not blend them.
-
vendor-sync— a pure, unmodified snapshot ofhomeassistant/components/growatt_servercopied from currenthome-assistant/coreupstream. No local patches ever land here. Its only purpose is to be a clean, up-to-date reference point:- to diff
master's accumulated changes against, so "what's ours vs what's upstream's" stays answerable at any time - as a clean base for testing whether a new fix/idea reproduces against vanilla core before deciding it needs a patch here
- as the source of truth when eventually preparing an upstream
contribution PR to
home-assistant/core
- to diff
-
master— what HACS actually ships.vendor-syncplus every local patch (SPH sensors, throttle guard, growattServer version bumps, bug fixes), each as its own identifiable commit on top.
cd ../core
git fetch upstream dev # local `dev` branch is often stale — don't trust it un-fetched
git log -1 upstream/dev # note the SHA, it goes in the sync commit message
cd ../growatt_server_upstream
git checkout vendor-sync
rm -rf custom_components/growatt_server
cp -r ../core/homeassistant/components/growatt_server custom_components/growatt_server
find custom_components/growatt_server -name "__pycache__" -exec rm -rf {} +
git add -A
git commit -m "vendor: sync growatt_server from home-assistant/core@<sha> (<date>)"
git pushThen decide per-change whether to merge/rebase the new upstream delta into
master (conflicts here are exactly the interesting part — they show where
our patches touch code upstream has since changed).
Commit it on master only, as its own commit with a clear message
describing why (not just what — the diff already shows what). If the
patch is something upstream would plausibly want, say so in the commit
message; that's the trigger for eventually splitting it into an upstream
PR against home-assistant/core.
pytest tests/runs the existing suite (config flow, init, sensors, number, switch, services, throttle).- To test against a locally-edited
growattServer(from../PyPi_GrowattServer) before it's released: install it editable into whatever Python env runs your test HA instance (pip install -e ../PyPi_GrowattServer), which satisfies the import regardless of themanifest.jsonversion pin. Bump the pin for real once a release is cut. - For end-to-end testing against a real Home Assistant instance, see
bess-manager'sdocs/agents/for how the user's dev HA instance and mock-HA e2e stack are reached — this repo doesn't have its own e2e setup.
These apply here too, since the same user/workflow conventions hold:
- Never commit directly to
masterfor anything beyond what's described above (vendor syncs and patches both go onmasterintentionally here — this repo has no separate release/beta branch split like bess-manager). For genuinely new/risky feature work, use afeature/*orfix/*branch and a PR, same as the existing branch history shows (fix/sph-type5-device-list,feature/sph-sensors, etc.). - Never push to a remote or open a PR without the user's explicit go-ahead.
- Verify against actual source (upstream core, the growattServer library, real API responses/logs) before proposing a fix — don't guess at entity names, error codes, or upstream behavior.