[kde-linux] hardware temperature widget

[Duncan]

James posted on Sun, 20 May 2012 11:44:25 -0400 as excerpted:

> My available temperatures/sensors is empty in the widget but the command
> sensors shows temperatures.
> The widget was written by Petri Damsten.

Thanks, the author allowed me to confirm that I was trying the right 
one.  But you didn't post the version of kde you're using.  That could 
matter if there have been fixes...  FWIW, kde 4.8.3 here (on gentoo/
~amd64 with the kde overlay), the latest shipped by kde upstream, tho 
you're likely to be running something a bit older there if you're just 
running the distro version, for most distros.

Upon adding it, only a few (four I think) of the 10 available temps were 
showing, and those didn't have names.  Some reported temps, some reported 
0.

But with a bit of resizing larger, I could see the names, and opening the 
settings dialog, I could check/uncheck any of the 10.  With all 10 
checked, shortening the names a bit (I know they're temps, no need to 
have that in the name), and further resizing, all 10 eventually started 
reporting temps.  Whether it just took a bit longer than I expected to 
start reporting temps on some and they would have reported them normally 
had I waited a bit, or not, I don't know, but anyway...

The settings dialog shows the sensor path it's using.  You can check that 
against the CLI sensors command output.  FWIW, the plasmoid (plasma 
widget) simply gets (or should be getting, if it's not, something's 
wrong) the readings from the ksysguardd system-monitor daemon, the same 
one that you can browse by starting up ksysguard (probably listed as 
system monitor in the apps menu, but ksysguard entered in krunner is 
easier, once you know the name, and unlike system monitor, it's not so 
generic that it's unclear what we're actually talking about!).  So you 
can start that up, and see if ksysguard is getting the numbers, too.  I 
actually prefer the line-graph readout option in ksysguard, since that 
gives me a bit of history and trend-lines.

If ksysguard isn't getting them either, you can try editing your 
sensors.conf/sensors3.conf file, changing the names it reports, there.  
Some years ago I actually did that here, as I didn't like the names 
sensors was using.  I'm guessing that the plasmoid is keying off "temp" 
in the name to decide which of the many sensors to show, however, so if 
you're going to continue using the plasmoid, you'll probably want to keep 
the "temp" in the name, so the plasmoid can detect it as a temp.

Meanwhile, there's a couple other options, as well.  On kdelook.org, 
there's a plasmoid called yasp-scripted (yasp standing for yet another 
system-monitor plasmoid), that's EXTREMELY flexible, as you can actually 
script its reporting for among other things, anything that can be output 
to the command-line.  So with a bit of shell scripting, you can for 
instance sed/grep/cut/whatever the sensors output itself, down to the 
desired temperature line and the specific number field.  Then you can 
have yasp-scripted report that as a simple number (text), a bar graph, a 
line graph (my favorite as I mentioned), etc.  That's what I used for 
several years in early kde4 (from 4.2.5 when I switched from kde3, to 4.6 
or so), since early on, ksysguard was severely buggy and the normal kde 
sysmon plasmoids had other problems, plus I liked the linegraph display 
anyway, and the plasmoids didn't offer that.  You can even set it up to 
display, say, the last 10 lines of your syslog (obviously that would be 
text) if you like! =:^)

The biggest downside of yasp-scripted, however, is that it's a bit more 
advanced than many users are ready for, as you really set it up as you 
want for your own system, and to be really effective, you need to know 
not only how to set it up for the output you want (there's good 
documentation), but enough about how to work on the commandline to sed/
grep/cut/awk/whatever the bits of commandline output you want to monitor.

If you'd like to try it, as I said, kdelook, yasp-scripted.  There's a 
whole "duncan" subdir of sample scripts I submitted for it.  Of course 
you'll have to modify them to fit your system, but that's part of the fun 
of it. =:^)

Another option, similar but a bit more advanced, is superkaramba.  This 
is actually part of kde and depending on your distro, will have either 
been installed with kde, or should be available as an additional 
package.  The idea is similar to yasp-scripted but superkaramba started 
in the kde3 era, and its layout language is even more flexible/advanced 
than yasp-scripted.  That's what I eventually switched to and what I use 
now, but yasp-scripted was an easier first stepping-stone toward it, 
being a bit simpler.

Another advantage of superkaramba is that it's a bit more CPU efficient 
than yasp-scripted, which begins to matter if you're monitoring as many 
different things as I am, at the frequency (1 second) I update!  Some 
things that I had to write command-line-output scraping bash scripts for 
in yasp-scripted, are coded directly into superkaramba in C++, thus 
eliminating the repeated hatching of the bash script along with all the 
greps/seds/etc at each update.  With just a handful of monitors every 2-5 
seconds it's not bad, but with the many system stats I monitor, every 
second, I was running ~20% CPU utilization on each of four cores with 
yasp-scripted, down now to ~5-7% with superkaramba, and I'm actually 
doing a bit more monitoring than I was, as well.

Another superkaramba advantage is that its more advanced layout language 
allows a much more compact display, more information in less pixels! =:^)

Either superkaramba or yasp-scripted will allow you to bypass kde's 
sysguardd and get the information from the command line or /sys/ or /proc/ 
files directly, if necessary (tho it can be used for stuff it reports 
correctly).  But they're both very much for users who know enough about 
the command line to actually be able to script up the output they want.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman