Battery maintain feature is not working after upgrading to the MacOS 26 Developer beta (Tahoe)
What is the issue? (required) The program functioned flawlessly until the upgrade. After the upgrade the battery maintain feature did not function properly. Moreover, the program did not show any errors. Apple must have changed their security protocols.
On further inspection using the smc cli tool, it seems like the keys that were previously used in the code no longer exist.
Just to add more context — I encountered a similar issue, but slightly different in setup:
- My main macOS system is still 15.5 (I have NOT updated it).
- I recently installed a second macOS system (macOS 26 beta) on the same MacBook Pro(m2 pro) for testing purposes.
- After installing and booting into macOS 26, I noticed that Battery stopped working properly on BOTH systems — it no longer limits charging, even though the UI shows no errors.
Seems like something from macOS 26 (e.g., SMC/NVRAM config?) might have changed the battery management behavior globally, affecting the other system as well.
Hope this helps with narrowing down the issue.
A similar issue can be found at AlDente: https://github.com/AppHouseKitchen/AlDente-Charge-Limiter/issues/1529
Seems like something from macOS 26 (e.g., SMC/NVRAM config?) might have changed the battery management behavior globally, affecting the other system as well.
I (unsuccessfully) installed the macOS 26 beta onto an external drive, and I'm running into the same issues on macOS 15.5. I think this is related to the new system firmware which seemingly got installed during that previous upgrade attempt. My current system firmware version (in System Information) is 13822.0.88.511.1 which corresponds to macOS 26 according to this list.
Is there a way for us to contribute? I might be able to help find the SMC keys.
I dumped the output of smc -l to some files based on the charging state of my device (MacBook Air M1). These samples might help in finding the right SMC keys, although I can't really understand the output directly.
- Plugged in and actually charging (after clicking "Charge Now"): smc - plugged and charging.log
- Unplugged normally (after clicking "Charge Now"): smc - unplugged.log
- Plugged in, after I clicked "Charge Now" but the battery icon has a plug on it: smc - plugged and not charging.log
- Unplugged normally (this one was made a bit later): smc - unplugged 2.log
- Plugged in and held at 80% by macOS itself (Optimized Battery Charging): smc - plugged and held at 80 percent.log
- Unplugged while held at 80% (made shortly after the fifth one): smc - unplugged and held at 80 percent.log
Key Insights from MacBook Air M1 SMC Log (Charging)
The System Management Controller (SMC) on a Mac is responsible for many low-level functions, including power management, battery charging, thermal management, keyboard backlight, and more. When charging, many of these parameters become highly active.
Here's an updated interpretation:
-
KEY [ui32] 1506: Still likely a unique log identifier or an internal revision number for the log format. -
AC-S [flag] (bytes 01): Confirms AC (Alternating Current) power is connected and active. This is expected when charging. -
AC-B [si8] -1 (bytes ff): This typically indicates the battery is not present or not detected for charging parameters, which is a common way the SMC reports an external power source. Or it could signify "no battery" mode when fully powered by AC. -
AC-N [ui8] 2 (bytes 02): Could relate to the number of AC adapters detected or a specific power state related to AC input. -
AC-W [si8] 2 (bytes 02): This might be related to the wattage or power state derived from the AC adapter. -
ACAP [ui8] 0 (bytes 00): Could be "AC Adapter Present" or similar. A value of 0 seems counter-intuitive if charging, but it might indicate a specific type of adapter not fully enumerated by this particular flag, or it's a legacy flag not used in M1. -
ACCF [ui8] 30 (bytes 1e): Could be "AC Current Factor" or maximum current allowed. $30_{10}$ would be $1E_{16}$. -
ACCP [ui8] 2 (bytes 02): Possibly "AC Charge Protocol" or another indicator related to the charging method. -
ACFP [flag] (bytes 01): Confirms fast charging or a specific power delivery profile is active/present. This is relevant for modern USB-C PD charging. -
ACPW [ui32] 2159738880 (bytes 80 bb 00 00): This is a large number. Let's convert it from little-endian:00 00 BB 80. This is $48000_{10}$ when considering it as a 16-bit value, or $32 \times 1024 \times 1024$ which hints at $32MB$ or $32W$ as a power. If it's $32W$ (a common charging wattage for smaller MacBooks), then80 BB(reverse byte order) could be $BB80_{16} = 48000_{10}$. This could represent input power in milliwatts. If it's a 32W charger, 32000mW = $7D00_{16}$ which is00 00 7D 00reversed. The value80 BB 00 00reversed is00 00 BB 80. $BB80_{16}$ is $48000_{10}$. So this could indeed be 48000 mW (48 Watts), indicating the power output of the connected charger. -
B0AC [si16] 56580 (bytes dd 04): This might be a battery amperage/current reading. Signed integer value $56580_{10}$ is outside a typical range for mA directly. Let's look at the bytes04 DD(little-endian:DD 04). This is $1245_{10}$. This could be 1245 mA (1.245 Amps), which is a very reasonable charging current. -
B0AT [ui16] 62219 (bytes f3 0b): Battery temperature in some unit (often degrees Celsius, or a raw sensor reading). $F30B_{16} = 62219_{10}$. If this is a raw sensor, it needs scaling. If it's temperature, $62219/256$ (common for fixed-point temp) would be around 243. That's too high for Celsius. It could be in Kelvin or a very specific raw reading. Let's check typical battery operating ranges. -
B0AV [ui16] 561 (bytes 02 31): Battery voltage reading. $0231_{16} = 561_{10}$. This is too low for actual battery voltage in Volts. It's likely in millivolts (mV), meaning 561 mV (0.561 Volts). This could be a specific cell voltage or a highly divided raw reading, as a full battery is usually ~12V for a MacBook. This might be a reading from a specific part of the charging circuit rather than the overall battery pack voltage. -
BMDN [ch8*] bq20z451: As noted, this is almost certainly the battery fuel gauge IC model, likely from Texas Instruments. This chip manages battery data. -
BMSN [ch8*] D862496AC5DPJYRAE: Confirms a battery serial number. -
BTTS [flag] (bytes 01): Still points to Battery Test Status being active, or more generally, the battery system is operational and likely performing its internal checks during charging. -
CHFS [ui32] 16777216 (bytes 01 00 00 00): Could be related to charger communication or status. $01000000_{16}$ might represent a specific protocol or state. -
CHIE [hex_] (bytes 00): Given the charging context, this could relate to "Charger Input Enabled" or similar. -
CHPS [ui32] 16777216 (bytes 01 00 00 00): Likely related to charger power status or presence. -
CLSD [ui64] (bytes 16 8d 47 cc a5 46 00 00)andCLSP [ui64] (bytes 72 22 30 54 1f 47 00 00): TheseCLvalues often relate to charge cycles, capacity, or current limits.-
CLSD(Charge LSB Data?):00 00 46 A5 CC 47 8D 16. This is a huge 64-bit number ($4935408906370000_{10}$). Very likely raw battery capacity data in units like mAh or mWh, or total accumulated charge/discharge. -
CLSP(Charge LSB Present?):00 00 47 1F 54 30 22 72. Another large 64-bit number ($4986708759080000_{10}$). Similar toCLSD, possibly current capacity or design capacity.
-
-
D2BD [ui8] 10 (bytes 0a): Could be a "Device 2 Battery Data" or "Device 2 Bus Data." Value 10 (0Ahex). -
D2BI [ui16] 56325 (bytes dc 05): IfD2is the PD charger, this could be its internal identifier or status code.05DChex is $1498_{10}$. -
D2DE [ch8*] pd charger: This is a direct string confirming the presence of a Power Delivery charger. This is crucial. -
D2EP [flag] (bytes 01): "Device 2 Enabled/Present" is active, confirming the PD charger is recognized. -
D2FC [ui32] 171966688 (bytes 0a 40 00 e0): This value is $E000400A_{16}$ (reversed bytes). This is a large number. For a charger, it could be a firmware version, serial number, or a complex status register. -
D2IR [ui16] 45580 (bytes b2 0c): Could be current from charger, input resistance, or a calibration value. $0CB2_{16} = 3250_{10}$. GivenD2MIis 3250, this looks like 3250 mA (3.25 Amps), a common charging current for PD chargers. -
D2MI [ui16] 3250 (bytes 0c b2): As above, likely Maximum Input Current (3250 mA = 3.25 Amps) expected from the PD charger. -
D2MP [ui32] 65000 (bytes 00 00 fd e8): Likely Maximum Power (65000 mW = 65 Watts) of the charger. Reversed bytes:E8FD0000. This looks like little-endianE8FDas $65000_{10}$ isFD E8in hex. So, the $65W$ charger is correctly identified. -
D2VM [ui16] 20000 (bytes 4e 20): Likely Maximum Voltage (20000 mV = 20 Volts) of the charger, which is a standard PD profile. -
D2VX [ui16] 20000 (bytes 4e 20): Same asD2VM, reinforcing the 20V maximum voltage. -
PDTR [flt ] 24 (bytes cd d6 bf 41): $41BFD6CD_{16}$ is indeed 23.985... which rounds to 24. This could be "Power Delivery Target Rate" or target wattage/voltage. -
PHPB [flt ] 65 (bytes 00 00 82 42): $42820000_{16}$ is exactly 65.0. This is very likely the power being drawn from the charger in Watts, confirming the 65W charger previously identified (D2MP). -
PSTR [flt ] 9 (bytes bf 03 0c 41): $410C03BF_{16}$ is 8.75... which rounds to 9. Could be "Power State Register" or specific charging power level. -
VBUS [ui32] 16777216 (bytes 01 00 00 00): This value $01000000_{16}$ (16,777,216) looks more like a bitmask or a specific status code for the VBUS (Voltage on Bus), indicating it's active or a particular power state on the USB-C bus. -
xPPT [flt ] 65 (bytes 00 00 82 42): $42820000_{16}$ is 65.0. "External Power Present Target" or Total Power Present (in Watts). This reinforces that the system is receiving 65W of power from the charger.
Summary of Charging State
This log clearly indicates:
- A Power Delivery (PD) charger is connected and recognized.
- The charger is rated for 65 Watts (or providing 65W).
- The charger is supplying 20 Volts.
- The system is drawing around 3.25 Amps from the charger.
- A battery (likely a bq20z451 controlled one) is present and its charging state is active.
- The
KDBGflag being1suggests this log might be from a debug-enabled system or collected with diagnostic tools.
Understanding Optimized Battery Charging in macOS
Optimized battery charging in macOS is designed to reduce battery aging by learning your daily charging routine. It aims to charge the battery to 100% just before you need to use your Mac, and for the rest of the time, it keeps the battery at a lower charge level (often around 80%) to minimize wear. This is precisely what your log reflects.
Key Differences and Observations in This Log
Let's compare this log to the previous one and highlight the relevant changes, particularly concerning the 80% charge hold.
-
B0AC [si16] 0 (bytes 00 00): This is a major change from the previous log whereB0ACwas56580(interpreted as ~1.245 Amps charging current). A value of 0 here strongly indicates that no current is flowing into the battery. This is exactly what we'd expect when optimized battery charging is holding the battery at 80% – the charging process has paused. -
B0AV [ui16] 30767 (bytes 78 2f): This is the battery voltage. $2F78_{16} = 12152_{10}$. This value likely represents 12152 mV (12.152 Volts). For a typical MacBook battery, this is a healthy voltage, consistent with an 80% charge level. It's significantly higher than the previous log's561 mV, suggesting that the previous reading might have been from a different part of the circuit or a transient state. -
BMSC [ui8] 80 (bytes 50): This value, 80, directly corresponds to the battery's current State of Charge (SoC) in percentage. This perfectly confirms that optimized battery charging is indeed holding the battery at 80%. -
BRSC [ui8] 79 (bytes 4f): Similar toBMSC, this might be another battery charge status or a related "remaining charge" indicator, showing 79%. -
BT0V [flag] (bytes 00): This flag, potentially "Battery 0 Volts," is now 0, meaning the battery is not at zero volts. This is good, it indicates the battery has charge. (In the previous log, it was01, which was a bit counter-intuitive for a charging Mac, but00makes sense here). -
BTTS [flag] (bytes 00): The "Battery Test Status" or "Battery Total Status" flag is now 0, indicating that the battery is not actively charging. This directly supports the observation that charging is paused at 80%. -
BTIL [ui32] 2751791104 (bytes a4 05 00 00): This is current battery capacity, likely in milliamp-hours (mAh). $000005A4_{16}$ (reversed bytes) is actually $1444_{10}$ if it's the rightmost bytes, but if it's the full $A4050000_{16}$ as a 32-bit value, it's $2751791104_{10}$. The latter is too large for mAh. Reversing for little-endian, it's $000005A4_{16}$ (if it's a value where the high bytes are 0s), which is $1444_{10}$. This could represent current capacity in mAh, $1444$ mAh. -
BTSI [ui32] 2751791104 (bytes a4 05 00 00): Same value asBTIL. This might be the initial capacity at the start of the current cycle, or perhaps the 'last full charge capacity' when it was held at 80%. This suggests your battery's current capacity is around 1444 mAh (if interpreted as 16-bit,05A4hex = 1444 decimal). This is quite low for an M1 MacBook Air's total battery capacity (which is around 49.9 Wh or ~4379 mAh). This suggests it's reporting the current effective capacity available in the 80% range, or it might be a partial reading. -
CLSD [ui64] (bytes 16 8d 47 cc a5 46 00 00)andCLSP [ui64] (bytes 72 22 30 54 1f 47 00 00): These are battery design capacity (CLSD) and full charge capacity (CLSP). In the previous log,CLSDwas interpreted as ~4935408906370000. Let's re-evaluate these with typical battery units.-
CLSD: Reversing bytes00 00 46 A5 CC 47 8D 16. This is a very large number that doesn't directly map to Wh or mAh in common interpretations. SMC keys sometimes store these as very specific raw values that need a conversion factor. - A typical M1 MacBook Air battery is around 49.9 Wh or 4379 mAh.
- The
CLSDandCLSPvalues in your log remain unchanged from the previous log. This is expected, as these represent the designed capacity and the current maximum full capacity of the battery, which don't change based on the charging state (unless the battery health degrades).
-
-
PHPB [flt ] 65 (bytes 00 00 82 42): This value of 65.0 (Watts) for "Power Held/Present from Battery" (or main power) indicates the power being consumed by the Mac from the external power source. This confirms the 65W charger is still connected and providing power for the system's operation, even if the battery isn't actively charging. -
PSTR [flt ] 5 (bytes b7 fc ab 40): This value of 5.37 (from $40ABFCB7_{16}$) for "Power State Register" or "Power Strategy Target Rate" has changed from the previous 9. This lower value might signify the reduced power draw for charging as the battery is no longer actively accepting a full charge, only maintaining its 80% level.
Overall Battery State
This log confirms your MacBook Air M1 is performing optimized battery charging as designed. The system has stopped actively charging the battery (B0AC = 0, BTTS = 0) but is still receiving full power from the 65W Power Delivery charger (PHPB = 65.0) to run the machine. The battery is successfully being held at approximately 80% (BMSC = 80).
This behavior is completely normal and healthy for your battery, Kaveen. It helps extend the overall lifespan of your MacBook's battery by reducing the time it spends at 100% charge, which can cause more wear.
Can we modify the old battery release with these new keys? I am new to this.
Can we modify the old battery release with these new keys? I am new to this.
Did you solve it?
Looks like AlDente just released an update for Tahoe: https://github.com/AppHouseKitchen/AlDente-Charge-Limiter/releases/tag/1.33.2
Any updates?
This fork has solved the issue.
Why doesn't he submit this as a PR to this project?