Answer zero-MAC CT probes with the configured CT MAC

[kvanbiesen]

Problem

A Marstek Venus E Mini (VNSEM-0) cannot be paired with the CT003 emulator. Selecting the AstraMeter CT in the Marstek app and pressing configure ends in "configuration failed", with nothing in the AstraMeter log. A real CT003 pairs with the same battery instantly, and a Venus E 2.0 (HMG-50) pairs with the emulated CT without problems.

Cause

An unpaired battery probes for a CT with an all-zero CT MAC:

meter_dev_type=VNSEM-0 meter_mac=aabbccddeeff ct_type=HME-3 ct_mac=000000000000 phase='0' power=0

Neither CT_MAC mode answers that probe the way a real CT does:
`

CT_MAC	Behaviour on a zero-MAC probe	Result on Venus E Mini
empty	answers, but echoes 000000000000 as its own MAC	pairing fails
set (e.g. 02b250aabbcc)	ignores it: "CT MAC mismatch (req=000000000000, cfg=02b250aabbcc)"	pairing fails
`

A real CT answers with its own MAC. The Venus E Mini apparently uses that reply to confirm the CT it was told to pair with exists. The Venus E 2.0 doesn't hit this because it already probes with the bound MAC, even during inspection:

meter_dev_type=HMG-50 meter_mac=112233445566 ct_type=HME-3 ct_mac=02b250aabbcc phase='0'

Change

When CT_MAC is configured, CT002._ct_mac_matches now also accepts requests whose CT MAC is empty or 000000000000. The existing response path (self.ct_mac or request.ct_mac) then answers with the configured MAC, so the emulator identifies itself like a real CT.

• CT_MAC empty: unchanged (still answers everything and echoes the request's MAC).
• CT_MAC set: requests naming a different non-zero CT MAC are still ignored, so multiple CTs on one network keep working.
• Batteries that already send the bound MAC (Venus E 2.0, B2500, …) see no difference.

Testing

Tested on real hardware with AstraMeter develop, CT003 emulation, CT_MAC set to the managed cloud CT's MAC:

• Before: the Venus E Mini keeps probing with ct_mac=000000000000 in inspection mode, and configure in the Marstek app fails.
• After: responses to the Venus E Mini carry the configured MAC (fields=['HME-3', '02b250aabbcc', 'VNSEM-0', ...]), configure succeeds immediately, and the battery leaves inspection mode and is steered normally.
• The Venus E 2.0 on the same instance keeps pairing and steering as before.

Notes / possible follow-up

With Marstek cloud registration ([MARSTEK]), AstraMeter already knows the managed CT's MAC. Defaulting CT_MAC to that value when it's left empty would make Venus E Mini pairing work without any manual configuration. I've left that out of this PR to keep the change minimal.

Checklist

• [0 ] Base branch is develop, not main -> its in main cause i can test that one more easely, easy to port to develop ofc

• [ x] uv run ruff format . && uv run ruff check . && uv run mypy src/ && uv run pytest

• [ x] Python ↔ ESPHome parity held for shared CT002 behaviour, or does not apply (CONTRIBUTING.md)

• [0 ] web/ changes: rebuilt the dashboard bundle (cd web && npm run build:dashboard) and committed it

• [ 0] User-visible change: one bullet under ## Next in CHANGELOG.md

Summary by CodeRabbit

• Bug Fixes
  • CT002 requests with an empty CT MAC or an all-zero placeholder are now accepted; mismatched nonempty MAC addresses remain rejected.
• Documentation
  • ESPHome setup instructions and examples now use version 2.3.1 rather than the development branch.
• Release
  • Updated the changelog and Home Assistant add-on version to 2.3.1.

[github-actions]

I moved this pull request onto develop, where feature work lands — main only ever receives releases, and GitHub offers it as the base by default, so this is nothing you did wrong.

If you branched off main, the diff above now carries commits that are not yours. Please rebase onto develop:

git fetch origin
git rebase --onto origin/develop origin/main
git push --force-with-lease

If you branched off develop to begin with, there is nothing to do.

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8c3a9393-07ee-4bcb-b0e5-d2b26b301c3e

📥 Commits

Reviewing files that changed from the base of the PR and between 4623e2f and 4499e48.

📒 Files selected for processing: 7

• CHANGELOG.md
• docs/esphome-powermeters.md
• docs/installation/esphome.md
• esphome.example.yaml
• esphome/components/ct002/ct002.cpp
• ha_addon/config.yaml
• src/astrameter/ct002/ct002.py

 __________________________________________________________________
< Ah yes, the classic pattern: 'parse first, ask questions never'. >
 ------------------------------------------------------------------
  \
   \   (\__/)
       (•ㅅ•)
       / 　 づ

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kvanbiesen]

Darn, i fucked up the PR, just update the 2 files ct002.cpp and ct002.py and i accidently added the main one