I just ran an apt update and apt upgrade today and since then the battery indicator in waybar constantly shows “100%” while the OLED menu has the right value (63% right now for example).
upower --dump on the command line reports the correct value btw
ouch, yes, this totally fooled me actually, it shows 100% on desktop but I just checked the OLED and I’m seeing 30% - mind you I also see a kernel update this morning, so I’m installing that as well to see if that brings things back into line. the latest kernel image didn’t affect this.
upower shows the expected values.
I’m not an expert here but it looks like Waybar’s battery module has a few open issues.
Yeah, I’ve experienced the same. I’m currently letting my battery drain to calibrate the battery gauge and waybar’s still showing 100% despite the OLED menu/upower showing something much lower.
upower is still working.
You have to install it and modify the waybar config.
I will try this out and will give an update
I added upower to waybar:
Just very quick and dirty. It is interessting, because the upower module displays two batteries: one 100% and one with real value.
The relevant part of your waybar config is probably this?
"upower": {
"format": "{percentage}",
"format-alt": "{time}",
"icon-size": 20,
"hide-if-empty": true,
"tooltip": true,
"tooltip-spacing": 20
},
Maybe. Before we “have” to do this, can we approach this problem in a more structured way?
There was a recent upload of waybar 0.10.3-1 to 0.10.4-1 to unstable on July 19. This kinda fits the timeframe of those who reported issues. Can those with issues please confirm that waybar is what got updated from 0.10.3-1 to 0.10.4-1 at the point where things stopped working? You can find apt logs in /var/log/apt/history.log.
This is a regression, so it should be easy to git bisect the upstream git at GitHub - Alexays/Waybar: Highly customizable Wayland bar for Sway and Wlroots based compositors. 🎉 between the working 0.10.3-1 and the broken 0.10.4-1 to find the offending commit. Reverting that commit should fix it again. Building each waybar commit should be as simple as running: meson setup build && ninja -C build. You can then run ./build/waybar (yes, you can have multiple waybars open at the same time) to check the status of the commit you are currently testing.
Yes, meant to be a short fix. I am more a user. I one thing, does not work, I pick another thing. Maybe not the perfect way 
I think I see an issue with the battery meter being wrong with the latest waybar version on the big reform as well. In case of the big reform, the offending commit is modules/battery: Deprioritize `capacity` /sys value · Alexays/Waybar@d68bcbd · GitHub
Can somebody with a Pocket Reform confirm that reverting this commit fixes the issue?
Hi @josch, I’m more than happy to help and learn new stuff, but I’d need more detailed/step-by-step info to try out what you’re suggesting. It might be extra work for you, and it’d probably be easier for a more advanced user to test it. Anyway I’m here if I can help 
Hey again, I’ve been looking into testing the method you suggested, but I’m stuck on the command meson setup build && ninja -C build with the following error:
meson.build:73:17: ERROR: Dependency lookup for wayland-client with method 'pkgconfig' failed: Pkg-config for machine host machine not found. Giving up.here
I’ve installed libwayland-client0 but no luck either.
I’m also sending you the meson log in case it helps.
You generally need to install the dev version of what it is missing. in your case, something like libwayland-client0-dev
Yes. You can easily install all required build dependencies by running this:
apt-get build-dep waybar
Since this is a meson project, you do not necessarily need to run this as meson will also take care to download and build some of the build dependencies if you do not have the associated libfoo-dev package installed. Personally, I prefer installing the libfoo-dev package from the Debian repos over meson doing the downloading for me.
Thank you for your help, @josch. Sorry for my late reply. I think I have completed the git bisect analysis you were proposing and the result is the following:
892042eb92f9b95736930298bf07ff02ebfaded9 is the first bad commit
commit 892042eb92f9b95736930298bf07ff02ebfaded9 (HEAD)
Author: Oliver Locke <oliver@lockenet.com.au>
Date: Wed Jun 12 17:03:39 2024 +1000
Support muted icons for pulseaudio devices/ports
src/modules/pulseaudio.cpp | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
From here, I’m not really sure how to go on. Any hints? Thanks!
Yeah that’s fixed it.
I tested this by cloning the original source, checking out the version tag for 0.10.4, reverting the commit (d68bcbd, the one @josch suggested) and then creating a patch with git format-patch, then grabbing the package source with apt-get source waybar and applying the patch with patch and building the package… If there’s a better way of doing this please let me know!
I’m wondering though if this patch would need reverting if the charge_now file gave the correct value instead of always being equal to charge_full?
the pocket system controller reports charge_now as charge_full, the reform lpc should be reporting a correct charge_now.
I’m having issues running the build-dep for the package (it complains that libxml2-dev/libxml2 have a conflict, likely due to being on unstable). I noticed that a new 0.10.4-2 build of the waybar package was issued but I’m guessing that it didn’t revert that commit since I still see the same 100% in my bar right now.
I found the bug in the system controller firmware last night and Lukas has already tested a fix, so for the pocket reform at least this should be a solved problem when the new firmware is released.
Just to confirm my understanding of the current status - we need to wait for the system controller drop to resolve this incompatibility with the Waybar battery monitor, right? And in the meantime, we can add a upower element to Waybar instead.
Yeah, I did ask @josch what package it’s part of but I almost instantly forgot what the answer is. Also iirc the system controller will not be automatically be flashed when the package is updated, this will be a manual step so that people who are maintaining their own patches won’t have them clobbered by upstream but I’ll let @josch confirm this before anyone should take my word for it.
The channel is logged. You probably mean you asking here? 2024-08-02.log
It cannot be automatically updated because the firmware is not packaged anywhere (yet). Once it is packaged, any firmware upgrade will be manual because you are supposed to be able to hack your firmware without apt overwriting that.
