Read Temperatures with sensors and Tune the Display

The sensors command reads every hardware-monitoring chip Linux can see, and one flag quietly needs root while the rest are perfectly safe to run. You will finish with a reliable way to read those chips, capture their output as JSON, and make a small, reversible libsensors configuration change when the default labels are not useful.

Allow about 15 minutes. The examples use lm-sensors 3.6.0 with libsensors 3.6.0, which is the version installed on this machine. You need a shell and the lm-sensors package. Reading values is normally an ordinary user operation. Writing limits with sensors -s is different: it needs root and can change values in the monitoring chip, so treat that option as a hardware-setting operation, not another display flag.

1. Confirm the installed command

Start with read-only checks. This confirms which executable is being called and records the local version, since output and supported options can differ between releases:

$ command -v sensors
/usr/bin/sensors
$ sensors --version
sensors version 3.6.0 with libsensors version 3.6.0
$ dpkg-query -W -f='${Package} ${Version}\n' lm-sensors
lm-sensors 1:3.6.0-9build1

2. Read the normal human-friendly output

With no chip argument, sensors prints every detected chip. The first line identifies the chip, followed by its adapter and features:

$ sensors
pch_skylake-virtual-0
Adapter: Virtual device
temp1:        +36.0°C

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +53.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +41.0°C  (high = +80.0°C, crit = +100.0°C)

Your chips, temperatures and labels will differ. A value such as temp1 is a feature label chosen by the sensors configuration and driver, not a universal promise that every machine's first temperature is the same physical component.

The displayed high and critical values are limits reported by the chip when those sub-features exist. They are not a diagnosis of a fault. Compare them with the documentation for the machine and its hardware before deciding that a reading is unsafe.

3. Select a chip when you need less output

Pass the chip name shown at the start of a block to restrict the report. Quote a name if you use shell wildcard characters, because the wildcard in a chip description is understood by sensors, not by the shell:

$ sensors 'coretemp-isa-0000'
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +53.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +41.0°C  (high = +80.0°C, crit = +100.0°C)

Use the exact name printed on your host. A pattern such as 'coretemp-*' can be useful when the address changes, but keep the quotes: an unquoted * may be expanded against files in the current directory before sensors sees it.

4. Produce data for a script

Use JSON when another program needs the readings. The schema still reflects the chip and feature names, so consumers should tolerate features appearing or disappearing on different hardware:

$ sensors -j > sensors.json
$ test -s sensors.json && echo 'JSON report written'
JSON report written
$ head -n 12 sensors.json
{
   "pch_skylake-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 36.000
      }
   },

The redirection creates or truncates sensors.json. If the old report matters, choose a new filename first. A successful command and a non-empty file show that the report was produced; they do not guarantee that every chip has the same keys next time.

For configuration work, use raw output instead:

$ sensors -u
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:
  temp1_input: 53.000
  temp1_max: 80.000
  temp1_crit: 100.000

Raw names such as temp1_input and temp1_max are the names used by label, ignore, compute and set statements. The friendly label in the normal report is not necessarily the raw name.

5. Check Fahrenheit or adapter details without changing hardware

Use -f for Fahrenheit display. It changes presentation only; it does not alter the underlying sensor value or a limit:

$ sensors -f
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +141.8°F  (high = +176.0°F, crit = +212.0°F)

Use -A when adapter names add noise to a human report. Keep them in diagnostic output because they help distinguish otherwise similar chips. Use --bus-list when you have multiple chips with the same address on different I2C or SMBus adapters:

$ sensors --bus-list

No lines is a valid result on a system where that extra bus mapping is not needed. Bus numbers can change across reboots, so do not invent a bus line from an old number. If the command does produce lines, review them before adding them to a configuration file.

6. Make one display-only configuration change

The default configuration is normally /etc/sensors3.conf, falling back to /etc/sensors.conf; additional files in /etc/sensors.d are processed alphabetically. A small file in that directory is easier to review and remove than an edit to the system-wide file.

Before changing anything, identify the target chip and raw feature with sensors -u. Then create a file with a specific, local name and a label for a feature you have verified exists:

# sudo install -m 0644 /dev/null /etc/sensors.d/90-local-labels
# sudo sh -c 'printf "%s\n" "chip \"coretemp-*\"" "label temp1 Package" > /etc/sensors.d/90-local-labels'
$ sensors 'coretemp-isa-0000'
coretemp-isa-0000
Adapter: ISA adapter
Package:       +53.0°C  (high = +80.0°C, crit = +100.0°C)

The configuration affects how libsensors presents the feature. It does not rename the kernel attribute and it does not change the chip.

# sudo rm /etc/sensors.d/90-local-labels
$ sensors 'coretemp-isa-0000'

The removal is the undo operation for this example. Do not use ignore to hide a surprising value until you have established that the sensor is genuinely unused or bogus; hiding it can remove useful evidence during a fault.

7. Treat computed values and set statements as hardware policy

A compute line translates a raw reading to a real-world value, commonly for a voltage divider. The resistor values are board-specific. Do not paste an example formula into your configuration without confirming the circuit and the driver documentation.

A set line writes a writable limit or other sub-feature to the chip, but it is inert during ordinary sensors runs. It is evaluated only when sensors -s is used, and that command requires root:

$ sensors
# set statements are not executed here
# sudo sensors -s

Common traps

• No chips appear. Check that the kernel exposes hardware-monitoring devices and that the relevant driver is loaded. The sensors command cannot create a missing device.
• A chip appears but a feature is absent. That feature may not exist on this model or may be hidden by configuration.
• Labels look wrong. Compare the normal output with sensors -u and inspect files in /etc/sensors.d in alphabetical order; a later statement of the same kind can override an earlier one.
• Output changes after a reboot. Do not assume a bus number remains stable; use --bus-list and a named adapter binding where that distinction is needed.
• A monitoring application disagrees with the command. Check whether it reads libsensors or the raw files under /sys. Different applications can choose different labels and may not apply the same configuration; compare the raw feature names and values before changing limits.