One registry. Every sensor your machine has.

91 sensors. 16 kinds. 79 present, 12 absent. 10 of 10 backends loaded, zero failing. That is the actual output of running the CLI on an ordinary laptop, a Dell G3 3779, re-run right before this page was published.

Half of it is the obvious hardware: a camera, a microphone, a battery, Wi‑Fi and Bluetooth radios. The other half is the part most owners have never seen surfaced anywhere on this exact machine: a hinge‑angle sensor, an inclinometer, per‑core CPU load for all eight logical cores, live die temperatures, individual power rail voltages, package power draw in watts, and clock speeds. Seventy of the ninety‑one rows this machine can report arrive once sensortap's bundled Windows helper is running, through the same sensortap list call, no extra code.

captured 2026-09-16, re-run before publish

A camera adapter and a hardware-telemetry adapter have nothing in common as code: one talks to WinRT, the other spawns a bundled .NET helper and reads LibreHardwareMonitor over a local pipe. Each sensor family is one adapter, one file, registered through a normal Python entry point. The registry's job is narrow: load every adapter it finds, run discovery concurrently with a shared timeout so one slow backend can't stall the rest, de-duplicate and validate what comes back, and hand you one flat, typed list.

Every sensor, regardless of source, reports the same shape: a stable id, a kind from one closed vocabulary, a unit, a sampling rate, and whether it's currently reachable. That's what makes the CLI's one command work identically whether it's asking a webcam or a voltage rail.

hwmon_bridge

CPU/GPU/board temperature, fan, voltage, current, power, clock, load, via the bundled .NET helper. 70 sensors on this machine.

winrt_motion / winrt_orientation

Accelerometer, gyroscope, magnetometer, inclinometer, orientation sensor, hinge angle. All absent on this laptop; the class exists, the physical sensor does not.

win_battery / win_radio / win_touchpad

Charge percentage, capacity, charge rate; Wi‑Fi signal, Bluetooth presence; touch-pointer presence, contact count, capacitive image.

winrt_camera / winrt_audio / winrt_light

Camera and microphone, both consent-gated; ambient light.

A WinRT sensor class the operating system doesn't expose reports absent rather than guessing whether the physical chip exists underneath it. Reporting a wrong number is worse than reporting none. These are real: the class was queried, the answer was no.

accel.winrt.0 ABSENT

No physical accelerometer exposed by WinRT on this laptop. The reference adapter's synthetic accelerometer (accel.reference.0) is present instead, used for testing without hardware.

gyro.winrt.0 ABSENT

No gyroscope. Same WinRT class check as accel.winrt.0, same honest result.

magn.winrt.0 ABSENT

No magnetometer exposed by the OS on this hardware.

hinge-angle.winrt.0 ABSENT

Hinge-angle sensors ship on 2-in-1 and foldable devices. A Dell G3 3779 is neither.

incline.winrt.0 / orientation.winrt.0 ABSENT

Both are derived from the same motion sensors this machine doesn't have, so both report absent rather than a fabricated reading.

light.winrt.0 ABSENT

No ambient light sensor on this laptop's lid.

temp.win-temp / voltage.win-volt ABSENT

Battery-pack temperature and cell voltage aren't exposed by this laptop's battery controller over the Windows API this adapter uses.

touchpad.win-capimg.0 CONSENT REQUIRED

This sensor is present. Reading it needs an explicit consent grant, because it's the touchpad's raw capacitive image.

A CLI for looking, a Python API for building.

1. KEY 1

   Look

   $ pip install sensortap
   $ sensortap list
   $ sensortap read temp.reference.0
   $ sensortap stream microphone.reference.0 --consent microphone.reference.0

   Copy
2. KEY 2

   Build

   import sensortap
   
   # enumerate, opens nothing, prompts nothing
   sensors = sensortap.list_sensors()
   
   # read a sensor that needs no consent
   reading = sensortap.read("accel.winrt.0")
   
   # a privacy-sensitive sensor needs an explicit grant
   with sensortap.consent(["microphone.winrt.0"]):
       for block in sensortap.stream("microphone.winrt.0"):
           ...

   Copy
3. KEY 3

   Go deeper into the board

   Board temperatures, fan tachometers and extra voltage rails live behind motherboard, Super‑IO and embedded‑controller access, which is off by default:

   $ sensortap list --include-motherboard

   Copy

   It's opt‑in because that path can collide with a vendor tool or another monitoring app already holding the same EC registers, and an unrecognised Super‑IO chip can hand back plausible‑looking nonsense instead of an obvious failure. sensortap still never installs or starts a kernel driver, so on a machine with no Ring 0 driver present and no recognised Super‑IO chip this flag safely finds nothing extra, which is exactly what happens on the G3 3779 above. A desktop board with a standard Nuvoton or ITE chip usually has more to give. Sensors that appear only under this flag carry hwmon-mb in their id rather than hwmon.

4. KEY 4

   Contribute a sensor

   One sensor family is one adapter file, registered through a standard Python entry point, no edit to sensortap's own source. A reusable Conformance_Check ships in the package itself, so you can validate your adapter against the exact same rules sensortap's own nine Windows adapters were checked against, without needing sensortap's repository at all.

Every CLI command, flag and exit code; the whole Python API; every schema field and enum value; the sensor‑id grammar; the kind and unit vocabularies; the consent and streaming models; the complete error table; and the adapter interface for contributors.

The same reference is also one self‑contained markdown file with no external includes, so you can hand the whole thing to a model and ask questions about sensortap without it guessing at the API.

The docs have search, a section index, and copy buttons on every command. The second button puts the whole reference on your clipboard as markdown.

A young, one-person project. No adoption numbers exist to quote, so none are invented here.

Windows is where it's built out

Nine adapters ship: WinRT motion, orientation, light, camera, and microphone; battery; Wi‑Fi and Bluetooth; touchpad; and a bundled .NET helper bridging LibreHardwareMonitor for CPU, GPU, and board telemetry. All nine run against real hardware, none of them mocked.

Linux is designed, not built

The adapter interface and the registry are already platform-neutral. Nothing in the core imports anything Windows-specific. A Linux backend (sysfs hwmon, V4L2, ALSA, evdev) is the clearest open contribution.

The hardware-telemetry helper is optional weight

pip install sensortap alone stays small: motion, camera, battery, and radio sensors all work with zero extra downloads. Per-core CPU load, temperatures, and voltages need sensortap[hwmon], which pulls in a self-contained .NET helper of a few dozen megabytes. That weight is disclosed, not hidden in the base install.

219 tests

None require physical sensor hardware in the default run.