Assuming that when you saw "full" that meant AC connected but fully charged, 
here is what I have. Probably should be tested on all 3 platforms before 
letting it fly as a finished utility. Works a peach on the Mac.

function getPowerSource
   -- returns the current power source for a laptop
   --    "AC" or "Battery"
   -- 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
         return 
caseSwitch(tStatus,"discharging=Battery","charging,full=AC","*=*")
         -- if non-standard,
         --    just returns whatever "/sys/class/power_supply/BATx/" reports
   end switch
end getPowerSource

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig


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
> ____________________________________________________________________
> ambassa...@fourthworld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to