1sensors.conf(5)               Linux User's Manual              sensors.conf(5)
2
3
4

NAME

6       sensors.conf - libsensors configuration file
7
8

DESCRIPTION

10       sensors.conf  describes  how  libsensors, and so all programs using it,
11       should translate the raw readings from the kernel modules to real-world
12       values.
13
14

SEMANTICS

16       On  a given system, there may be one or more hardware monitoring chips.
17       Each chip may have several features. For example, the LM78  monitors  7
18       voltage inputs, 3 fans and one temperature. Feature names are standard‐
19       ized. Typical feature names are in0, in1, in2...  for  voltage  inputs,
20       fan1, fan2, fan3... for fans and temp1, temp2, temp3... for temperature
21       inputs.
22
23       Each feature may in turn have one or more sub-features, each represent‐
24       ing  an  attribute  of the feature: input value, low limit, high limit,
25       alarm, etc. Sub-feature names are standardized as  well.  For  example,
26       the  first  voltage  input  (in0)  would  typically  have  sub-features
27       in0_input (measured value), in0_min (low limit), in0_max  (high  limit)
28       and  in0_alarm  (alarm  flag).  Which sub-features are actually present
29       depend on the exact chip type.
30
31       The sensors.conf configuration file will let you configure  each  chip,
32       feature and sub-feature in a way that makes sense for your system.
33
34       The  rest  of  this section describes the meaning of each configuration
35       statement.
36
37
38   CHIP STATEMENT
39       A chip statement selects for which chips all following compute,  label,
40       ignore  and  set  statements  are meant. A chip selection remains valid
41       until the next chip statement. Example:
42
43              chip "lm78-*" "lm79-*"
44
45       If a chip matches at least one of the chip descriptions, the  following
46       configuration lines are examined for it, otherwise they are ignored.
47
48       A chip description is built from several elements, separated by dashes.
49       The first element is the chip type, the second element is the  name  of
50       the  bus, and the third element is the hexadecimal address of the chip.
51       Such chip descriptions are printed by sensors(1) as the first line  for
52       every chip.
53
54       The  name  of the bus is either isa, pci, virtual, spi-*, i2c-N or mdio
55       with N being a bus number as bound with  a  bus  statement.  This  list
56       isn't  necessarily  exhaustive  as  support  for other bus types may be
57       added in the future.
58
59       You may substitute the wildcard operator * for every element. Note how‐
60       ever that it wouldn't make any sense to specify the address without the
61       bus type, so the address part is plain omitted when the bus type  isn't
62       specified.  Here is how you would express the following matches:
63
64
65       LM78 chip at address 0x2d on I2C bus 1      lm78-i2c-1-2d
66
67       LM78 chip at address 0x2d on any I2C bus    lm78-i2c-*-2d
68       LM78 chip at address 0x290 on the ISA bus   lm78-isa-0290
69       Any LM78 chip on I2C bus 1                  lm78-i2c-1-*
70       Any LM78 on any I2C bus                     lm78-i2c-*-*
71       Any LM78 chip on the ISA bus                lm78-isa-*
72       Any LM78 chip                               lm78-*
73       Any chip at address 0x2d on I2C bus 1       *-i2c-1-2d
74       Any chip at address 0x290 on the ISA bus    *-isa-0290
75
76       If  several chip statements match a specific chip, they are all consid‐
77       ered.
78
79
80   LABEL STATEMENT
81       A label statement describes how a feature should  be  called.  Features
82       without a label statement are just called by their feature name. Appli‐
83       cations can use this to label the readings they present. Example:
84
85              label in3 "+5V"
86
87       The first argument is the feature name. The second argument is the fea‐
88       ture description.
89
90       Note  that  you must use the raw feature name, which is not necessarily
91       the one displayed by "sensors" by default. Use "sensors -u" to see  the
92       raw feature names. Same applies to all other statement types below.
93
94
95   IGNORE STATEMENT
96       An ignore statement is a hint that a specific feature should be ignored
97       - probably because it returns bogus values (for example, because a  fan
98       or temperature sensor is not connected). Example:
99
100              ignore fan1
101
102       The  only  argument is the feature name. Please note that this does not
103       disable anything in the actual sensor chip; it simply hides the feature
104       in question from libsensors users.
105
106
107   COMPUTE STATEMENT
108       A  compute  statement  describes  how  a  feature's raw value should be
109       translated to a real-world value, and how a real-world value should  be
110       translated  back  to a raw value again. This is most useful for voltage
111       sensors, because in general sensor chips have a limited range and volt‐
112       ages  outside  this range must be divided (using resistors) before they
113       can be monitored.  Example:
114
115              compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)
116
117       The example above expresses the fact that the voltage input is  divided
118       using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the
119       VOLTAGE COMPUTATION DETAILS section below for details.
120
121       The first argument is the feature  name.  The  second  argument  is  an
122       expression  which  specifies  how  a  raw value must be translated to a
123       real-world value; `@' stands here for the raw value. This is  the  for‐
124       mula which will be applied when reading values from the chip. The third
125       argument is an expression that specifies how a real-world value  should
126       be  translated  back to a raw value; `@' stands here for the real-world
127       value. This is the formula which will be applied when writing values to
128       the  chip. The two formulas are obviously related, and are separated by
129       a comma.
130
131       A compute statement applies to all sub-features of the  target  feature
132       for  which  it makes sense. For example, the above example would affect
133       sub-features in3_min and in3_max (which are  voltage  values)  but  not
134       in3_alarm (which is a boolean flag.)
135
136       The following operators are supported in compute statements:
137              + - * / ( ) ^ `
138       ^x means exp(x) and `x means ln(x).
139
140       You  may  use  the  name  of sub-features in these expressions; current
141       readings are substituted. You should be careful though to avoid  circu‐
142       lar references.
143
144       If  at any moment a translation between a raw and a real-world value is
145       called for, but no compute statement applies, a one-on-one  translation
146       is used instead.
147
148
149   SET STATEMENT
150       A  set  statement  is used to write a sub-feature value to the chip. Of
151       course not all sub-feature values can be set that  way,  in  particular
152       input  values  and  alarm flags can not. Valid sub-features are usually
153       min/max limits.  Example:
154
155              set in3_min  5 * 0.95
156              set in3_max  5 * 1.05
157
158       The example above basically configures the chip to allow a 5%  deviance
159       for the +5V power input.
160
161       The  first  argument  is  the  feature  name. The second argument is an
162       expression which determines the written value. If there is an  applying
163       compute statement, this value is fed to its third argument to translate
164       it to a raw value.
165
166       You may use the name of  sub-features  in  these  expressions;  current
167       readings  are substituted. You should be careful though to avoid circu‐
168       lar references.
169
170       Please note that set statements are only executed  by  sensors(1)  when
171       you  use  the  -s option. Typical graphical sensors applications do not
172       care about these statements at all.
173
174
175   BUS STATEMENT
176       A bus statement binds the description of an I2C or SMBus adapter  to  a
177       bus  number.  This makes it possible to refer to an adapter in the con‐
178       figuration file, independent of the actual correspondence of  bus  num‐
179       bers  and  actual  adapters  (which  may change from moment to moment).
180       Example:
181
182              bus "i2c-0" "SMBus PIIX4 adapter at e800"
183
184       The first argument is the bus number. It is the literal text i2c-, fol‐
185       lowed  by a number. As there is a dash in this argument, it must always
186       be quoted.
187
188       The second argument is the adapter name,  it  must  match  exactly  the
189       adapter  name  as  it appears in /sys/class/i2c-adapter/i2c-*/name.  It
190       should always be quoted as well as it will most certainly contain  spa‐
191       ces or dashes.
192
193       The  bus statements may be scattered randomly throughout the configura‐
194       tion file; there is no need to place the  bus  line  before  the  place
195       where  its binding is referred to. Still, as a matter of good style, we
196       suggest you place all bus statements together at the top of  your  con‐
197       figuration file.
198
199       Running sensors --bus-list will generate these lines for you.
200
201       In  the  case where multiple configuration files are used, the scope of
202       each bus statement is the configuration file it was  defined  in.  This
203       makes  it  possible  to  have bus statements in all configuration files
204       which will not unexpectedly interfere with each other.
205
206
207   STATEMENT ORDER
208       Statements can go in any order, however it is recommended to  put  `set
209       fanX_div' statements before `set fanX_min' statements, in case a driver
210       doesn't preserve the  fanX_min  setting  when  the  fanX_div  value  is
211       changed.  Even  if the driver does, it's still better to put the state‐
212       ments in this order to avoid accuracy loss.
213
214

VOLTAGE COMPUTATION DETAILS

216       Most voltage sensors in sensor chips have a range of 0 to 4.08 V.  This
217       is  generally  sufficient for the +3.3V and CPU supply voltages, so the
218       sensor chip reading is the actual voltage.
219
220       Other supply voltages must be scaled with an external resistor network.
221       The  driver  reports  the value at the chip's pin (0 - 4.08 V), and the
222       userspace application must convert this raw value to an actual voltage.
223       The compute statements provide this facility.
224
225       Unfortunately the resistor values vary among motherboard types.  There‐
226       fore you have to figure out the correct resistor values  for  your  own
227       motherboard.
228
229       For positive voltages (typically +5V and +12V), two resistors are used,
230       with the following formula:
231               R1 = R2 * (Vs/Vin - 1)
232
233       where:
234               R1 and R2 are the resistor values
235               Vs is the actual voltage being monitored
236               Vin is the voltage at the pin
237
238       This leads to the following compute formula:
239               compute inX @*((R1/R2)+1),  @/(((R1/R2)+1)
240
241       Real-world formula for +5V and +12V would look like:
242               compute in3 @*((6.8/10)+1), @/((6.8/10)+1)
243               compute in4 @*((28/10)+1),  @/((28/10)+1)
244
245       For negative voltages (typically -5V and -12V), two resistors are  used
246       as  well,  but  different  boards use different strategies to bring the
247       voltage value into the 0 - 4.08 V range. Some use an  inverting  ampli‐
248       fier,  others use a positive reference voltage. This leads to different
249       computation formulas. Note that most users won't have to  care  because
250       most  modern  motherboards make little use of -12V and no use of -5V so
251       they do not bother monitoring these voltage inputs.
252
253       Real-world examples for the inverting amplifier case:
254               compute in5 -@*(240/60), -@/(240/60)
255               compute in6 -@*(100/60), -@/(100/60)
256
257       Real-world examples for the positive voltage reference case:
258               compute    in5    @*(1+232/56)    -    4.096*232/56,    (@    +
259       4.096*232/56)/(1+232/56)
260               compute    in6    @*(1+120/56)    -    4.096*120/56,    (@    +
261       4.096*120/56)/(1+120/56)
262
263       Many recent monitoring chips have a 0 - 2.04 V range, so scaling resis‐
264       tors are even more needed, and resistor values are different.
265
266       There are also a few chips out there which have internal scaling resis‐
267       tors, meaning that their value is known and  doesn't  change  from  one
268       motherboard  to  the  next. For these chips, the driver usually handles
269       the scaling so it is transparent to the user and no compute  statements
270       are needed.
271
272

TEMPERATURE CONFIGURATION

274       On  top  of  the  usual  features,  temperatures  can have two specific
275       sub-features: temperature sensor type (tempX_type) and hysteresis  val‐
276       ues (tempX_max_hyst, tempX_crit_hyst etc.).
277
278
279   THERMAL SENSOR TYPES
280       Available thermal sensor types:
281
282       1   PII/Celeron Diode
283       2   3904 transistor
284       3   thermal diode
285       4   thermistor
286       5   AMD AMDSI
287       6   Intel PECI
288
289       For example, to set temp1 to thermistor type, use:
290
291              set temp1_type 4
292
293       Only  certain  chips support thermal sensor type change, and even these
294       usually only support some of the types above. Please refer to the  spe‐
295       cific  driver  documentation  to  find out which types are supported by
296       your chip.
297
298       In theory, the BIOS should have configured the sensor types  correctly,
299       so you shouldn't have to touch them, but sometimes it isn't the case.
300
301
302   THERMAL HYSTERESIS MECHANISM
303       Many  monitoring  chips do not handle the high and critical temperature
304       limits as simple limits. Instead, they have two values for each  limit,
305       one  which triggers an alarm when the temperature rises and another one
306       which clears the alarm when the temperature falls. The latter is  typi‐
307       cally  a  few degrees below the former. This mechanism is known as hys‐
308       teresis.
309
310       The reason for implementing things that way is  that  high  temperature
311       alarms  typically trigger an action to attempt to cool the system down,
312       either by scaling down the CPU frequency, or by  kicking  in  an  extra
313       fan.  This should normally let the temperature fall in a timely manner.
314       If this was clearing the alarm immediately, then the  system  would  be
315       back  to  its  original state where the temperature rises and the alarm
316       would immediately trigger again, causing an undesirable tight  fan  on,
317       fan  off  loop.  The  hysteresis  mechanism  ensures that the system is
318       really cool before the fan stops, so that it will not have to  kick  in
319       again immediately.
320
321       So, in addition to tempX_max, many chips have a tempX_max_hyst sub-fea‐
322       ture.  Likewise,   tempX_crit   often   comes   with   tempX_crit_hyst.
323       tempX_emerg_hyst,  tempX_min_hyst  and  tempX_lcrit_hyst  exist too but
324       aren't as common.  Example:
325
326              set temp1_max      60
327              set temp1_max_hyst 56
328
329       The hysteresis mechanism can be disabled by giving both limits the same
330       value.
331
332       Note  that it is strongly recommended to set the hysteresis value after
333       the limit value it relates to in the configuration file. Implementation
334       details  on the hardware or driver side may cause unexpected results if
335       the hysteresis value is set first.
336
337

BEEPS

339       Some chips support alarms with beep warnings. When an  alarm  is  trig‐
340       gered  you  can  be  warned  by  a beeping signal through your computer
341       speaker. On top of per-feature beep flags, there is  usually  a  master
342       beep control switch to enable or disable beeping globally. Enable beep‐
343       ing using:
344
345              set beep_enable 1
346
347       or disable it using:
348
349              set beep_enable 0
350
351

WHICH STATEMENT APPLIES

353       If more than one statement of  the  same  kind  applies  at  a  certain
354       moment, the last one in the configuration file is used. So usually, you
355       should put more general chip statements at the top, so you can overrule
356       them below.
357
358

SYNTAX

360       Comments  are  introduced by hash marks. A comment continues to the end
361       of the line. Empty lines, and lines containing only whitespace or  com‐
362       ments are ignored.  Other lines have one of the below forms. There must
363       be whitespace between each element, but the  amount  of  whitespace  is
364       unimportant. A line may be continued on the next line by ending it with
365       a backslash; this does not work within a comment, NAME or NUMBER.
366
367              bus NAME NAME NAME
368              chip NAME-LIST
369              label NAME NAME
370              compute NAME EXPR , EXPR
371              ignore NAME
372              set NAME EXPR
373
374       A NAME is a string. If it only  contains  letters,  digits  and  under‐
375       scores, it does not have to be quoted; in all other cases, you must use
376       double quotes around  it.   Within  quotes,  you  can  use  the  normal
377       escape-codes from C.
378
379       A  NAME-LIST  is one or more NAME items behind each other, separated by
380       whitespace.
381
382       A EXPR is of one of the below forms:
383
384              NUMBER
385              NAME
386              @
387              EXPR + EXPR
388              EXPR - EXPR
389              EXPR * EXPR
390              EXPR / EXPR
391              - EXPR
392              ^ EXPR
393              ` EXPR
394              ( EXPR )
395
396       A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples
397       of valid floating-point numbers; `10.' or `10E4' are not valid.
398
399

FILES

401       /etc/sensors3.conf
402       /etc/sensors.conf
403              The  system-wide  libsensors(3)  configuration  file.  /etc/sen‐
404              sors3.conf is tried first, and if it  doesn't  exist,  /etc/sen‐
405              sors.conf is used instead.
406
407       /etc/sensors.d
408              A  directory  where you can put additional libsensors configura‐
409              tion files.  Files found in this directory will be processed  in
410              alphabetical  order  after the default configuration file. Files
411              with names that start with a dot are ignored.
412
413

SEE ALSO

415       libsensors(3)
416
417

AUTHOR

419       Frodo  Looijaard  and  the  lm_sensors  group   https://hwmon.wiki.ker
420       nel.org/lm_sensors
421
422
423
424lm-sensors 3                     November 2012                 sensors.conf(5)
Impressum