sensors.conf - libsensors configuration file
Which Statement Applies
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 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 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 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 /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 compatibility reasons, the parser still accepts this third argument, but ignores it.
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 these lines.
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 confusing 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 cant specify the address if you wildcard the complete second element. 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 features 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 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 dont 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 cant 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 cant 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 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 , @*2It 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.
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.
Frodo Looijaard and the lm_sensors group http://www.lm-sensors.org/
|sensors.conf (5)||April 2007|