RIGStats (rig-dashboard)

RIGStats is a free hardware monitor and control center for Windows gaming PCs, built as a native Rust/egui app — no WebView, no telemetry.

• Monitor — live CPU, GPU, RAM, storage, network and motherboard sensors on a dedicated secondary display (portrait or landscape), as freely placed floating panels, or drawn into the desktop wallpaper.
• Game overlay — a compact, click-through metric strip on top of your game, toggled with Ctrl+Alt+O.
• Control Center — per-profile fan curves, Windows power plans, AMD Ryzen and Radeon power tuning, and RGB lighting (Aura Sync, Dynamic Lighting, Philips Hue), run by a background service so it keeps working with the app closed.
• Peripherals — battery level and charging of ROG wireless headsets, keyboards and mice, in a dashboard panel and a hover card over the tray icon, with a low-battery alert.
• Session history — record a session and chart it afterwards.

For the full product overview, screenshots, and download, see rigstats.app.

Installation

• winget: winget install Codeby.RIGStats
• Direct download: grab the latest installer from the Releases page

Both install the same signed NSIS installer, which also registers the sensor sidecar as a Windows Service. See rigstats.app for requirements and first-run guidance.

Repository Layout

Path	Contents
src-egui/	egui binary (rigstats.exe) — panels, tray, dialog windows
rigstats-backend/	Shared Rust lib — data sources, settings, hardware detection
sensor-sidecar/	.NET 10 C# Windows Service — LHM embedded, named-pipe server
xtask/	Cargo xtask — build, verify, fmt, clippy, test tasks
docs/	Architecture, setup, release, troubleshooting
website/	Product landing page source — not served at runtime
build/	NSIS installer script + official PawnIO setup

Prerequisites

• Windows 10/11 x64 — the app and sensor sidecar are Windows-only
• Rust — install rustup.rs; the toolchain version is pinned in rust-toolchain.toml, so rustup auto-installs the exact version CI uses the first time you run cargo in this repo
• .NET 10 SDK — winget install Microsoft.DotNet.SDK.10 (required for the sensor sidecar)
• Visual Studio 2022 Build Tools with "Desktop development with C++" workload (for linking)
• NSIS (installer builds only) — choco install nsis -y

cargo xtask verify and cargo xtask build fail if the rigstats-sensor Windows Service is running because the service holds the exe open. Stop it first (sc.exe stop rigstats-sensor in an elevated terminal), then run the command, then restart the service.

Quick Start

1. Install git hooks (run once after cloning):

   cargo xtask setup

2. Build and run the debug binary:

   cargo build --manifest-path src-egui/Cargo.toml
   .\target\debug\rigstats.exe

3. Restart workflow (Windows locks the exe while it runs):

   Stop-Process -Id (Get-Process rigstats -ErrorAction Stop).Id -Force
   cargo build --manifest-path src-egui/Cargo.toml
   Start-Process .\target\debug\rigstats.exe

   Verify the exe timestamp changed before launching — if not, the process was still running.

4. Production installer build:

   cargo xtask build

   The sensor sidecar exe is bundled automatically.

Development

# Format Rust (modifies files)
cargo xtask fmt

# Clippy — zero warnings required (-D warnings)
cargo xtask clippy

# Run Rust tests
cargo xtask test

# Full verify: sidecar build + tests + clippy + fmt-check
cargo xtask verify

# Build sensor sidecar only
dotnet build sensor-sidecar/sensor-sidecar.csproj

# Run a single Rust test
cargo test --manifest-path rigstats-backend/Cargo.toml classify_system_brand

Stop rigstats-sensor before running cargo xtask verify or cargo xtask build — the service holds the exe open.

Architecture

The sensor sidecar (rigstats-sensor.exe, .NET 10, LocalSystem Windows Service) embeds LibreHardwareMonitor and streams one JSON line per second over \\.\pipe\rigstats-sensors. The Rust backend reads that pipe alongside sysinfo (CPU/RAM/disk/network) and WMI (static hardware metadata at startup), then sends a StatsPayload to the egui UI thread each tick. The egui binary renders all panels and dialog windows natively — no WebView, no JavaScript at runtime.

See docs/architecture.md for module-level detail and docs/setup.md for the full local development setup. The lighting devices the Control Center drives are listed in docs/supported-devices.md.

Display & Placement

The dashboard renders on a secondary monitor and is configured entirely from Settings (a 560×600 dialog with six tabs: Display, Panels, Alerts, Appearance, General, Overlay).

• Display profiles — pick a portrait or landscape profile that matches the target screen (e.g. portrait-xl = 450×1920, landscape-xl = 1920×450). The dashboard auto-targets the connected monitor whose resolution and orientation best match, and falls back to the primary monitor when none match. Switching profiles keeps the window where you left it as long as that spot is still on-screen.
• Window layer — Normal, Always on Top, Always Behind, or Desktop Wallpaper.
• Floating mode — render panels as individually draggable/lockable cards.
• Fill Screen — fill the height of the monitor the window currently sits on (panel proportions are preserved).

Desktop Wallpaper (WorkerW) mode

Selecting Window Layer → Desktop Wallpaper renders the dashboard as a live wallpaper, reparented into the desktop WorkerW layer between the wallpaper and the desktop icons. It survives Win+D, is never covered by other windows, and coexists with Wallpaper Engine / Lively.

Because the wallpaper is drawn by a separate background process (rigstats-wallpaper.exe) that reads settings from disk, a few behaviours differ from the normal layers and are expected:

• Settings apply on Save, not as a live preview (an amber banner reminds you).
• No-op controls grey out and the Display Profile is locked — switch back to a non-wallpaper layer to change the profile, then return and Save.
• Window opacity has no effect (a Win32 WS_EX_LAYERED limitation on WorkerW children).

See docs/troubleshooting.md for details.

Game Overlay

A compact strip of chosen metrics drawn on top of games, independent of whatever the main dashboard is doing. Show/hide it from the tray or with Ctrl+Alt+O; configure it under Settings → Overlay.

• Metrics — pick and reorder from CPU/GPU load, temperature, clock and power, VRAM, RAM, network, ping, battery and more; values are coloured by the same warn/crit thresholds as the dashboard.
• Columns — one row, a vertical list, or 2–6 columns. Labels sit flush left and values flush right in fixed-width columns with thin dividers, so nothing shifts as values change.
• Placement — anchored to a screen corner with a margin, or dragged anywhere; scale, opacity, and an optional background card.
• Click-through — lock it (tray or Settings) so mouse clicks pass through to the game.

Session History

Explicit start/stop recording sessions, replacing the old continuous daily-rolling log. Toggle Start/Stop Recording from the tray menu — the tray icon blinks while a session is live — then open Session History to browse and chart past sessions.

• Each session gets its own CSV file plus a SessionMeta entry (name, time range, duration, pinned) in a JSON index.
• Rename, pin (exempt from retention pruning), reveal in Explorer, or delete any session from the list.
• Per-session detail view: CPU/GPU/RAM/network/disk/ping charts (egui_plot) with synced hover across every metric, plus avg/peak summary tiles.
• log_retention_days (Settings → General) prunes old, unpinned sessions automatically; pinned and still-recording sessions are never pruned.
• The index is resilient to corruption and cross-process writes (this app and rigstats-wallpaper can both record) — a .bak copy and a short file lock around each read-modify-write guard against a bad write or a lost update.

Control Center

Hardware control per profile — Silent, Balanced, Gaming, Eco and your own — switched from the tray, the header chip or Ctrl+Alt+P. Open it from the tray (Control Center…). Everything runs inside the rigstats-sensor service, so fan curves keep working with the app closed and after a reboot. Each tab appears only when this PC's hardware supports it.

Tab	What it controls	Where it works
Power	The Windows power plan each profile switches to	Any PC
Fans	Per-fan curves on CPU, GPU or a motherboard temperature; Identify measures which fans a channel drives	Motherboards with writable fan control (LibreHardwareMonitor)
CPU	PPT/TDC/EDC power limits, and Curve Optimizer (−30…0, all-core or per core)	AMD Ryzen 9000, on hardware-verified SMU tables
GPU	Power limit, the same setting as Adrenalin's or Afterburner's	AMD Radeon (ADLX), desktop NVIDIA GeForce (NVML)
Lighting	Aura Sync: one effect and colour for every device, live preview, the light bar's desk lamp	ASUS Aura motherboards, ROG monitors and light bar, ROG keyboards and headsets, any Windows Dynamic Lighting device, Philips Hue rooms and zones via the Hue Bridge — see supported devices

Safety, all in the service:

• CPU above 95 °C or GPU above 90 °C sends every controlled fan to 100 %; a lost temperature sensor does the same for its fan.
• New CPU limit, Curve Optimizer and GPU settings are tried for 15 seconds and revert by themselves unless you keep them; if the PC goes down right after a change, it is not re-applied at the next start.
• Never above what the BIOS or driver allows; stopping the service hands fans and limits back to the firmware.
• Lighting yields to Armoury Crate or OpenRGB when they run, and to Windows Dynamic Lighting per device.
• Philips Hue: only the rooms and zones you choose follow the rig. The bridge is reached on the local network only (no Hue account, no cloud); its key is stored encrypted and readable by the service only, and RIGStats only talks to a bridge whose certificate is signed by Philips Hue / Signify.

Not yet: Intel CPU limits (#209), laptop GPU power — it follows the laptop's own performance modes (ASUS: #234). Design and protocol notes: docs/control-architecture.md.

Sensor Coverage

Data is merged from three sources each tick: LibreHardwareMonitor v0.9.6 (sensor telemetry via named pipe), sysinfo (OS-level counters), and WMI (static metadata at startup).

CPU

Metric	Source
Total load (%)	sysinfo
Per-core load (%)	sysinfo
Clock frequency (GHz)	sysinfo
Package temperature (°C)	LHM — AMD: Core (Tctl/Tdie), Intel: CPU Package or Core Average
Package power (W)	LHM — Package power sensor

CPU temperature is matched by sensor name. The AMD label is preferred when both are present (dual-CPU edge case).

GPU

Metric	Source
Core load (%)	LHM — GPU Core load
Core temperature (°C)	LHM — GPU Core temperature
Hot spot temperature (°C)	LHM — GPU Hot Spot temperature
VRAM temperature (°C)	LHM — GPU Memory Junction (NVIDIA) / GPU Memory (AMD) temperature — its MEM column appears only on GPUs that report it
Core clock (GHz)	LHM — GPU Core clock
Memory clock (MHz)	LHM — GPU Memory clock — collected but not yet shown in the panel
Package power (W)	LHM — GPU Package power
Fan speed (RPM)	LHM — GPU Fan
VRAM used / total (GB)	LHM — GPU Memory Used / GPU Memory Total
D3D 3D engine load (%)	LHM — GPU Core D3D 3D — shown when active
D3D Video Decode load (%)	LHM — GPU Core D3D Video Decode — None when idle

Supports NVIDIA and AMD discrete GPUs through LHM. Intel Arc GPUs should work but have not been tested.

RAM

Metric	Source
Used / free / total (GB)	sysinfo
Memory type (DDR–DDR5)	WMI Win32_PhysicalMemory.SMBIOSMemoryType
Speed (MT/s)	WMI Win32_PhysicalMemory.ConfiguredClockSpeed / Speed
Manufacturer & part number	WMI Win32_PhysicalMemory
DIMM temperature (°C)	LHM — SensorId prefix /memory/dimm/ — DDR5 and equipped DDR4

Storage

Metric	Source
Read throughput (MB/s)	LHM — aggregated across all drives
Write throughput (MB/s)	LHM — aggregated across all drives
Per-drive capacity and usage	sysinfo
Filesystem label	sysinfo
Drive temperature (°C)	LHM — highest real temperature sensor per drive (/nvme/, /hdd/, /ata/, /scsi/, /ssd/), matched to drive letter via WMI at startup

Motherboard

Metric	Source
Board name	WMI Win32_BaseBoard — manufacturer normalized (ASUSTeK → ASUS, Micro-Star → MSI, etc.)
Super I/O chip name	LHM — grandparent of the first /lpc/ sensor node
Fan speeds (RPM)	LHM — all active /lpc/ fan channels, sorted descending; 0-RPM channels hidden
Temperatures (°C)	LHM — all /lpc/ temperature sensors ≥ 5 °C
Voltage rails (V)	LHM — named /lpc/ voltage rails only; generic Voltage #N slots excluded

Works chip-agnostically across Nuvoton NCT, ITE IT87xx, Winbond W836xx, and other Super I/O controllers. Opt-in via Settings → Panels.

Network

Metric	Source
Upload speed (Mbps)	sysinfo — best active interface by traffic volume
Download speed (Mbps)	sysinfo — best active interface by traffic volume
Active interface name	sysinfo
Latency / ping (ms)	Windows ping command — default gateway, falls back to 1.1.1.1

Clock & System Identity

Panel	Metric	Source
Clock	Time, day, date	system time
System Identity	Hostname	hostname crate — truncated with ellipsis if too long
System Identity	CPU model string	sysinfo
System Identity	GPU model string	WMI Win32_VideoController, falls back to LHM tree
System Identity	System brand / logo	WMI Win32_ComputerSystem, Win32_ComputerSystemProduct, Win32_BaseBoard

Processes (opt-in)

Metric	Source
Top 8 processes by CPU usage	sysinfo
Per-process CPU % of total system	sysinfo
Per-process RAM usage (MB / GB)	sysinfo

GPU Apps (opt-in)

Metric	Source
Top processes by GPU engine utilisation (%)	Windows PDH \GPU Engine(*)\Utilization Percentage — the same counters Task Manager's per-process GPU column reads
Engine type(s) per process (3D, Decode, Encode, Compute, Copy, ...)	PDH GPU Engine instance name, sorted by that engine's own utilisation
Physical GPU attribution (which app runs on which adapter)	DXGI adapter enumeration matched by LUID — shown when more than one GPU is active

Vendor-neutral (NVIDIA / AMD / Intel) and reads without elevation — no sensor sidecar involved. See src-egui/fixtures/gpu-engine/README.md for the real-hardware regression corpus behind this panel's parsing.

Peripherals (opt-in)

Metric	Source
Battery level (%) per wireless device	Sensor service, read once a minute from the device: ROG headsets (Delta II, Pelta), and ROG keyboards and mice on the ROG Omni receiver
Charging state	Same
Connection (USB cable, Bluetooth, 2.4 GHz)	Windows HID path and product name — no device command; shown as a small icon

Colours follow the Battery panel's charge thresholds, and so does the low-battery notification (only while discharging, one per device). Hovering the tray icon shows a small card with each device's battery in the same colours. Commands come from ASUS Gear Link's device data, cross-checked with G-Helper; devices nobody has tested yet are read the same way. Bluetooth devices come later (#291).

Battery (opt-in)

Metric	Source
Charge percentage (0–100 %)	WMI Win32_Battery.EstimatedChargeRemaining
Charging / discharging state	WMI Win32_Battery.BatteryStatus
Estimated time remaining	WMI Win32_Battery.EstimatedRunTime
Live power draw (W)	WMI root\wmi BatteryStatus — charge/discharge rate in mW

Shows "NO BATTERY" gracefully on desktops.

---

Brand & Logo Detection

The header panel logo follows a three-step fallback chain:

1. Brand logo — if the system matches a known gaming/OEM brand below.
2. CPU architecture logo — Intel or AMD, derived from the CPU model string.
3. Nothing — the logo area is hidden silently.

Brand is detected from WMI fields Win32_ComputerSystem.Manufacturer, Win32_ComputerSystem.Model, Win32_ComputerSystemProduct.Name/Version, and Win32_BaseBoard.Manufacturer/Product. Product-line names (Alienware, Legion, OMEN, Predator, AORUS) take priority over generic OEM names.

Brand logos

Logo	Brand	Detected when
	ROG (ASUS)	Manufacturer contains ASUS, ROG, or Republic of Gamers
	MSI	Manufacturer contains MSI, Micro-Star, or Micro Star
	Alienware	System name / model contains Alienware
	Razer	Manufacturer contains Razer
	Lenovo Legion	System name / model contains Legion
	HP OMEN	System name / model contains OMEN
	Acer Predator	System name / model contains Predator
	AORUS	System name / model contains AORUS
	Gigabyte	Manufacturer contains Gigabyte

CPU architecture fallback

If no brand logo matches, the CPU model string is used to show an architecture badge instead.

Logo	Architecture	Detected when
	Intel	CPU model contains Intel, Core i, Xeon, or Arc
	AMD	CPU model contains AMD, Ryzen, Athlon, or EPYC

Other recognized brands (ASRock, Corsair, NZXT, Dell, Lenovo, HP, Acer) fall through to the CPU architecture fallback. Fully unknown systems show nothing.

---

Diagnostics Export

The Status dialog has a Collect Diagnostics… button that writes a ZIP file capturing everything needed to investigate hardware compatibility issues, missing sensor support, or unexpected behaviour. The ZIP is written only to the location you choose. No data is transmitted automatically; no credentials, browser history, or files outside the RIGStats data directory are included.

File in ZIP	Contents	Why it is needed
manifest.json	Collection timestamp, RIGStats version	Ties the report to a specific build
debug.log	Full debug log for the current session	Startup sequence, connectivity, settings save errors
debug-prev.log	Debug log from the previous session	Captures the log from a session that crashed
settings.json	Persisted user settings	Rules out configuration-specific issues
install.log	NSIS installer/upgrade log	Diagnose install failures (service registration, driver install)
sidecar-log.txt	Raw log written by the rigstats-sensor Windows Service	Most important file for adding sensor support — LibreHardwareMonitor startup and pipe-server activity
sensor-tree.txt	Full LHM hardware and sensor tree at last sidecar start	Find the exact identifier for a sensor not being picked up
control-capabilities.json	What the Control Center found: writable fan channels and their measured fans, power plans, CPU/GPU power-limit and Curve Optimizer support (or why not), lighting devices, the paired Hue Bridge and its rooms (no key), and why a device's last write failed	Diagnose a Control Center tab that is missing or limited on this hardware
profiles.json	The service's saved profiles (power plan, fan curves, CPU/GPU limits, Curve Optimizer, lighting)	Reproduce a profile that misbehaves
lighting-devices.json	Lighting devices RIGStats drives (firmware, zones, raw config replies; for Hue rooms the bridge model and firmware) read-only replies from ASUS receivers and the mice paired to them, plus a scan of every USB HID device (no paths or serials)	Add support for a lighting device that isn't listed, or confirm one — see supported devices
hardware.json	WMI/CIM snapshot: OS, CPU, GPU, motherboard, RAM	Hardware identification and brand detection
sidecar-service.txt	Output of sc query + sc qc for rigstats-sensor	Diagnose sidecar autostart and service registration failures
environment.txt	USERNAME, APPDATA, COMPUTERNAME, PROCESSOR_ARCHITECTURE, etc.	Diagnose child/standard account issues where APPDATA may be redirected
event-log.txt	RIGStats crashes of the last 30 days and other recent errors from the Windows Application Event Log	Crashes a log can't record itself (e.g. inside a driver), with the stack
sysinfo.json	sysinfo snapshot: CPU, memory, disks, network, ping target	Verify what sysinfo sees on the machine
displays.json	Connected monitors (position, resolution) and which one was auto-selected for the current dashboard profile	Diagnose window placement and wrong-monitor issues
gpu-engine.txt	Raw Windows \GPU Engine(*) performance-counter instances (per-process, per physical GPU) plus the DXGI adapter list	Diagnose the GPU Apps panel — which app is attributed to which engine/GPU. Doubles as a ready-made regression fixture (src-egui/fixtures/gpu-engine/)

---

Documentation

Document	Contents
Architecture	Data flow, module reference, design decisions
Setup Guide	Full local dev setup, display profiles, installer build
Release & CI	Verify workflow, branch protection, release pipeline
Control Center	Hardware control design, protocols, live testing
Supported lighting devices	Every lighting device RIGStats drives, verified or from OpenRGB
Troubleshooting	Common issues, sensor diagnostics
Changelog	Full version history
Roadmap	Planned features and status

Contributing

Open a GitHub issue first, fork the repo, branch from main, verify your change in the running app, then open a pull request with a Conventional Commits message referencing the issue (Closes #N).

See CONTRIBUTING.md for the full guide — prerequisites, workflow, commit convention, code standards, and CI. CLAUDE.md holds the documentation-update requirements and the AI-agent workflow.

License

This project is licensed under the MIT License. See the LICENSE file for details.