OpenHardwareMonitor API in PowerShell: A complete guide to monitoring your hardware

If you work with Windows and PowerShell and are concerned about monitoring the temperature of your CPU, GPU, fans, or even the health of your hard drives, you've probably noticed that Windows' native tools fall short. Understanding the thermal framework in Windows is essential . WMI and CIM offer some information, but often return empty values ​​or simply don't support the sensors on your motherboard or graphics card.

Fortunately, projects like OpenHardwareMonitor and its fork LibreHardwareMonitor have opened the door to much more comprehensive hardware monitoring , which we can also leverage from PowerShell via its API, WMI, or even a small embedded web server. In this article, we'll see, in considerable detail, how to take advantage of these tools and what real options you have for setting up your own system of metrics, alerts, and even dashboards with Grafana and InfluxDB.

What is OpenHardwareMonitor and what can it contribute to PowerShell?

OpenHardwareMonitor is a free and open-source application capable of reading a wide variety of hardware sensors in Windows: temperatures, fan speeds, voltages, load, frequencies, and more. Forks of this project, such as LibreHardwareMonitor , have emerged, continuing its development and adding compatibility with newer hardware.

The devices these tools can read include motherboards, Intel and AMD processors, RAM modules, NVIDIA and AMD graphics cards, HDD/SSD/NVMe drives, network cards, power supplies, and laptop batteries . This allows them to cover everything from a simple desktop PC to workstations, home servers, or ultralight laptops like a HUAWEI MateBook X Pro.

In addition to the desktop app, OpenHardwareMonitor and LibreHardwareMonitor expose their information through a .NET library, WMI/CIM, and a remote web server mode . And this is where PowerShell comes in: we can consume this data directly from scripts to automate reports, alerts, or sending metrics to a time-series database like InfluxDB and visualizing them with Grafana.

Some sensors are only displayed if you run the application with administrator privileges . This especially affects more sensitive readings, such as certain motherboard sensors or hardware access that requires specific drivers . The same applies if you're using the .NET library from PowerShell: you'll often need to launch the PowerShell console "As administrator" to obtain all the data.

Methods to access sensors from PowerShell

The good news is that the information displayed by OpenHardwareMonitor/LibreHardwareMonitor can be read from PowerShell in several different ways. Each has its pros and cons in terms of performance, ease of use, and flexibility, but they all share the same goal: to obtain reliable metrics on hardware temperature, load, and health.

In the ecosystem that has developed around these projects, three main approaches stand out: REST API (web server mode), WMI/CIM, and the .NET library . Additionally, there are PowerShell modules that encapsulate some of this logic to facilitate workflow, such as the module that acts as an "agent" between LibreHardwareMonitor/OpenHardwareMonitor and an InfluxDB database.

These types of modules usually expose commands specific to initialize the hardware monitor or measure CPU temperatureFor example, functions with names like New-HardwareMonitor o Measure-CPUTemperatureUnder the hood, what they do is load the OpenHardwareMonitorLib or LibreHardwareMonitor DLL, open an instance of the Computer class, enable the devices you are interested in (CPU, GPU, RAM, disks, etc.) and iterate through the list of sensors.

In some more advanced implementations, the module is not limited to reading data, but is also designed to configure the periodic sending of metrics to InfluxDB v1.x and generate ready-to-use dashboards in Grafana . This allows you to set up a fairly professional monitoring system without getting bogged down in the code, ideal for centralizing data from multiple teams.

Using WMI/CIM with OpenHardwareMonitor

One of the strengths of OpenHardwareMonitor is its WMI integrationWhen you enable the WMI interface option, the application exposes a specific namespace, typically root\OpenHardwareMonitor, with two main classes: Hardware y SensorFrom PowerShell, this can be conveniently queried using CIM or classic WMI.

To explore this information graphically, it is very useful to use a tool like WMI ExplorerWhen you connect to the namespace root\OpenHardwareMonitor And when you run queries on the Hardware and Sensor classes, you'll see all the available fields: identifiers, sensor names, types, units, and current values. Typically, the fields Name, SensorType, and Value These are the ones you'll use most to filter and extract exactly what you need.

With WMI you can launch general queries such as SELECT * FROM Sensor o SELECT * FROM Hardware To get the complete list, or to go to something more specific, for example, to request the CPU core temperature with a filtered query:
SELECT value FROM Sensor WHERE Name LIKE "%CPU Core%" AND SensorType = "Temperature"

In PowerShell, this translates to commands based on Get-CimInstance or Get-WmiObject, targeting that namespace. In terms of performance, numerous real-world tests have shown that querying data via WMI/CIM from an already running OpenHardwareMonitor is quite fast. In fact, differences of up to five times compared to directly accessing the .NET library have been observed: around 200 ms versus about 1 second , partly because the application instance that is already collecting and storing minimum and maximum values ​​is reused.

Data consumption via REST API and web server mode

Another very interesting option is to use the remote web server mode included in these projects. When activated, OpenHardwareMonitor or LibreHardwareMonitor sets up a small HTTP server on a configurable port, with optional authentication support, which exposes sensor data in a format suitable for use by other programs.

Working with this web server from PowerShell is as simple as using `Invoke-WebRequest` or `Invoke-RestMethod` against the URL of the host running the monitor. This could be your local machine or a remote server on your network. If you've configured a username and password on the monitor, simply include those credentials in the PowerShell call.

This "agent" mode allows a single central machine to collect data from multiple hosts. For example, you can have LibreHardwareMonitor running as a service or resident application on several Windows computers and, from an administrative machine, launch periodic REST requests to consolidate all the data and save it to a common database.

If you need to deploy the agent remotely across multiple machines, a common strategy is to use the WinRM protocol in conjunction with PowerShell Remoting. With administrator privileges on the domain and the appropriate group policies, you can create a script that downloads the latest version from GitHub, adapts the configuration file, and automatically launches the process on each host you want to monitor.

Using the .NET library directly from PowerShell

When you need maximum control or want to integrate monitoring directly into your own scripts or tools, the most direct way is to load the DLL OpenHardwareMonitorLib (or LibreHardwareMonitor) in PowerShell with Add-TypeThat allows you to instantiate the object OpenHardwareMonitor.Hardware.Computer and work with it as if you were in C#.

The typical PowerShell workflow involves loading the DLL, creating the Computer object, enabling the hardware types you're interested in (CPU, GPU, RAM, disks, motherboard, fan controller), opening the connection, and iterating through the collection of hardware and sensors . Conceptually, it looks something like this:

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()

This approach allows access not only to the current reading, but also to the minimum and maximum values ​​recorded by that sensor since the library was created. This is very useful for generating alerts when a certain maximum threshold is reached or for compiling basic statistics without needing an external system.

It's important to note that, on some systems, the combination of a .NET library and specific hardware may not expose all expected sensors. For example, there have been reports of LibreHardwareMonitor reading the CPU and some disks without issue, but OpenHardwareMonitor failing to return data for certain drives . In such situations, it's worth testing both projects and, if you encounter read failures, opening an issue or pull request in the corresponding GitHub repository to help improve compatibility.

PowerShell modules as a monitoring agent

Instead of writing all the code from scratch, you can also use pre-built PowerShell modules that integrate LibreHardwareMonitor or OpenHardwareMonitor as a backend. These modules typically package the necessary DLL and include a series of commands to initialize the monitor, obtain sensor listings, and send data to databases like InfluxDB.

Many of these modules are distributed through NuGet repositories , which greatly simplifies their installation via PowerShell. It's common for the author to recommend installing them "for all users" (for example, through managers like Scoop or by configuring the module in a global directory) so they are available even when the scripts are run as a service or under system accounts.

A typical example of a module manifest includes fields such as RootModule, ModuleVersion, GUID, Author, ScriptsToProcess, FunctionsToExport, FileList and PrivateData. Within FileList The OpenHardwareMonitorLib DLL, public and private script files, and the module's main file usually appear (.psm1). In addition, there are exported functions such as New-HardwareMonitor to instantiate the monitor and Measure-CPUTemperature to directly obtain the CPU temperature without having to manually navigate through all the sensors.

Some modules also include helper scripts for creating, starting, stopping, and removing Windows services that periodically send metrics to InfluxDB. The idea is to save your main data sending script in a specific path, specify that path in the service creation script, and let Windows handle running that service in the background, without manual intervention.

This modular approach is ideal for scenarios where you want to turn a device into a monitoring "agent" that collects data locally and exposes it for remote collection, whether via REST, WMI, or directly from the .NET library. Furthermore, it simplifies code reuse across different automation or observability projects.

Configure InfluxDB and Grafane to visualize metrics

Once you have data capture under control with OpenHardwareMonitor or LibreHardwareMonitor and your PowerShell scripts, the next logical step is to store those metrics in a time-series database and visualize them in dashboards . A very popular combination is InfluxDB v1.x for storage and Grafana for visualization.

The first step is deciding which server you'll install InfluxDB on . This could be a Windows machine, a Linux distribution like Ubuntu (either natively, under WSL, or in a virtual machine), or even a Docker container. The important thing is that it's accessible from the machines that will be sending the metrics and, ideally, that it has sufficient stability if you're going to use it in production.

On Windows, you can install InfluxDB using the corresponding installer or through tools like Chocolatey. On Ubuntu, installation typically involves adding the InfluxData repository, installing the package, and starting the service. In either case, you'll end up with a service listening on the configured port (8086 by default in v1.x) where you can receive data using the InfluxDB protocol.

From PowerShell, your main send script will collect readings from the CPU, GPU, disks, fans, etc., format them in the InfluxDB line protocol (measurement, tags, fields, timestamp), and make the HTTP request to the write endpoint . You will need to have previously created the database and, if you want to fine-tune it, the retention policy that determines how long the data is stored.

Once you confirm from the InfluxDB console (or from tools like InfluxDB Studio) that data is being received, it's time to configure Grafana. In Grafana, you'll register InfluxDB as a data source, select the database you created, and start setting up dashboards to visualize CPU temperature, GPU load, fan RPM, power consumption, and the remaining lifespan of your SSDs.

Designing panels in Grafana and filtering metrics

Once you have the complete workflow set up (OpenHardwareMonitor/LibreHardwareMonitor → PowerShell → InfluxDB → Grafana), the fun part begins: creating useful and clear dashboards . A key point here is how to label the data to facilitate subsequent filtering and grouping; techniques similar to creating diagnostic dashboards with Perfmon.

A simple and effective strategy is to use tags like “host” and “hardwareName ,” allowing you to group by machine and component (for example, “PC-Room – Intel Core i5 10400 CPU”). From there, queries in Grafana can filter by sensor names (the Name field comes from OpenHardwareMonitor) and sensor types (Temperature, Load, Power, Fan, etc.).

To make the visualization more user-friendly, it's recommended to define the data type as Celsius for temperatures , configure colors according to thresholds (green for normal temperatures, yellow for temperatures approaching the limit, and red for dangerous values), and display the minimum, maximum, and average values ​​for each series within the selected time range in the legends. It's also advisable to consider the ideal ambient temperature and relative humidity for computers when interpreting readings.

If you're monitoring more than one host, it's very useful to create dashboards that show the CPU temperatures of several machines side-by-side , or that compare the GPU temperature of your main PC against your home server. This way, you can quickly identify machines that are overheating or have poor airflow.

In some practical examples, panels have been created to monitor two machines in parallel, track their temperature and load over time, and take appropriate action (cleaning fans, changing thermal paste, adjusting fan curves, etc.). Combined with email notifications or Grafana's native alerts, you can build a fairly robust monitoring system with relatively little effort.

Monitor CPU and GPU temperature with PowerShell

A very common question is whether it's possible to obtain CPU and GPU temperatures from PowerShell using only WMI/CIM, as is done in Linux with tools like lm_sensors . The short answer is that, on many systems, native Windows WMI doesn't reliably provide this information or simply doesn't display it at all.

In more than one case, when trying to use standard WMI classes for CPU temperature, the response has been that the system is "not supported" or simply returns empty values. Therefore, solutions like OpenHardwareMonitor and LibreHardwareMonitor are used, which communicate directly with the motherboard's sensor chips and other components to obtain accurate readings.

From PowerShell, one of the most direct ways to achieve this is to load the OpenHardwareMonitorLib library or its equivalent from LibreHardwareMonitor and iterate through its sensors as described earlier . This allows you to filter sensors by type (e.g., "Temperature") and by name (e.g., "CPU Core," "GPU Core," "GPU Memory"), and build custom functions that return only the data you need.

An added advantage is that this approach gives you access not only to temperature, but also to other parameters such as power consumption, load per core, frequency, fan RPM, and the remaining lifespan of your SSDs . By combining several sensors, you can gain a very comprehensive view of your system's thermal and performance status.

Monitoring templates: CPU, fans, SSD, and more

Over time , many users have created monitoring templates and examples based on OpenHardwareMonitor that cover the most common scenarios. One of the most widespread configurations is designed to monitor CPU temperature, processor power consumption, control of various system fans (System Fan 1-5), and the lifespan of SSD drives.

These templates typically start with a reference system, such as a PC with an Intel i3 processor, a generic motherboard, and an SSD , and define the necessary WMI/PowerShell queries or filters to locate the specific sensors corresponding to that hardware. From there, minor adjustments are almost always necessary for each system, as sensor names and hardware layouts vary depending on the manufacturer and model.

In this type of guide, the basic requirements include having OpenHardwareMonitor installed and running, along with WMI Explorer to inspect the root\OpenHardwareMonitor namespace . Using WMI Explorer, you can locate the exact sensor names such as “CPU Core 1”, “CPU Package”, “System Fan 3”, “SSD Life Remaining”, etc., and then use those same names in queries you make from PowerShell or your monitoring system.

It's also common to find specific OpenHardwareMonitor documentation included, such as PDFs describing the WMI schema, the Hardware and Sensor classes, and sample queries . This greatly simplifies adapting the templates to your environment, preventing you from having to guess or use trial and error with sensor names.

A significant limitation of the classic implementation is that OpenHardwareMonitor runs as an application, not as a Windows service . This requires the user to enable options such as "Run on Windows Startup" in the application's menu for it to launch at system startup. For more advanced uses, many administrators end up creating scheduled tasks or custom services that start the hardware monitor automatically, although instability has been reported if intensive use is forced over many consecutive days.

Security considerations, permissions, and antivirus

When we talk about tools that access low-level hardware sensors, it's normal for some antivirus or security systems to get nervous . Although the official versions of OpenHardwareMonitor and LibreHardwareMonitor are open source and generally safe, machine learning-based detection systems may flag new versions as suspicious during the first few days.

In the specific case of Windows DefenderIf you are sure you downloaded the binary from the official source, you can create a exclusion for the folder containing the applicationFor example, with a simple PowerShell command run as administrator:
Add-MpPreference -ExclusionPath "C:\ruta\carpeta\OpenHardwareMonitor"

It is also important to remember that many sensor readings require elevated privilegesIf you are developing your own C# application that integrates the library, it is recommended to add a app.manifest with the execution level requireAdministratorso that the system requests permissions when necessary. In the case of PowerShell, the solution is to run the console or script with "Run as administrator".

Finally, from a legal standpoint, projects like OpenHardwareMonitor are distributed under the GNU GPL v3 license . This means you can use, modify, and redistribute them, but any modifications you publish must also be licensed under the GPL, and you must comply with the established terms, including the lack of any warranty of functionality or fitness for a particular purpose.

With this entire ecosystem of libraries, WMI, REST, PowerShell modules, InfluxDB, and Grafana, you have all the necessary components to build a comprehensive hardware monitoring system on Windows. All you need to do is combine the tools effectively: use OpenHardwareMonitor or LibreHardwareMonitor as a reliable source of sensors, leverage PowerShell to automate data collection and filtering, and take advantage of databases and dashboards to keep track of temperatures, loads, and the overall health of your equipment over time.