sensors.conf(5) Linux User's Manual sensors.conf(5)
NAME
sensors.conf - libsensors configuration file
DESCRIPTION
sensors.conf describes how libsensors, and so all programs using it,
should translate the raw readings from the kernel modules to real-world
values.
SEMANTICS
On a given system, there may be one or more hardware monitoring chips.
Each chip may have several features. For example, the LM78 monitors 7
voltage inputs, 3 fans and one temperature. Feature names are standard-
ized. Typical feature names are in0, in1, in2... for voltage inputs,
fan1, fan2, fan3... for fans and temp1, temp2, temp3... for temperature
inputs.
Each feature may in turn have one or more sub-features, each represent-
ing an attribute of the feature: input value, low limit, high limit,
alarm, etc. Sub-feature names are standardized as well. For example, the
first voltage input (in0) would typically have sub-features in0_input
(measured value), in0_min (low limit), in0_max (high limit) and
in0_alarm (alarm flag). Which sub-features are actually present depend
on the exact chip type.
The sensors.conf configuration file will let you configure each chip,
feature and sub-feature in a way that makes sense for your system.
The rest of this section describes the meaning of each configuration
statement.
CHIP STATEMENT
A chip statement selects for which chips all following compute, label,
ignore and set statements are meant. A chip selection remains valid un-
til the next chip statement. Example:
chip "lm78-*" "lm79-*"
If a chip matches at least one of the chip descriptions, the following
configuration lines are examined for it, otherwise they are ignored.
A chip description is built from several elements, separated by dashes.
The first element is the chip type, the second element is the name of
the bus, and the third element is the hexadecimal address of the chip.
Such chip descriptions are printed by sensors(1) as the first line for
every chip.
The name of the bus is either isa, pci, virtual, spi-*, i2c-N or mdio
with N being a bus number as bound with a bus statement. This list isn't
necessarily exhaustive as support for other bus types may be added in
the future.
You may substitute the wildcard operator * for every element. Note how-
ever that it wouldn't make any sense to specify the address without the
bus type, so the address part is plain omitted when the bus type isn't
specified. Here is how you would express the following matches:
LM78 chip at address 0x2d on I2C bus 1 lm78-i2c-1-2d
LM78 chip at address 0x2d on any I2C bus lm78-i2c-*-2d
LM78 chip at address 0x290 on the ISA bus lm78-isa-0290
Any LM78 chip on I2C bus 1 lm78-i2c-1-*
Any LM78 on any I2C bus lm78-i2c-*-*
Any LM78 chip on the ISA bus lm78-isa-*
Any LM78 chip lm78-*
Any chip at address 0x2d on I2C bus 1 *-i2c-1-2d
Any chip at address 0x290 on the ISA bus *-isa-0290
If several chip statements match a specific chip, they are all consid-
ered.
LABEL STATEMENT
A label statement describes how a feature should be called. Features
without a label statement are just called by their feature name. Appli-
cations can use this to label the readings they present. Example:
label in3 "+5V"
The first argument is the feature name. The second argument is the fea-
ture description.
Note that you must use the raw feature name, which is not necessarily
the one displayed by "sensors" by default. Use "sensors -u" to see the
raw feature names. Same applies to all other statement types below.
IGNORE STATEMENT
An ignore statement is a hint that a specific feature should be ignored
– probably because it returns bogus values (for example, because a fan
or temperature sensor is not connected). Example:
ignore fan1
The only argument is the feature name. Please note that this does not
disable anything in the actual sensor chip; it simply hides the feature
in question from libsensors users.
COMPUTE STATEMENT
A compute statement describes how a feature's raw value should be trans-
lated to a real-world value, and how a real-world value should be trans-
lated back to a raw value again. This is most useful for voltage sen-
sors, because in general sensor chips have a limited range and voltages
outside this range must be divided (using resistors) before they can be
monitored. Example:
compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)
The example above expresses the fact that the voltage input is divided
using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the
VOLTAGE COMPUTATION DETAILS section below for details.
The first argument is the feature name. The second argument is an ex-
pression which specifies how a raw value must be translated to a
real-world value; `@' stands here for the raw value. This is the formula
which will be applied when reading values from the chip. The third argu-
ment is an expression that specifies how a real-world value should be
translated back to a raw value; `@' stands here for the real-world
value. This is the formula which will be applied when writing values to
the chip. The two formulas are obviously related, and are separated by a
comma.
A compute statement applies to all sub-features of the target feature
for which it makes sense. For example, the above example would affect
sub-features in3_min and in3_max (which are voltage values) but not
in3_alarm (which is a boolean flag.)
The following operators are supported in compute statements:
+ - * / ( ) ^ `
^x means exp(x) and `x means ln(x).
You may use the name of sub-features in these expressions; current read-
ings are substituted. You should be careful though to avoid circular
references.
If at any moment a translation between a raw and a real-world value is
called for, but no compute statement applies, a one-on-one translation
is used instead.
SET STATEMENT
A set statement is used to write a sub-feature value to the chip. Of
course not all sub-feature values can be set that way, in particular in-
put values and alarm flags can not. Valid sub-features are usually
min/max limits. Example:
set in3_min 5 * 0.95
set in3_max 5 * 1.05
The example above basically configures the chip to allow a 5% deviance
for the +5V power input.
The first argument is the feature name. The second argument is an ex-
pression which determines the written value. If there is an applying
compute statement, this value is fed to its third argument to translate
it to a raw value.
You may use the name of sub-features in these expressions; current read-
ings are substituted. You should be careful though to avoid circular
references.
Please note that set statements are only executed by sensors(1) when you
use the -s option. Typical graphical sensors applications do not care
about these statements at all.
BUS STATEMENT
A bus statement binds the description of an I2C or SMBus adapter to a
bus number. This makes it possible to refer to an adapter in the con-
figuration file, independent of the actual correspondence of bus numbers
and actual adapters (which may change from moment to moment). Example:
bus "i2c-0" "SMBus PIIX4 adapter at e800"
The first argument is the bus number. It is the literal text i2c-, fol-
lowed by a number. As there is a dash in this argument, it must always
be quoted.
The second argument is the adapter name, it must match exactly the
adapter name as it appears in /sys/class/i2c-adapter/i2c-*/name. It
should always be quoted as well as it will most certainly contain spaces
or dashes.
The bus statements may be scattered randomly throughout the configura-
tion file; there is no need to place the bus line before the place where
its binding is referred to. Still, as a matter of good style, we suggest
you place all bus statements together at the top of your configuration
file.
Running sensors --bus-list will generate these lines for you.
In the case where multiple configuration files are used, the scope of
each bus statement is the configuration file it was defined in. This
makes it possible to have bus statements in all configuration files
which will not unexpectedly interfere with each other.
STATEMENT ORDER
Statements can go in any order, however it is recommended to put `set
fanX_div' statements before `set fanX_min' statements, in case a driver
doesn't preserve the fanX_min setting when the fanX_div value is
changed. Even if the driver does, it's still better to put the state-
ments in this order to avoid accuracy loss.
VOLTAGE COMPUTATION DETAILS
Most voltage sensors in sensor chips have a range of 0 to 4.08 V. This
is generally sufficient for the +3.3 V and CPU supply voltages, so the
sensor chip reading is the actual voltage.
Other supply voltages must be scaled with an external resistor network.
The driver reports the value at the chip's pin (0 to 4.08 V), and the
userspace application must convert this raw value to an actual voltage.
The compute statements provide this facility.
Unfortunately the resistor values vary among motherboard types. There-
fore you have to figure out the correct resistor values for your own
motherboard.
For positive voltages (typically +5 V and +12 V), two resistors are
used, with the following formula:
R1 = R2 * (Vs/Vin - 1)
where:
R1 and R2 are the resistor values
Vs is the actual voltage being monitored
Vin is the voltage at the pin
This leads to the following compute formula:
compute inX @*((R1/R2)+1), @/(((R1/R2)+1)
Real-world formula for +5 V and +12 V would look like:
compute in3 @*((6.8/10)+1), @/((6.8/10)+1)
compute in4 @*((28/10)+1), @/((28/10)+1)
For negative voltages (typically -5 V and -12 V), two resistors are used
as well, but different boards use different strategies to bring the
voltage value into the 0 to 4.08 V range. Some use an inverting ampli-
fier, others use a positive reference voltage. This leads to different
computation formulas. Note that most users won't have to care because
most modern motherboards make little use of -12 V and no use of -5 V so
they do not bother monitoring these voltage inputs.
Real-world examples for the inverting amplifier case:
compute in5 -@*(240/60), -@/(240/60)
compute in6 -@*(100/60), -@/(100/60)
Real-world examples for the positive voltage reference case:
compute in5 @*(1+232/56) - 4.096*232/56, (@ + 4.096*232/56)/(1+232/56)
compute in6 @*(1+120/56) - 4.096*120/56, (@ + 4.096*120/56)/(1+120/56)
Many recent monitoring chips have a 0 to 2.04 V range, so scaling resis-
tors are even more needed, and resistor values are different.
There are also a few chips out there which have internal scaling resis-
tors, meaning that their value is known and doesn't change from one
motherboard to the next. For these chips, the driver usually handles the
scaling so it is transparent to the user and no compute statements are
needed.
TEMPERATURE CONFIGURATION
On top of the usual features, temperatures can have two specific
sub-features: temperature sensor type (tempX_type) and hysteresis values
(tempX_max_hyst, tempX_crit_hyst etc.).
THERMAL SENSOR TYPES
Available thermal sensor types:
1 PII/Celeron Diode
2 3904 transistor
3 thermal diode
4 thermistor
5 AMD AMDSI
6 Intel PECI
For example, to set temp1 to thermistor type, use:
set temp1_type 4
Only certain chips support thermal sensor type change, and even these
usually only support some of the types above. Please refer to the spe-
cific driver documentation to find out which types are supported by your
chip.
In theory, the BIOS should have configured the sensor types correctly,
so you shouldn't have to touch them, but sometimes it isn't the case.
THERMAL HYSTERESIS MECHANISM
Many monitoring chips do not handle the high and critical temperature
limits as simple limits. Instead, they have two values for each limit,
one which triggers an alarm when the temperature rises and another one
which clears the alarm when the temperature falls. The latter is typi-
cally a few degrees below the former. This mechanism is known as hys-
teresis.
The reason for implementing things that way is that high temperature
alarms typically trigger an action to attempt to cool the system down,
either by scaling down the CPU frequency, or by kicking in an extra fan.
This should normally let the temperature fall in a timely manner. If
this was clearing the alarm immediately, then the system would be back
to its original state where the temperature rises and the alarm would
immediately trigger again, causing an undesirable tight fan on, fan off
loop. The hysteresis mechanism ensures that the system is really cool
before the fan stops, so that it will not have to kick in again immedi-
ately.
So, in addition to tempX_max, many chips have a tempX_max_hyst sub-fea-
ture. Likewise, tempX_crit often comes with tempX_crit_hyst.
tempX_emerg_hyst, tempX_min_hyst and tempX_lcrit_hyst exist too but
aren't as common. Example:
set temp1_max 60
set temp1_max_hyst 56
The hysteresis mechanism can be disabled by giving both limits the same
value.
Note that it is strongly recommended to set the hysteresis value after
the limit value it relates to in the configuration file. Implementation
details on the hardware or driver side may cause unexpected results if
the hysteresis value is set first.
BEEPS
Some chips support alarms with beep warnings. When an alarm is triggered
you can be warned by a beeping signal through your computer speaker. On
top of per-feature beep flags, there is usually a master beep control
switch to enable or disable beeping globally. Enable beeping using:
set beep_enable 1
or disable it using:
set beep_enable 0
WHICH STATEMENT APPLIES
If more than one statement of the same kind applies at a certain moment,
the last one in the configuration file is used. So usually, you should
put more general chip statements at the top, so you can overrule them
below.
SYNTAX
Comments are introduced by hash marks. A comment continues to the end of
the line. Empty lines, and lines containing only whitespace or comments
are ignored. Other lines have one of the below forms. There must be
whitespace between each element, but the amount of whitespace is unim-
portant. A line may be continued on the next line by ending it with a
backslash; this does not work within a comment, NAME or NUMBER.
bus NAME NAME
chip NAME-LIST
label NAME NAME
compute NAME EXPR , EXPR
ignore NAME
set NAME EXPR
A NAME is a string. If it only contains letters, digits and underscores,
it does not have to be quoted; in all other cases, you must use double
quotes around it. Within quotes, you can use the normal escape-codes
from C.
A NAME-LIST is one or more NAME items behind each other, separated by
whitespace.
A EXPR is of one of the below forms:
NUMBER
NAME
@
EXPR + EXPR
EXPR - EXPR
EXPR * EXPR
EXPR / EXPR
- EXPR
^ EXPR
` EXPR
( EXPR )
A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples
of valid floating-point numbers; `10.' or `10E4' are not valid.
FILES
/etc/sensors3.conf
/etc/sensors.conf
The system-wide libsensors(3) configuration file. /etc/sen-
sors3.conf is tried first, and if it doesn't exist, /etc/sen-
sors.conf is used instead.
/etc/sensors.d
A directory where you can put additional libsensors configuration
files. Files found in this directory will be processed in alpha-
betical order after the default configuration file. Files with
names that start with a dot are ignored.
SEE ALSO
libsensors(3)
AUTHOR
Frodo Looijaard and the lm_sensors group https://hwmon.wiki.ker-
nel.org/lm_sensors
lm-sensors 3 November 2012 sensors.conf(5)
Generated by dwww version 1.16 on Tue Dec 16 07:42:01 CET 2025.