sensors.conf(5) Linux Programmer's Manual sensors.conf(5)
sensors.conf - libsensors configuration file
sensors.conf describes how libsensors, and so all programs using it, should translate the
raw readings from the kernel modules to real-world values.
Comments are introduces 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 should be whitespace between each element, but the amount of
whitespace is unimportant. 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 NAME
label NAME NAME
compute NAME EXPR , EXPR
set NAME EXPR
A NAME is a string. If it only contains letters, digits and underscores, it does not have
to quoted; in all other cases, you should 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:
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 float-
ing-point numbers; `10.' or `10E4' are not valid.
This section describes the meaning of each statement. Each statement is accompanied by an
example line. Please ignore line wrap-arounds.
bus "i2c-0" "SMBus PIIX4 adapter at e800" "Non-I2C SMBus adapter"
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 configuration file, independent of the
actual correspondence of bus numbers and actual adapters (which may change from moment to
The first argument is the bus number. It is the literal text i2c-, followed by a number.
As there is a dash in this argument, it must always be quoted.
The second and third arguments are the description texts. They must be exactly match the
texts as they appear in /proc/bus/i2c, except for trailing spaces, which are removed both
from the /proc entries and the arguments. The adapter description comes first, followed by
the algorithm description.
The bus statements may be scattered randomly throughout the configuration 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.
The program prog/config/grab_busses.sh in the source distribution can help you generate
chip "lm78-*" "*-isa-*" "*-i2c-3"
The chip statement selects for which chips all following configuration statements are
meant. The chip selection remains valid until the next chip statement. It does not influ-
ence the operation of a bus statement.
If a chip matches at least one of the chip descriptions, all following configuration lines
are examined for it. If it matches none of the chip descriptions, every non-bus statement
is ignored upto the next chip statement.
A chip description is built from a couple of elements, separated by dashes. To complicate
matters, sometimes an element can also contain dashes. This complicates the parsing algo-
rithm, but is not too confusing for humans (we hope!). The chip descriptions are equal to
those appearing in /proc/sys/dev/sensors, but may contain the * wildcard.
The first element is the name of the chip type. Sometimes a single driver implements sev-
eral chip types, with several names. The driver documentation should tell you. You may
substitute the wildcard operator * for this element.
The second element is the name of the bus. This is either isa or i2c-N, with N being any
number as binded with a bus statement. You may substitute the wildcard operator * for this
element, or only for the number of the I2C bus (which means 'any non-ISA bus').
The third element is the hexadecimal address. This is a number between 0 and ffff for the
ISA bus, and between 0 and 7f for an I2C bus. You may substitute the wildcard operator *
for this element.
There are some folding rules for wildcards to make things easier for humans to read. Also,
you can't specify the address if you wildcard the complete second element. The following
are all valid chip type specification based on lm78-i2c-10-5e or lm78-isa-10dd:
compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)
The compute statement describes how you should translate a feature's raw value to a
real-world value, and how you should translate it back to a raw value again.
The first argument is the feature name, which may be the name of a feature class (see
below). The second is an expression which specifies how a raw value must be translated to
a real-world value; `@' stands here for the raw value. The third 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.
You may use the name of other features in these expressions; you should be careful though
to avoid circular references, as this may hang the expression evaluator.
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.
The comma is an unfortunate necessity to stop the statement from becoming ambiguous.
The 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
The only argument is the feature name, which may be a feature class; in that case the
label class is used (see below).
label in3 "+5V"
The label statement describes how a feature should be called. Features without a label
statement are just called by their feature name. Applications can use this to label the
readings they present (but they don't have to).
The first argument is the feature name, which may be a feature class (see below). The sec-
ond argument is the feature description.
set in3_min 5 * 0.95
The set statement gives an initial value for a feature. Not each feature can be given a
sensible initial value; valid features are usually min/max limits.
The first argument is the feature name. The second argument is an expression which deter-
mines the initial 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 other features in these expressions; current readings are substi-
tuted. You should be careful though to avoid circular references, as this may hang the
expression evaluator. Also, you can't be sure in which order set statements are evaluated,
so this can lead to nasty surprises.
There are two kinds of classes, here called compute and label classes, after the state-
ments for which they are defined. Classes are defined over features: the kind of values
that can be read from or set for a specific kind of chip.
Each class has a class name, which is usually the same as its most prominent feature. A
label or compute statement for the class name feature forces the same settings for all
other class members. A specific statement for a class member feature always overrides the
general class setting, though. This means that you can't override the class name feature
A simple example will explain this better. The fan1 label class of the lm78 chip contains
three members: fan1 itself, fan1_min and fan1_div. The last feature sets the number by
which readings are divided (to give the fan less resolution, but a larger field of opera-
tion). The following line will set the name of all these features to describe the fan:
label fan1 "Processor 1 FAN"
Now we happen to know that, due to the type of fan we use, all readings are always off by
a factor of two (some fans only return one 'tick' each rotation, others return two):
compute fan1 @/2 , @*2
It will be clear that this should be done for the fan1_min feature too, but not for the
fan1_div feature! Fortunately, the fan1 compute class contains fan1_min, but not fan1_div,
so this works out right.
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 genereal chip statements
at the top, so you can overrule them below.
There is one exception to this rule: if a statement only applies because the feature is in
the same class as the feature the statement contains, and there is anywhere else a state-
ment for this specific class member, that one takes always precedence.
February 8, 1999 sensors.conf(5)