OpenHardwareMonitor API i PowerShell: En komplett guide för att övervaka din hårdvara

Om du arbetar med Windows och PowerShell och är bekymrad över att övervaka temperaturen på din processor, grafikkort, fläktar eller till och med dina hårddiskars hälsa, har du förmodligen märkt att Windows inbyggda verktyg inte är tillräckliga. Att förstå det termiska ramverket i Windows är viktigt . WMI och CIM erbjuder viss information, men returnerar ofta tomma värden eller stöder helt enkelt inte sensorerna på ditt moderkort eller grafikkort.

Lyckligtvis har projekt som OpenHardwareMonitor och dess fork LibreHardwareMonitor öppnat dörren för mycket mer omfattande hårdvaruövervakning , som vi också kan utnyttja från PowerShell via dess API, WMI eller till och med en liten inbäddad webbserver. I den här artikeln ska vi se, i detalj, hur man utnyttjar dessa verktyg och vilka verkliga alternativ du har för att konfigurera ditt eget system med mätvärden, varningar och till och med dashboards med Grafana och InfluxDB.

Vad är OpenHardwareMonitor och vad kan det bidra med till PowerShell?

OpenHardwareMonitor är ett gratis program med öppen källkod som kan läsa en mängd olika hårdvarusensorer i Windows: temperaturer, fläkthastigheter, spänningar, belastning, frekvenser och mer. Forks från detta projekt, som LibreHardwareMonitor , har dykt upp, fortsätter sin utveckling och lägger till kompatibilitet med nyare hårdvara.

Enheterna som dessa verktyg kan läsa inkluderar moderkort, Intel- och AMD-processorer, RAM-moduler, NVIDIA- och AMD-grafikkort, hårddiskar/SSD-/NVMe-enheter, nätverkskort, nätaggregat och batterier för bärbara datorer . Detta gör att de kan läsa allt från en enkel stationär dator till arbetsstationer, hemmaservrar eller ultralätta bärbara datorer som en HUAWEI MateBook X Pro.

Förutom skrivbordsappen exponerar OpenHardwareMonitor och LibreHardwareMonitor sin information via ett .NET-bibliotek, WMI/CIM och ett fjärrwebbserverläge . Och det är här PowerShell kommer in i bilden: vi kan konsumera dessa data direkt från skript för att automatisera rapporter, varningar eller skicka mätvärden till en tidsseriedatabas som InfluxDB och visualisera dem med Grafana.

Vissa sensorer visas bara om du kör programmet med administratörsbehörighet . Detta påverkar särskilt känsligare avläsningar, till exempel vissa moderkortssensorer eller hårdvaruåtkomst som kräver specifika drivrutiner . Detsamma gäller om du använder .NET-biblioteket från PowerShell: du behöver ofta starta PowerShell-konsolen "Som administratör" för att hämta all data.

Metoder för att komma åt sensorer från PowerShell

Den goda nyheten är att informationen som visas av OpenHardwareMonitor/LibreHardwareMonitor kan läsas från PowerShell på flera olika sätt. Var och en har sina för- och nackdelar när det gäller prestanda, användarvänlighet och flexibilitet, men de delar alla samma mål: att få tillförlitliga mätvärden för hårdvarans temperatur, belastning och hälsa.

I det ekosystem som har utvecklats kring dessa projekt sticker tre huvudsakliga tillvägagångssätt ut: REST API (webbserverläge), WMI/CIM och .NET-biblioteket . Dessutom finns PowerShell-moduler som inkapslar en del av denna logik för att underlätta arbetsflödet, till exempel modulen som fungerar som en "agent" mellan LibreHardwareMonitor/OpenHardwareMonitor och en InfluxDB-databas.

Den här typen av moduler exponerar vanligtvis kommandon specifikt för att initiera hårdvarumonitorn eller mäta CPU-temperaturenTill exempel funktioner med namn som New-HardwareMonitor o Measure-CPUTemperatureUnder huven laddar de OpenHardwareMonitorLib- eller LibreHardwareMonitor-DLL:en, öppnar en instans av datorklassen, aktiverar de enheter du är intresserad av (CPU, GPU, RAM, diskar, etc.) och itererar genom listan över sensorer.

I vissa mer avancerade implementeringar är modulen inte begränsad till att läsa data, utan är också utformad för att konfigurera periodisk sändning av mätvärden till InfluxDB v1.x och generera färdiga dashboards i Grafana . Detta gör att du kan konfigurera ett ganska professionellt övervakningssystem utan att fastna i koden, perfekt för att centralisera data från flera team.

Använda WMI/CIM med OpenHardwareMonitor

En av styrkorna med OpenHardwareMonitor är dess WMI-integrationNär du aktiverar WMI-gränssnittsalternativet exponerar programmet ett specifikt namnutrymme, vanligtvis root\OpenHardwareMonitor, med två huvudklasser: Hardware y SensorFrån PowerShell kan detta enkelt frågas med hjälp av CIM eller klassisk WMI.

För att utforska denna information grafiskt är det mycket användbart att använda ett verktyg som WMI-utforskarenNär du ansluter till namnrymden root\OpenHardwareMonitor Och när du kör frågor på klasserna Hårdvara och Sensor ser du alla tillgängliga fält: identifierare, sensornamn, typer, enheter och aktuella värden. Vanligtvis är fälten Namn, sensortyp och värde Det här är de du kommer att använda mest för att filtrera och extrahera exakt det du behöver.

Med WMI kan du starta allmänna frågor som SELECT * FROM Sensor o SELECT * FROM Hardware För att få den kompletta listan, eller för att gå till något mer specifikt, till exempel för att begära CPU-kärntemperatur med en filtrerad fråga:
SELECT value FROM Sensor WHERE Name LIKE "%CPU Core%" AND SensorType = "Temperature"

I PowerShell översätts detta till kommandon baserade på Get-CimInstance eller Get-WmiObject, som riktar sig mot det namnområdet. När det gäller prestanda har ett flertal verkliga tester visat att det är ganska snabbt att fråga data via WMI/CIM från en redan körd OpenHardwareMonitor. Faktum är att skillnader på upp till fem gånger jämfört med att direkt komma åt .NET-biblioteket har observerats: cirka 200 ms kontra cirka 1 sekund , delvis på grund av att applikationsinstansen som redan samlar in och lagrar minimi- och maximivärden återanvänds.

Dataförbrukning via REST API och webbserverläge

Ett annat mycket intressant alternativ är att använda fjärrwebbserverläget som ingår i dessa projekt. När det aktiveras konfigurerar OpenHardwareMonitor eller LibreHardwareMonitor en liten HTTP-server på en konfigurerbar port, med valfritt autentiseringsstöd, som exponerar sensordata i ett format som är lämpligt för användning av andra program.

Att arbeta med den här webbservern från PowerShell är lika enkelt som att använda `Invoke-WebRequest` eller `Invoke-RestMethod` mot URL:en för värden som kör monitorn. Detta kan vara din lokala dator eller en fjärrserver i ditt nätverk. Om du har konfigurerat ett användarnamn och lösenord på monitorn, inkludera helt enkelt dessa inloggningsuppgifter i PowerShell-anropet.

Detta "agentläge" gör det möjligt för en enda central maskin att samla in data från flera värdar. Du kan till exempel köra LibreHardwareMonitor som en tjänst eller ett residentprogram på flera Windows-datorer och, från en administrativ maskin, starta regelbundna REST-förfrågningar för att konsolidera all data och spara den i en gemensam databas.

Om du behöver distribuera agenten på distans över flera maskiner är en vanlig strategi att använda WinRM-protokollet tillsammans med PowerShell Remoting. Med administratörsbehörighet på domänen och lämpliga grupprinciper kan du skapa ett skript som laddar ner den senaste versionen från GitHub, anpassar konfigurationsfilen och automatiskt startar processen på varje värd du vill övervaka.

Använda .NET-biblioteket direkt från PowerShell

När du behöver maximal kontroll eller vill integrera övervakning direkt i dina egna skript eller verktyg är det mest direkta sättet att ladda DLL OpenHardwareMonitorLib (eller LibreHardwareMonitor) i PowerShell med Add-TypeDet låter dig instansiera objektet OpenHardwareMonitor.Hardware.Computer och arbeta med det som om du vore i C#.

Det typiska PowerShell-arbetsflödet innebär att man laddar DLL-filen, skapar datorobjektet, aktiverar de hårdvarutyper du är intresserad av (CPU, GPU, RAM, diskar, moderkort, fläktstyrenhet), öppnar anslutningen och itererar genom samlingen av hårdvara och sensorer . Konceptuellt ser det ut ungefär så här:

Add-Type -Path "C:\Ruta\OpenHardwareMonitorLib.dll"
$comp = New-Object OpenHardwareMonitor.Hardware.Computer
$comp.CPUEnabled = $true
$comp.GPUEnabled = $true
$comp.RAMEnabled = $true
$comp.MainboardEnabled = $true
$comp.HDDEnabled = $true
$comp.FanControllerEnabled = $true
$comp.Open()
foreach ($hw in $comp.Hardware) {
$hw.Update()
if ($hw.HardwareType -eq "CPU") {
foreach ($sensor in $hw.Sensors) {
if ($sensor.SensorType -eq "Temperature") {
$sensor.Name, $sensor.Value, $sensor.Min, $sensor.Max
}
}
}
}
$comp.Close()

Denna metod ger åtkomst inte bara till den aktuella avläsningen, utan även till de minimi- och maximivärden som registrerats av den sensorn sedan biblioteket skapades. Detta är mycket användbart för att generera varningar när ett visst maximalt tröskelvärde uppnås eller för att sammanställa grundläggande statistik utan att behöva ett externt system.

Det är viktigt att notera att kombinationen av ett .NET-bibliotek och specifik hårdvara på vissa system kanske inte exponerar alla förväntade sensorer. Till exempel har det rapporterats att LibreHardwareMonitor läser processorn och vissa diskar utan problem, men OpenHardwareMonitor misslyckas med att returnera data för vissa diskar. I sådana situationer är det värt att testa båda projekten och, om du stöter på läsfel, öppna en problem- eller pull-förfrågan i motsvarande GitHub-arkiv för att förbättra kompatibiliteten.

PowerShell-moduler som en övervakningsagent

Istället för att skriva all kod från grunden kan du också använda färdiga PowerShell-moduler som integrerar LibreHardwareMonitor eller OpenHardwareMonitor som backend. Dessa moduler paketerar vanligtvis den nödvändiga DLL-filen och inkluderar en serie kommandon för att initiera monitorn, hämta sensorlistor och skicka data till databaser som InfluxDB.

Många av dessa moduler distribueras via NuGet -repositorier , vilket avsevärt förenklar installationen via PowerShell. Det är vanligt att författaren rekommenderar att de installeras "för alla användare" (till exempel via hanterare som Scoop eller genom att konfigurera modulen i en global katalog) så att de är tillgängliga även när skripten körs som en tjänst eller under systemkonton.

Ett typiskt exempel på ett modulmanifest inkluderar fält som Rotmodul, Modulversion, GUID, Författare, SkriptTillBearbetning, FunktionerTillExport, Fillista och PrivataData. Inom FileList OpenHardwareMonitorLib DLL, publika och privata skriptfiler och modulens huvudfil visas vanligtvis (.psm1Dessutom finns exporterade funktioner som New-HardwareMonitor för att instansiera monitorn och Measure-CPUTemperature för att direkt hämta CPU-temperaturen utan att behöva navigera manuellt genom alla sensorer.

Vissa moduler innehåller även hjälpskript för att skapa, starta, stoppa och ta bort Windows-tjänster som regelbundet skickar mätvärden till InfluxDB. Tanken är att spara ditt huvudskript för datasändning i en specifik sökväg, ange den sökvägen i skriptet för tjänstskapande och låta Windows hantera körningen av den tjänsten i bakgrunden, utan manuell åtgärd.

Denna modulära metod är idealisk för scenarier där du vill förvandla en enhet till en övervaknings-"agent" som samlar in data lokalt och exponerar den för fjärrinsamling, antingen via REST, WMI eller direkt från .NET-biblioteket. Dessutom förenklar den återanvändning av kod i olika automatiserings- eller observerbarhetsprojekt.

Konfigurera InfluxDB och Grafane för att visualisera mätvärden

När du har kontroll över datainsamlingen med OpenHardwareMonitor eller LibreHardwareMonitor och dina PowerShell-skript är nästa logiska steg att lagra dessa mätvärden i en tidsseriedatabas och visualisera dem i dashboards . En mycket populär kombination är InfluxDB v1.x för lagring och Grafana för visualisering.

Det första steget är att bestämma vilken server du ska installera InfluxDB på . Det kan vara en Windows-maskin, en Linux- distribution som Ubuntu (antingen nativt, under WSL eller i en virtuell maskin), eller till och med en Docker-container. Det viktiga är att den är tillgänglig från de maskiner som kommer att skicka mätvärdena och, helst, att den har tillräcklig stabilitet om du ska använda den i produktion.

På Windows kan du installera InfluxDB med hjälp av motsvarande installationsprogram eller via verktyg som Chocolatey. På Ubuntu innebär installationen vanligtvis att lägga till InfluxData-arkivet, installera paketet och starta tjänsten. I båda fallen kommer du att få en tjänst som lyssnar på den konfigurerade porten (8086 som standard i v1.x) där du kan ta emot data med hjälp av InfluxDB-protokollet.

Från PowerShell kommer ditt huvudsakliga send-skript att samla in avläsningar från CPU, GPU, diskar, fläktar etc., formatera dem i InfluxDB-linjeprotokollet (mätning, taggar, fält, tidsstämpel) och göra HTTP-begäran till write-slutpunkten . Du måste tidigare ha skapat databasen och, om du vill finjustera den, den lagringspolicy som avgör hur länge data lagras.

När du har bekräftat från InfluxDB-konsolen (eller från verktyg som InfluxDB Studio) att data tas emot är det dags att konfigurera Grafana. I Grafana registrerar du InfluxDB som en datakälla, väljer den databas du skapade och börjar konfigurera dashboards för att visualisera CPU-temperatur, GPU-belastning, fläktvarvtal, strömförbrukning och återstående livslängd för dina SSD-diskar.

Designa paneler i Grafana och filtrera mätvärden

När du har konfigurerat hela arbetsflödet (OpenHardwareMonitor/LibreHardwareMonitor → PowerShell → InfluxDB → Grafana) börjar den roliga delen: att skapa användbara och tydliga dashboards . En viktig punkt här är hur man märker data för att underlätta efterföljande filtrering och gruppering; tekniker som liknar de som används för att skapa diagnostiska dashboards med Perfmon.

En enkel och effektiv strategi är att använda taggar som ”host” och ”hardwareName ”, vilket gör att du kan gruppera efter maskin och komponent (till exempel ”PC-Room – Intel Core i5 10400 CPU”). Därifrån kan frågor i Grafana filtrera efter sensornamn (namnfältet kommer från OpenHardwareMonitor) och sensortyper (temperatur, belastning, effekt, fläkt, etc.).

För att göra visualiseringen mer användarvänlig rekommenderas att definiera datatypen som Celsius för temperaturer , konfigurera färger enligt tröskelvärden (grönt för normala temperaturer, gult för temperaturer som närmar sig gränsen och rött för farliga värden) och visa minimi-, maximi- och medelvärden för varje serie inom det valda tidsintervallet i förklaringarna. Det är också lämpligt att beakta den ideala omgivningstemperaturen och relativa luftfuktigheten för datorer när man tolkar avläsningar.

Om du övervakar mer än en värd är det mycket användbart att skapa dashboards som visar CPU-temperaturerna för flera maskiner sida vid sida , eller som jämför GPU-temperaturen på din huvuddator med din hemmaserver. På så sätt kan du snabbt identifiera maskiner som överhettas eller har dåligt luftflöde.

I några praktiska exempel har paneler skapats för att övervaka två maskiner parallellt, spåra deras temperatur och belastning över tid och vidta lämpliga åtgärder (rengöra fläktar, byta kylpasta, justera fläktkurvor etc.). Kombinerat med e-postmeddelanden eller Grafanas inbyggda varningar kan man bygga ett ganska robust övervakningssystem med relativt liten ansträngning.

Övervaka CPU- och GPU-temperatur med PowerShell

En mycket vanlig fråga är om det är möjligt att hämta CPU- och GPU-temperaturer från PowerShell med hjälp av endast WMI/CIM, som man gör i Linux med verktyg som lm_sensors. Det korta svaret är att på många system tillhandahåller inte Windows WMI denna information på ett tillförlitligt sätt, eller så visar den helt enkelt inte alls.

I mer än ett fall, när man försökt använda standard WMI-klasser för CPU-temperatur, har svaret varit att systemet "inte stöds" eller helt enkelt returnerar tomma värden. Därför används lösningar som OpenHardwareMonitor och LibreHardwareMonitor, vilka kommunicerar direkt med moderkortets sensorkretsar och andra komponenter för att få korrekta avläsningar.

Från PowerShell är ett av de mest direkta sätten att uppnå detta att ladda OpenHardwareMonitorLib-biblioteket eller dess motsvarighet från LibreHardwareMonitor och iterera genom dess sensorer som beskrivits tidigare. Detta låter dig filtrera sensorer efter typ (t.ex. "Temperatur") och efter namn (t.ex. "CPU Core", "GPU Core", "GPU Memory"), och bygga anpassade funktioner som bara returnerar den data du behöver.

En ytterligare fördel är att den här metoden ger dig tillgång inte bara till temperaturen, utan även till andra parametrar som strömförbrukning, belastning per kärna, frekvens, fläktvarvtal och återstående livslängd för dina SSD-diskar . Genom att kombinera flera sensorer kan du få en mycket omfattande bild av ditt systems termiska och prestandastatus.

Övervakningsmallar: CPU, fläktar, SSD och mer

Med tiden har många användare skapat övervakningsmallar och exempel baserade på OpenHardwareMonitor som täcker de vanligaste scenarierna. En av de mest utbredda konfigurationerna är utformad för att övervaka CPU-temperatur, processorns strömförbrukning, styrning av olika systemfläktar (systemfläkt 1-5) och livslängden för SSD-diskar.

Dessa mallar börjar vanligtvis med ett referenssystem, till exempel en dator med en Intel i3-processor, ett generiskt moderkort och en SSD , och definierar nödvändiga WMI/PowerShell-frågor eller filter för att hitta de specifika sensorer som motsvarar den hårdvaran. Därifrån är mindre justeringar nästan alltid nödvändiga för varje system, eftersom sensornamn och hårdvarulayouter varierar beroende på tillverkare och modell.

I den här typen av guide inkluderar de grundläggande kraven att OpenHardwareMonitor är installerat och igång, tillsammans med WMI Explorer för att inspektera namnrymden root\OpenHardwareMonitor . Med hjälp av WMI Explorer kan du hitta de exakta sensornamnen som "CPU Core 1", "CPU Package", "System Fan 3", "SSD Life Remaining" etc., och sedan använda samma namn i frågor du gör från PowerShell eller ditt övervakningssystem.

Det är också vanligt att hitta specifik OpenHardwareMonitor-dokumentation inkluderad, till exempel PDF-filer som beskriver WMI-schemat, klasserna Hardware och Sensor, och exempelfrågor . Detta förenklar avsevärt anpassningen av mallarna till din miljö, vilket förhindrar att du behöver gissa eller använda trial and error med sensornamn.

En betydande begränsning med den klassiska implementeringen är att OpenHardwareMonitor körs som ett program, inte som en Windows-tjänst . Detta kräver att användaren aktiverar alternativ som "Kör vid Windows-start" i programmenyn för att det ska startas vid systemstart. För mer avancerad användning skapar många administratörer schemalagda uppgifter eller anpassade tjänster som startar hårdvaruövervakaren automatiskt, även om instabilitet har rapporterats om intensiv användning tvingas fram under många dagar i följd.

Säkerhetsaspekter, behörigheter och antivirusprogram

När vi pratar om verktyg som har åtkomst till lågnivåsensorer för hårdvara är det normalt att vissa antivirus- eller säkerhetssystem blir nervösa . Även om de officiella versionerna av OpenHardwareMonitor och LibreHardwareMonitor är öppen källkod och generellt säkra, kan maskininlärningsbaserade detekteringssystem flagga nya versioner som misstänkta under de första dagarna.

I det specifika fallet av Windows DefenderOm du är säker på att du laddade ner binärfilen från den officiella källan kan du skapa en undantag för mappen som innehåller programmetTill exempel, med ett enkelt PowerShell-kommando som körs som administratör:
Add-MpPreference -ExclusionPath "C:\ruta\carpeta\OpenHardwareMonitor"

Det är också viktigt att komma ihåg att många sensoravläsningar kräver förhöjda privilegierOm du utvecklar din egen C#-applikation som integrerar biblioteket rekommenderas det att lägga till en app.manifest med utförandenivån requireAdministratorså att systemet begär behörigheter vid behov. När det gäller PowerShell är lösningen att köra konsolen eller skriptet med "Kör som administratör".

Slutligen, ur ett juridiskt perspektiv, distribueras projekt som OpenHardwareMonitor under GNU GPL v3-licensen . Det betyder att du kan använda, modifiera och omdistribuera dem, men alla modifieringar du publicerar måste också licensieras under GPL, och du måste följa de etablerade villkoren, inklusive avsaknaden av garantier för funktionalitet eller lämplighet för ett visst ändamål.

Med hela detta ekosystem av bibliotek, WMI, REST, PowerShell-moduler, InfluxDB och Grafana har du alla nödvändiga komponenter för att bygga ett omfattande system för hårdvaruövervakning i Windows. Allt du behöver göra är att kombinera verktygen effektivt: använd OpenHardwareMonitor eller LibreHardwareMonitor som en pålitlig källa till sensorer, utnyttja PowerShell för att automatisera datainsamling och filtrering, och dra nytta av databaser och instrumentpaneler för att hålla reda på temperaturer, belastningar och din utrustnings allmänna hälsa över tid.