Å ta vare på batteriet i laptopen.

SveinHa · 23. februar

Jeg har "i alle år" hatt laptopen stående på lading mer eller mindre døgnet rundt vel vitende om at batteriet ikke liker det... Lithiumbatteri liker seg aller best med en ladeprosent på 20 til 80.

Der finnes en del programmer som kan installeres på laptopen der du kan styre batteriladingen til f.eks. 20 og 80% og jeg har prøvd noen av de på min HP ENVY x360 med Ryzen 7 prosessor men denne maskinen lar seg ikke styre på denne måten.

Da får en ty til andre midler. I Linux finnes jo en mengde forskjelige verktøy som kan kombineres og i dette tilfellet endte jeg opp med denne løsningen:

upower kan lese ut en masse informasjon om batteriet (finn navnet på batteriet med: upower --enumerate)
grep gir en enkel utsortering av aktuell info
resultatet lagres i tekstfil
mosquitto_pub sender data fra tekstfil til mqtt broker
Ovenforstående ligger i et shell script som fyres i gang f.eks. hvert 5 minutt av cron (sudo crontab -e)
Node-RED henter data fra mqtt, gjør nødvendige beregninger og styrer en wallplug av/på etter valgte grenser for ladestatus

mintre.sh:

#!/bin/sh
upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep percentage > /home/svein/mintre.txt
mosquitto_pub -h 172.16.0.94 -u useruser -P passpass -t Teknisk/mintre/soc -f /home/svein/mintre.txt

cron:

*/5 * * * * /home/svein/mintre.sh

Node-RED:

Funksjonsblokken "Charge on/off" inneholder:

let chgCmd = true;
let soc = Number(msg.payload.slice(-6,-2));
if (soc >= 80) context.set("chgCmd", false);
if (soc <= 20) context.set("chgCmd", true);

msg.topic = "Teknisk/mintre/charge"
msg.payload = context.get("chgCmd");
return msg;

...og plutselig holder batteriet seg innenfor 20-80%😎 i alle fall så lenge den er på sin vante plass...

...og så kan en jo raffinere litt slik at batteriet bare går ned til 20 om natten og ned til 50-60 om dagen slik at en har større reserve om en må ta laptopen "ut på tur"...

Endret 23. februar av SveinHa

Teknor · 23. februar

Skulle gjerne hatt "power admistration" som en del av Home Assistant Operating System.

SveinHa · 23. februar

Dette her skulle nå være forholdsvis enkelt å lage i flere sammenhenger, i alle fall under Linux.

SveinHa · 25. februar

Dette her fungerte jo helt som tenkt men ikke helt ideelt likevel for nå brukes batteriet aktivt (tømmes) rundt halve tiden og så lades opp igjen. Li-Ion batterier har vel noe sånt som 800 sykler tilgjengelig... Det beste hadde jo vært å lade batteriet opp til 80% og så gå over til å kjøre laptopen på direktestrøm uten batterilading men det vet jeg ikke hvordan jeg skal få til... Får gruble litt eller kanskje noen har tips?

Endret 25. februar av SveinHa

Bjørn Mork · 25. februar

Vet ikke hvordan på en HP, men den riktige måten er å lage en driver som snakker med ECen i laptopen og forteller den hva grensene skal være. Typisk har ECen ACPI og/eller WMI funksjoner for den slags.

I Linux er det standardiserte og dokumenterte grensesnittet et par sysfs attributter. Dokumentasjon her:

https://www.kernel.org/doc/html/latest/admin-guide/abi-testing.html#abi-sys-class-power-supply-supply-name-charge-control-end-threshold

Dersom du har en driver som støtter dette så finner du dem under batteri-objektet i sysfs. Helt sikkert også i diverse GUI-verktøy på toppen, men det er jo mer krøkkete å forholde seg til. På min Stinkpad så har jeg:

root@miraculix:/home/bjorn# ls -l /sys/class/power_supply/BAT0/charge_control_*
-rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_end_threshold
-rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_start_threshold
root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_*
/sys/class/power_supply/BAT0/charge_control_end_threshold:90
/sys/class/power_supply/BAT0/charge_control_start_threshold:80

Så dermed lader ECen batteriet til 90% og stopper der. Så kjører den maskinen på AC inntil batteriet har droppet til 80% før den begynner å lade igjen. Kan jo ta en del tid når den ikke bruker batteriet. Dette er grenser jeg har valgt og bare lagt inn i de filene der (vha sysfsutils, men det kunne jo like gjerne vært et par echo kommandoer i et boot script).

Navnene på driverne som har implementert slikt forteller det meste om hvilke merker du kan forvente at det virker. Dessverre ikke HP ser det ut til:

bjorn@miraculix:/usr/local/src/git/linux$ git grep -l charge_control_end_threshold drivers/
drivers/platform/x86/asus-wmi.c
drivers/platform/x86/dell/dell-laptop.c
drivers/platform/x86/fujitsu-laptop.c
drivers/platform/x86/huawei-wmi.c
drivers/platform/x86/lg-laptop.c
drivers/platform/x86/msi-ec.c
drivers/platform/x86/system76_acpi.c
drivers/platform/x86/thinkpad_acpi.c
drivers/platform/x86/toshiba_acpi.c

Noe å tenke på neste gang du handler laptop... Evt er det jo sikkert mulig å implementere på HP også hvis man har tid og ork. Regner med at de har funksjonaliteten i WIndows, så det er jo "bare" å finne ut hva de magiske ACPI eller WMI besvergelsene er

SveinHa · 25. februar

Bjørn Mork skrev (9 minutter siden):

Noe å tenke på neste gang du handler laptop... Evt er det jo sikkert mulig å implementere på HP også hvis man har tid og ork. Regner med at de har funksjonaliteten i WIndows, så det er jo "bare" å finne ut hva de magiske ACPI eller WMI besvergelsene er

Supert, da har jeg litt mer å jobbe med. Har som nevnt prøvd noen alternative programmer men ingen klarte å gjøre noe på min laptop.

SveinHa · 25. februar

Ser jeg ikke har "charge_control_*":

Sitat

svein@mintre:~$ sudo ls -l /sys/class/power_supply/BAT0/*
-rw-r--r-- 1 root root 4096 feb. 25 16:18 /sys/class/power_supply/BAT0/alarm
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/capacity
-r--r--r-- 1 root root 4096 feb. 25 16:18 /sys/class/power_supply/BAT0/capacity_level
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/charge_full
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/charge_full_design
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/charge_now
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/current_now
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/cycle_count
lrwxrwxrwx 1 root root 0 feb. 25 13:37 /sys/class/power_supply/BAT0/device -> ../../../PNP0C0A:00
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/manufacturer
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/model_name
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/present
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/serial_number
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/status
lrwxrwxrwx 1 root root 0 feb. 25 16:18 /sys/class/power_supply/BAT0/subsystem -> ../../../../../../../../../class/power_supply
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/technology
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/type
-rw-r--r-- 1 root root 4096 feb. 25 16:18 /sys/class/power_supply/BAT0/uevent
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/voltage_min_design
-r--r--r-- 1 root root 4096 feb. 25 13:37 /sys/class/power_supply/BAT0/voltage_now

Bjørn Mork · 25. februar

Nei, du må nok lage driveren. Ikke helt umulig, men litt risikabelt å fikle med siden det er udokumentert blind fikling inn i det aller helligste der minst en av funksjonene etter all sannsynlighet starter selvdestruksjonsekvensen. seriøst.

Nyttige verktøy:

Intels ASL+ kompilator. iasl. Inkludert i Debian-pakken acpica-tools
https://github.com/mkottman/acpi_call. Pakket som acpi-call-dkms i Debian

Eksempel på hvordan dekompilere DSDT for å se på hva som er tilgjengelig og kalle funksjoner der. Utøves med stor forsiktighet - firmware i en laptop gjør veldig mye rart og er vanligvis skrevet av idioter på crack:

apt install acpi-call-dkms
modprobe acpi-call
cp /sys/firmware/acpi/tables/DSDT /tmp/
iasl -d /tmp/DSDT
less /tmp/DSDT.dsl

Her ser jeg f.eks denn blokken, som jeg er så heldig å allerede vite har noe med batteri/lading å gjøre

        Scope (\_SB.PCI0.LPC.EC.HKEY)
        {
            Method (PSSG, 1, NotSerialized)
            {
                Return (\PSIF (0x00, 0x00))
            }

            Method (PSSS, 1, NotSerialized)
            {
                Return (\PSIF (0x01, Arg0))
            }

            Method (PSBS, 1, NotSerialized)
            {
                Return (\PSIF (0x02, Arg0))
            }

            Method (BICG, 1, NotSerialized)
            {
                Return (\PSIF (0x03, Arg0))
            }

            Method (BICS, 1, NotSerialized)
            {
                Return (\PSIF (0x04, Arg0))
            }

            Method (BCTG, 1, NotSerialized)
            {
                Return (\PSIF (0x05, Arg0))
            }

            Method (BCCS, 1, NotSerialized)
            {
                Return (\PSIF (0x06, Arg0))
            }

            Method (BCSG, 1, NotSerialized)
            {
                Return (\PSIF (0x07, Arg0))
            }

            Method (BCSS, 1, NotSerialized)
            {
                Return (\PSIF (0x08, Arg0))
            }

            Method (BDSG, 1, NotSerialized)
            {
                Return (\PSIF (0x09, Arg0))
            }

            Method (BDSS, 1, NotSerialized)
            {
                Return (\PSIF (0x0A, Arg0))
            }
        }

Funksjonsnavnene er kryptiske, men det er et visst mønster. Slutter på G => get , Slutter på S => set. Interessant nok ser vi at alle samme kaller den samme funksjonen \PSIF med en id og et argument. Hvis vi av nysgjerrighet kikker litt lenger ned så ser vi hva den er

    Method (PSIF, 2, NotSerialized)
    {
        Return (SMI (0x14, 0x05, Arg0, Arg1, 0x00))
    }

SMI = System Management Interface. Så der har du magien.

Men vi kan prøve et par av get-kallene ihvertfall. Må gjette argumentet, men her jeg så heldig at jeg vet at det er batteri 1 eller 2. Og jeg har bare 1. Så dermed (med echo "" for lesbarheten bare)

root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCTG 1' >/proc/acpi/call; cat /proc/acpi/call; echo ""
0x350
root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSG 1' >/proc/acpi/call; cat /proc/acpi/call; echo ""
0x35a

Og så er jeg også så heldig at jeg vet at det bare er den laveste byten jeg er interessert i der, så dermed er svarene 0x50 og 0x5a. Eller 80 og 90 som var det jeg hadde som start og end threshold i prosent. Og jeg kan endre f.eks. stop til 85% med (ettersom alle disse fuksjonene bare tar ett argument så forsvinner magisk nok batterinummeret her):

root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSS 0x55' >/proc/acpi/call; cat /proc/acpi/call; echo ""
0x0

Endringen kan jeg se igjen i driverens grensesnitt:

root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_*
/sys/class/power_supply/BAT0/charge_control_end_threshold:85
/sys/class/power_supply/BAT0/charge_control_start_threshold:80

Vel, der har du mer enn nok info til å skrive en ACPI-driver for Linux. Og vi har kanskje sporet av nok for i dag. Men håper det er underholdning i det minste

SveinHa · 25. februar

Bjørn Mork skrev (31 minutter siden):

Nei, du må nok lage driveren. Ikke helt umulig, men litt risikabelt å fikle med siden det er udokumentert blind fikling inn i det aller helligste der minst en av funksjonene etter all sannsynlighet starter selvdestruksjonsekvensen. seriøst.

Jeg tror nok dette er en smule utenfor komfortsonen min. Ikke det at jeg tviholder på komfortsonen, det er jo ikke noe gøy, men jeg vil heller legge jobb i andre ting...

Etter å ha lett litt på nett ser det ut til at HP kun har optimalisering av batterilevetid på laptoper for bedriftsmarkedet og ikke hjemmemarkedet. Proffene har en setting i BIOS som aktiverer dette og hjemmelaptoper har en helt annen BIOS (ser helt forskjellig ut og mangler bl.a. det saliggjørende valget).

Litt begrenset hva en legger av jobb i en velbrukt laptop til kr 2000 også. Får se etter en proffmaskin neste gang.

Logg inn

Å ta vare på batteriet i laptopen.

Anbefalte innlegg

SveinHa

Teknor

SveinHa

SveinHa

Bjørn Mork

SveinHa

SveinHa

Bjørn Mork

SveinHa

Bli med i samtalen

Artikler

Forum

Mine aktivitetsstrømmer

Ressurser

Om oss

Viktig informasjon