Das Problem
Meine beiden Stream Decks zeigen seit Jahren Hardwarewerte an: CPU-Last, RAM, GPU, die Temperaturen meiner Laufwerke und beim Zocken die FPS. Die Daten kamen aus HWiNFO. Das hat auch funktioniert, meistens.
Zwei Dinge haben mich dabei genervt. Erstens begrenzt die kostenlose Version den Shared Memory auf zwölf Stunden. Danach sind die Werte weg. Mein Workaround war ein geplanter Neustart per .bat-Datei und der war ungefähr so zuverlässig, wie es klingt.
Zweitens und das war der eigentliche Grund: Bestimmte Sensorabfragen haben bei mir DPC-Latenzspitzen verursacht. Mikroruckler im Spiel, Knacken im Audio. Der Hauptverdächtige war die SMART-Abfrage auf meiner Intel-NVMe. Wer schon einmal mit LatencyMon nach einem Knacken gesucht hat, weiß, wie viel Spaß das macht.
Die Lösung
Also habe ich mir ein eigenes Tool gebaut: DeckSense. Es besteht aus zwei getrennten Teilen. Ein Sensordienst liest die Werte und stellt sie ausschließlich auf 127.0.0.1 bereit und ein Plugin für das Stream Deck zeichnet die Tasten selbst. Stürzt das eine ab, reißt es das andere nicht mit.
Die oberste Regel von Anfang an: Das Tool darf keine Latenzprobleme verursachen. Lieber ein Wert weniger als ein Ruckler. Auf meinem Rechner laufen Onlinespiele, deshalb kommt es außerdem ohne Kernel-Treiber aus. Bis auf eine Ausnahme, dazu gleich mehr.
Und ja, ich bin kein Entwickler. Ich habe das Ganze per Vibe Coding mit KI-Unterstützung gebaut, mit viel Geld und viel Cola Doppel-Zero. Das steht auch so in der README, weil es bei einem Programm, das Admin-Rechte will und SMART-Daten liest, eine wichtige Information ist. Die Tasten sind übrigens in Violett gehalten, wie meine individuell eingestellte Ambientebeleuchtung im Auto. Die Lesbarkeit ging trotzdem vor: Der Wert steht weiß da und wird bei Hitze gelb oder rot.
Das Ergebnis mit allen acht Laufwerken und 21 Sensoren:
| Messwert | Ergebnis |
|---|---|
| CPU-Last des Dienstes | 0,1 Prozent, verteilt auf 32 Kerne |
| Speicher | 49 MB, bleibt flach |
| Speichertreiber (DPC) | 4 bis 54 Mikrosekunden |
| Grafiktreiber im selben Lauf | rund 1000 Mikrosekunden |
Die Intel-NVMe, die früher den Ärger gemacht hat, wird jetzt alle 15 Sekunden einmal abgefragt und LatencyMon sieht dabei nichts Auffälliges. Ein einziger Wert ist gestiegen: CLASSPNP von 64 auf 259 Mikrosekunden. Das habe ich bewusst zurückgestellt, weil es immer noch ein Viertel vom Grafiktreiber ist. Sollte es je wieder knacken, schaue ich dort zuerst nach.
Was schiefging
Der Speicher: Mein Ziel waren unter 100 MB. Der Dienst wuchs aber stetig auf 139 MB. Mein Verdacht fiel auf die HTTP-Schnittstelle und der war nur zum Teil richtig. Gemessen hat sich gezeigt, dass die .NET-Speicherverwaltung in 17 Minuten kein einziges Mal aufgeräumt hatte. Bei so viel RAM im Rechner behält ein kleiner Dienst einfach alles. Drei Einstellungen, die das eigentlich beheben sollten, haben nichts gebracht und ich habe sie wieder ausgebaut. Geholfen hat nur, alle fünf Minuten selbst aufzuräumen. Das dauert höchstens 16 Millisekunden.
HWiNFO blieb im System: Ich habe es deinstalliert und danach nachgesehen. Neun Kernel-Treiber von HWiNFO liefen weiter, die ältesten von 2021, alle mit Startsystem, also bei jedem Boot geladen. Ich habe dafür ein kleines Skript gebaut, das sie anzeigt und auf Wunsch entfernt. Ohne ausdrücklichen Schalter ändert es nichts.
Die CPU-Temperatur: Sie ist der einzige Wert, der einen Kernel-Treiber braucht, bei meinem Ryzen heißt er PawnIO. Deshalb ist sie standardmäßig aus und im Setup gibt es einen Schalter, der vorher zeigt, was bekannt ist. FACEIT blockiert PawnIO, das Spiel startet dann nicht. Bei Riot Vanguard, Easy Anti-Cheat und BattlEye gibt es keine Berichte, weder dafür noch dagegen. Bei mir liegt PawnIO jetzt neben Vanguard. Ich bin also der ungeprüfte Fall. Ich melde mich, sobald ich mehr weiß.
Die E-Mail-Adresse: Beim ersten Veröffentlichen auf GitHub steckte meine echte Mailadresse im ersten Commit. Ich hatte alle Dateien auf persönliche Daten geprüft aber nicht die Git-Historie. Aufgefallen ist es erst beim Gegenlesen. Ein Force-Push reichte nicht, weil GitHub den alten Commit über seine Kennung noch eine Weile ausliefert. Am Ende habe ich das Repository gelöscht und neu angelegt, was schnell ging, weil noch nichts daran hing. 🥲
Was ich daraus mitnehme
- Messen statt vermuten. Mein Speicherverdacht war falsch. Erst die Zahlen haben gezeigt, woran es wirklich lag.
- Prüft auch die Historie. Bei Git zählen nicht nur die Dateien, sondern auch Autor, E-Mail-Adresse und alte Commits.
- Deinstalliert heißt nicht entfernt. Treiber bleiben gern zurück. Ein Blick in die Dienste lohnt sich.
- Ein fehlender Wert ist besser als ein falscher. Liefert ein Sensor nichts, zeigt die Taste
--statt 0 Grad. - Kernel-Treiber nur mit offenen Karten. Wer einen braucht, sollte vorher lesen, was bekannt ist und nicht erst danach.
- Auch die KI liefert Ballast. Sie hat mir 527 Gedankenstriche in Code, Doku und Oberfläche gesetzt, einen sogar in den Fenstertitel. Kein normaler Mensch weiß, wie man die auf der Tastatur tippt, also sind sie alle raus. 😅
Fazit
DeckSense läuft seit Version 1.0.0 bei mir produktiv, HWiNFO ist weg und die Tasten zeigen CPU, GPU, RAM, FPS, Frametime und alle acht Laufwerke.
Wer es ausprobieren will: Das Release gibt es auf GitHub unter https://github.com/cydato/DeckSense/releases/latest. Ihr braucht Windows 10 oder 11, die .NET-10-Runtime und die Stream-Deck-Software ab Version 7.1. Die Programme sind nicht signiert, SmartScreen wird also meckern. Die Prüfsummen stehen in der Release-Beschreibung und der Quellcode liegt offen im Repository.
Wenn bei euch etwas anders läuft oder ihr einen Fehler findet, schreibt es gern in die Kommentare oder macht ein Issue auf GitHub auf.
