rigstats

RIGStats (rig-dashboard)

RIGStats started as a replacement for ROG Armoury Crate: a lightweight, simple program that does what it should, does it well, and stays out of your way. No bloat, no accounts, no telemetry — just your hardware, under your control.

It’s a free hardware monitor and control center for Windows gaming PCs, built as a native Rust/egui app — no WebView.

• 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 — plus what’s playing, with its cover, from any player that tells Windows.
• Game overlay — a compact, click-through metric strip on top of your game, toggled with Ctrl+Alt+O (every shortcut can be changed or turned off under Settings → Shortcuts).
• Microphone mute — Ctrl+Alt+M or the tray row mutes/unmutes your microphone (the one Windows uses for calls, or one you pick in Settings) with a toast saying which way it went (optional).
• Control Center — profiles (Silent, Balanced, Gaming, Eco and your own) with fan curves, Windows power plans, AMD Ryzen, Radeon and GeForce power tuning, RGB lighting (Aura Sync, Dynamic Lighting, Philips Hue), and the settings of ROG headsets (sidetone, noise reduction) and ROG mice (DPI, polling rate, button bindings, energy — and which of the mouse’s own profiles each profile uses), run by a background service so it keeps working with the app closed.
• Profiles that follow you — switch by themselves while a program runs (Gaming while your game is open), and set your desktop too: a background picture per profile or per screen, and Wallpaper Engine wallpapers per screen, paused while you game or off in a profile of its own.
• Peripherals — battery level and charging of ROG wireless headsets, keyboards and mice, and the battery of any Bluetooth device Windows knows it for, 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.

How You Can Help

RIGStats’ sensor readings have been checked on seven machines — AMD and Intel desktops, an ASUS ROG Zephyrus G14 and a Razer Blade, Radeon and GeForce cards (see the sensor fixtures) — but the hardware control (fans, power limits, lighting) has mostly been tested on one PC: a Ryzen 7 9800X3D, a Radeon RX 9070 XT, an ASUS B650M board and ROG peripherals. What helps most is hardware it hasn’t met yet.

• Test it on your hardware — no programming needed. Install it, try the Control Center, and tell us what works and what doesn’t. Wanted in particular:

  • lighting devices marked “not yet verified” (#341) — the device report takes two minutes
  • a device RIGStats doesn’t support yet, whose protocol nobody has documented: a short USB recording of what its maker’s software sends is often the missing piece
  • ASUS laptops (#234), Intel CPUs (#209), NVIDIA graphics cards (#210), Bluetooth headsets and mice (#291)

  Attach a diagnostics ZIP (Status → Collect Diagnostics…) — it’s what turns “it doesn’t work” into a fix. It holds your hardware details and RIGStats’ logs and settings, including your computer and Windows user name (environment.txt); look through it before you share it, and remove anything you’d rather not.

• Ask, share, suggest — in Discussions: questions, ideas, or show your setup. Bugs go in issues.

• Write code — start with a good first issue or one marked help wanted. CONTRIBUTING.md gets you building in a few minutes; a change to the app’s UI needs only Rust.

• Buy me a coffee — RIGStats is free and open source, with no ads and no paid version. If it’s useful to you, a coffee helps cover the domain and code signing, and makes it easier to find time to keep improving it.

  

Contributions are welcome with or without AI tools.

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

The installed rigstats-sensor service runs from C:\Program Files\RIGStats and doesn’t block builds. A running dev sidecar (tools\dev-sidecar.ps1) holds the sidecar’s debug exe open — stop it with Ctrl+C before cargo xtask verify or cargo xtask build.

How it’s built

RIGStats is developed by one person with AI assistance (Anthropic’s Claude) — commits it helped with say so in their Co-Authored-By line. Nothing lands on main without passing the same bar:

• Tests and checks in CI: several hundred Rust tests and the sensor service’s .NET tests, clippy with zero warnings, a format check and a dependency audit (cargo xtask verify, required for every pull request), plus CodeQL.
• Live testing on real hardware for anything that touches it — fan control, power limits and lighting are tried on the developer’s own PC before they ship, and hardware writes follow strict safety rules inside the service (sensor-sidecar/Control/CLAUDE.md).
• Signed releases through a documented routine (docs/release.md): the installer is code-signed, and the app only installs an update whose checksum and signature check out.
• Release candidates, if you want them: Settings → General → Updates → “Release candidates too” offers each release candidate as an update before the release ships, then the release itself.

Architecture

The sensor service (rigstats-sensor.exe, .NET 10, LocalSystem Windows Service) reads the hardware through LibreHardwareMonitor and streams one JSON line per second over \\.\pipe\rigstats-sensors. LibreHardwareMonitor and the graphics-driver libraries run in worker processes of the service, so a driver that crashes costs a restarted worker, not the service. The Rust backend reads that pipe alongside sysinfo (CPU/RAM/disk/network) and WMI (static hardware metadata at startup), then sends a PollStats 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. Where it goes is set in Settings (pages: General, Display, Overlay, Notifications — what applies to the whole app); how it looks — accent colour, opacity, which panels in what order, floating panels or not and their size, the overlay’s metrics and the alert levels — belongs to each Control Center profile and switches with it.

• 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. On or off and the panels’ size belong to the Control Center profile (Control Center → Dashboard), so one profile can float while another shows the fixed dashboard — switch profile (tray, shortcut or app rule) to switch layout. Each profile also remembers where you placed its panels.
• Compact panels — every panel can be drawn compact: the key values only, no graphs or bars, in one common style (rings and columns of values; Processes and GPU Apps keep their top 3). The choice is per panel and per Control Center profile (Control Center → Dashboard, Full / Compact beside each panel), so they take less room on a small screen or as floating cards — a compact floating card is also narrower, so it can be scaled up for easier reading without growing as wide as a full one.

• Panel spacing — the space between panels, 0–30 px (6 by default), in portrait and between the cells of the landscape grid; floating panels you place yourself.
• 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. What it shows (metrics, layout) is part of the profile — set it under Control Center → Overlay; where it sits and how it looks is 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, Ctrl+Alt+P (the next one) or Ctrl+Alt+F1…F9 (the first … ninth, in the profile bar’s order — bind a macro key to one in your keyboard’s software; both can be changed under Settings → Shortcuts). 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
Dashboard, Overlay, Alerts	The profile’s own look: accent colour, opacity, panels and their order (each full or compact), floating panels and their size, the game overlay’s metrics, alert levels — previewed live	Any PC
Desktop	The Windows background picture (one per screen if you like), and Wallpaper Engine: as it is, chosen wallpapers per screen, paused, or off — with Start/Stop	Any PC; the Wallpaper Engine part when it is installed (troubleshooting)
App rules	Switch profile automatically while a program runs (e.g. Gaming while your game is open)	Any PC
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
Headset	Sidetone (hear your own voice), microphone noise reduction and the equalizer, kept in the headset — no GearLink needed. Each profile can switch the equalizer to a preset	ROG Delta II and Pelta, through their 2.4 GHz dongle — see supported devices
Keyboard	Which of the keyboard’s own onboard profiles (its lighting and keys) the profile uses — the keyboard switches with the profile, and Fn + that number on the keyboard switches to the profile. Also its energy settings — when it sleeps, what its lighting does when the battery is low and at which level — for every profile	ASUS keyboards RIGStats lights (Azoth, Falchion, Strix Scope …); verified on the ROG Azoth X through the ROG Omni receiver
Mouse	Which of the mouse’s own onboard profiles the profile uses, and that profile’s DPI levels, polling rate, button response, lift-off, angle snapping, acceleration, button bindings (on a drawing of the mouse) and energy — kept in the mouse	ROG mice on the common ROG protocol, wired, on their dongle or on the ROG Omni receiver (ROG Harpe Ace Aim Lab Edition verified, the rest unverified) — 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.
• Headsets and mice get only the commands GearLink itself sends; every change is read back from the 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 0.9.7-pre749 (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; Intel GPUs, which have none, the busiest D3D engine (as Task Manager)
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 (what it runs at), else Speed; a configured speed of half Speed is MHz from older firmware and is doubled (#506)
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)	Windows’ process list — bytes every process read, summed
Write throughput (MB/s)	Windows’ process list — bytes every process wrote, summed
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 Control Center → Dashboard (per profile).

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	sysinfo 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	Windows’ process list (NtQuerySystemInformation)
Per-process CPU % of total system	Windows’ process list
Per-process RAM usage (MB / GB)	Windows’ process list (working set)

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 (%) and charging per wireless device	Sensor service, every 20 s: from the device in its own protocol, or the level Windows shows for a Bluetooth device. Which devices: supported devices › Battery
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 connected and 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. A device that disconnects or stops answering is shown dimmed as “Not connected” at once, with its last level, for 10 minutes (Bluetooth mice drop their link when idle, so it doesn’t flicker in and out), then drops off.

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; ROG mice and headsets found, and their settings as read with the device’s raw replies — to confirm an unverified model
sensor-tree.txt	Full LHM hardware and sensor tree at last sidecar start	Find the exact identifier for a sensor not being picked up
sensor-tree-now.txt	The same tree, read when the ZIP was collected	See whether a sensor that was there at start has gone missing since
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, marking the ones RIGStats recognises — a ROG mouse’s settings channel included (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/)
driver-updates.txt	The graphics drivers installed now, every driver Windows Update installed (or failed to) in the last 60 days, and the last week’s display driver resets, graphics driver errors, sleep/wake and unexpected restarts	A driver Windows replaced behind your back — the cause of a crashing graphics driver (#370); what happened when a reading disappeared
dashboard-now.json	The last sample the sensor service sent the app, how old it is, and what the dashboard shows from it	Whether a missing value never came from the service or the app didn’t show it
gpu-worker.txt	Whether the graphics driver library crashed or hung this Windows session, with the driver files and the reason	Why the GPU power limits are off

---

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 devices	Every lighting device RIGStats drives and every device whose battery it shows, verified or not yet
Record a device’s USB traffic	How to record what a device’s own software sends, with Wireshark and USBPcap, so support for it can be built
Troubleshooting	Common problems and what to do, for users
Developer troubleshooting	Logs, the diagnostics ZIP’s files, crash causes, running from source
Changelog	Full version history
Roadmap	Planned features and status

Contributing

Small fixes — a typo, a label, a broken link — can go straight to a pull request. For anything bigger, open an issue first so we can agree on the approach, then fork the repo, branch from main, verify your change in the running app, and 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. The CLAUDE.md files are configuration for AI coding tools — a compact map of the code and its rules, handy to read, but not required.

License

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