BatteryChargeManager - Festlegung von Ladeschwellen

[schiel]

Unter Windows 10 wird es m.E. mit der Software von Lenovo immer schwieriger, die Ladeschwellen festzulegen. Ich habe deshalb ein kleines Tool programmiert, mit dessen Hilfe die obere und untere Ladeschwelle festgelegt werden kann. Dabei werden im Wesentlichen lediglich die relevanten Registry-Einträge bearbeitet.

Systemvoraussetzungen: Windows 7 / 8.x / 10, jeweils 32 und 64 bit
Downloadgröße: 1,13 MB
Lizenz: Freeware

Screenshots:






Nähere Infos und Download: https://www.batterychargemanager.de
Rückmeldungen, Kritik, Anregungen bitte an schiel@batterychargemanager.de


Ergänzung am 13.4.2020: Hinweise, falls es nicht funktioniert

BatteryChargeManager schreibt lediglich die erforderlichen Werte in die Registry, das Einhalten dieser Ladeschwellen erledigen dann die Lenovo-Treiber.

Es werden folgende Werte geschrieben:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Lenovo\PWRMGRV\Data]
"ChargeStartControl"=dword:00000001
"ChargeStartPercentage"=dword:0000004b
"ChargeStopControl"=dword:00000001
"ChargeStopPercentage"=dword:00000055
"Automatic"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Lenovo\PWRMGRV\ConfKeys\Data]
"ChargeStartControl"=dword:00000001
"ChargeStartPercentage"=dword:0000004b
"ChargeStopControl"=dword:00000001
"ChargeStopPercentage"=dword:00000055
"Automatic"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Lenovo\PWRMGRV\ConfKeys\Data\<AccuID>]
"ChargeStartControl"=dword:00000001
"ChargeStartPercentage"=dword:0000004b
"ChargeStopControl"=dword:00000001
"ChargeStopPercentage"=dword:00000055
"Automatic"=dword:00000002

<AccuID> muss durch den jeweiligen Akku-Barcode ersetzt werden.
ChargeStartControl und ChargeStopControl müssen jeweils 1 sein, wenn die Ladeschwellen aktiv sein sollen.
ChargeStartPercentage und ChargeStopPercentage stellen (hexadezimal) die Ladeschwellen dar.
Automatic sollte den Wert 2 haben.


Die gleichen Einträge sollten (je nach Windows-Version) auch unter HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Lenovo\PWRMGRV\ zu finden sein. Unter einem 32-bit-Betriebssystem entfällt jeweils das WOW6432Node.

Falls es trotz Beachtung aller Voraussetzungen nicht funktioniert: Man kann mit dem Registrierungseditor (regedit) kontrollieren, ob die Einträge da sind und korrekte Werte haben. Wenn da alles in Ordnung ist, stimmt etwas mit den Lenovo-Treibern nicht. Dann kann man versuchen, diese Treiber zu deinstallieren, den PC neu zu starten und die auf der Programmhomepage angebotenen Treiber erneut zu installieren.

Wichtig ist auch, dass die Akkuladung bei abgezogenem Netzteil (einmalig) UNTER die untere eingestellte Ladeschwelle fallen muss, damit die Werte in den Controller des Akkus übernommen werden.

Michael Schiel

 

[schiel]

Habe geantwortet - aber warum muss ein Moderator meinen Beitrag prüfen? Das klappt nämlich meist nicht!
Das hat dank Mornsgrans sehr schnell funktioniert - Danke!

 

[Mornsgrans]

Beitrag #20 freigeschaltet.

@schiel:
Siehe Hinweise für neue Mitglieder (verlinkt auf Startseite oben mitte)

 

[mcb]

Beim Aufladen, also nach Entladung, lädt nur der externe wieder auf. Der interne reagiert erst wieder, wenn ich im Programm erneut die Ladeschwelle einstelle und neustarte. In der Registry ist der Barcode vermekt, die Schwellen sind richtig erfasst.

Ev. kannst du mal mit dem Lenovo Kommandozeilentool gegenchecken.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\>cd pstools

C:\pstools>dir *bat*
 Volume in drive C is Win NT
 Volume Serial Number is 1A9E-C0BE

 Directory of C:\pstools

05/25/2019  01:58 PM                29 battery.cmd
08/11/2017  12:55 PM            79,872 BatteryInfoView.exe
05/23/2019  09:57 AM        10,104,923 Fix-Battery-Gauge.zip
11/07/2016  01:35 PM               224 Kill-mencoder.bat
03/03/2017  10:34 AM                54 sigcheck.bat
09/16/2015  11:00 AM               319 Turn_Off_Fast_Startup.bat
               6 File(s)     10,185,421 bytes
               0 Dir(s)  367,217,729,536 bytes free

C:\pstools>battery

C:\pstools>cmd /k chargethreshold status
Error connecting the Base module (1722). Please make sure the following:
  - Lenovo Power Manager driver is installed.
  - PowerMgr.exe is running.

C:\pstools>

^^ geht leider erst ab Windows 10

- - - Beitrag zusammengeführt - - -

Beitrag #20 freigeschaltet.

@schiel:
Siehe Hinweise für neue Mitglieder (verlinkt auf Startseite oben mitte)

Ist eine Ausnahme für Toolentwickler möglich? Ich wäre dafür.

 

[linrunner]

Für das Starten und Stoppen des Ladevorgangs ist der Lenovo Power Management Treiber verantwortlich.

Ich denke, tatsächlich wird der Ladevorgang vom Embedded Controller gesteuert, denn es muss ja auch ohne gestartetes OS und insbesondere bei ausgeschaltetem ThinkPad funktionieren. Der Lenovo Treiber dürfte lediglich die Schwellenwerte aus der Registry in die Register des EC befördern.

Ab der *20 Generation passiert das per ACPI-Call. So machen es jedenfalls der Linux-Kernel-Treiber und das ältere Linux-Tool tpapci-bat (beides nicht meine Schöpfung, TLP nutzt sie nur). Vor der *20 Generation wurde der EC per IO-Port angesprochen (Linux: tp-smapi).

Beide Varianten muss auch Lenovos Windows Treiber beherrschen. Wobei das kein reiner Kernel-Treiber sein kann, denn .NET Framework 3.x bedeutet Userspace Code.

 

[schiel]

@linrunner: Stimmt - da habe ich mich undeutlich ausgedrückt.

Im konkreten Fall ist es schwer zu sagen, woran es liegt: Entweder übermittelt der Power Management Driver die Werte nicht korrekt an die Embedded Controller der beiden Akkus, oder die ECs bekommen den Ladevorgang - aus welchen Gründen auch immer - nicht geregelt.

Stellt sich die Frage: Wer regelt, welcher Akku zuerst geladen wird, insbesondere, wenn der ThinkPad heruntergefahren ist? "Sprechen" sich die Controller der Akkus irgendwie gegenseitig ab? Schwer vorstellbar...

 

[mcb]

Beim T440s:

entläd immer der externe Akku zuerst.
lädt der interne Akku zuerst bis 80% => und dann erst der externe (bis 80%) und dann lädt der interne weiter (das beißt sich zwangsläufig mit gesetzten Ladeschwellen).

Das muß in der Hardware fest vorgegeben sein. Mit tlp kann man noch ein Entladen des internen erzwingen.

 

[linrunner]

Der Boss ist immer der EC. Ich hatte beim X1C6 mal das Problem, dass man die Stop-Schwelle nach Herabsetzen nicht zurück auf 100% bekam. Wurde später durch ein EC Update gelöst, wohlgemerkt ohne Vermerk im Changelog.

 

[schiel]

Bei einem T450s, mit dem ich ausführlich testen konnte, wurde auch zuerst der externe Akku entladen, danach der interne. Beim Aufladen war es dann andersherum: Zuerst wurde der interne bis zu seiner oberen Ladeschwelle aufgeladen, dannach der externe, ebenso bis zur individuellen oberen Ladeschwelle. Danach wurde jedoch NICHT mehr geladen, auch der interne wurde also danach NICHT über die obere Ladeschwelle hinaus geladen. Es wurden also BEIDE oberen Ladeschwellen dauerhaft eingehalten.

 

[mcb]

@schiel Danke für die Info, ich kann aber nur vom T440s berichten und dort funktionieren einige Ladeeistellungen nicht durch die feste Umschaltung des Ladevorgangs bei 80 %.

@linrunner Wie ist das den unter Linux mit dem T450s ?

 

[Numinos]

Bei einem T450s, mit dem ich ausführlich testen konnte, wurde auch zuerst der externe Akku entladen, danach der interne. Beim Aufladen war es dann andersherum: Zuerst wurde der interne bis zu seiner oberen Ladeschwelle aufgeladen, dannach der externe, ebenso bis zur individuellen oberen Ladeschwelle. Danach wurde jedoch NICHT mehr geladen, auch der interne wurde also danach NICHT über die obere Ladeschwelle hinaus geladen. Es wurden also BEIDE oberen Ladeschwellen dauerhaft eingehalten.

Das kann ich so bestätigen, wie ich zuvor ja auch bereits schrieb. Beim T450s wird erst der externe, dann der interne entladen.

Zudem werden die Ladeschwellen für beide Akkus eingehalten, wie Herr Schiel schreibt. Das ist ja wichtig, sonst wäre das Programm ja für die Katz.

Mein Problem ist eben nur, dass beim Laden der interne Akku nicht mehr angesteuert wird, sodass nur der externe lädt. Ich gucke mir die Geschichte nochmal in den kommenden Tagen in Ruhe an.

 

[linrunner]

@schiel: der ("Boss"-)EC, den ich meine, sitzt auf dem Systemboard, nicht im Akku.

Was die Ladestrategie bei zwei Akkus betrifft, so nimmt Lenovo offensichtlich manchmal mit einer neuen Generation Änderungen vor. Das man sie nicht ändern kann, da in der EC-Firmware hartkodiert, bleibt aber das bestimmende Merkmal.

@Numinos: bei dir scheint es nicht auf dem Weg von der Registry über den "Treiber" in den EC zu haken – die geänderte Start-Schwelle nimmt er ja –, sondern bei der Steuerung des Ladevorgangs durch den EC. Könnte es vielleicht sein, dass der externe Akku nicht wirklich ganz voll ist bzw. das nicht meldet und deshalb der EC das Ladeziel noch nicht wechseln mag? Dann wäre der ext. Akku selbst die Ursache. Lädt er denn den internen, wenn Du den externen Akku rausgenommen hast?

Vielleicht hat dein Fall auch Parallelen zu diesem aus meiner FAQ.

ps. @mcb: mein T450s entlädt zuerst den externen, danach den internen Akku.

 

[Numinos]

Zwei Ergänzungen:

1. Das Entladen

Auf reddit las ich irgendwann, dass Lenovo die Entlade-Reihenfolge irgendwann im Laufe der Geräteevolution änderte. Mehrere User berichteten davon.

2. Das Aufladen

Es lädt ja erst der "interne auf", dann der externe. Das ist ja auch an meiner Problematik zu sehen: der externe Akku steht auf 90%, der interne auf 10. Sobald ich im Programm die Ladeschwelle dann auf 9% setze und neustarte, lädt der interne Akku bis auf 90% auf. Das heißt ja, dass der externe mit seiner eingerichteten Ladeschwelle auch als "voll" erkannt wird, zumindest nach dem Neustart, sonst würd der interne ja nicht laden.

 

[Numinos]

Leider läuft der battery manager bei mir einfach nicht vernünftig.

Der interne Akku wird nun geladen, auch mit Einhaltung der Ladeschwelle, dafür lädt aber jetzt der externe auf 100%, obwohl in der Registry alles richtig gesetzt ist.

Auch ist mir aufgefallen, dass nun beide Akkus per BarCode auswählbar sind. Zuvor war es nur der interne bzw. "all batteries".

 

[schiel]

Was genau ist mit "zuvor" gemeint?

Wenn in der Registry alle Werte richtig gesetzt sind, hat der BatteryChargeManager seine Aufgabe erfüllt - das Verwalten der entsprechenden Registry-Werte ist die einzige Funktion (es gibt je nach Windows-Version hier verschiedene Registry-Zweige). Das Abschalten des Ladevorgangs bleibt der Lenovo-Software vorbehalten. Insofern ist es ein gutes Zeichen, dass beide Akkus auswählbar sind. BatteryChargeManager liest die Barcodes nur aus der Registry aus (und setzt die gewünschten Ladeschwellen), angelegt werden die Registry-Einträge von der Lenovo-Software (Lenovo Power Management Driver bzw. ThinkPad Settings Dependency bzw. System Interface Foundation). Das Anlegen dieser Einträge hat also offensichtlich funktioniert - gut.

Warum die obere Ladeschwelle beim externen Akku nicht beachtet wird, hängt also mit der Lenovo-Software zusammen. Evtl. könnte es helfen, die Lenovo-Software mal neu zu installieren. Schon mal versucht?
Und: Mal bitte den in der Registry hinterlegten Barcode mit dem tatsächlichen Barcode des externen Akkus vergleichen (Anleitung dazu auf der Website des Programms). Stimmt da alles?

Michael

 

[Numinos]

Danke für die Rückmeldung. Mein Problem ist inzwischen gelöst. Ich hoffe, das bleibt so.

Hier noch einmal im Detail die Lage von der Installation bis zur Lösung:

1. Installation mit allen erforderlichen Treibern für ein Gerät mit zwei Akkkus (Powerbridge)
2. Der interne Akku wird nicht geladen
3. Manuelle Eingabe des Barcodes für den internen Akku
4. Interner Akku wird nun geladen
5. Die Ladeschwelle des externen Akkus wird auf einmal nicht mehr eingehalten
6. Plötzlich taucht von allein auch der externe Akku per BarCode auf
7. Erneutes Speichern im battery manager der Schwellen für beide Akkus (BarCodes)
8. Programm läuft

Keine Ahnung, ob das nun bei mir so abläuft. Am besten ist es wohl, direkt beide BarCodes manuell einzugeben. Da der externe Akku von Beginn an mit Ladeschwelle geladen wurde, ging ich davon aus, ich müsste den BarCode für diesen nicht eingeben, sondern nur den des internen Akkus, denn der war ja nicht gelistet.

 

[schiel]

Kurze Rückfrage: Du schreibst, dass du den INTERNEN Akku per Barcode eingetragen hast. Weiter unten steht: Plötzlich taucht ... auch der EXTERNE Akku auf.
Welcher Akku wurde denn "gefunden" und angezeigt, BEVOR du den Barcode (des internen Akkus) per Hand eingegeben hattest?

Ansonsten: Schön, dass nun alles funktioniert. Und schön, dass du deine Erfahrungen mitteilst - sicher hilfreich für manch andere mit ähnlicher Konfiguration.

Michael

 

[Flesch]

Hallo, erstmal vielen lieben Dank für das Tool!
Es hat bei meinem guten alten T530 auch ein paar Tage lang einwandfrei funktioniert. Nur irgendwann war der Akku plötzlich wieder auf 100% geladen, und egal was ich versuche, er ignoriert alles was ich im BatteryChargeManager einstelle. Ich hab die Einstellungen rauf und runter geändert, für den eingebauten und für alle Akkus abgespeichert - keine Wirkung.
Da es eine Zeit funktioniert hat, dürften Bios und Treiber nicht das Problem sein, oder?

 

[Mornsgrans]

Doch, z.B. ein nicht sauber arbeitender Power Management Driver, der möglicherweise zwischenzeitlich installiert wurde. Ein Blick in Gerätemanager, Ereignisanzeige und Installationsprotokoll von Windows Update könnte Klärung bringen.

 

[Numinos]

Kurze Rückfrage: Du schreibst, dass du den INTERNEN Akku per Barcode eingetragen hast. Weiter unten steht: Plötzlich taucht ... auch der EXTERNE Akku auf.
Welcher Akku wurde denn "gefunden" und angezeigt, BEVOR du den Barcode (des internen Akkus) per Hand eingegeben hattest?

Ansonsten: Schön, dass nun alles funktioniert. Und schön, dass du deine Erfahrungen mitteilst - sicher hilfreich für manch andere mit ähnlicher Konfiguration.

Michael

Bevor ich beim T450s den internen Akku per BarCode eintrug, wurde der externe ganz normal erkannt und funktionierte mit der entsprechenden Ladeschwelle. Allerdings wurde dieser eben nicht zu Beginn im Porgramm mit BarCode gelistet, dieser Eintrag tauchte, wie geschrieben, erst nach Hinzufügen des internen Akkus auf. Bei allen anderen Geräten mit nur einem Akku wird unter Get Values auch kein BarCode angezeigt.

 

[Flesch]

Uff, mit einem Blick ist es anscheinend nicht getan...
Das einzige, was ich mit Sicherheit behaupten kann ist, dass im Geräte-Manager bei keinem Gerät eine Warnung daneben steht. Aus dem Wust der Meldungen in der Ereignisanzeige werde ich leider nicht schlau, und die Installationsprotokolle krieg ich nicht mal gelesen, sorry.