sensors.conf(5) Linux User's Manual sensors.conf(5)NAMEsensors.conf - libsensors configuration file
DESCRIPTIONsensors.conf describes how libsensors, and so all programs using it,
should translate the raw readings from the kernel modules to real-world
values.
SYNTAX
Comments are introduces by hash marks. A comment continues to the end
of the line. Empty lines, and lines containing only whitespace or com‐
ments 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
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 under‐
scores, 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:
NUMBER
NAME
@
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.
SEMANTICS
This section describes the meaning of each statement. Each statement is
accompanied by an example line. Please ignore line wrap-arounds.
BUS STATEMENT
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 con‐
figuration file, independent of the actual correspondence of bus num‐
bers and actual adapters (which may change from moment to moment).
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 /proc/bus/i2c (2.4 kernel) or
/sys/class/i2c-adapter/i2c-*/device/name (2.6 kernel). It should
always be quoted as well as it will most certainly contain spaces or
dashes.
There used to be a third argument, the algorithm name. For compatibil‐
ity reasons, the parser still accepts this third argument, but ignores
it.
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 con‐
figuration file.
The program prog/config/grab_busses.sh in the source distribution can
help you generate these lines.
CHIP STATEMENT
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
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 algorithm, but is not too confus‐
ing for humans (we hope!).
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.
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 specifi‐
cation based on lm78-i2c-1-2d or lm78-isa-0290:
lm78-i2c-1-2d
lm78-i2c-1-*
lm78-i2c-*-2d
lm78-i2c-*-*
lm78-isa-0290
lm78-isa-*
lm78-*
*-i2c-1-2d
*-i2c-1-*
*-i2c-*-2d
*-i2c-*-*
*-isa-0290
*-isa-*
*-*
*
COMPUTE STATEMENT
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 fea‐
ture 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 becom‐
ing ambiguous.
IGNORE STATEMENT
ignore fan1
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 STATEMENT
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. Appli‐
cations 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 STATEMENT
set in3_min 5 * 0.95
The set statement gives an initial value for a feature. Not each fea‐
ture 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 circu‐
lar 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.
FEATURE CLASSES
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 fea‐
ture 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 fea‐
ture 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 follow‐
ing 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 general 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.
CONFORMING TO
lm_sensors-2.x
SEE ALSOlibsensors(3)AUTHOR
Frodo Looijaard and the lm_sensors group http://www.lm-sensors.org/
April 2007 sensors.conf(5)
