Charger polling needs a cool-off period when finished charging

[sveinse]

The dynamic polling of charger state, where the unit is polled every 1 minute while charging and 10 minutes. In the current implementation the polling interval is adjusted as soon as it detects no more charging, however there are some additional information about the finished charge that should be polled more frequently.

I think the best fix here is to implement a scheme that keep the high poll rate running for X minutes after the charging has finished. It does add complexity and stateful-ness, but I think the current implement will lead to complaints.

When testing this, it turns out that Zaptec had no data update during those 10 minutes. I am uncertain if this is a problem or not. I'm creating the issue, and we can look at it with some more real-life exposure.

# Car finished charging
22:42:38.128 [zaptec.api] @@@  EVENT {'ChargerId': 'Charger[f40861]', 'StateId': '710 (ChargerOperationMode)', 'Timestamp': '2025-07-23T22:42:37.530253Z', 'ValueAsString': '5'}
22:42:38.129 [zaptec.api] >>>  Updating Charger[f40861].charger_operation_mode (ChargerOperationMode)  =  <str> 'Connected_Finished'  (was Connected_Charging)

# Coordinator turns down the update interval
22:42:38.129 [zaptec] Charger[f40861] is now Connected_Finished, setting update interval to 0:10:00 (was 0:01:00)
22:42:38.130 [zaptec]     sensor.sol_charger_mode  =  'Connected_Finished' <str>   from Charger[f40861].charger_operation_mode
22:42:38.131 [zaptec]     switch.sol_charging  =  False <bool>   from Charger[f40861].charger_operation_mode

# Next update is 10 minutes later - note it has no vital information
22:52:38.157 [zaptec] --- Polling Charger[f40861] from Zaptec
22:52:38.158 [zaptec.api] Poll state from Charger[f40861] (Sol)
22:52:38.314 [zaptec.api] >>>  Updating Charger[f40861].pulse_interval (PulseInterval)  =  <str> '600'  (was 180)
22:52:38.314 [zaptec] Finished fetching zaptec-charger[f40861] data in 0.157 seconds (success: True)

[steinmn]

On a similar note: do we also need increased update rate while in Connected_Requesting? In case authorization is coming form outside HA and we need to react to it?

[rhammen]

#434 covers most of this, via a different mechanism than the proposed cool-off.

ChargerOperationMode (710) is streamed, so stream_callback now runs the existing [2, 7, 15] s poll burst on any 710 frame. For the log above that means three polls in the 15 s after Connected_Finished instead of one empty poll 10 minutes later. Measured on a Go 2: ChargerCurrentUserUuid cleared at +2 s, CompletedSession updated at +7 s. Any 710 value triggers, so Connected_Requesting (@steinmn's case) is included.

What it doesn't cover:

• The burst is 15 s, not minutes. I haven't seen anything arrive later than that, but can't rule it out.
• It's stream-driven. With the stream down, set_update_interval still drops to the slow interval as soon as a poll sees not-charging, with no burst.

If #434 is considered sufficient, this can be closed. If a longer cool-off is wanted, ZAPTEC_POLL_CHARGER_TRIGGER_DELAYS could simply be extended, or something different designed.

[rhammen]

@sveinse With #434 merged and planned for v0.8.8, consider tagging this one also as v0.8.8 (depending on whether you agree #434 covers this issue sufficiently)