Make remote id tag configurable and reset on Home Assistant transaction start

[mightytry]

• Added remote_id_tag as configuration option in configuration.yaml
• Fixed when Id Tag was set by using wall box, it was not set back to _remote_id_tag when using home assistant to start afterward

Summary by CodeRabbit

• New Features
  • Added configuration option to specify a remote ID tag for OCPP transactions. When configured, this tag is used for transactions; otherwise, a random tag is generated automatically.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request introduces configuration-driven remote ID tag management for the OCPP charging point. A new configuration option enables specifying a remote ID tag, which is retrieved by a new method that falls back to random generation if not configured. Upon successful transaction start, the stored remote ID tag updates the corresponding metric.

Changes

Cohort / File(s)	Summary
Configuration & Constants config/configuration.yaml, custom_components/ocpp/const.py	Added new configuration option ocpp.remote_id_tag with value "TESTRFIDTAG123456789" and introduced corresponding constant CONF_REMOTE_ID_TAG to support configuration-based remote ID tag retrieval.
ChargePoint ID Tag Management custom_components/ocpp/chargepoint.py	Added get_remote_id_tag() method to retrieve configured remote ID tag or generate a random 20-character alphanumeric string as fallback. Updated __init__ to use this method instead of direct random generation.
Transaction Metric Update custom_components/ocpp/ocppv16.py	Modified start_transaction to reset the id_tag metric to the stored remote ID tag upon receiving an accepted response.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Configuration addition and constant declaration are straightforward
• New get_remote_id_tag() method implements simple config lookup with fallback logic
• Verify that the metric update in start_transaction correctly applies the remote ID tag and doesn't conflict with PR #1777
• Ensure configuration parsing correctly handles the new remote_id_tag option

Possibly related PRs

• PR #1777: Also modifies id_tag metric management in ocppv16.py, may have interactions with this metric update on transaction start.

Suggested reviewers

• drc38

Poem

🐰 A remote tag now configured to stay,
No random strings hop 'round this day,
On transaction's start, metrics align—
Our OCPP chargepoint, by design! ⚡

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check	✅ Passed	The pull request title clearly summarizes both main changes: making the remote id tag configurable and resetting it on Home Assistant transaction start, matching the actual changeset.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

custom_components/ocpp/chargepoint.py (1)

297-303: Replace unused loop variable with underscore.

The loop variable i on line 302 is unused and should be replaced with _ per Python convention.

🔎 Apply this diff to follow Python conventions:

     def get_remote_id_tag(self) -> str:
         """Get remote id tag from configuration.yaml or generate a random 20 char one."""
         config = self.hass.data[DOMAIN].get(CONFIG, {})
         alphabet = string.ascii_uppercase + string.digits
         return config.get(
-            CONF_REMOTE_ID_TAG, "".join(secrets.choice(alphabet) for i in range(20))
+            CONF_REMOTE_ID_TAG, "".join(secrets.choice(alphabet) for _ in range(20))
         )

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fecf73f and fa69550.

📒 Files selected for processing (4)

• config/configuration.yaml (1 hunks)
• custom_components/ocpp/chargepoint.py (3 hunks)
• custom_components/ocpp/const.py (1 hunks)
• custom_components/ocpp/ocppv16.py (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

custom_components/ocpp/ocppv16.py (2)

custom_components/ocpp/chargepoint.py (2)

• value (85-87)
• value (90-92)

tests/test_charge_point_v16.py (2)

• value (4252-4258)
• value (4261-4263)

🔇 Additional comments (5)

config/configuration.yaml (1)

50-50: LGTM!

The new configuration option is properly formatted and demonstrates the feature with a clear test value.

custom_components/ocpp/const.py (1)

31-31: LGTM!

The new constant follows the existing naming convention and is properly positioned in the file.

custom_components/ocpp/chargepoint.py (2)

54-54: LGTM!

The import is correctly added and follows the existing pattern.

---

284-284: LGTM!

The refactoring to use get_remote_id_tag() improves maintainability and enables configuration-driven behavior.

custom_components/ocpp/ocppv16.py (1)

629-630: Verify connector-specific metric update in remote transaction start.

The start_transaction method (line 621) accepts a connector_id parameter but updates the global metric self._metrics[0][cstat.id_tag.value] rather than connector-specific metrics. However, the on_start_transaction handler (line 1084) uses the connector_id in its metric key: self._metrics[(connector_id, cstat.id_tag.value)].

Clarify the design intent: Is the global metric update at line 630 intentional (tracking the remote_id_tag used globally across all connectors) or should it be changed to self._metrics[(connector_id, cstat.id_tag.value)] to track per-connector remote start operations? This matters especially if the same charge point has multiple connectors and you call start_transaction with different connector IDs.