07.09.2026, 12:52
You're right — with a WebSocket-only reconnect, changes that happen while the socket is down are not re-synced. Let me correct the proposal: keep the value resync, but make it incremental.
Your legacy visualization already does exactly this: POST /scada-vis/objects/ws with "updatetime" returns only the objects changed since that time. Measured on 20251204 with 2832 objects: 14 bytes / 39 ms when nothing changed, 90 KB with updatetime=0.
Could /apps/localbus.lp accept the same "updatetime" parameter (the last tsec the client received), or could the WebSocket send a catch-up of changes since that time on open? Then the client can reopen the socket immediately and fetch only the delta: no data loss, no fixed 1 s wait, no 285 KB per reconnect.
Until then, on our side we will reopen the socket first and run the full POST in the background, merging by updatetime, so live data resumes within ~25 ms and consistency is restored when the POST completes.
Your legacy visualization already does exactly this: POST /scada-vis/objects/ws with "updatetime" returns only the objects changed since that time. Measured on 20251204 with 2832 objects: 14 bytes / 39 ms when nothing changed, 90 KB with updatetime=0.
Could /apps/localbus.lp accept the same "updatetime" parameter (the last tsec the client received), or could the WebSocket send a catch-up of changes since that time on open? Then the client can reopen the socket immediately and fetch only the delta: no data loss, no fixed 1 s wait, no 285 KB per reconnect.
Until then, on our side we will reopen the socket first and run the full POST in the background, merging by updatetime, so live data resumes within ~25 ms and consistency is restored when the POST completes.