CS2RGB — Counter-Strike × OpenRGB Lighting
A Python service that taps CS2's Game State Integration API and drives OpenRGB directly — lighting reacts to health, flash/smoke/burn status, game phase and round events (bomb, kills, round wins) with secure secret-key authentication and full event logging.
What was happening.
Bridging a game's internal state to physical RGB hardware through Counter-Strike 2's Game State Integration API and a local OpenRGB client — no injection, no overlays, no touching the game process. Just the game publishing its state and hardware reacting to it.
What needed to change.
- PC lighting is static — a machine with a full RGB setup runs the same light show whether you're winning, burning, or dead.
- Games expose no lighting hooks; most reactive setups rely on heuristics, screen capture or hooking the game process — fragile and invasive.
- CS2 already broadcasts rich match state, but nothing was mapping it to hardware.
How it was done.
CS2 publishes player, round, map and provider state over HTTP to a local listener using a signed Game State Integration config — every update arrives as structured JSON, so the game is never touched or injected into.
A local HTTP server validates requests against a secret key from the GSI config before any state is trusted, blocking spoofed or stale event streams.
openrgb-python talks to the running OpenRGB daemon, so lighting changes work across manufacturers and devices without vendor-specific SDKs.
Health tiers (green 80–100, yellow 50–79, orange 20–49, red 1–19), environment effects (white flash, orange burn flicker, grey smoke), game phase (loading, searching, main menu) and round events (bomb planted/exploded, kill confirmed, round wins) each resolve to a deterministic colour and effect.
Every game-state payload and system event is written to a structured log for debugging mappings and tracing missed events.
The numbers that came out.
Health, environment, game phase, round events.
Green, yellow, orange and red based on HP.
Only GSI data flows — no hooks, no injection.
Where it landed.
- A working pipeline from in-game event to physical RGB change, driven entirely by the game's own state feed.
- Reactive ambience for health, status effects and round moments — with zero modification of the game.
- A small, dependency-light pattern (Python + local HTTP + GSI + OpenRGB) reusable for any game that publishes GSI state.
More case studies.
Full-Stack School ERP
Designed and shipped a full-stack ERP end-to-end — from requirements through deployment — consolidating student records, attendance, finance and communication, with notification, messaging and authentication capabilities serving the whole institution.
Read case studyAtlas — Distributed Infrastructure Engine
Atlas discovers and models infrastructure as a graph, schedules workloads, replicates state through a from-scratch Raft layer, injects controlled failures, correlates them into incidents and produces advisory AI analysis — running entirely over an in-memory event bus on a single machine, with real-time visualization and algorithmic transparency.
Read case studyNEXUS — Autonomous Homelab SRE
An evidence-first autonomous SRE agent built around four hard rules — evidence over vibes, allowlisted typed tools, approval enforced outside the model, and explainable reasoning. Investigates incidents the way a careful operator would, verified live against PostgreSQL and Redis.
Read case studyYour situation probably looks different — but the method doesn't.
Understand the work, decide the approach, deliver and measure. A free conversation establishes whether it applies to your problem.
or email joseph.gitau.c@gmail.com