SensorView: 3-thread architecture, embedded LAN dashboard, and Hex Viewer

[manupawickramasinghe]

Adds the three-thread architecture, an embedded LAN telemetry server, and the Hex Viewer pane — plus a fix for a crash that was taking out every sensor.

Thread architecture

Thread 1  poll::spawn ......... fast lane ~1 s
   SensorSource::snapshot() -> Monitor (min/max/avg) -> TelemetryFrame
   the ONLY writer to TelemetryStore
        |                                    |
   ArcSwap (atomic ptr)            broadcast::Sender<Arc<String>>
        v                                    v
Thread 2  GUI (main thread)        Thread 3  web::spawn
   eframe/egui, store.load()          tokio + axum, one task per WS client

Thread 1b  inventory::spawn_collector ..... slow lane ~30 s
   ACPI / SMBIOS / storage / topology -> ArcSwap, read by Thread 1

The UI previously locked the poller and deep-cloned the whole hardware tree every frame, in every window. Adding a web server on that lock would have made contention the dominant cost. Instead the poller is the sole writer and publishes an immutable Arc<TelemetryFrame> via ArcSwap; readers never block, and the deep clone is gone.

Why it can't deadlock (src/state.rs, src/main.rs):

1. One writer — only Thread 1 mutates telemetry.
2. UI mutations are messages, not locks — poll::Command over an mpsc channel.
3. No lock guard is ever held across .await — enforced by #![deny(clippy::await_holding_lock)] plus a CI gate.
4. No lock-ordering cycle — the remaining locks (history ring, logger slot) are leaves.
5. Backpressure stops at the channel — a stalled browser gets Lagged and resyncs; it can never slow the hardware loop.
6. Ordered shutdown — GUI exit → stop web (release port) → stop poller (release driver) → stop collector.

Web tier (src/web/, feature web, default on)

GET / (embedded SPA) · /api/telemetry · /api/system · /api/history/{id} · /api/health · /metrics (Prometheus) · /ws/telemetry.

Each frame is serialized once into an Arc<String> that every client forwards, so N clients cost O(1) per tick, not O(N).

Security: binds 127.0.0.1:8080 by default. This endpoint exposes drive serials and raw SPD/PCI dumps, so any non-loopback bind makes a per-run token mandatory on every route except /api/health. Verified 401 on /api/telemetry, /, and the WS upgrade without it; 200 via query string, Authorization: Bearer, and WS with it.

Hex Viewer (src/ui/hex_window.rs)

Offset · 16 bytes in 4-byte groups with a mid-row gutter · ASCII gutter, selection synced across columns, rows virtualized through egui_extras::TableBuilder. Beyond a plain dump: ACPI header fields are tinted by kind and named under the cursor, and the selected offset decodes as int8..uint64, float32/64, binary, char and ascii[8] in either byte order. Search (hex or text, wrapping) and go-to-offset.

Data comes from GetSystemFirmwareTable (ACPI + SMBIOS) — plain kernel32, no driver and no elevation — so it works despite the blocked Ring-0 driver on the dev machine. Linux reads /sys/firmware/acpi/tables. Read-only by design: nothing writes to hardware; Export writes a .bin/.txt copy.

Two deliberate departures from the brief

• Polling is tiered. S.M.A.R.T. reads keep drives out of low-power states and sub-500 ms SMBus polling provokes SMI storms, so storage/SPD/topology live on a 30 s slow lane on their own thread, where a multi-second read cannot delay a 1 s sensor tick.
• The dashboard is loopback-first. LAN serving is delivered as asked, just not unauthenticated by default.

Bugs found and fixed along the way

Bug	Consequence
Sidecar died on non-finite sensor values	Every sensor lost; app silently fell back to demo data
PollHandle::stop() only cleared a flag	Exit stalled up to a full poll interval (10 s) — the loop parks in recv_timeout
rust-version = "1.77" was stale	Cargo silently resolved egui_tiles to a version built against egui 0.30
HexBlob::find clamped its start offset downward	Searched backwards; find-next could never leave the last match
Windows keys ACPI tables by signature	The same 34 KiB SSDT listed 15 times as distinct tables
Go-to field allocated a fresh String per frame	Every keystroke discarded
JSON serialized even with the web tier compiled out	Full-tree serialization every second for zero consumers

The sensor outage is worth its own note: with VBS blocking BCLK reads, LHM returned NaN for the per-core clocks, and System.Text.Json throws rather than write non-finite floats — so the sidecar exited 0xE0434352 on its first snapshot. It now maps non-finite readings to null and survives a bad tick.

Verification

• 72 tests; clippy clean under -D warnings -D clippy::await_holding_lock; GUI-only (--no-default-features) build checked. CI now gates all three.
• Runtime: two concurrent WebSocket clients tracking the same monotonic seq, priming frame in 65 ms, ping→pong; REST + Prometheus + history (404 on unknown sensor); token gate verified both ways; graceful close releases the port with no orphans.
• Sensors: source: LibreHardwareMonitor bridge, 151 sensors across 12 devices (Ryzen 7 7700, RTX 5060, Radeon iGPU, memory, six NICs) — previously demo data.
• Hex Viewer: 16 real firmware blobs (MCFG, FACP, APIC, IVRS, SSDT, VFCT 44 KiB, SMBIOS 3.8); window renders and titles itself from the selected blob. Every settings tab, the sensors window and the graph window smoke-tested for panics.

Not included

Docking (egui_tiles resolves but is unused), the topology and storage panes, and the per-OS sensor backends. feature/portable-build remains an open item — the branch exists but its workflow was never written.

Known environmental issue (not a code defect)

Two blockers on the dev machine, confirmed against HWiNFO's own manual §10.5:

Blocker	State	Breaks	Fix
VulnerableDriverBlocklistEnable	1	WinRing0 → SMU/MSR power	Install PawnIO
Virtualization-Based Security	running, despite Memory Integrity off	BCLK → ratio-based clocks	Also disable Virtual Machine Platform + Windows Hypervisor Platform

17 sensors report "no value" until those are resolved; the other 134 read correctly.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.