Skip to content

Combine --watch functionality with --server#110

Open
victor-hucklenbroich wants to merge 5 commits into
rhyst:masterfrom
victor-hucklenbroich:server-watch
Open

Combine --watch functionality with --server#110
victor-hucklenbroich wants to merge 5 commits into
rhyst:masterfrom
victor-hucklenbroich:server-watch

Conversation

@victor-hucklenbroich

@victor-hucklenbroich victor-hucklenbroich commented May 11, 2026

Copy link
Copy Markdown

RESOLVES #94

Add a persistent BLE notification subscription to the HTTP server, gated
on a new watch: bool config option. When enabled, the server mirrors
desk state changes to stdout (matching the CLI --watch behaviour) and
exposes a new /events websocket endpoint that streams JSON updates of
the form {"height": , "speed": <mm/s>} to connected clients.

To support multiple consumers of the same notification stream, the Desk
class gains an in-process pub/sub layer (subscribe / unsubscribe ->
start_watching / stop_watching) with a cached latest_height and
latest_speed. The existing watch_height_speed CLI entrypoint is
reimplemented on top of this layer with no change in behaviour.

The TCP server is unchanged and remains request/response only.

Adds corresponding new flag (watch: True / False) to config.yaml. Defaults to false, so existing configs are unaffected until they opt in.

Re-establish watch subscription after reconnect

While working on the server watch changes I found a pre-existing gap in the reconnect handling. disconnect_callback transparently reconnects the BLE client, but the notification subscription dies with the old connection while desk._watching stays True. After a reconnect the subscription is never rebuilt and the if self._watching: return guard in start_watching would prevent it anyway so the height/speed event stream goes silently dead.

This affects both the new --server --watch path and the existing CLI --watch. It isn't introduced by the server watch changes, but a long-running server will eventually hit it, so it's worth fixing here.

The fix is small: Desk.mark_disconnected() clears the watching flag on disconnect and reports whether watching was active, and connect re-calls start_watching on the new connection when it was. Existing subscribers are preserved, so clients keep receiving events seamlessly across a reconnect.

Functionality (new and existing) is manually tested on my local macOS machine with my Ikea Idasen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Request: watch combined with server

1 participant