Linux Projektvorstellung: TLP – Linux Stromsparen

[linrunner]

Nachdem im Forum öfters nachgefragt wird, wie man Linux die Feinheiten des Stromsparens beibringt, habe ich mich vor einiger Zeit entschlossen, meine Skriptsammlung in eine allgemein benutzbare Form zu bringen. Das Ergebnis möchte ich Euch an dieser Stelle vorstellen.

Dokumentation ist auf der offiziellen Website https://linrunner.de/tlp/ zu finden (die Infos in unserem Wiki werden von mir nicht mehr gepflegt und sind veraltet).

Fragen und Probleme einfach hier im Thread posten.

Für die erste Analyse benötige ich bitte stets den kompletten Output von

sudo tlp-stat

Anmerkung: ich fordere oft in der weiteren Analyse Teilausgaben an - das sollt ihr jedoch nicht selbstständig tun! Immer zuerst die vollständige Ausgabe.

Bitte auch die FAQ beachten!

Rückmeldungen der Art "alles funktioniert" sind natürlich auch gern gesehen ...

 

[mcb]

Da ist der Debian Backport!

 marc@t14:~$ apt policy tlp*
tlp:
  Installed: 1.9.1-1
  Candidate: 1.9.1-1~bpo13+1
  Version table:
 *** 1.9.1-1 500
        500 file:/var/local/repository/trixie ./ Packages
        100 /var/lib/dpkg/status
     1.9.1-1~bpo13+1 1000
        100 http://ftp.ch.debian.org/debian trixie-backports/main amd64 Packages
        100 http://ftp.ch.debian.org/debian trixie-backports/main i386 Packages
        100 http://ftp.es.debian.org/debian trixie-backports/main amd64 Packages
     1.8.0-1 500
        500 http://ftp.ch.debian.org/debian trixie/main amd64 Packages
        500 http://ftp.ch.debian.org/debian trixie/main i386 Packages
        500 http://ftp.es.debian.org/debian trixie/main amd64 Packages
tlp-rdw:
  Installed: 1.9.1-1
  Candidate: 1.9.1-1~bpo13+1
  Version table:
 *** 1.9.1-1 500
        500 file:/var/local/repository/trixie ./ Packages
        100 /var/lib/dpkg/status
     1.9.1-1~bpo13+1 1000
        100 http://ftp.ch.debian.org/debian trixie-backports/main amd64 Packages
        100 http://ftp.ch.debian.org/debian trixie-backports/main i386 Packages
        100 http://ftp.es.debian.org/debian trixie-backports/main amd64 Packages
     1.8.0-1 500
        500 http://ftp.ch.debian.org/debian trixie/main amd64 Packages
        500 http://ftp.ch.debian.org/debian trixie/main i386 Packages
        500 http://ftp.es.debian.org/debian trixie/main amd64 Packages
tlp-pd:
  Installed: 1.9.1-1
  Candidate: 1.9.1-1~bpo13+1
  Version table:
 *** 1.9.1-1 500
        500 file:/var/local/repository/trixie ./ Packages
        100 /var/lib/dpkg/status
     1.9.1-1~bpo13+1 1000
        100 http://ftp.ch.debian.org/debian trixie-backports/main amd64 Packages
        100 http://ftp.ch.debian.org/debian trixie-backports/main i386 Packages
        100 http://ftp.es.debian.org/debian trixie-backports/main amd64 Packages

Bookworm kommt wohl auch.

Beitrag automatisch zusammengeführt: 19 Jan. 2026

Bookworm kommt wohl auch.

marc@t14:~$ rmadison tlp
tlp        | 1.3.1-2         | oldoldstable                      | source, all
tlp        | 1.5.0-2         | oldstable                         | source, all
tlp        | 1.8.0-1~bpo12+1 | oldstable-backports               | source, all
tlp        | 1.8.0-1         | stable                            | source, all
tlp        | 1.9.1-1~bpo12+1 | buildd-oldstable-backports-sloppy | source, all
tlp        | 1.9.1-1~bpo12+1 | oldstable-backports-sloppy        | source, all
tlp        | 1.9.1-1~bpo13+1 | stable-backports                  | source, all
tlp        | 1.9.1-1         | testing                           | source, all
tlp        | 1.9.1-1         | unstable                          | source, all

 

[linrunner]

Bookworm kommt wohl auch.

Ist inzwischen da.

Nun ist 1.9.1 sowohl bei Debian Trixie (13) als auch Bookworm (12) via Backports verfügbar.

 

[KB19]

Gibt es eigentlich eine Möglichkeit, dass die Battery-Thresholds beim Systemstart nur gesetzt werden, wenn sich die Werte geändert haben? Falls nicht, wäre eine Konfigurationsvariable dafür echt praktisch.

Sofern ich da nichts durcheinander gebracht habe, scheint es aktuell nämlich so zu sein, dass das Setzen der Werte u.a. beim Systemstart oder auch beim Aufwachen aus dem Standby dazu führt, dass das Laden unterbrochen wird, wenn der aktuelle Ladestand zwischen Start und Endwert liegt. Wenn die Werte jedoch nicht neu gesetzt werden, wird das Laden ganz normal bis zum Endwert fortgesetzt. Dieses Verhalten einem Otto-Normal-User zu erklären ist dann relativ schwierig.

 

[Ambrosius]

KF: welche Datei kann ich zb mit cat auslesen um im laufenden System die verfügbare Ladung (BAT0/BAT1) auszulesen, wenn tlp grad nicht verfügbar ist?

 

[KB19]

KF: welche Datei kann ich zb mit cat auslesen um im laufenden System die verfügbare Ladung (BAT0/BAT1) auszulesen, wenn tlp grad nicht verfügbar ist?

Ich habe gerade nur das Gerät mit Coreboot in Reichweite, aber die Pfade sollten afaik gleich sein:

/sys/class/power_supply/BAT0/charge_full_design
/sys/class/power_supply/BAT0/charge_full
/sys/class/power_supply/BAT0/charge_now

(Oder halt BAT1 statt BAT0.)

 

[Crisser67]

Nun ist 1.9.1 sowohl bei Debian Trixie (13) als auch Bookworm (12) via Backports verfügbar.

Super.
Ich habe gerade mein MX-Linux-KDE 23.6 (Libretto) basierend auf Debian Bookworm (12) auf 1.9.1 aktualisiert.
Die neue Version gab es bei den MX-Test-Paketquellen, bei den Debian-Backports ist nur 1.8.0-1 verfügbar, warum auch immer.

Es wurde leider wieder eine der zwei SSDs im X280 nicht erkannt bei DISK_DEVICES, diesmal die 2280er Haupt-SSD, statt wie letztes mal die kleine SSD im WWAN-Slot.
Ich habe beim Update mutmasslich die (geänderte) Config ( DISK_DEVICES="nvme1n1 nvme0n1 sda") übernommen bei der Nachfrage (mit: y).
Es wurde scheinbar eine neue Config mit dem Standard (#DISK_DEVICES="nvme0n1 sda") installiert, denke ich.
Ich weiss nicht, ob das alles so normal und sinnvoll ist, weil ich auch normalerweise, wenn überhaupt, TLP mit TLP-UI als grafische Oberfläche und nicht mit der Config benutze.


Ansonsten scheint, wie gehabt, alles zu funktionieren.
Danke an alle Beteiligten, vor allem @linrunner. Tolle Arbeit, weiter so

 

[mcb]

Die neue Version gab es bei den MX-Test-Paketquellen, bei den Debian-Backports ist nur 1.8.0-1 verfügbar, warum auch immer.

1.9.1 ist in bookworm-backports-sloppy ;-)

Falls nicht, wäre eine Konfigurationsvariable dafür echt praktisch.

Da bräuchte es sowas wie

RESTORE_THRESHOLDS_ON_BAT="1"

für AC? Keine schlechte Idee.

Sollte es eine einstellbare Präferenz geben, die etwas anderes als die feste Zuweisung von Profilen zur Stromquelle Netzteil / Akku ermöglicht? Was sind eure Anwendungsfälle?

Habe mich jetzt für

TLP_AUTO_SWITCH="1"

entschieden. Gefällt mir am T14 am besten.
Den Power Saver schalte ich mit alias ein.

 

[linrunner]

Gibt es eigentlich eine Möglichkeit, dass die Battery-Thresholds beim Systemstart nur gesetzt werden, wenn sich die Werte geändert haben? Falls nicht, wäre eine Konfigurationsvariable dafür echt praktisch.

Bevor Ihr @KB19 @mcb euch jetzt weiter den Kopf zerbrecht: genau so macht es TLP seit Ewigkeiten. Die Schwelle wird zuerst gelesen, und nur wenn der Sollwert abweicht, wird geschrieben: https://github.com/linrunner/TLP/blob/main/bat.d/05-thinkpad#L587

@KB19 das von dir beschriebene Verhalten kommt nicht von TLP und ist mir auch noch nicht begegnet.

KF: welche Datei kann ich zb mit cat auslesen um im laufenden System die verfügbare Ladung (BAT0/BAT1) auszulesen, wenn tlp grad nicht verfügbar ist?

Falls Ladestand in Prozent benötigt: /sys/class/power_supply/BAT0/capacity (mit seltsamer Abrundung)
Die Werte in µW(h) - u.A. bei ThinkPads (nicht Coreboot): /sys/class/power_supply/BAT0/energy_*
Die Werte in µA(h) - diverse andere Fabrikate: /sys/class/power_supply/BAT0/charge_*

Ich habe beim Update mutmasslich die (geänderte) Config ( DISK_DEVICES="nvme1n1 nvme0n1 sda") übernommen bei der Nachfrage (mit: y).
Es wurde scheinbar eine neue Config mit dem Standard (#DISK_DEVICES="nvme0n1 sda") installiert, denke ich.

Unter Debian (und Derivaten) ist die beste Strategie, nicht die neue Version der tlp.conf installieren zu lassen, d.h stets <N> zu drücken. Oder <Enter>, denn N ist der Default.

Das ist ein Debian-Standardmechanismus, der für alle Pakete mit Konfigurationsdateien gilt, nicht nur für TLP.
In der Mehrzahl der Fälle kommen neue Programmversionen mit alten Konfigurationsdateien klar. Oft ändern sich nur Kommentare.

Ich weiss nicht, ob das alles so normal und sinnvoll ist, weil ich auch normalerweise, wenn überhaupt, TLP mit TLP-UI als grafische Oberfläche und nicht mit der Config benutze.

Da TLP-UI (separates Projekt, nicht von mir) keine eigene Datenbank verwendet, sondern alles per TLP Konfigurationdatei abspeichert, ändert das nichts. Wenn Du beim Update <Y> drückst, sind deine Änderungen weg. TLP-UI setzt auf diesem Stand auf.

Meine Empfehlung ist: nicht die /etc/tlp.conf verwenden, sondern eigene Konfiguration als Schnipsel unter /etc/tlp.d/*.conf ablegen:

Introduction — TLP 1.9.1 documentation

Die werden beim Paket Upgrade niemals angefasst und die blöde Fragerei entfällt.

 

[Crisser67]

und die blöde Fragerei entfällt.

Alles klar Cheffe...

 

[mcb]

Die Schwelle wird zuerst gelesen, und nur wenn der Sollwert abweicht, wird geschrieben: https://github.com/linrunner/TLP/blob/main/bat.d/05-thinkpad#L587

Impressive!

 

[KB19]

genau so macht es TLP seit Ewigkeiten. Die Schwelle wird zuerst gelesen, und nur wenn der Sollwert abweicht, wird geschrieben: https://github.com/linrunner/TLP/blob/main/bat.d/05-thinkpad#L587

@KB19 das von dir beschriebene Verhalten kommt nicht von TLP und ist mir auch noch nicht begegnet.

Danke für die passende Zeile!

Interessant, dann muss ich das nochmals im Detail untersuchen und schauen, durch was dieses Verhalten dort wirklich getriggert wird. Sorry für die Störung und den falschen Bug Report bzw. Feature Request!

 

[linrunner]

@KB19 wenn Du in der Konfiguration den Trace einschaltest durch Einfügen der Zeile

TLP_DEBUG="bat ps run"

Kannst Du mit

sudo tlp-stat -T

nachvollziehen, was TLP im Hintergrund getan hat.

 

[KB19]

@linrunner Danke für den Tipp mit der Debug-Variable. Das bestätigt Deine Aussage, dass TLP genau das macht, wie es gedacht ist. Nämlich nichts

Ich habe das gerade auf einem (Non-Coreboot) T440p versucht zu reproduzieren, mit einer Testinstallation von Xubuntu: Wenn ich den Startwert während des Ladevorgangs manuell in /sys ändere, während der aktuelle Ladestand zwischen Start/Endwert liegt, stoppt das Laden sofort.

Danach habe ich die Ladeschwellen auf 55/80 gesetzt, während der Akku auf 50% war, und das Gerät sofort heruntergefahren. Nach ein paar Minuten wieder gebootet, der Akku war nun bereits auf 61% und wurde nicht mehr geladen. TLP hat währenddessen aber garantiert nichts gemacht.

Offenbar habe ich mir da etwas zusammengereimt, was eine andere Ursache hat, vielleicht reagiert der EC bei einigen Serien anders und eigenständig? Oder z.B. ein L440 (um das es ursprünglich geht), verhält sich dabei anders? Das kann ich aber erst in einigen Tagen erneut testen, das ist aktuell nicht bei mir.

Wie auch immer, falls ich noch neue Erkenntnisse finde, teile ich die gerne hier. Im Moment ist es für mich ein Mysterium. Oder ist dieses Verhalten eh normal, wenn das Gerät gestartet wird?

 

[linrunner]

Ich habe das gerade auf einem (Non-Coreboot) T440p versucht zu reproduzieren, mit einer Testinstallation von Xubuntu: Wenn ich den Startwert während des Ladevorgangs manuell in /sys ändere, während der aktuelle Ladestand zwischen Start/Endwert liegt, stoppt das Laden sofort.

Das scheint je nach Modell/Generation unterschiedlich zu sein. Wenn ich z.B. beim X1 Gen9 oder P14s Gen2 AMD nachträglich eine Startschwelle setze, die unterhalb des Ladestands ist, dann stoppt das Laden nicht.

Danach habe ich die Ladeschwellen auf 55/80 gesetzt, während der Akku auf 50% war, und das Gerät sofort heruntergefahren. Nach ein paar Minuten wieder gebootet, der Akku war nun bereits auf 61% und wurde nicht mehr geladen. TLP hat währenddessen aber garantiert nichts gemacht.

Startschwelle über Ladestand setzen scheint in der Regel zu klappen, das nutzt der Befehl tlp chargeonce. Da kam nur einmal eine Beschwerde.