Once #2 adds device-scoped events to the log, they still won't appear live — hatty's existing
live-append path (controllers/connection.py:213-221) only fires on state_changed events, and
device-scoped events (a button press, a ping) are never state_changed. They'd only show up after
closing and reopening the log, or paging back and forward.
To show them the moment they happen, hatty needs to subscribe to Home Assistant's
logbook/event_stream websocket command and route its live frames into the open log panel,
alongside (or replacing, while a stream is active) the current state_changed live-append —
including subscribing when the log opens, unsubscribing when it closes or the window pages away
from "live", and resubscribing after a reconnect (the subscription dies with the socket). hatty
has no unsubscribe_events command today either, so that needs adding too.
Depends on #2 for the entry normalizer (WS logbook entries need the same when/name handling
whether they arrive via get_events or event_stream).
Refs #2
Once #2 adds device-scoped events to the log, they still won't appear live — hatty's existing
live-append path (
controllers/connection.py:213-221) only fires onstate_changedevents, anddevice-scoped events (a button press, a ping) are never
state_changed. They'd only show up afterclosing and reopening the log, or paging back and forward.
To show them the moment they happen, hatty needs to subscribe to Home Assistant's
logbook/event_streamwebsocket command and route its live frames into the open log panel,alongside (or replacing, while a stream is active) the current
state_changedlive-append —including subscribing when the log opens, unsubscribing when it closes or the window pages away
from "live", and resubscribing after a reconnect (the subscription dies with the socket). hatty
has no
unsubscribe_eventscommand today either, so that needs adding too.Depends on #2 for the entry normalizer (WS logbook entries need the same
when/namehandlingwhether they arrive via
get_eventsorevent_stream).Refs #2