NobodyXu/swaystatus

[Feature Request] Multiple batteries

nikp123 opened this issue ยท 46 comments

Is your feature request related to a problem? Please describe.
Yes, my feature request is related to a problem with systems with more than one battery present, be it within certain laptop models such as the ThinkPad X250 or a Bluetooth device that reports it's battery to the host operating system.
When using such a system swaystatus tends to often recognize the incorrect battery, using the options offered I was not able to solve this issue, which is why I would like to have the option to choose a specifc battery in my configuration file (as the low-level IDs used stay persistent)

Describe the solution you'd like
An ideal solution for this problem would be to implement {for_battery:BAT0} (or however you decide to make the syntax look like}. However I would still accept {per_battery_fmt_str} as it would still allow me to see the battery percentage on my laptop unlike now.

Describe alternatives you've considered
Writing a separate script for this is a waste of time in my opinion and ideally should be fixed within the software itself.

Additional context
Add any other context or screenshots about the feature request here.

Example of such an system with two batteries:

nikp123@HP-Laptop /home/nikp123 $ acpi
Battery 0: Discharging, 0%, rate information unavailable <-- my mouse (buggy, I know)
Battery 1: Unknown, 95% <-- the actual laptop
nikp123@HP-Laptop /home/nikp123 $ 

sure, I will implement this when I am free (probably this weekend)

No pressure, just do it whenever you like

@nikp123 I have implemented the feature you requested in branch FeatureMultipleBAT.

Can you try that branch to see if that works out for you?

exes.zip

Here are the executables built for x86-64 glibc linux.

It works although I can't see the percentage, is this my configs fault or is there something more going on?

Tried both {charge} and {charge_now} but I get this in both cases

image

But as far as this feature is concerned it works now, I think...

@nikp123 I think you need to use capacity.

swaystatus read input from /sys/class/power_supply/<BAT>/uevent, and on my machine it looks like this:

POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=15400000
POWER_SUPPLY_VOLTAGE_NOW=17412000
POWER_SUPPLY_CHARGE_FULL_DESIGN=3712000
POWER_SUPPLY_CHARGE_FULL=3712000
POWER_SUPPLY_CHARGE_NOW=3712000
POWER_SUPPLY_CAPACITY=100
POWER_SUPPLY_CAPACITY_LEVEL=Full
POWER_SUPPLY_MODEL_NAME=Primary
POWER_SUPPLY_MANUFACTURER=HP
POWER_SUPPLY_SERIAL_NUMBER=

Same result even with:

"format": "{per_battery_fmt_str:{is_full:๏‰€ }{is_charging:๏—ง {capacity}%}{is_discharging:๏‰„ {capacity}%}{is_not_charging:๏‰€ {capacity}%}}"

Tried {capacity_level} as well.

Although I would mention uevent output seems to be fine:

nikp123@HP-Laptop /sys/class/power_supply $ cat BAT0/uevent 
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000
POWER_SUPPLY_VOLTAGE_NOW=16705000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=2308000
POWER_SUPPLY_CHARGE_FULL=2308000
POWER_SUPPLY_CHARGE_NOW=2203000
POWER_SUPPLY_CAPACITY=95
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=Primary
POWER_SUPPLY_MANUFACTURER=Hewlett-Packard
POWER_SUPPLY_SERIAL_NUMBER=00602 2015/07/31

What does capacity and capacity_level gives you?

capacity == "LEVEL=Normal"
capacity_level == "Normal"

OOPs, now I understand what happend.

Will fix it right now.

Just pushed a fix to the branch.

exes.zip

Here's the new executables.

It still doesn't work.... What's stranger is that the default config somehow displays the percentage properly.

And there's also a NULLPTR in the default config.

I'm assuming that's the bugged out mouse I have.

That's totally unexpected.

The default config is:

{has_battery:{per_battery_fmt_str:{status} {capacity}%}}

nullptr in the output means the corresponding property is not found.

Then it means that somehow the capacity is actually shown in status and capacity is not there?

Perhaps I should add an entry to the battery config that allows a specific device to be picked.

I think that would work better in this case

yeah

it's due to the mouse battery
it's reading nullptr always

exes.zip

Just pushed the new option. excluded_device that can be used in battery to exclude certain device.

It doesnt seem to do it, although I might be naming my device wrong. Let's see...

It causes a assertion failure when configured properly.

{"version":1,"click_events":true}
[
./dep/fmt/include/fmt/format-inl.h:2660: assertion failed: argument not found

swaystatus(+0x88e7)[0x5626c03638e7]

Also if you're building new versions don't bother building them, my glibc is incompatible anyway for some reason :(

Also forgot to share the config:

    "battery": {
        "excluded_device": "BAT0",
        "format": "{is_full:๏‰€}{is_charging:๏—ง}{is_discharging:๏‰„}{is_not_charging:๏‰€} {capacity}%}"
    },

@nikp123 You forgot to use {per_battery_fmt_str:...}.

It's still required despite the fact that excluded_device is added.

I am now considering enable C++ exception for this project, as it would help improve the error message dramatically #35

@nikp123 Hey, did you get it working?

Hey, sorry. Not at the moment, will test sometime today. I hope.

No worries, just wondering if things worked out.

Please don't feel pressured.

@nikp123 Hey, just regular polling for update here.

Does the new branch work for you?

Errors are more clear and detailed now. Thanks.

Example:

Error when formatting: argument not found in void fmt::v7::detail::error_handler::on_error(const char *), 2660, ./dep/fmt/include/fmt/format-inl.h

However, the battery {capacity} parameter is still buggy.

Example config:

        "format": "{per_battery_fmt_str:{is_full:๏‰€}{is_charging:๏—ง}{is_discharging:๏‰„}{is_not_charging:๏‰€} {capacity}%}"

Example output:

[{"name":"battery","instance":"0","full_text":"๏‰„ nullptr% 98%","excluded_device":"hidpp_battery_1","separator":true},{"name":"memory_usage","instance":"0","full_text":"๏”ธ 1022M/7G","separator":true},{"name":"network_interface","instance":"0","full_text":"๏ž– 192.168.100.5","short_text":"enp8s0","short_format":"{is_connected:{per_interface_fmt_str:{name}}}","separator":true},{"name":"time","instance":"0","full_text":"2021-04-26 10:34:39","separator":true},{}],

As you can see there is a nullptr insertion there for some reason. Sorry for the delay btw.

I guess that might be due to the battery inside of the mouse being shown as well. Will try to exclude it.

Even though I've specified the device name ealier

@nikp123 I have updated the branch, you might need to rebuild the binary.

It works, sorry. The mouse's battery name changed for some reason. Would you mind changing it into included devices instead, or perhaps a serial number check.

Actually MODEL_NAME would be a good identifier.

My primary battery:

POWER_SUPPLY_MODEL_NAME=Primary

My buggy wireless mouse:

POWER_SUPPLY_MODEL_NAME=Wireless Mouse PID:0080

No pressure, just do it whenever you feel like it.

@nikp123 I have now replaced option excluded_device with excluded_model.

Can you please try that out when you are free?

@nikp123 I have now replaced option excluded_device with excluded_model.

Can you please try that out when you are free?

works perfectly, thanks

@nikp123 Thanks for testing, I will tag a new release.