[seaspotter]

• cp.soc_timestamp > ev.soc_timestamp löste force_soc_update bisher jeden Zyklus neu aus, nicht nur beim Wechsel wie die beiden anderen Bedingungen daneben. Bleibt der EV-seitige SoC dauerhaft veraltet (zB API-Fehler, Tageslimit erschöpft), entsteht daraus ein Retry-Loop, der das konfigurierte Intervall umgeht und selbst das Limit weiter befeuert.
• Tracking erfolgt jetzt pro (CP-SoC-Timestamp, EV), damit ein EV-Wechsel am selben Ladepunkt weiterhin die eine legitime Aktualisierung auslöst, auch wenn der CP-Timestamp dabei unverändert bleibt.
• Zusätzlich: soc/soc_timestamp wurden beim Publish nie auf None geprüft, anders als imported/exported/plug_state/rfid/phases_in_use in derselben Methode. Ohne frische HLC-Werte in einem Poll wurde dadurch der zuletzt bekannte SoC-Wert mit None überschrieben statt erhalten zu bleiben - das war die Ursache des abwechselnden Wert/None-Musters im Log.

#4029

[Copilot]

🟡 Changes recommended

Two moderate issues remain involving duplicate updates and unsupported metadata topics.

2 open findings

• Avoid duplicate SoC force-update requests after EV switching · New
• Prevent publishing internal retry fields as unsupported set-topics · New

What changed in this PR

This PR prevents repeated stale EV SoC updates and preserves existing SoC values when fresh data is unavailable.

Changes:

• Tracks force-update requests by CP timestamp and EV.
• Skips publishing None SoC values.
• Adds force-update tracking state.

File	Summary
packages/​modules/​common/​store/​_chargepoint.py	Preserves SoC values when incoming data is missing.
packages/​control/​chargepoint/​chargepoint.py	Suppresses repeated force-update requests.
packages/​control/​chargepoint/​chargepoint_data.py	Adds force-update tracking fields.

🧠 Review effort: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.