# OhmGraphite reads hardware sensors and writes them into a time series store

> OhmGraphite is a Windows service that samples CPU, GPU, disk and motherboard sensors through LibreHardwareMonitor and pushes the values to Graphite, InfluxDB, Prometheus or Postgres. It suits a Windows operator who wants a Grafana dashboard of their own machine, and it needs administrator rights to see most sensors.

**nickbabcock/OhmGraphite** — Expose hardware sensor data to Graphite / InfluxDB / Prometheus / Postgres / Timescaledb

- Repository: https://github.com/nickbabcock/OhmGraphite
- Stars: 537 · Forks: 49
- Language: C#
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/nickbabcock-ohmgraphite

## The service polls sensors and writes them to a metric store

The mechanism is a poll loop with a configurable interval, and every store is reached the same way. OhmGraphite is a Windows service that exposes hardware sensor data to a metric store, so that you can build dashboards in Grafana or another time series UI. The configuration makes the loop explicit. The Graphite example polls the hardware every `5` seconds and sends the results to a graphite server listening on `localhost:2003`:

```xml
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="host" value="localhost" />
    <add key="port" value="2003" />
    <add key="interval" value="5" />
    <add key="tags" value="false" />
  </appSettings>
</configuration>
```

The hardware side is delegated. Hardware support is provided through LibreHardwareMonitor, and since the sensors detected are hardware dependent, the project points you at the LibreHardwareMonitor GUI to preview a subset of the metrics that will be exported. That is a practical design choice: you can see what will be collected before you wire it to a store, without writing a config for sensors that do not exist on your machine.

## What the dashboard actually shows

The sample dashboard in the project documentation enumerates the metric set, which is a better description of the scope than the word hardware. It captures power consumption of the CPU and GPU, CPU voltages and frequencies, a load breakdown on individual GPU components, CPU, GPU, disk and motherboard temperature readings, disk activity with space remaining and error monitoring, fan speed, and network consumption. The last two are the ones that show where the value is over time rather than at a glance. Fan speed tells you whether a machine is throttling, and disk activity plus space remaining plus error monitoring is a slow-burn failure signal that a single reading never reveals. A snapshot of a temperature tells you very little; a temperature series next to a fan speed series and a workload series tells you whether the cooling is adequate. That is the difference between a sensor reader and a metric exporter, and it is why the interval is configurable rather than a one-shot dump.

## Tags carry the sensor identity, and Graphite has them off by default

A sensor reading on its own is a number without a subject, so the tagging scheme does the real work. The tag types listed are sensor_type, with values like temperature, load, watts and rpms, hardware_type with cpu, gpu and hdd, host, app with the value ohm, hardware such as a specific GPU or CPU model, and raw_name for the sensor name itself, with CPU DRAM and CPU graphics given as examples. The same tag vocabulary is used for InfluxDB. The Graphite wire format changes depending on whether tags are on. Without tags the data format is `<name> <value> <timestamp>`, and with tags it becomes `<name>;tag1=a;tag2=b <value> <timestamp>`. Because tags are a newer Graphite feature, starting with Graphite v1.1.0, OhmGraphite has them disabled by default so that installations on Graphite 0.9 and 1.0 do not get a format they cannot read. The documentation also gives a blunt recommendation for anyone serious about tags: use an external database such as Postgres, MySQL or Redis, because sqlite will not cut it.

## InfluxDB needs a different key set, and the version 2 API a different one again

Graphite is the default export style, and switching to InfluxDB is a matter of changing the `type` and filling in the InfluxDB options:

```xml
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="type" value="influxdb" />
    <add key="interval" value="5" />
    <add key="influx_address" value="http://localhost:8086" />
    <add key="influx_db" value="mydb" />
<!--
    <add key="influx_user" value="myuser" />
    <add key="influx_password" value="mypassword" />
    <add key="interval" value="5" />
-->
  </appSettings>
</configuration>
```

Connecting to InfluxDB 2 requires a different configuration, with the `type` set to `influx2` and organisation, bucket and token keys replacing the database name and user and password:

```xml
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="type" value="influx2" />
    <add key="influx2_address" value="http://localhost:8086" />
    <add key="influx2_org" value="myorg" />
    <add key="influx2_bucket" value="mydb" />
    <add key="influx2_token" value="thisistheinfluxdbtoken" />
    <add key="interval" value="5" />
  </appSettings>
</configuration>
```

Note that the commented-out user and password in the first example also show a duplicate `interval` key inside the comment, which is a harmless artifact of a copy-paste but worth noticing since you will be editing this file. Both examples poll on the same `5` second interval, and the InfluxDB address points at the default port 8086.

## The Prometheus exporter inverts the direction of the data flow

This is the one exporter that behaves differently, and the difference is conceptual rather than cosmetic. The other three stores are pushed to. The Prometheus exporter instead creates a server that listens on `prometheus_port`, and the documentation says that instead of creating outbound data like the other exporters, the Prometheus config creates inbound data. The consequence for resource use is direct: OhmGraphite will only poll the hardware sensors when scraped by the Prometheus service. If nobody scrapes, no polling happens at all, which is the opposite of the fixed-interval push model used for Graphite, InfluxDB and Postgres. For a single machine that is a good trade, because the polling cost stops when the dashboard is not being watched. The visible documentation stops at the start of the Prometheus configuration block, so the exact key set for that exporter is not shown in what is available here, and the same is true of the TimescaleDB and Postgres section beyond the store list and the starter dashboard link. The store list at the top of the documentation does give the supported set, with a starter Grafana dashboard linked for each of Graphite, InfluxDB, Prometheus and Postgres or TimescaleDB.

## Secrets come from environment variables, with a service account caveat

The configuration file is XML and lives in the installation directory at `OhmGraphite.exe.config`, and any value in it can reference an environment variable using the `%NAME%` syntax, so secrets such as InfluxDB tokens and Postgres connection strings do not have to live in the file:

```xml
<add key="influx2_token" value="%INFLUX_TOKEN%" />
```

There is a Windows-specific wrinkle that is easy to get wrong. When running as a Windows service, the variable has to be set machine-wide, for example via `setx /M INFLUX_TOKEN ...` or through System Properties and Environment Variables, so that the service account inherits it, because per-user variables will not be visible to `LocalSystem`. If a reference is unset, it is left as the literal `%NAME%` placeholder, which is standard Windows behaviour, and means the service starts and then fails to authenticate rather than refusing to start. Config updates also require an app restart to take effect, which is worth knowing before you change an interval and wonder why nothing happened.

## Installation is a zip, an administrator shell and three commands

The installation sequence is spelled out and is worth following in order. The first step is PawnIO, which you need to install to allow OhmGraphite access to sensors like CPU temperature, wattage and frequency. The documentation is candid that OhmGraphite works without PawnIO but will emit limited data. Then you create a directory to be the home base for OhmGraphite, the example given being `C:\Apps\OhmGraphite`, download the latest zip and extract it into that directory, and update the app configuration located at `OhmGraphite.exe.config`. After that you open PowerShell or Command Prompt as Administrator and install the service with the `install` command. That command registers OhmGraphite as a Windows service, so you can manage it with your usual service commands or `services.msc`, and the `start` command brings it back up afterwards. If installing as administrator straight away feels uncomfortable, the documentation points out that OhmGraphite can be run interactively with `run` instead, while warning that running as a regular user will limit the number of sensors it can report on. Upgrades are a three-step loop: stop the service, unzip the latest release and copy `OhmGraphite.exe` into the installation directory, then start the service again. Uninstalling is stop, run the `uninstall` command, and remove the files.

## Where OhmGraphite does not fit

Three limits are visible in the documentation rather than inferred. The first is scale. OhmGraphite is a Windows service with a local configuration file on the machine it monitors, so a fleet of servers needs one installation each, and there is no central configuration or aggregation story in what is described. The second is that the metric set is hardware dependent, which the documentation says outright: since detected sensors are hardware dependent, you can use the LibreHardwareMonitor GUI to preview a subset of metrics that will be exported. A dashboard is therefore a per-machine artefact, and a heterogeneous estate means heterogeneous dashboards unless you design for the common subset. The third is the alternative the documentation itself recommends for the simplest case. If a GUI of hardware sensors is all that is desired, and the thought of running and configuring Grafana and a metric store sounds overwhelming, the project points at HWINFO instead. That is a fair comparison of effort, not of capability. The other alternative is to run the collection side yourself: LibreHardwareMonitor already exposes the same sensors through its own interface, so the difference in approach is that OhmGraphite adds the store exporters, the tag vocabulary and the Grafana dashboards, while a hand-rolled exporter gives you exactly the series you decide you want and none of the rest.

## Conclusion

OhmGraphite is worth installing on a Windows workstation or home server that you want to watch over time, because it turns the sensor readings that LibreHardwareMonitor already knows how to collect into a metric stream that any of four stores can hold and Grafana can graph, and because each store has a starter dashboard linked from the project. It is a poor fit if you need a fleet of machines monitored from one place, since the service is a per-host Windows service with a local configuration file, and a poor fit if you cannot run it as administrator, since the documentation says that running as a regular user limits the number of sensors it can report on. Before deploying it, install PawnIO, because without it the service works but emits limited data, and read the licence file, since the repository records a custom licence that GitHub cannot classify. The last push to the repository was on 2026-08-15, and the most recent release is v0.38.0 from 2026-06-03.

## FAQ

### What does OhmGraphite do and what does it collect?

It is a Windows service that exposes hardware sensor data to a metric store so you can build Grafana dashboards. The sample dashboard captures CPU and GPU power consumption, CPU voltages and frequencies, a load breakdown on individual GPU components, CPU, GPU, disk and motherboard temperatures, disk activity with space remaining and error monitoring, fan speed, and network consumption.

### How do I install OhmGraphite on Windows?

Install PawnIO first, since without it the service emits limited data. Extract the latest release zip into a directory, update OhmGraphite.exe.config, open an administrator PowerShell or Command Prompt, then run .\OhmGraphite.exe install and .\OhmGraphite.exe start. You can also run .\OhmGraphite.exe run interactively, though as a regular user it will report on fewer sensors.

### Which metric stores does OhmGraphite support?

Graphite, InfluxDB, Prometheus, and Postgres or TimescaleDB, with a starter Grafana dashboard linked for each. Graphite is the default export style, and connecting to InfluxDB 2 needs a separate set of configuration keys with the type set to influx2.

### How is the Prometheus exporter different from the other exporters in OhmGraphite?

The Prometheus exporter creates a server that listens on prometheus_port and produces inbound data rather than outbound, so OhmGraphite only polls the hardware sensors when scraped by the Prometheus service. The Graphite, InfluxDB and Postgres exporters push on a fixed interval instead.

## Sources

- [Issues](https://github.com/nickbabcock/OhmGraphite/issues)
- [nickbabcock/OhmGraphite on GitHub](https://github.com/nickbabcock/OhmGraphite)
- [README](https://github.com/nickbabcock/OhmGraphite/blob/master/README.md)
- [Releases](https://github.com/nickbabcock/OhmGraphite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nickbabcock-ohmgraphite