[REQUEST] Add battery meter

[foundObjects]

It would be nice to have some battery/power info included in bpytop for battery backed systems (laptops, machines with UPS)

must haves for a basic feature: battery power status/meter (battery at xx%, meter or gauge, etc) power state (on battery, on A/C power)

nice to have: instantaneous power draw estimated time to empty

htop does the basic bits (battery meter, plugged status) well

[aristocratos]

@foundObjects

This should be doable since psutil provides the needed info https://psutil.readthedocs.io/en/latest/#psutil.sensors_battery

I'm not sure about placement though, maybe in the top bar where the clock is.

Power state could be indicated with an up arrow for charging and an down arrow for discharging.

Power draw isn't available so that's a no go.

Estimated time is available and could be expressed in "HOURS:MINUTES" to not take up to much space.

So maybe something like BAT↓|50%|[#####-----][HH:MM] but with the fancier kind of meter.

Will take a look at it when I've got time.

[RedBearAK]

I guess that would end up in the space where I was suggesting the uptime should be displayed. I'd be sad about that, because of how nice this looks:

What about putting the battery info on the bottom line of the CPU box, above the process box? I've played with putting the uptime down there and it actually didn't look that bad, but I much preferred how it looks up there balancing out the top bar elements. If you're proposing something for the battery info that will be much longer than the uptime display in my screenshot above, it might look best down there just above the process box.

I would also vote for a variable to disable (hide) the battery info display if desired.

[RedBearAK]

With the right number of characters the battery info could look very good centered on the bottom CPU box bar. Had to use a "fake" uptime output to get this screenshot. Main problem with the uptime output is the length keeps changing.

Same but in "full" view mode:

And in "proc" view mode:

Aligning it to the right really doesn't look as good (but a longer, fuller battery info display with a graph might look much better aligned to the right than this does):

[RedBearAK]

@aristocratos

Silly me, I realized that I had all the code necessary to do a test display showing both uptime in the top bar and your proposed battery info format in the bottom bar. Here it is in all three view modes.

With the fancy graph style this could be pretty nice!

Here's a simpler version, both centered and right-aligned.

[aristocratos]

@RedBearAK I would probably move the uptime to the center lower part of the cpu box if the uptime move is decided to be implemented. Since the battery in the top right corner is more likely were people would except a battery meter to be (from years of cellphone layout indoctrination). The battery would be toggleable though since there could be false positives of a battery being detected.

[RedBearAK]

@aristocratos

While you have a point about the "standard" location of the battery info on a mobile device interface, which I also thought about, many desktops especially in Linux have their battery info in a system tray which may be on the bottom left or bottom right (like Windows), or top right (like macOS) depending on where the default taskbar/panel is located.

It's just my opinion but I don't think that overpowers the logic of keeping the "time" elements near each other as a group. I also can't imagine how you would fit the proposed battery info in the top unless you allowed it to auto-hide at the minimum window size. The screenshot below is my initial test of this and it's already stepping on two thirds of the clock. Even if you cut the number of symbols down to 4 or 5, you'd have to de-center the clock to fit everything. Heaven forbid. shivers

Then there is the problem of the uptime output varying in length so much that it will be difficult to get it to be properly centered at all times. Unless it's possible to shift text elements by less than a single character width?

I look forward to seeing what you do with it. But this just doesn't do anything for me:

The one way I can imagine doing it would be to move the clock to the far right, with the battery info to the left of it, and the update_ms moved over near the menu and mode elements, which would make a sort of sense because those are all "settings" related elements, where the clock and battery info are "informational" elements. That arrangement would leave nothing centered on the top bar (clock and battery info would be tied to the right and expand away from the other elements when the window is enlarged), and it would mimic a typical top menu bar / taskbar / info bar in a way that many people would instantly understand.

I don't have the skills to simulate a screenshot of this, but hopefully you understand what I'm describing.

[RedBearAK]

@aristocratos

Aaaaand, I was bored and just wanted to know what it would look like, so I hacked together a mockup of the layout I described above. It's not half bad.

Edit: Just for fun, what if the update_string was bottom-right under the clock.

Or even both uptime and update_string right-aligned under the clock:

Oh dear, I shortened the battery graph and allowed the uptime to be longer, and this happened:

You can't tell me that doesn't look pretty good.

[RedBearAK]

@aristocratos

I'm seeing the new battery meter in the 1.0.30 update (looks quite nice at all sizes), but when I resize the terminal window it disappears from the top bar and won't return until I quit and restart the app.

This happens if I start small and resize larger, or start large and resize smaller. Just any resizing at all and the battery meter vanishes and won't come back until I quit and restart bpytop.

[aristocratos]

@RedBearAK This is likely because I coded it to not update unless the percentage has changed, so would most likely reappear when the percentage changes. Will add a forced update on terminal resize in next update.

[RedBearAK]

@aristocratos

Cool.

Another small issue, the battery info in BpyTOP is showing 99% with the last square on the graph dark, but the little light on the power adapter is green, indicating no active charging, and the battery add-on (Power Manager Plugin) in my XFCE tray is showing Fully Charged (100%). So there seems to be some kind of mismatch somewhere between whatever system info Power Manager Plugin is reading from and what psutil is reporting.

I can't think of any good reason for that mismatch. Psutil should not be reporting that my system is charging when it isn't. I'll have to look into exactly what psutil is spitting out on my system.

[RedBearAK]

@aristocratos

Just FYI.

Even just changing the theme makes the battery info disappear. No window resizing involved.

[aristocratos]

@RedBearAK

I can't think of any good reason for that mismatch. Psutil should not be reporting that my system is charging when it isn't. I'll have to look into exactly what psutil is spitting out on my system.

That's because the psutil percentage is a floating point and I used the default python round function to convert to integer, I can change to the ceil function to always round up to integer which should fix this.

Even just changing the theme makes the battery info disappear. No window resizing involved.

Changing theme triggers the same functionality as a window resize, that's why.

[RedBearAK]

@aristocratos

That's because the psutil percentage is a floating point and I used the default python round function to convert to integer, I can change to the ceil function to always round up to integer which should fix this.

Yes, that sounds excellent. But isn't the indication of "charging" vs "not charging" a separate function? I have the "up triangle" character displayed next to BAT at the same time, which would seem to indicate psutil thinks the system is charging. Sorry I didn't include that bit of info in the first post.

Changing theme triggers the same functionality as a window resize, that's why.

And of course I realized that five seconds after clicking "Comment". I guess it gets clobbered by the horizontal line characters on any window update.

[RedBearAK]

@aristocratos

Yes, any window update is an issue, including when I change the update interval:

Guess it's getting hit by the Symbol.h_line * 7 that comes before the update_string is displayed. That kept happening to me when I wanted to put the uptime in the same place.

[aristocratos]

@RedBearAK

But isn't the indication of "charging" vs "not charging" a separate function?

The charging indicator only updates with the rest of the battery stuff (when the cpu percent changes) so doesn't change the indicator until percentage changes. Will also be fixed in next update, I've added a couple of more conditions for a forced update to the battery meter.

[RedBearAK]

@aristocratos

Just saw the thread about the crashing when disconnecting the power cable. I guess that's all fixed already but I decided to pull my power cable and see what happened. So the battery percent changed and triggered the display update, but this happened (misalignment of battery info):

And then put the cable back to recharge and the battery info updated back to its original position, but left the glitch in place (of course, until something else updates the horizontal lines, I guess):

Repeated by quitting and restarting bpytop and disconnecting power cable for a while. Same thing happened. Battery info shifted over by about 20 characters, then went back to the original location after reconnecting the power cable.

[aristocratos]

@RedBearAK I'm not quite sure what that's about, will have the next update with the new fixes up tomorrow, let me know if that behavior isn't fixed then.

[RedBearAK]

@aristocratos

Will do. And as a last input this is what it looks like at the smallest 80x24 window size. It doesn't appear to be moving location but something definitely clobbers it while the cable is unplugged:

Discharging:

Recharging:

Am I reading the code right that there is no symbol to display for the "fully charged" state as opposed to the charging/discharging triangle symbols?

I have a laptop with a faulty power circuit that is constantly moving between charging and fully charged, and I'd prefer of that were accurately shown in the battery info by switching between the up triangle and perhaps a square, or just a blank space when there is no charging or discharging.

[RedBearAK]

@aristocratos

Version 1.0.31 stops the battery info from disappearing on window updates, but I still have the location shifting issue from above.

Now that the battery info element tries to refresh on every window update, I can see better what happens at the smallest window size. The battery info shifts over into the clock location, and the clock and battery info alternate clobbering each other with every window and/or clock update. If I increase update_ms the clock will always clobber the battery info quickly, but the battery info will reappear at every update interval, then get clobbered again by the clock.

So the "99%|-" in the small-window screenshot above is just a ghost, like the battery graph ghost from the larger-window screenshot above it.

It's just a theory but I feel like the location shifting issue is related to whatever triggers the battery time info to be visible or hidden. Unless that just coincidentally happens at the same time. But it seems to shift left when the time appears, and shift back to the right when the time disappears.

The shifted battery info at the smallest screen size also shows the time. Hard to catch a screenshot of it.

[aristocratos]

@RedBearAK

but I still have the location shifting issue from above.

Will take a look at it later, I probably messed something up in the placement calculation.

Am I reading the code right that there is no symbol to display for the "fully charged" state as opposed to the charging/discharging triangle symbols?

This is fixed but haven't released it yet, will do after I find the placement error.

[aristocratos]

@RedBearAK Should be fixed in v1.0.32

[foundObjects]

Just wanted to say thanks, this is super useful and it's exactly what I was looking for.

Cheers!

[RedBearAK]

@aristocratos

Location shifting is gone. Looks good.

I see the square now, but it's not accurately mirroring the actual charging activity when I plug the cable back in. It appears to flip from triangle to square right when the percentage goes from 99 to 100. But the red light is still lit on the charging cable and the system will be charging for another 10-15 minutes or so. The power plugin continues to say "Charging" and the time remaining until charged until the charging stops, even though it also says the battery is at 100%.

Percentage of charge with lithium batteries (or any batteries I guess) is of course a sort of rough calculation based on the expected battery voltage at each state of charge, so it's common for devices to charge for quite some time after the system reports the battery as being "100%" charged.

There should be a way to know for certain when the charging circuit is active or inactive, and change the symbol accordingly. However, looking over the psutil documentation, I think I can understand why this discrepancy remains. There doesn't appear to be a simple way to know if the system is actively charging. Only plugged or unplugged, and percentage/time. The options are more rudimentary than I expected.

I have to wonder if this could be mitigated by a simple trick like waiting until the charge percentage stops changing by some significant decimal value before switching to the square symbol.

Alternately, this command will report back "Full", "Discharging", or "Charging". Initial testing seems to indicate that it accurately flips from "Charging" to "Full" right when the light on my charging cable goes from red to green.

cat /sys/class/power_supply/BAT0/status

Anyway, the battery info is 99% working now, with no major issues to report.

Side note: I experienced some very long "pauses" while running that cat command in a loop. I am now beginning to wonder if there really is a unique hardware-specific issue happening to me, causing the freezing in BpyTOP from issue #87. In this case I was not even able to Ctrl-C out of a simple terminal command. I've never seen anything like it. So maybe it is unique to me, or a bug in the actual terminal application. And the worst part is that TimeShift wasn't running when the pauses happened. 8-{

[aristocratos]

@RedBearAK Added additional check of /sys/class/power_supply/BAT0/status in v1.0.33, should make it more accurate.

Side note: I experienced some very long "pauses" while running that cat command in a loop. I am now beginning to wonder if there really is a unique hardware-specific issue happening to me, causing the freezing in BpyTOP from issue #87.

That does sound suspect of a hardware issue, you could run through MemTest and some harddrive tests and see if you find anything.

[RedBearAK]

@aristocratos

bpytop: 1.0.33 psutil: 5.7.2

Not to rain on your parade but I just finally managed to get BpyTOP working on a macOS Mojave 2011 MacBook Pro via homebrew, and the battery info is still being very shy on this platform. Whenever I open the options menu and then exit the menu, the battery info disappears, and won't come back until something triggers an update. A change in the battery status will bring it back, but also switching view modes will immediately bring it back. But otherwise it will stay gone until something changes.

With background updates disabled it stays until exiting the menu. Otherwise it disappears as soon as I open the menu. I can see in the background that it's gone already.

On the other hand, the charge symbols do seem to be accurately following the actual charging state on this machine, so that's good news. It was easy to check because this is the machine with the faulty power circuit that keeps switching back into charging mode all the time. That part seems to be working well. Which is odd, because /sys/class/power_supply/BAT0/status shouldn't be a thing on macOS. I guess psutil just works differently on macOS?

Also there's no temperature info at the moment, but I'm going to go over the recent macOS temperature thread and see if I can't get that working before filing a separate bug report. Probably just a missing package.

Edit: Got the coretemp module installed and it seems to be working fine.

[RedBearAK]

@aristocratos

Testing 1.0.33 on the usual Linux Mint system, the charging state symbols appear to be accurately following the unplugging/plugging, charging/discharging and fully charged states.

In fact it seems to be updating even quicker than the XFCE power plugin notifications, although that's probably just down to the power plugin having a longer internal update interval.

But I am seeing a small visual anomaly. A bit of a gap appears in the horizontal line to the left of the battery info after the time disappears, after replugging the cable. I don't recall seeing that before, but it could have been happening all along. The screenshots above mainly show the compact battery info when the time is showing or during the location shifting issue. So it's possible I just didn't notice this before.

Screenshot:

Otherwise the functioning seems to be good now.

[aristocratos]

@RedBearAK

Whenever I open the options menu and then exit the menu, the battery info disappears, and won't come back until something triggers an update

A bit of a gap appears in the horizontal line to the left of the battery info after the time disappears, after replugging the cable.

Gonna take another look at it when I've got time, it's hard to test the normal operation of the meter since the only laptop I've got is a Pinebook Pro and psutil doesn't detect any battery on that machine. So have to emulate the battery stats to test the functionality, which isn't optimal when trying to catch all possible states.

[RedBearAK]

@aristocratos

I have the same problem of the battery not being detected by psutil on my old Pentium 4 laptop. I just got done filing a bug report about it in the psutil issues forum.

https://github.com/giampaolo/psutil/issues/1828

In the meantime, the battery does thankfully actually identify itself properly via /sys/class/power_supply/BAT0/type:

Battery

So if BpyTOP could fall back to checking /sys/class/power_supply/BAT0/ for valid battery info even when psutil says "None" for battery, then the battery info display would work even on this machine.

[I'm crossing my fingers that /sys/class/power_supply/BAT0/ is actually a pretty standard place for a battery or UPS to show up in Linux.]

I am hoping for a better resolution for this from the psutil developer. This is a strange one since unlike my oddball CPU temp sensor that doesn't even show up in apps like Psensor, the battery info is displayed just fine in the XFCE power plugin, just like on the (six years newer) MacBook running Linux. It makes very little sense that psutil is failing to detect it.

I hope you filed a psutil bug report for your machine too. Did you hear elementary OS are having good success porting their distro to the PineBook Pro? There was an article about it on their blog. They will probably even have an official release of eOS 6 for the PineBook Pro. That could become quite a popular machine shortly.

[aristocratos]

@RedBearAK

I hope you filed a psutil bug report for your machine too.

Haven't reported anything yet, was thinking I was gonna go through that section of the psutil source and make a PR if I can solve it.

Did you hear elementary OS are having good success porting their distro to the PineBook Pro?

Was lucky enough to get in and reserve one from the first batch they released and just switched from debian to manjaro when pine64 made it the default dist. The graphics drivers are just now getting in a good state but otherwise it's a really cool machine :)

[RedBearAK]

@aristocratos

Haven't reported anything yet, was thinking I was gonna go through that section of the psutil source and make a PR if I can solve it.

Oh, ambitious. Try to make your patch generic enough to support mine too, eh? Wink, wink, nudge, nudge.

Was lucky enough to get in and reserve one from the first batch they released and just switched from debian to manjaro when pine64 made it the default dist. The graphics drivers are just now getting in a good state but otherwise it's a really cool machine :)

Yeah, it's too bad they couldn't make more. People are saying good things about it.

[aristocratos]

@RedBearAK I've submitted a PR for better battery sensor detection https://github.com/giampaolo/psutil/pull/1837 but I don't think it will help in your case. Looking at the directory listing you posted in your issue all files needed for a reading are already present, so am not quite sure why it isn't working for you.

[aristocratos]

@RedBearAK You can test my changes from my fork of psutil https://github.com/aristocratos/psutil but I doubt it will make a difference in your case.

A bit of a gap appears in the horizontal line to the left of the battery info after the time disappears, after replugging the cable.

This should be fixed already, forgot to mention it. Will close this issue for now since the request has been fulfilled, reopen if you're still having issues.

[RedBearAK]

@aristocratos

I had to uninstall the regular 5.7.2 version of psutil to get your 5.7.3 version recognized, but I think I was using your fork properly when I ran the command:

python3 -c "import psutil; print(psutil.sensors_battery())"

The result is still "None". And running bpytop -v shows 5.7.3 and still no battery displayed with "Show battery" = True.

I agree that it makes little sense that psutil is not detecting it. The info is all there and it works with the XFCE power plugin in the tray. I'm surprised this is an issue that still exists in a piece of software that is years old and has gone through so many iterations by now.

Will close this issue for now since the request has been fulfilled, reopen if you're still having issues.

If I understand correctly, even if I was the original author of the issue, I wouldn't be able to reopen the issue once the dev (you) closes it. This issue thread is getting quite long anyway, if I have additional related problems I'll start a new thread and mention this one for context.

Thanks!

[aristocratos]

@RedBearAK

If I understand correctly, even if I was the original author of the issue, I wouldn't be able to reopen the issue once the dev (you) closes it.

Oh, sorry, didn't know that :P

The result is still "None". And running bpytop -v shows 5.7.3 and still no battery displayed with "Show battery" = True.

If you zip all the files from your "BAT0" folder and upload here I can take a look at them and see if I can get it working when emulating your battery.

[RedBearAK]

@aristocratos

If you zip all the files from your "BAT0" folder and upload here I can take a look at them and see if I can get it working when emulating your battery.

I notice the BAT0 folder is actually a symlink to something else:

I tried zipping the BAT0 folder via both GUI and command line. Having a lot of trouble. The GUI option said something about preparing to add more than 8,000 files, then quit with an error. Command line has similar issues. Zipping a folder is not something I'm used to having issues with.

I tried to just copy from one folder to another and then zipped the result. Don't really know if this is exactly what you wanted.

BAT0.zip

[aristocratos]

@RedBearAK I can see the issue now, to get a reading you need one the files: "energy_now" or "charge_now" (present) and one of the files "power_now" or "current_now" (present), your "current_now" file is however empty, so it doesn't return a value, which results in the function returning None.

My patch added support for a "time_to_empty_now" file that can be used if either of the previous values fail, but your battery doesn't provide a "time_to_empty_now" file, so no help there.

It essentially fails because it can't get a value to report as "seconds to empty", but it does get a valid percentage value from "capacity" file and the current charge state from "status" file, so you could maybe argue that psutil should return the "seconds to empty" as unknown instead if it can get the other values.

[RedBearAK]

@aristocratos

Yeah, cat current_now yields "No such device". That explains why it was empty when copied.

It essentially fails because it can't get a value to report as "seconds to empty", but it does get a valid percentage value from "capacity" file and the current charge state from "status" file, so you could maybe argue that psutil should return the "seconds to empty" as unknown instead if it can get the other values.

Yes, I would argue that. All the necessary information is there to know the charging status, charge level, and certainly that the battery exists and identifies itself as a "Battery". If you don't want to spend time on it you could post your proposed solution to the 1828 issue and maybe somebody else will give it some attention. Thanks for taking a look.

[RedBearAK]

@aristocratos

I now have battery info on the ancient P4 laptop. Woohoo!

I can only confirm this to be working with your current v5.7.3 psutil branch, since I haven't been able to switch back to the main giampaolo branch yet. I get some kind of file error when attempting to force reinstall the main branch via pip3. I'll figure it out.

It's hard to test the charging modes because the battery is so old and degraded it can't actually run the computer if I unplug the power. But I tried removing the battery while the system is running, and this is what happened.

Remove battery: Battery info stays and continues to show 100%. XFCE plugin shows "?" in the battery icon.

Run bpytop without battery installed: No battery info shows. Good.

Reinsert battery while bpytop is running (with no battery info showing): Battery info appears and first shows charging, then fully charged, mirroring the XFCE plugin. Good.

So bpytop (or psutil) doesn't appear to be noticing when the battery is removed / not present (until a quit and restart of the app).

Resizing the window results in the battery info element staying in exactly the same place as the window changes size. It doesn't disappear, but it also doesn't move around with the other elements while the window is being resized. So basically when the battery is removed the battery element stops being updated, it becomes a static element.

I guess the preferred result would be the battery info disappearing if the battery is removed.

Good news, it should be very easy to notice when the battery is removed. I thought maybe you'd have to notice the "present" file going from 1 to 0, but it's even simpler than that. The entire BAT0 folder structure vanishes from the file system when the battery is removed. If psutil isn't yet capable of noticing this and reporting "no battery" when that happens, that seems like a bit of a problem. Or maybe you're just not expecting the battery to suddenly disappear so you're not catching the state change from psutil?

Battery installed:

python3 -c "import psutil; print(psutil.sensors_battery())"
sbattery(percent=100.0, secsleft=<BatteryTime.POWER_TIME_UNLIMITED: -2>, power_plugged=True)

Battery removed:

python3 -c "import psutil; print(psutil.sensors_battery())"
None

Psutil seems to be appropriately returning "None" when I remove the battery, so looks like bpytop is just not picking up on the state change and so fails to remove the battery info element when the sensor is no longer reporting.

I assume this may also be relevant to someone unplugging the USB cable from a UPS, or similar situations.

Other than that, it's working fine under normal circumstances.

[aristocratos]

In v1.0.42:

Fixed: Battery clear if removed

[RedBearAK]

@aristocratos

In testing on the P4 laptop, removing the battery leaves a phantom 00%| but no gaps in the green horizontal line. This is of course when the battery info shows BAT[square] 100% to begin with.

That was with the short battery display. With the longer display it leaves the last three colored squares of the battery graph.

So basically for some reason it's leaving the last three characters plus the vertical line symbol.

As always, resizing the window or cycling "Show battery" will make it completely disappear.

Edit: Also still seems to be some ghosting happening if the percentage happens to change from say 100% to 0% (thus getting two characters shorter). It ends up showing |B|BAT[charge symbol] 0%|. If I didn't have a basically dead battery I probably never would have noticed it.

I think the best possible solution to this vexing problem is changing both the update interval element and the battery info element to be a static length, via the use of leading zeros (with a darker theme applied, like the uptime display theme, to maintain the readability of the interface). That way these elements will never again change in length, besides the expansion of the battery info to the full graph when there is sufficient room. But it would be going from one static length to another static length, so all the length calculations would get much simpler.

The battery percentage is generally either 100% or NN%, and the default update interval is 4 characters, while the maximum update interval (86400) is just 5 characters. So using leading zeros for padding would usually only add one or two characters of total length to what the the battery and update element grouping would have been.

[aristocratos]

@RedBearAK

I think the best possible solution to this vexing problem is changing both the update interval element and the battery info element to be a static length, via the use of leading zeros

This shouldn't be necessary, it compares it's current character length to it's previous value and clears it if there is a difference, I have probably just not gotten the padding right. Will take a look at it next week when I've got some time.

[aristocratos]

@RedBearAK Fixed in v1.0.43

[RedBearAK]

@aristocratos

Battery info element doesn't get force-updated when changing themes. Unlike everything else on the screen it will temporarily retain the colors of the previous theme until something like a window resize or charging status change forces it to update.