1sensors.conf(5) Linux User's Manual sensors.conf(5)
2
6 sensors.conf - libsensors configuration file
7
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
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 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 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 The rest of this section describes the meaning of each configuration
35 statement.
36 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 chip "lm78-*" "lm79-*"
44 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 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 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 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 LM78 chip at address 0x2d on I2C bus 1 lm78-i2c-1-2d
66 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 If several chip statements match a specific chip, they are all consid‐
77 ered.
78 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 label in3 "+5V"
86 The first argument is the feature name. The second argument is the fea‐
88 ture description.
89 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 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 ignore fan1
101 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 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 compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)
116 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 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 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 The following operators are supported in compute statements:
137 + - * / ( ) ^ `
138 ^x means exp(x) and `x means ln(x).
139 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 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 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 set in3_min 5 * 0.95
156 set in3_max 5 * 1.05
157 The example above basically configures the chip to allow a 5% deviance
159 for the +5V power input.
160 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 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 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 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 bus "i2c-0" "SMBus PIIX4 adapter at e800"
183 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 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 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 Running sensors --bus-list will generate these lines for you.
200 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 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
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 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 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 For positive voltages (typically +5V and +12V), two resistors are used,
230 with the following formula:
231 R1 = R2 * (Vs/Vin - 1)
232 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 This leads to the following compute formula:
239 compute inX @*((R1/R2)+1), @/(((R1/R2)+1)
240 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 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 Real-world examples for the inverting amplifier case:
254 compute in5 -@*(240/60), -@/(240/60)
255 compute in6 -@*(100/60), -@/(100/60)
256 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 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 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
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 THERMAL SENSOR TYPES
280 Available thermal sensor types:
281 1 PII/Celeron Diode
283 2 3904 transistor
284 3 thermal diode
285 4 thermistor
286 5 AMD AMDSI
287 6 Intel PECI
288 For example, to set temp1 to thermistor type, use:
290 set temp1_type 4
292 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 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 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 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 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 set temp1_max 60
327 set temp1_max_hyst 56
328 The hysteresis mechanism can be disabled by giving both limits the same
330 value.
331 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
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 set beep_enable 1
346 or disable it using:
348 set beep_enable 0
350
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
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 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 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 A NAME-LIST is one or more NAME items behind each other, separated by
380 whitespace.
381 A EXPR is of one of the below forms:
383 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 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
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 /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
415 libsensors(3)
416
419 Frodo Looijaard and the lm_sensors group https://hwmon.wiki.ker‐
420 nel.org/lm_sensors
421lm-sensors 3 November 2012 sensors.conf(5)