UI Status Bar and Modes

UI: Status bar and modes

Two pieces of UI chrome that show up on every page: the mode badge in the top bar, and the status bar at the bottom. They're how the operator answers "is the system healthy and what's it doing right now?" without leaving whatever page they're on.

📷 Screenshot placeholder: the full Backyard Hero shell with the mode badge top-right and the status bar across the bottom.

The mode badge (top right)

A single-word indicator that tells you the operational mode of the entire system. Lives in TopBar.jsx and is computed by the useAppMode hook from daemon state.

Mode	Meaning	Color cue
Disconnected	No WS connection or daemon hasn't reported in >5 s.	Yellow
Design	No show is staged.	Neutral
Ready	Show is staged, daemon is healthy, system is not loaded.	Neutral
Loading	Show is being preloaded onto receivers.	Neutral, with spinner
Loaded	All receivers report loadComplete for the staged show.	Neutral
Armed	Arm switch is engaged + start switch is in STOP.	Red rail visible
Pre-check	run_precheck is running.	Red rail
Countdown	T-N timer is running before show start.	Red rail
Live	Show is running.	Red rail + animated barber-pole
Manual fire	Manual fire mode is engaged (start + arm + manual fire all on).	Red rail
Paused	Show is paused mid-run.	Red rail
Stopped	Show was stopped (manually or by error).	Red rail

The "armed rail" is a thin barber-pole strip on the side of the UI that appears when mode is armed/live/manual fire. It's a peripheral cue — you can see in your peripheral vision that the system is "hot" while focused on a different page.

Precedence (highest to lowest, so e.g. Live always wins over Loaded): Live > Armed > Manual fire > Countdown > Pre-check > Loaded > Ready > Design > Disconnected.

The status bar (bottom of every page)

A horizontal strip with system-health indicators. From left to right:

Link

A WebSocket connection indicator + daemon freshness signal.

Color	Meaning
Green	WebSocket connected and the last fw_last_update was within ~5 s.
Yellow	WebSocket disconnected, or fw_last_update is older than 5 s. Browser will auto-reconnect with backoff.
Red	Persistent failure (multiple reconnect attempts).

Click to expand a small panel with the last few fw_d_error lines from the daemon error log.

Daemon

Daemon: ON (green) or Daemon: ? (yellow). Driven by the daemon's device_running flag (which itself is "have I seen serial traffic in the last 10 s").

Dongle

Shows the active protocol (e.g. BKYD_TS_HYBRID), a small TX activity pulse (lights up briefly on every command sent), and an optional command-queue saturation bar (depth / capacity from the dongle's q/qmax).

States:

• Green — protocol loaded, dongle responding to the per-second status frame.
• Yellow ("Silent") — dongle hasn't sent a status frame in >10 s. Click the Restart button next to it to ask the daemon to re-send select_serial to the bridge (which will close and reopen the port). If that doesn't help, see Connecting the dongle.
• Red ("Device error") — the daemon hit a hard serial error.

Receivers

Receivers: M / N online where N is the count of enabled BKYD_TS_24_1 receivers in the SQL Receivers table and M is how many of those have reported in within the last 8 s. Bilusocn receivers don't count (they have no uplink and are always "assumed operational").

If M < N, click to expand and see which receivers are offline.

Show

If a show is loaded: shows the show name and a small Run/Pause/Stop indicator. If running: a T+NN.N show clock that increments in real time.

Cursor

A read-out of fw_cursor (current playback time in seconds, updated ~1 Hz). Mostly useful for diagnostics — the timeline cursor on the Console page is the primary visualization.

Manual fire

When manual fire mode is engaged, a red MANUAL FIRE badge appears here. When it's off, the badge is hidden.

Toasts

Daemon errors (fw_d_error) surface as transient toasts in the bottom-right corner. They auto-dismiss after a few seconds; persistent errors stay visible until you click the X. The full error log is also accessible from the Settings → Debug tab.

Behavior during disconnect

If the WebSocket drops:

• Mode badge → Disconnected.
• Status bar Link → yellow.
• All consumers of useStateAppStore see stale data (the last good payload).
• Browser attempts reconnect with exponential backoff (1 s → 2 s → 4 s → ...).

You can keep working in the Editor / Inventory / Settings — they don't need live state. Console actions that require the daemon (Load, Launch, Abort) will show errors if attempted, since the API write would succeed but the daemon obviously can't do anything about it.

Implementation files

• host/byh_app/backyardhero/src/components/shell/TopBar.jsx — top bar including mode badge and tab list.
• host/byh_app/backyardhero/src/components/shell/StatusBar.jsx — the entire bottom strip + the WebSocket loop.
• host/byh_app/backyardhero/src/components/shell/AppShell.jsx — the 3-row grid layout, the armed rail.
• host/byh_app/backyardhero/src/components/shell/useAppMode.js — the mode derivation rules.
• host/byh_app/backyardhero/src/components/shell/ModeBadge.jsx — the visual badge.