.\" Copyright (C) 1998, 1999 Adrian Baugh <adrian.baugh@keble.ox.ac.uk> and

.\"                          Frodo Looijaard <frodol@dds.nl>

.\" Copyright (C) 2008--2012 Jean Delvare <jdelvare@suse.de>

.\"

.\" Permission is granted to make and distribute verbatim copies of this

.\" manual provided the copyright notice and this permission notice are

.\" preserved on all copies.

.\"

.\" Permission is granted to copy and distribute modified versions of this

.\" manual under the conditions for verbatim copying, provided that the

.\" entire resulting derived work is distributed under the terms of a

.\" permission notice identical to this one.

.\"

.\" Since the Linux kernel and libraries are constantly changing, this

.\" manual page may be incorrect or out-of-date.  The author(s) assume no

.\" responsibility for errors or omissions, or for damages resulting from

.\" the use of the information contained herein.

.\"

.\" Formatted or processed versions of this manual, if unaccompanied by

.\" the source, must acknowledge the copyright and authors of this work.

.\"

.\" References consulted:

.\"     sensors.conf.eg by Frodo Looijaard

.TH sensors.conf 5  "November 2012" "lm-sensors 3" "Linux User's Manual"

.SH NAME

sensors.conf \- libsensors configuration file

.SH 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.

.SH 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

standardized. 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

representing 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

.I 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.

.SS CHIP STATEMENT

A

.I chip

statement selects for which chips all following

.IR compute ,

.IR label ,

.I ignore

and

.I set

statements are meant. A chip

selection remains valid until the next

.I chip

statement. Example:

.RS

chip "lm78\-*" "lm79\-*"

.RE

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

.IR isa ,

.IR pci ,

.IR virtual ,

.I spi-*,

.I i2c-N

or

.I mdio

with

.I N

being a bus number as bound with a

.I 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

.I *

for every element. Note however 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:

.TS

l l.

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

.TE

If several chip statements match a specific chip, they are all considered.

.SS LABEL STATEMENT

A

.I label

statement describes how a feature should be called. Features without a

.I label

statement are just called by their feature name. Applications can use this

to label the readings they present. Example:

.RS

label in3 "+5V"

.RE

The first argument is the feature name. The second argument is the feature

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.

.SS IGNORE STATEMENT

An

.I 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:

.RS

ignore fan1

.RE

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.

.SS COMPUTE STATEMENT

A

.I compute

statement describes how a feature's raw value should be translated to a

real\-world value, and how a real\-world value should be translated back

to a raw value again. This is most useful for voltage sensors, 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:

.RS

compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)

.RE

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

.B VOLTAGE COMPUTATION DETAILS

section below for details.

The first argument is the feature name. The second argument is an expression

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 argument 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

.I 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

.I compute

statements:

.RS

+ \- * / ( ) ^ `

.RE

^x means exp(x) and `x means ln(x).

You may use the name of sub\-features in these expressions; current readings

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

.I compute

statement applies, a one\-on\-one translation is used instead.

.SS SET STATEMENT

A

.I 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 input values

and alarm flags can not. Valid sub\-features are usually min/max limits.

Example:

.RS

set in3_min  5 * 0.95

.RE

.RS

set in3_max  5 * 1.05

.RE

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 expression

which determines the written value. If there is an applying

.I 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 readings

are substituted. You should be careful though to avoid circular references.

Please note that

.I set

statements are only executed by sensors(1) when you use the

.B \-s

option. Typical graphical sensors applications do not care about these

statements at all.

.SS BUS STATEMENT

A

.I 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). Example:

.RS

bus "i2c\-0" "SMBus PIIX4 adapter at e800"

.RE

The first argument is the bus number. It is the literal text

.IR 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

.IR /sys/class/i2c\-adapter/i2c\-*/name .

It should always be quoted as well as it will most certainly contain

spaces or dashes.

The

.I 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

.I bus

statements together at the top of your configuration file.

Running

.B sensors --bus-list

will generate these lines for you.

In the case where multiple configuration files are used, the scope

of each

.I 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.

.SS 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 statements in this order to avoid accuracy loss.

.SH 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.3V 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 \- 4.08 V), and the

userspace application must convert this raw value to an actual voltage.

The

.I compute

statements provide this facility.

Unfortunately the resistor values vary among motherboard types.

Therefore you have to figure out the correct resistor values for your

own motherboard.

For positive voltages (typically +5V and +12V), 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 +5V and +12V 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 \-5V and \-12V), two resistors are used

as well, but different boards use different strategies to bring the

voltage value into the 0 \- 4.08 V range. Some use an inverting

amplifier, 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 \-12V and no use of

\-5V 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 \- 2.04 V range, so scaling resistors

are even more needed, and resistor values are different.

There are also a few chips out there which have internal scaling

resistors, 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

.I compute

statements are needed.

.SH 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.).

.SS THERMAL SENSOR TYPES

Available thermal sensor types:

.TS

r l.

1	PII/Celeron Diode

2	3904 transistor

3	thermal diode

4	thermistor

5	AMD AMDSI

6	Intel PECI

.TE

For example, to set temp1 to thermistor type, use:

.RS

set temp1_type 4

.RE

Only certain chips support thermal sensor type change, and even these

usually only support some of the types above. Please refer to the

specific 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.

.SS 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

typically a few degrees below the former. This mechanism is known as

hysteresis.

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 immediately.

So, in addition to tempX_max, many chips have a tempX_max_hyst

sub-feature. 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:

.RS

set temp1_max      60

.RE

.RS

set temp1_max_hyst 56

.RE

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.

.SH 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:

.RS

set beep_enable 1

.RE

or disable it using:

.RS

set beep_enable 0

.RE

.SH 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

.I chip

statements at the top, so you can overrule them below.

.SH 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 unimportant. A line

may be continued on the next line by ending it with a backslash; this does

not work within a comment,

.B NAME

or

.BR NUMBER .

.RS

bus

.B NAME NAME NAME

.sp 0

chip

.B NAME\-LIST

.sp 0

label

.B NAME NAME

.sp 0

compute

.B NAME EXPR

,

.B EXPR

.sp 0

ignore

.B NAME

.sp 0

set

.B NAME EXPR

.RE

.sp

A

.B 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

.B NAME\-LIST

is one or more

.B NAME

items behind each other, separated by whitespace.

A

.B EXPR

is of one of the below forms:

.RS

.B NUMBER

.sp 0

.B NAME

.sp 0

@

.sp 0

.B EXPR

+

.B EXPR

.sp 0

.B EXPR

\-

.B EXPR

.sp 0

.B EXPR

*

.B EXPR

.sp 0

.B EXPR

/

.B EXPR

.sp 0

\-

.B EXPR

.sp 0

^

.B EXPR

.sp 0

`

.B EXPR

.sp 0

(

.B EXPR

)

.RE

A

.B NUMBER

is a floating\-point number. `10', `10.4' and `.4' are examples of valid

floating\-point numbers; `10.' or `10E4' are not valid.

.SH FILES

.I /etc/sensors3.conf

.br

.I /etc/sensors.conf

.RS

The system-wide

.BR libsensors (3)

configuration file. /etc/sensors3.conf is tried first, and if it doesn't exist,

/etc/sensors.conf is used instead.

.RE

.I /etc/sensors.d

.RS

A directory where you can put additional libsensors configuration files.

Files found in this directory will be processed in alphabetical order after

the default configuration file. Files with names that start with a dot are

ignored.

.RE

.SH SEE ALSO

libsensors(3)

.SH AUTHOR

Frodo Looijaard and the lm_sensors group

https://hwmon.wiki.kernel.org/lm_sensors