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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
