OpenHardwareMonitor API en PowerShell: guía completa para monitorizar tu hardware

Si trabajas con Windows y PowerShell y te preocupa tener bajo control la temperatura de la CPU, la GPU, los ventiladores o incluso la salud de tus discos, seguramente te habrás dado cuenta de que las herramientas nativas de Windows se quedan bastante cortas. Conviene entender el thermal framework en Windows. WMI y CIM ofrecen algo de información, pero muchas veces devuelven valores vacíos o directamente no soportan los sensores de tu placa base o tu tarjeta gráfica.

Por suerte, proyectos como OpenHardwareMonitor y su fork LibreHardwareMonitor han abierto la puerta a una monitorización de hardware mucho más completa, que además podemos aprovechar desde PowerShell a través de su API, de WMI o incluso de un pequeño servidor web integrado. En este artículo vamos a ver, con bastante detalle, cómo sacarles partido y qué opciones reales tienes para montar tu propio sistema de métricas, alertas e incluso paneles con Grafana e InfluxDB.

Qué es OpenHardwareMonitor y qué puede aportar en PowerShell

OpenHardwareMonitor es una aplicación gratuita y de código abierto capaz de leer una gran variedad de sensores de hardware en Windows: temperaturas, velocidades de ventiladores, voltajes, carga, frequencias y más. A partir de este proyecto han surgido forks como LibreHardwareMonitor, que continúan el desarrollo y añaden compatibilidad con hardware más reciente.

Entre los dispositivos que estas herramientas pueden leer se incluyen placas base, procesadores Intel y AMD, módulos de RAM, tarjetas gráficas NVIDIA y AMD, discos HDD/SSD/NVMe, tarjetas de red, fuentes de alimentación y baterías de portátiles. Eso permite cubrir desde un PC de sobremesa sencillo hasta estaciones de trabajo, servidores domésticos o portátiles ultra ligeros como un HUAWEI MateBook X Pro.

Además de la app de escritorio, OpenHardwareMonitor y LibreHardwareMonitor exponen su información mediante una librería .NET, WMI/CIM y un modo servidor web remoto. Y aquí es donde entra en juego PowerShell: podemos consumir esos datos directamente desde scripts para automatizar informes, alertas o envío de métricas a una base de datos de series temporales como InfluxDB y visualizarlas con Grafana.

Algunos sensores solo se muestran si ejecutas la aplicación con permisos de administrador. Esto afecta especialmente a lecturas más delicadas como ciertos sensores de placa base o accesos a hardware que requiere drivers específicos. Lo mismo se aplica si vas a usar la librería .NET desde PowerShell: muchas veces tendrás que lanzar la consola de PowerShell “Como administrador” para obtener todos los datos.

Métodos para acceder a los sensores desde PowerShell

La buena noticia es que la información que expone OpenHardwareMonitor/LibreHardwareMonitor se puede leer desde PowerShell de varias formas distintas. Cada una tiene sus pros y sus contras en rendimiento, facilidad y flexibilidad, pero todas comparten el mismo objetivo: obtener métricas fiables de temperatura, carga y estado del hardware.

En el ecosistema que se ha ido construyendo alrededor de estos proyectos destacan tres vías principales: REST API (modo servidor web), WMI/CIM y la librería .NET. Además, existen módulos de PowerShell que encapsulan parte de esta lógica para facilitar el trabajo, como el módulo que actúa como “agente” entre LibreHardwareMonitor/OpenHardwareMonitor y una base de datos InfluxDB.

Este tipo de módulos suelen exponer comandos específicos para inicializar el monitor de hardware o medir la temperatura de la CPU, por ejemplo funciones con nombres del estilo New-HardwareMonitor o Measure-CPUTemperature. Bajo el capó, lo que hacen es cargar la DLL de OpenHardwareMonitorLib o LibreHardwareMonitor, abrir una instancia de la clase Computer, habilitar los dispositivos que te interesan (CPU, GPU, RAM, discos, etc.) y recorrer la lista de sensores.

En algunas implementaciones más avanzadas, el módulo no se limita a leer datos, sino que también está preparado para configurar el envío periódico de métricas a InfluxDB v1.x y generar paneles listos para usar en Grafana. Esto permite montar un sistema de monitorización bastante profesional sin pelearse demasiado con el código, ideal para centralizar datos de varios equipos.

Uso de WMI/CIM con OpenHardwareMonitor

Uno de los puntos fuertes de OpenHardwareMonitor es su integración con WMI. Cuando activas la opción de interfaz WMI, la aplicación expone un espacio de nombres específico, típicamente root\OpenHardwareMonitor, con dos clases principales: Hardware y Sensor. Desde PowerShell, esto se puede consultar cómodamente con CIM o WMI clásico.

Para explorar esta información de manera gráfica, es muy útil usar una herramienta como WMI Explorer. Al conectarte al espacio de nombres root\OpenHardwareMonitor y ejecutar consultas sobre las clases Hardware y Sensor, verás todos los campos disponibles: identificadores, nombres de sensores, tipos, unidades y valores actuales. Normalmente, los campos Name, SensorType y Value son los que más vas a utilizar para filtrar y extraer justo lo que necesitas.

Con WMI puedes lanzar consultas generales como SELECT * FROM Sensor o SELECT * FROM Hardware para obtener el listado completo, o ir a algo más concreto, por ejemplo pedir la temperatura de los núcleos de la CPU con una consulta filtrada:
SELECT value FROM Sensor WHERE Name LIKE "%CPU Core%" AND SensorType = "Temperature"

En PowerShell, esto se traduce en comandos basados en Get-CimInstance o Get-WmiObject apuntando a ese espacio de nombres. A nivel de rendimiento, en muchas pruebas reales se ha comprobado que consultar datos por WMI/CIM a un OpenHardwareMonitor ya en ejecución es bastante rápido. De hecho, se han visto diferencias de hasta 5 veces respecto a acceder directamente a la librería .NET: unos 200 ms frente a alrededor de 1 segundo, en parte porque se reutiliza la instancia de la aplicación que ya está recogiendo y almacenando mínimos y máximos.

Consumo de datos vía REST API y modo servidor web

Otra opción muy interesante es utilizar el modo servidor web remoto que incluyen estos proyectos. Cuando lo activas, OpenHardwareMonitor o LibreHardwareMonitor levanta un pequeño servidor HTTP en un puerto configurable, con soporte opcional de autenticación, que expone la información de sensores en formato apto para ser consumido por otros programas.

Desde PowerShell, trabajar con este servidor web es tan sencillo como usar Invoke-WebRequest o Invoke-RestMethod contra la URL del host que está ejecutando el monitor. Puede ser el propio equipo local o un servidor remoto dentro de tu red. Si has configurado usuario y contraseña en el monitor, basta con incluir las credenciales en la llamada desde PowerShell.

Este modo “agente” permite que un único equipo central recoja datos de varios hosts. Por ejemplo, puedes tener LibreHardwareMonitor funcionando como servicio o aplicación residente en varios ordenadores con Windows y, desde una máquina de administración, lanzar peticiones REST periódicas para consolidar todos los datos y guardarlos en una base de datos común.

Si necesitas desplegar el agente de forma remota en muchas máquinas, una estrategia bastante habitual es utilizar el protocolo WinRM junto con PowerShell Remoting. Con permisos de administrador en el dominio y las directivas de grupo adecuadas, puedes crear un script que descargue la última versión desde GitHub, adapte el archivo de configuración y lance el proceso automáticamente en cada host que quieras monitorizar.

Uso directo de la librería .NET desde PowerShell

Cuando necesitas el máximo control o quieres integrar la monitorización directamente en tus propios scripts o herramientas, la vía más directa es cargar la DLL OpenHardwareMonitorLib (o la de LibreHardwareMonitor) en PowerShell con Add-Type. Eso te permite instanciar el objeto OpenHardwareMonitor.Hardware.Computer y trabajar con él como si estuvieras en C#.

El flujo típico en PowerShell consiste en cargar la DLL, crear el objeto Computer, habilitar los tipos de hardware que te interesan (CPU, GPU, RAM, discos, placa, controladora de ventiladores), abrir la conexión y recorrer la colección de hardware y sensores. Algo parecido a lo siguiente a nivel conceptual:

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

Con este enfoque es posible acceder no solo a la lectura actual, sino también a los valores mínimo y máximo que ha registrado ese sensor desde que se inició la librería. Eso viene muy bien para generar alertas cuando se alcanza cierto umbral máximo o para construir pequeñas estadísticas sin necesidad de un sistema externo.

Hay que tener en cuenta que, en algunos sistemas, la combinación de librería .NET y hardware concreto puede no exponer todos los sensores esperados. Por ejemplo, se han reportado casos en los que LibreHardwareMonitor permite leer CPU y algunos discos sin problemas, pero OpenHardwareMonitor no devuelve datos para ciertas unidades. En situaciones así, merece la pena probar ambos proyectos y, si detectas fallos de lectura, abrir un issue o pull request en el repositorio de GitHub correspondiente para ayudar a mejorar la compatibilidad.

Módulos de PowerShell como agente de monitorización

En lugar de escribir todo el código desde cero, también puedes apoyarte en módulos de PowerShell ya preparados que integran LibreHardwareMonitor u OpenHardwareMonitor como backend. Estos módulos suelen empaquetar la DLL necesaria e incluir una serie de comandos para inicializar el monitor, obtener listados de sensores y enviar datos a bases de datos como InfluxDB.

Muchos de estos módulos se distribuyen a través de repositorios de NuGet, lo que facilita bastante su instalación vía PowerShell. Es habitual que el autor recomiende instalarlos “para todos los usuarios” (por ejemplo, a través de gestores como Scoop o configurando el módulo en un directorio global) para que estén disponibles incluso cuando los scripts se ejecutan como servicio o bajo cuentas de sistema.

Un ejemplo típico de manifiesto de módulo incluye campos como RootModule, ModuleVersion, GUID, Author, ScriptsToProcess, FunctionsToExport, FileList y PrivateData. Dentro de FileList suelen aparecer la DLL de OpenHardwareMonitorLib, los ficheros de script públicos y privados, y el archivo principal del módulo (.psm1). Además, hay funciones exportadas como New-HardwareMonitor para instanciar el monitor y Measure-CPUTemperature para obtener directamente la temperatura de la CPU sin tener que navegar a mano por todos los sensores.

Algunos módulos también incluyen scripts auxiliares para crear, iniciar, detener y eliminar servicios de Windows que se encargan de enviar métricas a InfluxDB de forma periódica. La idea es guardar tu script principal de envío de datos en una ruta específica, indicarla en el script de creación de servicio y dejar que Windows se encargue de ejecutar ese servicio en segundo plano, sin intervención manual.

Este enfoque modular viene muy bien para escenarios en los que quieres convertir un equipo en un “agente” de monitorización que recoja datos localmente y los exponga para su recolección remota, bien sea vía REST, WMI o directamente desde la librería .NET. Además, simplifica la reutilización del código en distintos proyectos de automatización o de observabilidad.

Configurar InfluxDB y Grafana para visualizar las métricas

Una vez que tienes bajo control la captura de datos con OpenHardwareMonitor o LibreHardwareMonitor y tus scripts de PowerShell, el siguiente paso lógico es almacenar esas métricas en una base de datos de series temporales y visualizarlas en paneles. Un combo muy popular es InfluxDB v1.x para el almacenamiento y Grafana para la visualización.

El primer paso es decidir en qué servidor vas a instalar InfluxDB. Puede ser una máquina Windows, una distro Linux como Ubuntu (ya sea nativa, bajo WSL o en una máquina virtual) o incluso un contenedor Docker. Lo importante es que sea accesible desde los equipos que van a enviar las métricas y, a ser posible, que tenga cierta estabilidad si lo vas a usar en producción.

En Windows, puedes instalar InfluxDB mediante el instalador correspondiente o a través de herramientas como Chocolatey. En Ubuntu, la instalación suele pasar por añadir el repositorio de InfluxData, instalar el paquete e iniciar el servicio. En cualquiera de los casos, acabarás con un servicio escuchando en el puerto configurado (por defecto, el 8086 en v1.x) donde podrás recibir datos usando el protocolo de InfluxDB.

Desde PowerShell, tu script principal de envío se encargará de recopilar las lecturas de la CPU, GPU, discos, ventiladores, etc., formatearlas en el protocolo de línea de InfluxDB (measurement, tags, fields, timestamp) y hacer la petición HTTP al endpoint de escritura. Previamente tendrás que haber creado la base de datos y, si quieres afinar, la política de retención que determine cuánto tiempo se guardan los datos.

Una vez que confirmes desde la consola de InfluxDB (o desde herramientas como InfluxDB Studio) que están llegando datos, es el momento de configurar Grafana. En Grafana, registrarás InfluxDB como origen de datos, seleccionarás la base de datos que has creado y empezarás a montar paneles para visualizar la temperatura de la CPU, la carga de la GPU, el RPM de los ventiladores, el consumo de energía o la vida restante de tus SSD.

Diseño de paneles en Grafana y filtrado de métricas

Cuando tengas el flujo completo montado (OpenHardwareMonitor/LibreHardwareMonitor → PowerShell → InfluxDB → Grafana), llega el momento divertido: crear cuadros de mando útiles y claros. Un punto clave aquí es cómo etiquetar los datos para facilitar filtros y agrupaciones posteriores; técnicas similares a la creación de paneles de diagnóstico con Perfmon.

Una estrategia sencilla y efectiva es usar etiquetas como “host” y “hardwareName”, de modo que puedas agrupar por máquina y por componente (por ejemplo, “PC-Sala – CPU Intel Core i5 10400”). A partir de ahí, las consultas en Grafana pueden filtrar por nombres de sensor (campo Name procedente de OpenHardwareMonitor) y tipos de sensor (Temperature, Load, Power, Fan, etc.).

Para hacer la visualización más amigable, es recomendable definir el tipo de dato en grados Celsius para las temperaturas, configurar colores según umbrales (verde para temperaturas normales, amarillo para próximas al límite y rojo para valores peligrosos) y mostrar en las leyendas el mínimo, máximo y promedio de cada serie en el rango de tiempo seleccionado. También conviene tener en cuenta la temperatura ambiental y HR perfectas para ordenadores al interpretar lecturas.

Si estás monitorizando más de un host, es muy útil crear paneles que pongan lado a lado las temperaturas de CPU de varios equipos, o que comparen la temperatura de GPU de tu PC principal frente al servidor doméstico. De esta forma, puedes detectar rápidamente equipos que se calientan demasiado o que tienen un flujo de aire deficiente.

En algunos ejemplos prácticos se han creado paneles para vigilar dos máquinas en paralelo, seguir su temperatura y carga a lo largo del tiempo y actuar en consecuencia (limpieza de ventiladores, cambio de pasta térmica, ajuste de curva de ventilador, etc.). Combinado con notificaciones de correo o alertas nativas de Grafana, puedes construir un sistema de monitorización bastante serio con relativamente poco esfuerzo.

Monitorizar temperatura de CPU y GPU con PowerShell

Una duda muy habitual es si es posible obtener la temperatura de la CPU y la GPU desde PowerShell usando solo WMI/CIM, como se hace en Linux con herramientas tipo lm_sensors. La respuesta corta es que, en muchos sistemas, WMI nativo de Windows no ofrece esta información de forma fiable o directamente no la expone.

En más de un caso, al intentar usar clases estándar de WMI para la temperatura de la CPU, la respuesta ha sido que el sistema “no es compatible” o simplemente devuelve valores vacíos. Por eso, se recurre a soluciones como OpenHardwareMonitor y LibreHardwareMonitor, que hablan directamente con los chips sensores de la placa base y otros componentes para obtener lecturas precisas.

Desde PowerShell, una de las formas más directas de conseguirlo es cargar la librería OpenHardwareMonitorLib o la equivalente de LibreHardwareMonitor y recorrer sus sensores como hemos visto antes. De este modo, puedes filtrar sensores por tipo “Temperature” y por nombre “CPU Core”, “GPU Core”, “GPU Memory”, etc., y construir funciones personalizadas que devuelvan solo los datos que te interesan.

Una ventaja añadida es que esta aproximación te da acceso no solo a la temperatura, sino a otros parámetros como el consumo en vatios (Power), la carga de cada núcleo (Load), la frecuencia, las RPM de ventiladores o la vida restante de tus SSD. Combinando varios sensores, puedes tener una visión muy completa del estado térmico y de rendimiento de tu equipo.

Plantillas de monitorización: CPU, ventiladores, SSD y más

Con el tiempo, muchos usuarios han ido creando plantillas y ejemplos de monitorización basados en OpenHardwareMonitor que cubren los casos más habituales. Una de las configuraciones más extendidas está pensada para supervisar la temperatura de la CPU, el consumo de energía del procesador, el control de varios ventiladores del sistema (System Fan 1-5) y la vida útil de las unidades SSD.

Estas plantillas suelen partir de un sistema de referencia, por ejemplo un PC con procesador Intel i3, placa base genérica y SSD, y definen las consultas o filtros WMI / PowerShell necesarios para localizar los sensores concretos que corresponden a ese hardware. A partir de ahí, es casi obligatorio hacer pequeños ajustes en cada equipo, porque los nombres de los sensores y la disposición del hardware cambian según el fabricante y el modelo.

En este tipo de guías, los requisitos básicos incluyen tener OpenHardwareMonitor instalado y ejecutándose, junto a WMI Explorer para inspeccionar el espacio de nombres root\OpenHardwareMonitor. A través de WMI Explorer puedes localizar el nombre exacto del sensor de “CPU Core 1”, “CPU Package”, “System Fan 3”, “SSD Life Remaining”, etc., y después usar esos mismos nombres en las consultas que harás desde PowerShell o desde tu sistema de monitorización.

También es habitual que se adjunte documentación específica de OpenHardwareMonitor, como PDFs que describen el esquema WMI, las clases Hardware y Sensor, y ejemplos de consultas. Esto simplifica bastante la tarea de adaptar las plantillas a tu entorno, evitando tener que ir a ciegas o por prueba y error con los nombres de los sensores.

Una limitación relevante de la implementación clásica es que OpenHardwareMonitor se ejecuta como aplicación y no como servicio de Windows. Eso obliga a que el usuario habilite opciones como “Run on Windows Startup” en el menú de la aplicación para que se lance al inicio del sistema. Para usos más avanzados, muchos administradores acaban creando tareas programadas o servicios personalizados que inician el monitor de hardware automáticamente, aunque se han reportado casos de inestabilidad si se fuerza un uso intensivo durante muchos días seguidos.

Consideraciones de seguridad, permisos y antivirus

Cuando hablamos de herramientas que acceden a sensores de hardware a bajo nivel, es normal que algunos antivirus o sistemas de seguridad se pongan nerviosos. Aunque las versiones oficiales de OpenHardwareMonitor y LibreHardwareMonitor son de código abierto y suelen ser seguras, los sistemas de detección basados en aprendizaje automático pueden marcar nuevas versiones como sospechosas durante los primeros días.

En el caso concreto de Windows Defender, si estás seguro de que has descargado el binario desde la fuente oficial, puedes crear una exclusión para la carpeta que contiene la aplicación. Por ejemplo, con un simple comando en PowerShell ejecutado como administrador:
Add-MpPreference -ExclusionPath "C:\ruta\carpeta\OpenHardwareMonitor"

También es importante recordar que muchas lecturas de sensores requieren privilegios elevados. Si estás desarrollando una aplicación propia en C# que integra la librería, es recomendable añadir un app.manifest con el nivel de ejecución requireAdministrator, de manera que el sistema pida permisos cuando sea necesario. En el caso de PowerShell, la solución pasa por ejecutar la consola o el script con “Ejecutar como administrador”.

Por último, desde el punto de vista legal, proyectos como OpenHardwareMonitor se distribuyen bajo la licencia GNU GPL v3. Eso quiere decir que puedes utilizarlos, modificarlos y redistribuirlos, pero cualquier modificación que publiques deberá estar también bajo licencia GPL y tendrás que respetar los términos establecidos, incluyendo la ausencia de garantías de funcionamiento o idoneidad para un propósito concreto.

Con todo este ecosistema de librerías, WMI, REST, módulos de PowerShell, InfluxDB y Grafana, tienes a tu alcance las piezas necesarias para construir un sistema de monitorización de hardware muy completo en Windows. Solo hace falta combinar bien las herramientas: usar OpenHardwareMonitor o LibreHardwareMonitor como fuente fiable de sensores, apoyarte en PowerShell para automatizar la recogida y el filtrado de datos, y aprovechar bases de datos y paneles para mantener a raya temperaturas, cargas y salud de tus equipos a lo largo del tiempo.