Comment 4 for bug 680353

On 23 November 2010 20:40, Andreas Hasenack <email address hidden> wrote:
> This happens because we use acpi to get the thermal data, and this seems
> to work only for laptops.
>
> A workaround is to use a custom graph to plot the desired output of the
> sensors command. Here is an example:
>
> https://help.landscape.canonical.com/CustomGraphs/Examples#lm-sensors
>
> That being said, we could probably fallback to lm-sensors if there is no
> temperature being reported by acpi.

... or, perhaps better, just use the abstraction across various
methods provided by libsensors? People might also want to graph hdd
temperatures?

> One of the concerns I have is that the output of sensors is not always
> accurate and can be confusing, with names we have no idea what they
> represent, like temp1, temp2, etc.

I agree, though this does seem to be a problem for acpi too?

> In my laptop, for example, I have 16 values for "temp" alone when using
> the "ISA adapter", and two values for the "Virtual Device" adapter. I
> have no idea how we could decide programatically which values to use in
> the graph. What I usually do is pick the one that looks more reasonable,
> or agrees with what I see in the computer BIOS, and stick to that.

Another problem, across all methods, is that some sensors seem stuck
at unreasonable values like 0 or 127C.

If I was going to programmatically reduce it to a single value, I
would probably take the maximum plausible value at any moment across
all sensors. Or do this per grouping, if we're getting any useful
grouping metadata: the hottest probe in the drives is currently: 46C;
the hottest probe in the cpu is 48C; etc.

For things like drives or other swappable devices, users might care
which particular drive is overheating; for cpu or motherboard
measurement it seems to me not to be very meaningful.

--
Martin