Power Status (was Re: Because LC can't do two things at once.)
Peter M. Brigham
pmbrig at gmail.com
Tue Mar 3 15:03:54 EST 2015
OK, as usual, I find some tweaks *after* I hit the send button. I changed caseSwitch() so it handles the case of an empty tCheckValue, allowing getPowerSource() to report "no battery" if getting the URL returns empty. The expansion of caseSwitch() is useful in and of itself….
-- Peter
Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig
----------
-- watch linewraps
function getPowerSource
-- returns the current power source for a laptop
-- "AC" or "Battery"
-- or "no battery" if there is no battery (Unix)
-- requires caseSwitch()
switch the platform
case "MacOS"
-- thanks to Martin Koob, use-LC list
put shell ("pmset -g batt") into tSource
-- returns something like:
-- Currently drawing from 'AC Power'
-- -InternalBattery-0 99%; finishing charge; 0:00 remaining
return char 2 to -1 of word -2 of line 1 of tSource
break
case "Win32"
-- thanks to Bob Sneidar, use-LC list
put shell("WMIC Path Win32_Battery GetAvailability") into tSource
-- Line 3 will contain 2 if the battery is charging, 3 if running on battery
put line 3 of tSource into tStatus
return caseSwitch(tStatus,"3=Battery","*=AC")
break
default
-- Unix, thanks to Richard Gaskin, use-LC list
put url "/sys/class/power_supply/BAT0/" into tStatus
if tSource = empty then put url "/sys/class/power_supply/BAT1/" into tStatus
put word 1 of tStatus into tStatus
return caseSwitch(tStatus,"discharging=Battery","charging,full=AC","=no battery","*=*")
-- if tStatus = empty, returns "no battery", else if tStatus is non-standard,
-- just returns whatever "/sys/class/power_supply/BATx/" reports
end switch
end getPowerSource
function caseSwitch
-- does a quick inline switch/case
-- param 1 is checkValue
-- params 2+ are in the form matchValue(s)=returnValue
-- separate multiple matcheValues with commas
-- and enclose each matchValue=returnValue pair in quotes
-- if checkValue matches one or more items in matchValue(s),
-- returns returnValue
-- note that checkValue should NOT be enclosed in quotes
-- use a matchValue of "*" to specify a default value,
-- to be returned if no matches found in the list
-- if the default is "*=*" then no match returns the original checkValue
-- if no match and no default value specified, then returns empty
-- usage:
-- put caseSwitch(len(tZip),"5=zip","10=zip+4","*=not a zip code") \
-- into zipCodeType
-- from Ken Ray, use-LC list, originally named stsSwitch()
-- revised by Peter M. Brigham, pmbrig at gmail.com
-- to catch an empty checkValue, eg,
-- …,"=empty input",…
put param(1) into tCheckValue
set the itemDel to "="
put "" into tDefault
repeat with x = 2 to the paramCount
put param(x) into tCheck
put item 1 of tCheck into tMatch
put item 2 of tCheck into tRetVal
replace "," with "=" in tMatch
if tCheckValue = empty and tMatch = empty then return tRetVal
if tCheckValue is among the items of tMatch then return tRetVal
if tMatch = "*" then
if tRetVal = "*" then
put tCheckValue into tDefault
else
put tRetVal into tDefault
end if
end if
end repeat
return tDefault
end caseSwitch
On Mar 3, 2015, at 10:29 AM, Richard Gaskin wrote:
> Peter M. Brigham wrote:
> > So it looks from your links that I should use "/sys/class/power_supply
> > /BAT0/" for the URL on Unix, and check for "charging" or
> > "discharging" as the first word??
>
> ...or "full", as I saw last night while testing this.
>
> So far I'm only seeing one-word values, so using "word 1" would seem a safe choice - good call.
>
>
> We have one remaining mystery, however: my Dell has only one battery, but has no values at /sys/class/power_supply/BAT0/, instead using /sys/class/power_supply/BAT1/.
>
> I've read other cases online where folks find the same thing, but haven't found the definitive rule governing why.
>
> In my reading I also came across some laptop models (Toshiba came up a couple times) in which the battery firmware doesn't report its info in a standard way, making it more difficult for generalized utilities to obtain it. But frankly, if an OEM chooses to disregard published standards personally I can't see spending much time accommodating them, so I'm not too worried about such edge cases.
>
> Given all this, I would feel reasonably safe at this time with the following algorithm:
>
> First check BAT0/status
> If empty then
> check BAT1/status
> end if
> If both are empty there's probably no battery
> If a value is found then use it
>
> I've seen no mention of BAT2 or more, so I feel this should account for a reasonably useful range of contexts.
>
>
> My own goal here is to know whether I can feel save performing optional background processing which can improve performance but at the cost of battery life.
>
> So either "full" or "charging" implies that the laptop is plugged into a wall socket, so I'd proceed with those background tasks.
>
> And if no battery info can be found at all in either location (BAT0 or BAT1), it seems safe to assume we're not on a battery-powered device, so I'd also proceed with optional background tasks.
>
> So it's only when the status returns "discharging" that I know a battery is present and that it's not plugged into a wall socket, in which case I should at least let the user decide whether or not to run optional background tasks.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
More information about the use-livecode
mailing list