feat: bind Anenji GES48120 to Sumry/GES 0x7530 via identity anchors

[txau]

Summary

• Exact-match identity anchors for Anenji GES48120M250-500P: model 45, product class 10, protocol version raw 220 (0xC738/0xC739 and 0xC768)
• Bind a read-only surface to the existing sumry_ges_7530 evidence subset (9 sensors: battery + phase-A output/mains); no write profile
• Tests cover owner CRC-valid identity frames plus wrong/missing/bad-CRC rejection; telemetry alone still does not bind
• Live-validated on owner hardware after deploy from this branch

Test plan

• python3 tools/model_catalog.py validate
• python3 -m unittest tests.test_sumry_ges_7530
• Deploy to Home Assistant and confirm auto-detect + 9 read-only sensors
• Reviewer: confirm probe actions use decimal registers 51000 / 51048 and all three equals anchors are required
• Reviewer: confirm no fork extras (PV, L2, derived power, write profile) leaked into this PR

Made with Cursor

[groove-max]

Thanks for putting this together and testing it on your inverter! This follows the approach we discussed: three exact identity anchors, the existing catalog driver, and the nine-field read-only subset. No transport changes or extra write registers have slipped in.

The 14 focused tests and 191 Home Assistant tests passed locally. I've also enabled the GitHub CI run. There are just a few small things to finish before merging:

1. Update the Unreleased changelog entry, docs/architecture/SUMRY_GES_7530.md, the description in docs/README.md, and the test module's opening description. They still say automatic detection is blocked. Please describe the new exact-match, read-only support while keeping the remaining telemetry/control limitations clear.
2. In test_identity_bad_crc_does_not_bind, change a CRC byte without shortening the response. The current response[:-1] checks a truncated frame, not a full-length frame with an invalid checksum. Keeping both cases as separate tests would be ideal. I checked the full-length bad-CRC case separately and it is rejected correctly; this is about retaining that regression coverage.
3. Point the new identity source at the actual capture comment, using project-comment:5953299167, so the evidence is easy to trace.

No broader refactor or additional device captures are needed for this PR. The scope looks good.

[txau]

Thanks for the review — addressed in 5f85a01:

• Unreleased changelog, SUMRY_GES_7530.md, docs/README.md, and the test
  module docstring now describe exact-match read-only support and keep the
  remaining telemetry/control limits explicit.
• Split truncated-frame vs full-length bad-CRC identity cases into separate
  tests.
• Identity source reference now points at project-comment:5953299167.

Happy to wait for CI / merge as-is.

Separately (not in this PR): my dashboard needs a few more read-only fields
from the same map that I already validated on this unit — roughly:

• load_power_total (0x7552)
• pv1/pv2 power (and optionally a derived pv_power total)
• mains_power L1/L2 (0x7574/0x7575) with a total only when both legs are present

Would you prefer those as a follow-up PR after this merges, still read-only
and gated on the same 45/10/220 anchors? I can keep it small rather than
bringing the full fork map.

[groove-max]

Thanks for addressing all three review points. I checked the merge with the current main: the full quality gate and all 210 Home Assistant tests pass, and GitHub CI is green. The three exact identity anchors and nine-field read-only scope are intact. Approved.

[groove-max]

Merged into main — thank you for the captures, hardware testing and the focused PR! This is available in the test code now; no new release has been published.

Yes, a small follow-up PR for the additional read-only fields would be welcome. Please include the register/scaling evidence and missing-data tests. For a two-leg mains total, both legs must be available in the same read; do not fall back to a one-leg total. Keeping this separate from write support will make it much easier to review.