Recover a dropped Metasys SSE stream with Last-Event-Id without losing subscriptions

Documented steps

1. While consuming the stream, persist the 'id' field of the most recent SSE frame. Its format is {streamId}:{sequence}, e.g. b6d184ee-e137-44aa-b9b1-14bc704cd25d:5.
2. On disconnect, immediately reissue GET {base}/stream with header Last-Event-Id set to that saved id, using a current, unexpired access token.
3. A 200 response means the reconnect succeeded: Metasys replays buffered events and your existing subscriptions remain intact. On reconnect the first frame is subscribed data rather than a 'hello' event.
4. A 204 response means the reconnect failed - the buffer was cleaned up or the id is unknown. The documented recovery path is to call GET /stream again with no Last-Event-Id, take the new stream id from the 'hello' event, and recreate every subscription.
5. Reconnect fast: Metasys buffers events for at least thirty seconds after it detects the connection failure. Beyond that window, assume replay is unavailable.
6. Maintain a client-side registry of every subscription you created (object id, attribute, subscription location) so re-subscription after a 204 is mechanical rather than guesswork.
7. Treat a missing heartbeat as a disconnect signal; on the activities feed the heartbeat cadence is every 120 seconds, and the generic stream heartbeat carries a UTC timestamp payload.
8. If you use a browser EventSource with ?access_token=, update the token value in the URL on every reconnect; the spec warns the reconnect must carry the current access token.
9. Reference: https://jci-metasys.github.io/api-landing/api/v6-16 (Metasys REST API, 'Version 6 for 16.0', OpenAPI 3.0.3). Doc set index: https://jci-metasys.github.io/api-landing/ | changelog: https://jci-metasys.github.io/api-landing/guides/api-changelog/ | version support: https://jci-metasys.github.io/api-landing/guides/version-support-matrix/ | polling and streaming limits: https://jci-metasys.github.io/api-landing/guides/attribute-access-guidelines/