Provided by: lm-sensors_3.0.0-4ubuntu1_i386
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
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
must 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
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 floating-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"
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 moment).
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 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
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.
Running sensors --bus-list will generate these lines for you.
chip "lm78-*" "lm79-*"
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 influence 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
A chip description is built from a couple of elements, separated by
The first element is the name of the chip type. Sometimes a single
driver implements several 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, pci 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 I2C bus’).
The third element is the hexadecimal address of the chip. The valid
range depends on the bus type. You may substitute the wildcard operator
* for this element.
Note that it wouldn’t make any sense to specify the address without the
bus type. For this reason, the address part is plain omitted when the
bus type isn’t specified. The following are all valid chip type
specification based on lm78-i2c-1-2d or lm78-isa-0290:
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
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
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 connected).
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 second 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 determines 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 substituted. 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 statements 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 explicitly.
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 operation). The
following line will set the name of all these features to describe the
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 statement for this specific
class member, that one takes always precedence.
The system-wide libsensors(3) configuration file.
/etc/sensors3.conf is tried first, and if it doesn’t exist,
/etc/sensors.conf is used instead.
Frodo Looijaard and the lm_sensors group http://www.lm-sensors.org/