ChargerCurrentUserUuid (722) and CompletedSession (723) are never pushed over the
live stream, so anything reading them follows the poll interval — 10 minutes when the
charger is idle. Measured on a Go 2 (fw 3.3.0.0): an RFID tap streamed
721 (SessionIdentifier) within 4.4 s but no 722, and a 27-second
authorize-then-unplug session never registered at all.
Only one client was connected during the capture, and the bursts arrived complete
(501, 502, 503 and 710 together on the unplug), so this isn't a second
consumer taking messages off the subscription — cf. #292.
We can't ask for it either — the stream consumes the Service Bus subscription from
messagingConnectionDetails as-is, with no filter or per-observation subscribe.
But 721 does stream, and it fires when the authorization happens — 4.4 s after the tap.
That makes it a usable proxy: when 721 arrives, 722 has changed server-side but won't
be pushed, so ZaptecManager.stream_callback could trigger a poll to fetch it. Would
need a debounce so a burst of frames can't cause a burst of polls.
Affects the sensors added in #431 (for #200 and #420), which read 722 directly. #420's
own flow is unaffected — authorizing from the button entity already triggers a poll —
it's RFID taps and Zaptec-app authorizations that lag.
ChargerCurrentUserUuid(722) andCompletedSession(723) are never pushed over thelive stream, so anything reading them follows the poll interval — 10 minutes when the
charger is idle. Measured on a Go 2 (fw 3.3.0.0): an RFID tap streamed
721 (SessionIdentifier)within 4.4 s but no 722, and a 27-secondauthorize-then-unplug session never registered at all.
Only one client was connected during the capture, and the bursts arrived complete
(
501,502,503and710together on the unplug), so this isn't a secondconsumer taking messages off the subscription — cf. #292.
We can't ask for it either — the stream consumes the Service Bus subscription from
messagingConnectionDetailsas-is, with no filter or per-observation subscribe.But 721 does stream, and it fires when the authorization happens — 4.4 s after the tap.
That makes it a usable proxy: when 721 arrives, 722 has changed server-side but won't
be pushed, so
ZaptecManager.stream_callbackcould trigger a poll to fetch it. Wouldneed a debounce so a burst of frames can't cause a burst of polls.
Affects the sensors added in #431 (for #200 and #420), which read 722 directly. #420's
own flow is unaffected — authorizing from the button entity already triggers a poll —
it's RFID taps and Zaptec-app authorizations that lag.