Image 01


J Duncan
Yasp-Scripted (Systemmonitor) v1.0.8a

Plasma 4 Extensions 301 comments

Score 82.1%
Feb 25 2011
What I'd do in such a case is find a command line command that reports the info you need, then use it for your sensor instead of the system monitor engine. (I don't really know enough about wireless to be of help with the specific CLI command, unfortunately.) You can then script it to report the desired value if the net is up, or return some reasonable default, say 0, if it's down, or report the error but truncate it (using cut) if it's too long, thus making yasp-scripted too wide when there's an error. I did that for a couple sensors that under some circumstances would report really long errors here. The command line gives you far more control, but OTOH, isn't as efficient as there's quite a bit more overhead to starting a process than there is in simply reporting some number spit out by an existing process, so will use more CPU. - Jul 11 2011
The yasp-scripted plasmoid has a minimum size, controlled by the displayed content of the script you set it to run, but no maximum size -- plasma itself controls that. Change what you have the script set to display to change the minimum size.

If placed in a panel larger than the minimum size, plasma will expand one plasmoid dimension (vertical in a horizontal panel, horizontal in a vertical panel) to size of the panel, the other will remain at plasmoid minimum.

If placed on the desktop, plasma will let you drag it larger than the minimum size, but not smaller.

You mention problems getting it to save its size, but saw what size you're talking about. If it's the minimum size, as I said, you control that yourself based on what you have the script setup to display, the font and font size you set, the height of the plotters, etc. The minimum width of the plasmoid is normally the required width of the widest item. As such, I control it here by setting a fixed-width font (this helps in getting things to line up well, too) and adding spaces or abbreviating labels until the longest line is the size I want. (If some lines can be variable, say due to numbers that can be 1-3 digits, I make sure another line is long enough to allow space for the three digits of the variable lines so the size doesn't keep changing on me every time it updates.) The minimum height is simply the set height of every displayed line, text or graphical, of the script.

If the size you're setting is larger than the minimum as explained above, then it's not really the plasmoid setting the size, but plasma itself. If there's a problem with that, it'd therefore be a plasma bug, not something the plasmoid itself controls.

And to answer your question, no, I'm not having such a problem, but if there were a plasma bug in that regard I'd not notice it because I configure the minimum size via the script and always use that, of course with the exception of the dimension that's always set by the panel size for plasmoids in a panel. - May 19 2011
> For me, only one of the scripts works

That's because the scripts are all example scripts. They aren't really designed to be run as-is, unless you have exactly the same hardware setup as the person who authored the script. The idea is to customize them to your own hardware, partitions, etc.

There's typically two ways to get the data from your system into the script to be displayed -- two different types of "sensors" (the third listed in the README.syntax file is simply a math sensor that manipulates data already available from other sensors).

The first (second in the readme) type of sensor uses kde's existing plasma:dataengine, most frequently the systemmonitor engine. But what that engine exposes for use depends on what it can find in your system.

The second (first in the readme) type of sensor often requires a bit more work, but is *FAR* more flexible, because it simply takes the STDOUT of a (normally CLI mode command or command-pipe, making it available thru the sensor, for display via one of the text or graphic display elements yasp-scripted makes available for use by your yasp-script.

Thus, any output you can get to appear either on the command-line or via kde's systemmonitor engine, you can get yasp-scripted to display (obviously assuming generating that output doesn't require interactivity -- that it can be scripted, of course).

What this normally involves for lm_sensors output is running the command in the shell to see what the output you're looking for looks like, then piping that result to grep/sed/cut/awk/head/tail/etc to format it the way you need for the yasp-scripted sensor. (Typically, this will involve grepping a specific line of the output, then cutting/seding/grepping that down to just the number, either for formatted text/graphic display directly, or to be plugged into yasp-scripted's math functions to for instance turn KB into MB or GB, or to divide a value by the total possible to get a percentage for graphic.)

The shipped scripts do this already, but by definition, they measure statistics on the specific hardware that the author had. You can either modify the examples for your hardware, or you can use them as illustrations when creating your own.

In this way, yasp-scripted is very powerful, because it can be made to display whatever stats your system has available, *BUT*, it's also not a simple install and run plasmoid. It's designed for the power user, the user already familiar enough with his system and the command line, to know both what sort of information he wants, and how to use the traditional UNIX tools and shell scripting to get it in the form she wants. People who don't have the required skills will therefore find the this plasmoid pretty much worthless, because they won't know how to get it to display what they want it to display, not even to the point of modifying the existing scripts for their own system. - May 06 2011

For technical reasons, plasmoid binaries often must be built from sources to work with your specific distribution. That's the case here.

Download (and untar) the tarball, then, as is traditional for source tarballs, there's an INSTALL file included, with instructions. The assumption is that you already have a standard working development toolchain installed, plus cmake, standard for kde. If you don't, you'll likely have to install cmake and gcc, and possibly a few *-devel packages for kde related dependencies. (FWIW, I run Gentoo here, where the assumption is from-source, so such things are normally installed already, but I ran Mandrake 2001-2004, and remember well having to install various extra *-devel packages if I wanted to do anything from source.)

Yasp-scripted vs. superkaramba:

You mention that you're already familiar with superkaramba. =:^) That's a *huge* bonus, and yasp-scripted scripts should in fact look quite familiar indeed, as you'll quickly discover that yasp-scripted is in practice a mini-karamba, very similar, but with a rather simpler and thus somewhat less powerful syntax.

Which brings up the logical question: Since plasma natively supports superkaramba themes and you already understand it, why would you be interested in the simpler but less powerful yasp-scripted, given that it requires building and installing an additional plasmoid while superkaramba support is plasma-builtin, and yasp-scripted is in fact less powerful? (Yasp-scripted doesn't yet support theme/script nesting, for instance, and lacks superkaramba's positioning language features, so positioning is vertical-only, controlled by the order in the script. The horizontal positioning in the third screenshot (from me), is because I'm running multiple yasp-scripted plasmoids, lined up in a row on the same panel.)

Here, I used kde3's ksysguard to track system performance, and found the kde4 version buggy and unsuitable for the purpose, so when I switched to kde4, I needed something quickly to fill the gap. I researched superkaramba and in fact will probably upgrade to it eventually, but found its learning curve a bit too steep for immediate use when I switched. Yasp-scripted, having a simpler scripting language but still powerful enough to do the reporting I needed and more, was the easier "quick" solution, and I expect having learned it will greatly help when I upgrade to superkaramba. So it worked great for me and I in turn have tried to help others with it here as I can.

But I don't really understand what it would offer to someone already comfortable with superkaramba, especially since superkaramba support is already native to plasma, just (script if necessary and) install the appropriate theme, while yasp-scripted requires the additional binary plasmoid build and install, as well.

But since I'm coming from the yasp-scripted side, perhaps I'm missing something. Thus I'm not just asking the question for you, but for me too, as I always considered superkaramba the ultimate solution, for those who knew it, both because I believe it more powerful, and because of its native plasma support. If you see something in yasp-scripted that superkaramba can't do, I'd definitely like to know about it, as it could change my viewpoint and ultimate goal to learn superkaramba substantially.

Runtime script configuration:

As with superkaramba, yasp-scripted (mostly) simply provides a framework for the the graphical display and reporting of various scripted elements. A key thing to remember with both superkaramba and yasp-scripted is that neither one create their reports "out of thin air" as it were; they both require the data to be available elsewhere in the system. All they do is take that data from elsewhere, massage it a bit for graphical presentation, and then present it in the form chosen by the script/theme author.

You ask specifically about quad-core CPU info. I don't know as you didn't say, whether you're thinking about core-temps (°), simple use vs idle (%), more complex user/system/nice/wait/total vs idle (%), cpufreq (MHz/GHz), or... but all these are available on various system sensors if so configured for your system, and thus available to be presented by yasp-scripted and superkaramba. At least yasp-scripted (IDR for superkaramba) exposes some of these from the ksysguard/kde-systemmonitor engine... these are the same values available in ksysguard/kde-systemmonitor, with availability conditional on it understanding how to get them. However, that's just arguably the simplest method of getting the numbers. If the ksysguard/kde-systemmonitor engine doesn't understand the numbers, yet they're available as text elsewhere in the system, say from the "sensors" or "acpi" commands at the CLI and/or as exposed in files located in /proc or /sys, they're still available to yasp-scripted (and I believe superkaramba), which can take the STDOUT of various commands or command-pipes (using grep/sed/awk/cut/head/tail/etc as necessary), do math on it if necessary, and present the formatted output as text or as bar or line graphs.

What method you use to get that info will to some extent be system-specific, but you can check the scripts in the "duncan" subdir for how I got both temps and detailed user/system/nice/wait/total percentages, on my dual dual-core main system (dual Opteron 290s, each dual-core). The third screenshot includes the output from these scripts.

Since then, I've setup similar scripts on my Atom based netbook, line-graphing and text-reporting CPUFreq, which wasn't applicable on my main system. I also graph and text-report on battery status, if that's of any interest. But I've not turned that in, so ask if you're interested in that.

So while the answer is somewhat system-specific, you've a good likelihood of being able to grok it and figure out what changes you need for your system, if any, from one of the existing sample scripts... *PROVIDED* the numbers are either exposed in the ksysguard/kde-systemmonitor engine, or that you grok bash scripting well enough to figure out what's going on in the sample scripts and modify it as necessary. If you don't understand bash and it's not available in the ksysguard/kde-systemmonitor engine, then it'll be tough figuring out. But if you're familiar with superkaramba, you still might manage to do it, with a bit of muddling. - Mar 17 2011
As you note, the df for both root and user is the same, so that's not the problem. However, did you note that the / partition is missing there, too?

That suggests one of two things to me. Most likely, the rootfs remount stuff in your initscripts (or possibly simply the /etc/fstab entry for it) is screwed up, so the only root mount is the default rootfs mount, likely read-only, that the kernel does first, before starting any userspace (well, an initramfs/initrd changes that a bit, but anyway...). cat /proc/mounts (mount itself may report invalid info if inittab is stale due to read-only mounted rootfs). There should be TWO entries for /, the generic "rootfs" entry from the initial kernel mount, and if the system's remounting it correctly, a /dev/root entry that lists the real filesystem type (ext4 or whatever, I've used reiserfs here for years and will probably do until I switch to btrfs) and real mount options. If the second entry is missing or has strange mount options listed, that's probably why neither df nor kde can find it.

The other possibility would be some strange interaction with SELinux, AppArmor or similar security mechanism. That's well beyond me and the chance is rather small, but it's there if you're running such things, particularly with SELinux, which few enough people properly understand that most simply turn it off if it starts giving them problems.

I'd bet on the missing remount, tho, so the system doesn't see / in ordered for either df or kde's sysengine to be able to list it. - Mar 03 2011
It's a bit of a long shot as I'm not sure this info is affected and I'd normally think not, but... Did you possibly update your kernel recently?

The kernel folks have been strengthening "information leak" protections due to potential security issues recently (2.6.38, possibly 2.6.37), with the specific behavior being that certain values now appear as zero unless queried by root. I don't /know/ that partition sizes are affected, but it's possible.

Does running the "df" command from a shell (konsole window) report usable values? What about if you run it as root (su/sudo/whatever)? If a root df returns valid info but a user df only returns valid info for /home, not /, then we've found the problem -- stricter permissions on the / data. There should be a kernel option available to loosen those restrictions if indeed that's the problem. If not... - Mar 03 2011
The command he uses for CPU temps is "sensors", piped to grep, etc, to filter it to just the desired coretemp data.

"sensors" is part of the lm_sensors package. Do you have it installed and configured, so that running it from a command prompt produces a bunch of output including the coretemps? If not, you won't get anything for that and might as well comment those lines (or install and configure the package). You'll also need the appropriate kernel modules available. They may be available by default or installed as dependencies of lm_sensors for many distribution kernels, but if you build your own kernel, you may well need to go into the kernel config and turn on the appropriate drivers, either as built-in or as modules (which would then normally be loaded by the lm_sensors initscript, once it's configured).

HOWEVER: Many modern laptops (and presumably more modern desktops than mine, as well) don't actually need or use lm_sensors, instead using acpi based information, directly. My netbook doesn't have lm_sensors installed, tho it does have specific kernel drivers for that model of netbook, but cpu speed, temps, battery, etc, are all available, using other commands.

Bottom line. That's system-specific configuration. You'll need it configured for your system before it'll work. - Feb 13 2011
Two points:

1) I don't understand why, when everyone else (well, at least the browsers) are going separate processes in ordered to keep one applet/plugin from crashing the entire thing, plasma was /still/ designed with everything in the same process, even the same thread, so if one plasmoid crashes, it crashes the ENTIRE thing... if one stalls, it stalls the entire thing! It /does/ save memory, but come on, we're not running MS WormOS 3.1 with shared memory in 4 megabytes of RAM any more, and there's a /reason/ the browsers are spending all that work separating things from each other! </rant>

But at least in theory if it's actually crashing, there's another component of kde that's supposed to notice it and restart plasma automatically. I started noticing that with 4.5 and while I'm not sure 4.6 has crashed on me, it should be the same. So what I think is happening is that plasma is stalling, NOT crashing, stalling, waiting for something.

Which is where #2 comes in...

2) I've had yasp-scripted (and therefore all of plasma, due to the design I was ranting about above) stall out on me when I made a mistake, in my case a typo in a plotter use= phrase, so it pointed at a sensor name that didn't exist. When it tries to use a sensor that doesn't exist, it apparently locks up, thereby locking up all of plasma.

Try this to troubleshoot (it's what I did to find the problem line): First, start a konsole so you have somewhere to type commands when plasma goes haywire on you. Then, edit the script, commenting (leading #) each line. You should be able to then start plasma-desktop with the (now all comments) script running. You can then quit the desktop again. (I like the traditional killall plasma-desktop, the kde-specific method is kquitapp plasma-desktop, you can type it in the konsole window you opened.) Then edit the script, uncommenting /just/ the sensors (nothing using them, so no plotters, meters, values, or text lines using a sensor), and try running plasma-desktop again. My experience has been that sensors lines (at least as long as they don't use other sensors) shouldn't cause a stall, even if the command fails for whatever reason, because yasp-scripted is designed so it /should/ work around unresponsive sensors (if there's a typo in the line, causing bad format, say a missing set of quotes, that might still cause it). If that does NOT work, go back and try each individual sensors line until you find the bad one. If it DOES work, start uncommenting the plotters, values, etc, one or a group at a time, until you find the bad one.

As I said, it happened to me. I'll bet you find a bad line, and upon examining that line, you find a typo or something, possibly a use= pointing at a non-existent sensor (abbc instead of abc, or abcd instead of, or the like, that was the problem I had, simple, stupid typo). Correct that and you should be in business. =:^) - Feb 13 2011
To resize it, you must resize the longest element (usually a text element) inside. It will only shrink down until that element is displayed at its natural size.

That is in fact how I control the sizes on all of mine. I use monospace fonts, and strictly control the number of chars on each line. (I hadn't fully gotten the hang of it when I posted the sample scripts that now appear in the duncan subdir. I've refined my technique a bit since then.)

Hint: If you're using value lines with both key and (possibly formatted) use values, the longest key value will apply to all of them, as will the longest (formatted) use value, assuming the same font for all of them, anyway. So to calculate the length required for the value lines, add the longest key length to the longest use length.

Basically, what that means is that you need to trim/abbreviate more. If you have text results that are too long, feed them to grep or cut to trim them some. For integer results, divide by factors of 10 to reduce the number of digits. For floats, use format to control the number of decimal places. And of course abbreviate your keys/labels if necessary.

Or use narrower/smaller fonts...

Note that I don't use meter/bar graphs here, preferring plotters as I like to see the trends that bars hide. Thus, I don't have much experience with or advice on them, but the same idea would apply. If commenting everything but the sensor and meter lines results in the same minimum width, they're forcing the width, so you gotta figure out how to make them narrower. - Feb 10 2011
Note that the whole set of yasp-scripts I submitted are designed to run in a panel configuration, as they are doing in the third screenshot. That's using most of a horizontal full-width max-height (1/3 screen) panel across the top of my top monitor (of two, stacked), 1920x1200 monitor so 1920x400 panel, set to always-on-top, so I have system performance always visible. (BTW, I've modified the layout a bit since the screenshot, narrowing the views a bit and eliminating the diskstats one, in ordered to fit a syslog tail of 20-some lines, cut to 108 char width.)

But of course while that panel's only a sixth of the screen-space (a third of one monitor, of two) on my main machine, it's more panel than some netbooks have screenspace! So obviously, that's not going to work for everyone.

The solution I came up with on my netbook was to configure the dashboard as a separate activity (option available from kde 4.4, I believe), and put all my yasp-scripts and other general system status plasmoids (including the system-tray and the sys-log-tailer yasp-script I mentioned above) on the dashboard activity. That allows me a full-screen system-monitor "popup", by simply triggering the dashboard.

But popup implementation would be nice...

Of course, it can be done now, sort-of. In addition to the dashboard solution, there's another, if you want to take the time to configure it.

What you'd do is use the plasmoidviewer applet (ships as part of plasma-workspace, on gentoo anyway), to run your yasp-scripted plasmoid in a window instead of as part of the desktop activity, panel, or whatever.

You'd then setup a popup launcher for it as you would for a normal application. If the command line is complex, simply create a bash scriptlet that launches plasmoidviewer with the appropriate command line, thus giving you a simple one-word command-line bash script to invoke.

Then, for hotkey or gesture triggering, create an "input action" (in kcontrol/personalsettings/systemsettings) with the appropriate hotkey or gesture triggers. OR...

For icon-click triggering, use kmenuedit to create a menu entry, complete with desired icon, then (with widgets unlocked) drag it from the menu to your preferred containment (panel, folderview, activity, launcher) to create an icon launcher.

If desired, you could then use existing kwin "special window settings" functionality, to configure where the window pops up, make it borderless (you'd then use the keyboard close-window shortcut to close it), set the correct size, always-on-top, whatever.

So the functionality is already there in kde and yasp-scripted itself. It's just that as with yasp-scripted in general, it's a flexibility-first, configure-it-for-your-own-needs, thing, not something that ships pre-configured out-of-the-box for every anticipated usage, but at the same time limiting the flexibility for other-than-anticipated usage. True, people who don't want to bother with learning how to configure it on their own will have problems with this, but then again, yasp-scripted was never targeted at the "run-it-as-it-comes" crowd in the first place. There's other, more appropriate plasmoids (and I might add, more appropriate desktop environments), for the "I don't want to configure it, I just want it to work" non-power-user. - May 29 2010
yasp-scripted doesn't provide conditions AFAIK, but it doesn't need to, as bash does.

bash actually has the generally rich conditional branching choices available in many programming languages, including if/then/else/elif/fi (fi is the reverse of if, closing the conditional), case/esac, with shell style wildcards, while/until loops, etc. Take a look at a bash tutorial (or the bash manpage or info pages) and/or issue the command "help <builtin>" (where <builtin is the if/case/while/until or other bash builtin of interest) at the command line, for a briefer description. It's also possible to use the test builtin (commonly seen as a [ -x "$var" ] or [[ -x $var ]] style test) and simple exit code results, along with boolean logic operators like &&, ||, and !.

Scripts with conditionals are, however, generally complex enough that they don't fit well directly within a yasp-scripted sensor command itself, so the usual solution in that case would be a separately created bash script, with the yasp-scripted script simply invoking it as its command.

There is in fact one invoked bash script of "intermediate" complexity, shipped in my scripts pack as yasps.diskstats, with examples of functions, if/then/else branching (even nested), [] and &&/|| logic, etc (I don't see any case or while/until logic, tho). You can see how a yasp-script invokes it in the disks script.

Or, you can take a much simpler path and simply truncate the output to the maximum desired length, so it doesn't unreasonably widen the plasmoid. An easy way to do that is to simply pipe the existing output to the cut command, telling it at what character you want to truncate. Unfortunately, all the shipped script usage examples seem to use cut's -d delimiter and -f fieldnumber options, instead of the -c character-range option, but it takes a simple list or range, so:

<existing command> | cut -c -20

... gives you the first 20 characters, and...

<existing command> | cut -c 2-10

... would skip the first character and give you the next 9.

You can even do this:

<existing command> | cut -c 3-5,10,23-

... to get chars 3-5, 10, and 23 to the end of the line (altho if the line's of unknown length, that obviously wouldn't limit the output length, just shorten it a bit).

Simple, eh? =:^)

FWIW, the cut manpage has the details. As demonstrated by all the shipped examples, often, using the delimiter and field number options works better than using the character option. Head and tail are similarly useful "small and simple" commands, which together with sed, grep, pipes/redirection, and conditionals, help give Unix shell scripting the power it's rightly famous for.

FWIW, you could probably optimize things a bit from that cut, by tweaking the grep or sed appropriately, cutting the cut out of the pipeline while still getting the same effect, but as should be obvious by now, that gets pretty complex, with a simple pipe to cut being much easier to figure out if you're not extremely well versed in regex syntax as well as grep/sed options and commands themselves. That's where even the experts started! =:^) - May 28 2010
Several comments have mentioned hard drive temps, but the two at least appear to be at the max-reply-depth for kde-look, so it doesn't have a reply button for them. So I'm starting a new thread.

One single purpose and thus reasonably simple app that can report and monitor hard disk drive temps is the unsurprisingly named "hddtemp". It works for SATA, PATA, and SCSI drives. In simplest form, you can run it as follows, tho you probably have to run it as root (thus using sudo or the like) if it's not installed setUID on your system.

hddtemp <device>

Here's the the command and output for my four drives, as run (from my admin account, configured for unrestricted and passwordless sudo access) here:

sudo hddtemp /dev/sd[abcd]
/dev/sda: ST3300831AS: 47°C
/dev/sdb: ST3300831AS: 48°C
/dev/sdc: ST3300831AS: 47°C
/dev/sdd: ST3300831AS: 46°C

So assuming that sort of output and that appropriate sudo privs are configured for the user running yasp-scripted, a the command to get the temp for /dev/sda, as used in a yasp-script sensor command, might look like this:

sudo hddtemp /dev/sda | sed -n 's/.* \([0-9]\+\)°C/\1/p' - May 27 2010
That's all the sensors command outputs? If so, all you need to do is sed for the temps. If not, you'll have to grep for the adaptor (using the -An option to include n additional lines after), then grep or sed the result.

Assuming that it's the whole sensors output, try this as the command for temp1, change the temp1 to temp2 for it (if you don't want the fraction, simply omit the . in [0-9.]):

sensors | sed -n 's/temp1: +\([0-9.]\+\).*/\1/p'

You can try that on the command line and see what it outputs, before trying it in your yasp-script.

If you have other temp1 sensors as well, you'll probably need to grep for the adapter first, so you get the correct temp1, as so:

sensors | grep -A3 acpitz-virtual-0

So then the complete command looks like this:

sensors | grep -A3 acpitz-virtual-0 | sed -n 's/temp1: +\([0-9.]\+\).*/\1/p'

(As none of those lines include the " char, you can use it as the command delimiter in the yasp-script.) - May 27 2010
In that case, just change the "double" on that math sensor to "int". Should do the trick. It won't be quite as accurate, the reason I used double in the first place, but it sounds like a bit of rounding error isn't something that concerns you, and putting the multiplication first helps too. - May 13 2010
percentage of RAM currently in use, not counting buffers/cache.

Should be easy enough (famous last words!). You're wanting app RAM (not counting buffs/cache) divided by physical RAM (not counting swap), right?

Getting the two values is reasonably easy. Here's the sensors I use, as should be in the files I contributed to the tarball, minus the KB > MB conversion. (Note that each sensor is one line, regardless of what the wrapping as displayed here is, and that I'm retyping them "raw and untested", so there might be a typo in the form of a missing quote or some such. Testing and typo correction's your job. =:^)

# mem.phys in bytes

sensor name="mem.phys.kb" type="program" cmd="sed -ne 's/MemTotal: *\([0-9]*\).*/\1/p' /proc/meminfo"

# mem.appl in bytes

sensor name="mem.appl.kb" type="engine" cmd="systemmonitor:mem/physical/application:value"

# What's left is a math sensor to combine them with the appropriate division

sensor name="" type="math" use="mem.appl.kb" use="mem.phys.kb" math="double $1 100 * $2 /"

Of course, you could do the math at the end of the second sensor and not include a math sensor at all, if desired, and that's probably how I'd actually deploy it if I wasn't using the mem.appl raw KB number, but I left it as three separate sensors here, for clarity.

The other alternative, which I chose to use in my memory display as is now shipped in the tarball as an example, would be to convert both mem.phy and mem.appl (as well as buffer, cache, and total used) to MB, (divide the raw numbers by 1024), and display them both as-is, and plotted, with the physical RAM number hard-coded as the plotter max. This effectively gives me percentage as plotted, since the plotter domain is 100% of the physical memory, but megabyte values as displayed. Given that multiple values can be plotted at once, I can plot used/appl/cach/buff all on the same plotter against physical RAM as 100%, giving me several times the information of a single plot, while using no additional display space. =:^) The only additional display space used would be if all values were to be displayed as text as well, which I do, but which you could omit if you're short on space. - May 13 2010
Waiting for: HomeUsed. [...]

sensor name="HomeUsed" type="engine" cmd="systemmonitor:partitions/home
/usedspace:value" math="int $0 256 /"

Do you have a separate /home partition, or is it on the same partition as / ?

yasp-scripted is designed for you to be able to create your own system monitor scripts to fit your own needs and system layout, possibly modifying the ones shipped with it as examples, possibly creating your own, from scratch. If you're not modifying them for your own installation, you're missing the point, and there's likely a lot that's going to be broken -- that'd be just the first bit it couldn't understand.

If it's waiting for that system monitor engine value, it's probably because that value doesn't exist, which is probably because that partition doesn't exist. Check the README.syntax file shipped with the sources for the details, but in short, try running "plasmaengineexplorer" and taking a look at all the systemmonitor data-sources. If you have a partitions/home/usedspace source available, the problem is something else, but it won't be available if you don't have a separate partition mounted at /home, which is what I expect is the issue there, because you've not customized the script for your system. - Apr 17 2010
[AF: Could you put a note at the top to take care and erase extra Re:s in the subjects? They crowd out the subject after awhile. =:^( Plus, people might pay more attention to the subjects then, and change them if the subject of a (sub) thread changes. =:^)]

I was sick from yesterday and so slept a lot, then slept a lot again today, too. You know the free association, strange ideas and stuff that happens when you're kind of floating between sleep and awake? Well, I was there, and while a lot of the stuff was crazy, as usual, I did realize something... which I've made a bit more sane as I woke up and am writing this.

No, yasp.s doesn't have alarms per se, but there's no reason the script feeding yasp.s the values to monitor couldn't also check them, and trigger either a beep, or the playing of a short audio file, if they go out of range. One would need to do so in the background, so the script can finish and it won't hang yasp.s, but that's no big deal.

Actually, probably the best way to handle it would be to put the alarm handling in a secondary script, that could be called with say four parameters, the current value, the high-trigger value, the low-trigger value, and the command to play the alarm, if necessary. That way, the alarm script could be reused in any script without having to rewrite it in each.

Having it take the entire command, not just the audio-file, would allow people to change the player easily, if necessary because they don't have a particular player on their system. The command would include the audio file to play, which could then be customized so different alarms played different files.

Now you'd want to keep the audio clip short, a second or two, so as it's repeatedly triggered, it finishes playing before the next sensor update triggers it again.

Alternatively, some non-audio cue could be given as the command, say to flash the screen or whatever. I don't really know the sort of command that would do that, but I'm sure there's something.

There should probably be a check of some temp file, say $KDETMP/yasp.s.alarms-disabled, which if present, would disable the alarms, as well. That way, one could simply touch that file to hush the alarms and allow one to get on with fixing the problem.

Just a bit of brainstorming. Maybe I'll hack up such a script, maybe not, and who knows when I'd do it, but anyway, perhaps this points someone in the right direction to implement it if they want it bad enough.

Better yet, if someone with C/C++ skills could create a native code version that could be compiled, taking the four parameters I mentioned above on the command line and checking the shutup file mentioned above (with a sane default path, say /tmp/tmp-<user>/yasp.s.alarm-disable, if $KDETMP is unset), it'd run faster, thus saving CPU time over a bash implementation, which is what I'd be able to do. That's important when the thing is called perhaps every second, by multiple yasp.s sensors! - Feb 04 2010
Sure. I didn't include anything like that in the set of scripts I sent in earlier, because that was for my desktop/workstation. But I recently replaced the Linpus that came on my Acer Aspire One netbook with Gentoo, using KDE 4.3, just as on the main machine, and rejiggered my yasp-scripted scripts for it. Of course I needed battery info, and I happen to have that all setup already, here. Of course you may have to change commands and paths slightly for different hardware, but here's what I have. (To solve wrapping issues, I'm formatting each line as a paragraph, with a blank line between. So a single line might appear as several here, but everything between the blank lines is a single line. I'm omitting colors, etc, which you can choose and add as desired. The below is read off the script on my laptop, retyped on the browser on the main machine, so there may be typos, missed quotation marks, etc.):

For a battery percent plotter and text readout:

sensor name="batt.pct" type="program" cmd="acpi -b|cut -d' ' -f4|cut -d% -f1"

plotter use="batt.pct" plot="$1" max="100"

value key="Battery " use="batt.pct" format="$1 %"

Adding to that a battery status indicator (full, charging, discharging...):

sensor name="batt.stat" type="program" cmd="cat /sys/class/power_supply/BAT1/status"

text use="batt.stat"

OK, what about time remaining on battery or to charge?

sensor name="batt.time" type="program" cmd="acpi -b|cut -d, -f3|cut -c 2-9"

text use="batt.time"

Now the AC Adapter status (on-line/off-line, you'll note the .. in the name. I try to keep my names of uniform length so the fields line up easier and it's easier to edit, no other significance, just personal preference):

sensor name="" type="program" cmd="acpi -a|cut -d: -f2"

value key="AC Adapter" use=""

Finally, if you have laptop-mode-tools installed and configured on your machine, you may find its status useful to know as well. In particular, I noticed here that with just AC plug event detection, if I suspended with the machine plugged in, then unplugged and later resumed, the unplug event would have been missed as it happened while suspended, so laptop mode wouldn't activate. Having a display specifically for it allows me to double-check that, and issue the appropriate command manually to start or stop laptop mode, if needed. So here's a simple monitor for that, displaying either 2 (laptop mode enabled and on battery) or 0 (disabled and on AC):

sensor name="" type="program" cmd="cat /proc/sys/vm/laptop_mode"

value key="Laptop mod" use="" - Feb 04 2010
That's an interesting trick...

sed is "stream editor". Do you know regular expressions (regex)? That's one of sed's strengths. In this case we're using the sed s/original/replacement/modifiers command, where the s stands for "substitute". So, it says, substitute for a given string, some other string.

Quick review of some regex basics: "." means "any character" and "*" means any number (zero or more) of the preceding symbol, so ".*" in regex is equivalent to the "*" wildcard in shell patterns (as used in filenames and the like, *.txt, for instance). The backslash is used as it commonly is, as an escape character, meaning treat the next character other than you normally would, and the combos \( and \) enclose a segment of the expression for two purposes, grouping (treating the group as a single unit, \(at\)* means one or more "at"s, but won't match a string of only "a" or only "t", or ata, for that matter as it's lacking the final t, but it would match atat or atatatat), and saving to a buffer for use later in the expression. Here, they /are/ used later, in the replacement string, as \1 and \2.

So what the sed is doing, is taking a string of the format <anything>Temp:<single-space><numbers><anything>Temp:<single-space><numbers><exactly two characters of anything>, and returning /just/ the two strings of numbers (which are saved in buffers 1 and 2 by the \(\), then used in the replacement), separated by a single space. (Note the spaces between the :s and the number strings, and the two terminating dots, matching exactly two characters. I almost missed those.)

That (yasp.s) sensor won't be used directly, but rather, it'll be reused by presumably two additional (yasp.s) sensors, one of which uses the first number, the second of which uses the second.

The strategy is to avoid running the (lm_)sensors command (well, the whole string of commands) twice, thus making it perhaps more efficient than a script that repeatedly calls the (lm_)sensors command. It should run in a fraction of a second either way, but when you're running the script repeatedly every second or two, saving the overhead of another command call in the pipe is a significant savings. Additionally, both temps are read at the same instant, instead of calling (lm_)sensors twice, with perhaps the value changing between.

grep and cut could indeed be used instead, but it'd take a pipe of a couple additional commands to do it, since there's a (regex) ".*Temp: " in between them if it was reduced to the same string in the first (yasp.s) sensor. To avoid that, the first (yasp.s) sensor would then probably simply grep the string including the junk in the center, with the sensors building on it doing cuts or greps off the beginning and the end, ignoring the garbage in the center.

So it's a matter of style whether one uses sed in the initial (yasp.s) sensor, stripping the string down farther initially, or grep or cut, leaving a bunch of garbage in the initial result, which is then stripped by the later (yasp.s) sensors that use the result of the first one. But I do appreciate the insight of just running the (lm_)sensors command once, storing multiple data values in a result to be used by additional (yasp.s) sensors later. Presumably, yasp-scripted is more efficient at that, then bash is at running the extra commands, with the result being a savings of (for argument) say 1% over running two separate (lm_)sensors calls, each one doing its own piping to filter the garbage to the specific value it wants. - Feb 03 2010
More than than one command per line? [L]ike:
"download: xx | upload: xx | cpu: xx | ram: xx |"

Yes. See the README.syntax file, value section.

Basically, you define your separate sensors, then in your value line, you use multiple use= parms, and a format= parm listing them all with $1, $2, etc, at the spot where the values for the respective positioned use parms would go. There's even a multi-sensor example. =:^)

As documented, the default format is only "$1", so don't forget to add a format= parm, or it'll only show the first sensor value. As the example demonstrates, you can fill in text between the substituted values, so yes, your given line with four sensor values on the same line, complete with labels (which would be part of the format string), is quite possible.

There are a couple caveats, unfortunately. It seems the whole line takes the same color, so you can't multi-color the line. That's actually what prevented me from using it, as in most cases, my value lines corresponded to an element in a plotter as well, with the value lines serving the dual purpose of plotter color key and text readout. That was the big issue here, but a lessor one is that while I used a monospace font to maintain alignment, being very careful to allow spacing for the variable number of digits so the alignment wouldn't get screwed up, that's pretty much impossible with multiple value readouts per value line, because in most cases, each one can be variable digits wide, and multiple variable digits just doesn't allow for the possibility of proper alignment.

So yes, you /can/ have multiple output values per line; but the caveats may or may not be something you're willing to live with. If you have one long line of readout and thus don't need vertical alignment, it's possible, but you'll still lack the ability to color-code the individual outputs, and that was a deal-breaker for me. - Jan 24 2010
Just what I was going to say, check my scripts.

On the disk I/O, the kde system monitor data engine wasn't able to track md/raid last I checked (it had dummy values that were always zero), and I have md/raid, so I had to make my own script to handle that. The kernel makes the raw totals available in a file (in /proc or /sys IDR which, see the script), but I had to figure out how to track the last value, so I could do a comparison and get the difference between current and last. I used a tmpfile for that. Once I had the mechanism working for that, I was just simpler to use it for all my disk i/o, including the ones the engine supported, so I did.

On the network bandwidth, you could use similar techniques to track running totals, if desired. Also note that if you have iptables/netfilter installed, it can track the running totals over reboots, etc (but of course loses any from the time of the last iptables-save, in the event of a system crash). You could use that mechanism to save the numbers over reboots, and just do the iptables-save without a redirect to file, to grab the numbers for a script, if desired. (My Internet has no monthly/daily bandwidth cap, so I don't need to worry about that.)

For temps and stuff, the sensors command (package lm_sensors, probably a dep of what you're already running tho so likely already installed) gives you text output, which can be scripted. Or, the numbers are normally available in /sys, as well. Again, see my scripts.

I just got my netbook up and running. The acpi command gives me battery info, and again, there's /sys interface data I can use, as well. That's not in the tarball as I didn't have the netbook setup when I sent my scripts and screenshot in. What I sent in was off my main machine. - Jan 22 2010
... which would be fine, if there was some way to see what the scale then was. Knowing it's maxing out the graph doesn't help much if, to use the OP's example, I'm supposed to be getting 10 MiByte/s, but for all I know it's maxing at a MiByte/sec. - Jan 13 2010
> There is something just like this
> (if I could only remember the
> name!!).

Maybe superkaramba? FWIW plasma supports superkaramba themes now too. =:^)

But superkaramba is a bit more complex to learn (because it's a bit more powerful). Yasp-scripted is indeed very similar, but doesn't have the widget positioning bits as it simply reads the scripts top to bottom and places the widgets vertically in order as it reads them. To get multiple columns with yasp-scripted, you use multiple instances of the applet (as I did for the scripts and screenshot I contributed). As I didn't know superkaramba's scripting language yet and was looking for a solution I could get up and running with on kde4 (since there's no ksysguard kicker applet replacement and the kde4 app formerly known as ksysguard, itself, is terribly buggy at restoring settings), yasp-scripted was easier for me to start with, tho I expect I'll at least try superkaramba some time in the future, and keep to it when I do unless it has worse performance.

> 1. Everything in plasmoids needs be
> asynchronous. If it is "waiting for"
> something, plasma will hangup
> waiting. Your implementation may in
> fact be OK, but should pass the wait
> after a short! time, leave field
> blank (as the above app did).

That was indeed an issue at one point. I /think/ it has been fixed now. Well either that or I got the bugs in my scripts worked out. Probably a bit of both. =:^)

> 2. Most any attempt to live-edit the
> script and reparse crashes plasma.
> So no way to try and fix scripts.

That does remain somewhat of an issue, but it doesn't mean there's no way to edit/fix the scripts. Presumably, someone advanced enough to know how to do their own scripts in the first place can figure this out, but FWIW, krunner is entirely separate from plasma, as is khotkeys. Actually, due to plasma not yet having temporary panel retract buttons like kicker did and the hassle of reconfiguring panels just to get them out of the way when necessary, I deliberately killall plasma-desktop at times, and simply use krunner and khotkeys for invoking apps, until I'm done with whatever I wanted the panels out of the way for and can restart plasma-desktop (using the same krunner or khotkeys mechanisms).

Thus, when I made a mistake in a yasp-script (plotter using a sensor that wasn't there, due to a typo in the name) and it was triggering plasma-desktop crashes, I simply launched my editor using either krunner or khotkeys (IDR which), and did my editing from there. Of course, I could launch plasma-desktop to test my changes the same way.

As I said, while some users may find this challenging, in general it shouldn't be rocket science for the types of users already advanced enough that they're doing their own scripts.

> I am looking for a ksensors
> replacement so a better system
> monitor is the best idea.

I know the feeling. It'd have been great if there was a plasmoid to parallel the ksysguard kicker applet from kde3 -- and of course if the application formerly called ksysguard (in kde3, in kde4 called the so generic it entirely fails as a proper app identifier, system monitor) wasn't so buggy in kde4. I expect the latter will eventually be fixed, but with kde dumping kde3 support well before kde4 was up to replacing it, I didn't have luxury of being able to wait for that, unfortunately.

Yasp-scripted stepped in to fill the gap (and then some!). =:^) Of course, superkaramba would have done so and been even more powerful, but its additional complexity (even if that brings additional power as well) was a bit much to take on at a time when I was already spending way more time working on the upgrade from kde3 than I expected, and than I would have spent if kde had continued to support kde3 until kde4 was an appropriately stable and mature replacement for it. Unfortunately, they didn't, but fortunately, yasp-scripted was there when I needed it. =:^) - Jan 02 2010
> icons should be cached in RAM,
> so the file is not re-read
> every time the "value" containing
> an icon refreshes

That shouldn't be a problem, given a sane kernel (such as Linux). The system file cache (in RAM) should be enough, as the kernel will automatically take the read request and fill it from cache without ever going to disk, if it's in cache. For something reread every few seconds, it's not going to be dumped from cache, so there should be little issue, regardless of what the app itself does.

Yes, an strace will likely still say it's being opened, read and closed every update, but the disk activity LED shouldn't light up (unless something else is going on), as it'll be loaded from the system file cache.

Still, while I don't do icons here (too much data to display in too little space as it is) and thus I haven't followed what yasp-scripted does with icons, presuming the icon isn't changing, it'd be nice if the icon load could be made single-shot, regardless of what the timeing on widget it's associated with is. No need to be opening, reading and closing the file, plus redrawing the same icon every few seconds. That's a CPU activity sucker, especially since the file-read will require switching to kernel mode, even if it is in cache. (Actually, the same but to a lessor extreme could apply to the value labels, which don't change, just redraw the value data not the label. Maybe yasp-scripted already does this?) - Dec 29 2009
... Or try using a smaller or at least narrower font... - Dec 03 2009
Hmm... I don't use meters here, as I like to see the trends and thus use plotters instead. The plotters don't display a number, however, just the plot, so I use a value line as well, thus getting a text readout of the current number as well as a plot over time.

What happens if you add a value line? Does it show the whole thing, or is it truncated as well? Does the meter have enough room to display the whole thing?

Here's a value line to try:

value key="RamApp" use="RamApplicationMb" format="$1 MB"

If that shows up correctly, then the sensor is correct, the number is just being truncated in the meter display. As I don't do meters I can't help much there. If the number is coming up 05 instead of 805 there as well, then perhaps it's a sensor issue, and since the sensor is using the systemmonitor engine, it's likely a bug in it, that is, in kde itself, since that's where the engine is.

FWIW, I'm running Gentoo/amd64 here, so 64-bit, without issues, but as I said I don't do meters only plotters and values, so I'd not have seen any meter issues, and of course if it's a distribution bug, I'd have missed that too since I'm on a different distribution. - Dec 03 2009
Well... /THAT/ didn't work! Sleep behaved as it should, but with all of plasma apparently being single-threaded, the delay for the one script not only caused it to fail, but all the others to fail as well! Plus, the entire plasma desktop (both desktop and panels) was frozen for the length of the sleep, or until yasp-scripted timed it out and returned the usual sensor can't be registered error after about 10 seconds, if the sleep was 10s or longer.

Which reveals the other side of the coin. Yasp-scripted must be careful with its timeouts, because they freeze the entire plasma desktop during the wait! The same is true for users creating scripts. Anything they call that takes time to process... will apparently freeze the entire desktop until the processing is done, or until the timeout, whichever is first.

The ultimate fix would therefore be a new version of yasp-scripted, that (1) either shortens the timeout again or makes it a script or sensor configurable setting, and (2) introduces a new optional sensor parameter, at least for type engine and probably for type program as well, that sets the value to return on timeout. If this value isn't set, it'd return the current warning, "breaking" the script as it currently does, as that's useful for troubleshooting purposes in case of typos and the like.

(The one change I'd make to the warning, however, would be to wrap it at some arbitrary width, say 25 characters, as doubling or more the expected width of the plasmoid isn't particularly practical, especially when you have multiple yasp-scripted plasmoids lined up side-by-side on a panel, already filling the available width.) - Nov 06 2009
He's talking about modifying the yasp-scripted plasmoid source code itself, then recompiling it, as can be seen by the reference to the *.cpp file.

FWIW I've not tried it, but may, as I have the same issues here.

I have an idea that might work in a script, however, but haven't tried it yet. If the script is parsed in order as I suspect, it's possible a single-shot sensor at the top, type program, that simply called sleep, for a user-configurable number of seconds, might just do it. This "delay" sensor wouldn't have to be hooked up to an output, simply fired one-shot. If it works, that would be enough to give plasma and the rest of the system time to settle down, before the script started running normally.

I'll have to try it and post back... - Nov 05 2009
I'm using yasp-scripted as a more-flexible substitute for the missing "application formerly known as ksysguard" kicker applet in kde4. In kde3 I had a LOT of stuff graphed, so I missed that applet quite a bit until I found yasp-scripted and got my sets of scripts setup.

So now I have about eight scripts, designed to be lined up across a 400 px high (max height, here) panel, graphing and current numbers for CPU activity (four cores, separate user/system/nice/wait/total, %), memory (separate app, buffer, cache, total-used, swap-used, MB), load&fans (1/5/15 load average, 4 fans, RPM), temps (four core temps, five system temps, C), disk activity (read and write graphed separately for four separate disks, MB), Eth0 net activity (separate Rx/Tx, four graphs 8X factor, no wifi but it'd not be hard to adapt), and time&top (time locally and UTC, date, last repository sync, last boot date, day and week of year, Unix time in seconds updated 1/min, CPU% top five, Mem% top five).

I run them eight-across, lined up on a horizontal panel. It'd make a great screenshot for this kde-look page.

Additionally I created a gentoo ebuild, which could be posted.

The question is, what's the best way to get it to you? I suppose I could send the scripts and ebuild via the contact thing, or here, but I'm not sure whether they'd get line-wrap mangled. And the screen-shot...

I think you can click my name on the message and send me a private mail with your email address if you like. Either that, or if you have someplace I could upload them. Or I could imagebin/pastebin them, I suppose, if you'd get around to fetching them soon enough. Your call. - Oct 22 2009
Score 82.1%
Oct 22 2009