keyNotFound(code: "CHWA")

[Tackoil]

After updating the macOS 15.0 beta 5, bclm is not working well. Running read or write will get an error (maybe) following.

keyNotFound(code: "CHWA")

I know that using the beta version of macOS is my own risk. Creating this issue is just for a notice about this change.

[ftpd]

I experience the same issue - just for the record.

[Zw96042]

I'm also experiencing this issue

[IShinji]

same

[CalebMtuwetaM]

I have the same issue

[zackelia]

Ouch, not sure what we can do without it. Unless this was accidental, we'll just have to wait and see what replacement key (if there will be one) can do the same trick. Before, we learned about CHWA from the Asahi SMC driver so we'll see what findings they have soon I assume: https://github.com/AsahiLinux/linux/blob/asahi/drivers/power/supply/macsmc_power.c

[yanzhem02]

I updated my system to 15.1 beta 2 and encounter the same issue.

[TrainerBlade]

same error message. using MacOS 15.0 beta (24A5320a)

[samzong]

same with me. Version 15.1 Beta (24B5024e)

[TimNN]

Asahi now seems to have changes for the latest firmware: AsahiLinux/linux@c6ccbdd

[zackelia]

@TimNN Good eye! I'll install Sequoia on another volume and test that out.

[GimmiGoose]

Got this too on 15.1 I am using AlDente until it gets fixed, but will definitely switch back once it is fixed, because I prefer a more "native" solution.

[TimNN]

When trying to manually write to (or read from) CHLS (via smc), I'm getting kIOReturnNotPrivileged:

$ sudo smc -k CHLS -w 0150
Error: SMCWriteKey() = e00002c1

Disabling SIP didn't seem to help either...

[zackelia]

Getting the same error even just reading CHLS. From Console:

kernel    SMCC::smcYPCEventCheck ERROR: not entitled for key CHLS

Not really sure what entitlement I need to sign with to get access to this key. com.apple.private.applesmc.user-access stood out to me but I can't sign with that one.

[TimNN]

Ugh, this is very sad. I guess the only options are:

• Do something like Al Dente does (have the App monitor the charge level and toggle charging).
• Hope that Apple changes their mind and provides a way to write arbitrary SMC values.
• Hope that Apple provides a built-in way to always limit the charge level (as they do for some iPhones, IIRC).
• Reimplement SMC writes in a custom kext (though that obviously has its own problems, especially since kexts are very deprecated).
• Figure out if there's a way to hijack whatever process is in charge of implementing Apple's own "optimize battery charging" feature (and trick it into always limiting the charge level).

[sibilus]

CHWA is also gone on macOS Sonoma 14.7. I seem to be able to read and write CHLS though, but I'm not sure how it's supposed to function as nothing seems to happen when I change it.

[thaff786]

https://github.com/lslqtz/bclm_loop/tree/main

Fork of BCLM called BCLM_Loop which I can confirm does work on Sequoia 15.0 release. It installs and can be enabled pretty much in the same fashion as the original BCLM.

Under the hood it may not be as clean or elegant as the original BCLM as it runs in a loop as a background service (as opposed to writing to the SMC), but it still does the job 100% as far as I can tell so far with no impact on battery life when unplugged.

Still hoping the original BCLM can be fixed though.

[TimNN]

@sibilus: Which value did you try to write? Based on the Asahi code, setting CHLS to 0150 (hexadecimal) should have a similar behavior to setting CHWA to 1.

(The 01 apparently means "discharge down to target percentage" and 50 is the target percentage, in this case 80%).

[anqut]

I'm getting the same error, after updating to macOS 15.0

[zackelia]

This is great news if people are able to read/write CHLS! Something must've changed since the last beta if the entitlement isn't necessary anymore? I'll be able to test it out again in a few days.

[TimNN]

@zackelia: The success report was for "macOS Sonoma 14.7", so I have very little hope that this is going to work on 15.0.

I assume that 14.7 got the firmware update with CHLS, but the entitlement protections were only implemented in 15.0.

On the 15.0 release (24A335)) I still cannot write CHLS. I'll be testing this on all future releases as well, of course, but have relatively little hope.

[sibilus]

@TimNN: I've tried 0150 on 14.7, but it doesn't seem to work, unfortunately.

[wpiekutowski]

I tried CHLS with 0150 and 0100 (which seems to be supposed to cause discharge) on 14.7, but both values unfortunately do nothing.

I'm turning on builtin "Optmized battery charging" and I'll see if they maybe improved it.

[IshanFernandoCutAndDry]

macOS 15.0
same issue

[pgardiner]

Same issue on macOS 15.0. Using Al Dente for now, but would like to go back to bclm, which has been perfect since I started using it, and has definitely extended my battery life.

[PiterrsPl]

https://github.com/lslqtz/bclm_loop/tree/main > > Fork BCLM o nazwie BCLM_Loop, który mogę potwierdzić, działa na wydaniu Sequoia 15.0. Instaluje się i można go włączyć w taki sam sposób jak oryginalny BCLM. > > Pod maską może nie być tak czysty lub elegancki jak oryginalny BCLM, ponieważ działa w pętli jako usługa w tle (w przeciwieństwie do pisania do SMC), ale nadal wykonuje pracę w 100%, o ile mogę powiedzieć do tej pory, bez wpływu na żywotność baterii po odłączeniu zasilania. > > Nadal jednak mam nadzieję, że oryginalny BCLM może zostać naprawiony.

https://github.com/lslqtz/bclm_loop/tree/main

Fork of BCLM called BCLM_Loop which I can confirm does work on Sequoia 15.0 release. It installs and can be enabled pretty much in the same fashion as the original BCLM.

Under the hood it may not be as clean or elegant as the original BCLM as it runs in a loop as a background service (as opposed to writing to the SMC), but it still does the job 100% as far as I can tell so far with no impact on battery life when unplugged.

Still hoping the original BCLM can be fixed though.

hi i have one question how to install this fork ? because its not so easy like using brew. please help me because I have spend few hours to install this fork and I have no idea how to do this .. my Mac is with m1 procesor

[lslqtz]

hi i have one question how to install this fork ? because its not so easy like using brew. please help me because I have spend few hours to install this fork and I have no idea how to do this .. my Mac is with m1 procesor

brew support has been added, but versions obtained through it may occasionally be out of date.

BTW: It only supports Apple Silicon based Mac computers. (I don't have an Intel Mac to test)

$ brew tap lslqtz/formulae
$ brew install bclm_loop

And, macOS 15.1 beta 5 still does not provide the required permissions to write to CHLS.

$ sudo smc -k CHWA -r
  CHWA  [    ]  no data
$ sudo smc -k CHLS -r
Error: SMCReadKey() = e00002c1

[ssh352]

I changed to use https://github.com/mhaeuser/Battery-Toolkit now which works with any limits.

@lslqtz I was deciding on bclm_loop and Battery-Toolkit, could you advise on the benefits of bclm_loop over Battery-Toolkit?

for reference: I've asked the Battery-toolkit author mhaeuser/Battery-Toolkit#38

ideally the micro charging is as infrequent as possible when the laptop runs on power adapter.

[variia]

@ssh352
i switched to Battery-Toolkit yesterday temporarily. it is GUI but i like the more fine-grained control over my charging and the option to drain (condition) my battery while in clam-shell mode.

[lslqtz]

I changed to use https://github.com/mhaeuser/Battery-Toolkit now which works with any limits.

@lslqtz I was deciding on bclm_loop and Battery-Toolkit, could you advise on the benefits of bclm_loop over Battery-Toolkit?

for reference: I've asked the Battery-toolkit author mhaeuser/Battery-Toolkit#38

ideally the micro charging is as infrequent as possible when the laptop runs on power adapter.

bclm_loop is an improvement on bclm [1]. It has no GUI and runs silently in the background. This means it does not occupy the menu bar, but is less flexible. In terms of energy consumption, although the two projects use different methods, there is almost no difference in actual use. In addition, since the code of bclm_loop is simpler, it is easier to make user-defined code modifications.

In addition, bclm_loop, like bclm, (used to) support firmware-based charging control, and the current version of bclm_loop will still try to use firmware-based charging control on supported firmware.

[1] The original purpose of bclm_loop was to provide MagSafe LED control capabilities based on bclm. (PR #39)

If you need a GUI and the greater user flexibility it provides, there are other options, including this one or something like AIDente.

[ssh352]

In addition, bclm_loop, like bclm, (used to) support firmware-based charging control, and the current version of bclm_loop will still try to use firmware-based charging control on supported firmware.

thanks very helpful info.

"Battery Toolkit uses the OS APIs to be notified of changes to the charging level and is idling most of the time. "

Battery-toolkit appears not firmware based though.

[PiterrsPl]

thx

[PiterrsPl]

hi i have one question how to install this fork ? because its not so easy like using brew. please help me because I have spend few hours to install this fork and I have no idea how to do this .. my Mac is with m1 procesor

brew support has been added, but versions obtained through it may occasionally be out of date.

BTW: It only supports Apple Silicon based Mac computers. (I don't have an Intel Mac to test)

$ brew tap lslqtz/formulae

$ brew install bclm_loop

And, macOS 15.1 beta 5 still does not provide the required permissions to write to CHLS.

$ sudo smc -k CHWA -r

  CHWA  [    ]  no data

$ sudo smc -k CHLS -r

Error: SMCReadKey() = e00002c1

Thx very much for help

[Nolenius]

I'm also hoping the original BCLM can be fixed, very helpful!
Does anyone use batt [https://github.com/charlie0129/batt] ?

[reedgrass777]

Does anyone use batt [https://github.com/charlie0129/batt] ?

Why should I prefer BCLM over batt? It seems batt gets the job done, isn't it?

[sozercan]

Why should I prefer BCLM over batt? It seems batt gets the job done, isn't it?

Main difference is that bclm doesn't run in the background, but it's at the firmware level. Anything else runs in the background.

[majal]

Why should I prefer BCLM over batt? It seems batt gets the job done, isn't it?

Main difference is that bclm doesn't run in the background, but it's at the firmware level. Anything else runs in the background.

Which further means that batt and others will not be able to monitor charging if the system is suspended. (That's why batt by default will disable charging before suspend, which means no charging of a closed laptop.)

I'm actually thinking of having both batt and bclm together. batt has more features while the computer is on, and bclm limits charging even when the system is suspended.

[ivankovnatsky]

Forgive me, but this does not seem like a suitable place to discuss other battery tools.

[yuukiyuuna]

Is there any update plan for this project ?

[antoinelibert]

Hello,

Unless Apple has since reverted the changes in a beta version of macOS 15.1, there's little the author can do. The bclm feature is solely dependent on a specific flag in the Mac's battery management hardware, which Apple has removed. The 80% limit is a hardware-handled feature.

There are alternative ways to recreate the 80% limit using software (see the tools listed earlier). Since they're software-based, they may not be as optimal during sleep, but some implementations are still effective. I've switched to Battery-Toolkit, which appears to be the most advanced and stable option, utilizing events instead of loops, handling wake and sleep events, offering an optional GUI, and actively maintained.

[yuukiyuuna]

Hello,

Unless Apple has since reverted the changes in a beta version of macOS 15.1, there's little the author can do. The bclm feature is solely dependent on a specific flag in the Mac's battery management hardware, which Apple has removed. The 80% limit is a hardware-handled feature.

There are alternative ways to recreate the 80% limit using software (see the tools listed earlier). Since they're software-based, they may not be as optimal during sleep, but some implementations are still effective. I've switched to Battery-Toolkit, which appears to be the most advanced and stable option, utilizing events instead of loops, handling wake and sleep events, offering an optional GUI, and actively maintained.

OK, thank you. I will try to use Battery-Toolkit as well. But I really hope Apple will restore this specific flag.

[Jerrykooo]

same issue on macos 12.7.6

[zackelia]

I took a look at this again now that macOS 15.1 is out, but still the same issue.

With some more experimentation, I am highly confident that com.apple.private.applesmc.user-access is in fact the required entitlement. I used dyld interposing on /usr/sbin/systemstats which has that entitlement and I could successfully read/write CHLS (albeit with SIP disabled so this isn't too viable anyways).

Like others in this issue mentioned for older versions of macOS, writing values such as 0x0150 didn't seem to have any effect on the battery. I looked over the Asahi driver code some more but it's not obvious to me that we're doing something wrong. If anybody is able to glean any more insights on the older versions of macOS I'd be curious to hear.

[PiterrsPl]

https://github.com/lslqtz/bclm_loop/tree/main > > Fork BCLM o nazwie BCLM_Loop, który mogę potwierdzić, działa na wydaniu Sequoia 15.0. Instaluje się i można go włączyć w taki sam sposób jak oryginalny BCLM. > > Pod maską może nie być tak czysty lub elegancki jak oryginalny BCLM, ponieważ działa w pętli jako usługa w tle (w przeciwieństwie do pisania do SMC), ale nadal wykonuje pracę w 100%, o ile mogę powiedzieć do tej pory, bez wpływu na żywotność baterii po odłączeniu zasilania. > > Nadal jednak mam nadzieję, że oryginalny BCLM może zostać naprawiony.

https://github.com/lslqtz/bclm_loop/tree/main
Fork of BCLM called BCLM_Loop which I can confirm does work on Sequoia 15.0 release. It installs and can be enabled pretty much in the same fashion as the original BCLM.
Under the hood it may not be as clean or elegant as the original BCLM as it runs in a loop as a background service (as opposed to writing to the SMC), but it still does the job 100% as far as I can tell so far with no impact on battery life when unplugged.
Still hoping the original BCLM can be fixed though.

hi i have one question how to install this fork ? because its not so easy like using brew. please help me because I have spend few hours to install this fork and I have no idea how to do this .. my Mac is with m1 procesor

hi there is new release from bclm_loop how can I update this version ?

[zship]

Like others in this issue mentioned for older versions of macOS, writing values such as 0x0150 didn't seem to have any effect on the battery.

Just to double-check: are you saying that writing 0x0150 to CHLS had no discernible effect on macOS 15.1? Or on an older version?

Reason I ask is because I'm willing to jump through the same hoops as you (disable SIP, dyld interposing) if it works. Want to confirm before going down the rabbit-hole though, since I'm currently unfamiliar with dyld interposing. Thanks for your experimentation and reporting the results!

[zackelia]

@zship This was me running on 15.1. I have the code that does the dyld interposing so really it's just turning off SIP to test it out. If people wanted to look more at the SMC values, I could put a branch up that's capable of that at least.

[zship]

I'd definitely be interested. Have some time to experiment, too. I have some (small) context here FWIW: implemented a basic "calibration" script which writes CH0I/CH0C values and I have some idea of how those (used to) interact with CHWA.

If you manage to get some time to push your dyld interposing code, I'm sure that would be a great help! Even a gist or a separate work-in-progress/not-fully-working repo would likely be useful IMO, but whatever makes sense for you if/when you get time.

Would be happy to take measurements and report findings, if useful.

[zackelia]

@zship and others - I pushed an experimental repo for SMC testing on Seqouia: https://github.com/zackelia/smc-interpose

[pencilcheck]

wait, so bclm will start working by following the experimental repo? or is it still not?

[zship]

Short answer: no, as it is now the experimental script does not prevent the battery from charging past the 80% threshold.

Sorry, got busy again! I did manage to do one test run. The script appears to have set CHLS to 150 (80%) as intended, but my battery charged to 100% anyway. Planning to experiment with more CHLS values when I get a chance (which I think was the purpose of the experimental repo, thanks zackelia!).

A couple details of the test run I did on an M3 Macbook Pro, if helpful:

# battery is charged to 70%
$ pmset -g batt
Now drawing from 'AC Power'
 -InternalBattery-0 (id=21102691)       70%; AC attached; not charging present: true

# read CH0I and CH0C. CH0I=00 and CH0C=01 indicates "inhibit charging"
$ smc -k CH0I -r
  CH0I  [ui8 ]  0 (bytes 00)
$ smc -k CH0C -r
  CH0C  [hex_]  (bytes 01)

# run zackelia's experimental script (sets CHLS to 150/"80%")
$ DYLD_INSERT_LIBRARIES=./build/libsmc.dylib systemstats -h
1 80

# set CH0I and CH0C to the default values, indicating "auto"/"charge if needed"
$ sudo smc -k CH0I -w 00
$ sudo smc -k CH0C -w 00

# poll the battery percentage every minute
$ while true; do pmset -g batt; sleep 60; done
# above while loop is simplified... I actually processed the output a bit.
# (Mode=auto indicates CH0I=00, CH0C=00)
[2024-11-13 10:13:10] Percentage=70% Mode=auto
[2024-11-13 10:14:10] Percentage=71% Mode=auto
[2024-11-13 10:15:10] Percentage=72% Mode=auto
[2024-11-13 10:16:10] Percentage=73% Mode=auto
[2024-11-13 10:17:10] Percentage=74% Mode=auto
[2024-11-13 10:18:10] Percentage=75% Mode=auto
[2024-11-13 10:19:11] Percentage=76% Mode=auto
# ... continued to increment ...
[2024-11-13 10:53:13] Percentage=100% Mode=auto
[2024-11-13 10:54:13] Percentage=100% Mode=auto
# ... kept monitoring for a while just in case ...
# still at 100% after 2 hours
[2024-11-13 12:51:22] Percentage=100% Mode=auto

[noszti]

I have recently updated to MacOS 14.7.1 (from 14.5 (I think)) and experienced the “keyNotFound(code: "CHWA”): Searching that lead to me to this github thread.
So I am using smc to manually set these values and switching to using the “CHLS” seems to have worked, but it seems like just a little too well, e.g. after:

$ sudo smc -k CHLS} -w 0150

My MacBook Pro (M3) only charges to 80%. However setting the value back to “0000”:

$ sudo smc -k CHLS} -w 0000

Seems to not revert the change (i.e. still stuck at max 80%).

I also tried setting 0164 (thinking that might be for 100%) but that does not do anything either (stuck at 80%)
(Note that I did read the CHLS value before I started all this and it was 0000)

[zackelia]

Interesting, I'll have to look more at macOS 14.7 to mess with CHLS.

Regarding your charge limit issues, rebooting should clear the SMC and fix your issue.

[noszti]

So it seemed like my Macbook (after messing with the "CHLS" values) was not charging at all (i.e. when I unplugged it (at the 80% it was holding the charge at) it went down to ~68% and when I plugged it back in it just held at that 68% instead of charging.
Fortunately rebooting cleared this mode and started charging again. Also since the "Optimized Battery Charging" mode is enabled currently (should it be? Not sure if I had it that way or the update to 14.7 enabled it?) after the reboot and not messing with any SMC settings it did stop at 80% (with the drop down menu saying "will be charged by 1:30"). So not sure how my earlier setting CHLS to 0150 interfered with that exactly?

From what I recall with Sonoma 14.5 I had no issues, e.g. when I set CHWA to 01 it set the maximum charge at 80% and was charing fine when it was lower (although I did have to reset CHWA to 01 after every reboot - fortunately I did not reboot that often). And when I set it to 00 it charged to 100% without having to reboot. And if at 100% setting CHWA to 1 automatically discharged the battery until it reached 80%. Would be nice to have that behavior back.

Certainly there seem to lots of knobs/switches that could affect the behavior...