A GTK4/libadwaita desktop application for Linux that monitors laptop battery health, usage patterns, and long-term degradation trends. Unlike a one-shot query (upower -d), BatteryScope continuously collects data over time and surfaces insights that are only visible across days and weeks of usage.

A single measurement of your battery tells you almost nothing useful. Battery behavior is contextual: power draw varies with workload, health degrades slowly over months, and time-to-empty estimates are only accurate when averaged over realistic usage rather than a momentary spike. BatteryScope solves this by recording battery state every minute to a local SQLite database, then using that history to answer questions that a one-shot tool cannot.

With continuous data you can:

• Estimate remaining runtime based on your actual average power draw over the last 15 minutes, not a kernel heuristic
• Track health degradation over weeks and months as the battery's maximum charge capacity shrinks
• Spot anomalies — a sudden spike in power draw, an unusually fast drain, or a charge session that stopped short
• Project the future — model when your battery will cross the 80% health threshold that most manufacturers define as end-of-useful-life

The cost is minimal: a small bash script run by a systemd timer writes a single SQLite row per minute. The database grows by roughly 500 KB per year.

systemd timer (every 1 min)
    └── battery-logger.sh
            reads /sys/class/power_supply/BAT0/*
            writes one row to ~/.local/share/battery-logger.db

BatteryScope (GTK4 app)
    ├── reads DB every 30 seconds  →  Status panel, Health panel, Capacity chart
    ├── reads /sys directly every 1 second  →  real-time power draw chart
    └── reads /sys at launch  →  Battery info panel

cargo build --release
./target/release/BatteryScope

Requirements: Linux, GTK 4.12+, libadwaita 1.4+, SQLite, systemd (user session), Rust 2024 edition toolchain.

On first launch, open the Settings tab and enable background monitoring. The app will install the logger script and systemd timer automatically. Data collection begins within one minute.

BatteryScope is Linux-only. The data logger relies on sysfs (/sys/class/power_supply/) and systemd, and the app reads battery hardware directly from the same sysfs interface. macOS and Windows expose battery data through different platform APIs and would require separate implementations.

Disable background monitoring in the Settings tab before removing the binary. This stops the systemd timer and removes the logger script and unit files from ~/.local/bin/ and ~/.config/systemd/user/.

Your collected data at ~/.local/share/battery-logger.db is intentionally left intact. Delete it manually if you no longer need it.

Displays the current operating state of the battery, refreshed every 30 seconds.

Displays the long-term state of the battery's electrochemical capacity.

Static information read from sysfs at launch. Does not change during a session.

Contains a toggle to enable or disable background monitoring. Enabling installs the logger script to ~/.local/bin/battery-logger.sh and the systemd service and timer to ~/.config/systemd/user/, then starts the timer. Disabling reverses this. If monitoring is off when the app launches, a banner at the top of the window links directly to this tab.

Power draw (W) — last 2 min Updated every second by reading /sys/class/power_supply/BAT0/power_now directly, bypassing the database. Maintains a 120-sample rolling window. Useful for correlating power spikes with specific applications or system events in real time. Colored green when below 8 W (idle), amber up to 15 W, red above.

Capacity (%) — last 2 hours Updated every 30 seconds from the database, showing the last 120 logged readings. Reveals how fast the battery is draining under current conditions and makes charging sessions clearly visible as rising slopes.

Lithium-ion batteries lose capacity through irreversible chemical changes inside the cell. The two primary mechanisms are:

1. SEI layer growth. Each charge cycle deposits a thin layer of lithium compounds on the graphite anode (the solid-electrolyte interphase). This layer consumes lithium that can no longer participate in the charge-discharge reaction, permanently reducing capacity.

2. Cathode degradation. Repeated expansion and contraction of cathode material (typically lithium cobalt oxide or similar) during cycling causes microscopic cracking and structural changes, reducing how much lithium the cathode can hold.

Both processes are gradual and irreversible. They are accelerated by heat, by charging to 100% frequently, by discharging to 0% frequently, and by high charge rates.

The 80% capacity threshold is the industry standard definition of end-of-useful-life for a laptop battery, used by Apple, Lenovo, Dell, and most others. It is also the threshold at which:

• Many laptop warranty programs cover battery replacement
• macOS marks the battery as needing service
• The difference in real-world runtime becomes practically noticeable — a battery that once lasted 8 hours now lasts about 6.4 hours at equivalent workload

Crossing 80% does not mean the battery stops working. It will continue to discharge and charge normally. But the decline tends to accelerate below 80% because the internal resistance of a degraded cell is higher, which generates more heat during use, which accelerates further degradation.

The degradation rate is estimated by linear regression over daily peak energy_full readings. There are two reasons 14 days is the minimum:

1. Day-to-day noise. The kernel's energy_full reading is not perfectly stable — it fluctuates by a small amount between measurements depending on temperature, recent charge history, and measurement timing. With fewer than two weeks of daily data points, this noise can produce a regression slope that is meaningless or even inverted.

2. Statistical significance. Battery degradation over a two-week period is genuinely tiny — typically 0.05–0.25% of design capacity. Detecting a signal that small requires enough data points that the regression line is not dominated by individual noisy readings.

With 14+ days of data, the regression becomes stable enough to produce a slope accurate to within roughly ±0.1% per month. With 30–60 days the projection becomes reliable enough to plan around.

The following practices meaningfully extend battery lifespan:

Keep charge between 20% and 80%. The chemical stress on the electrodes is highest at the extremes of the charge range. Charging to 80% instead of 100% and plugging in before 20% can roughly double the number of cycles to 80% capacity. Many laptops now offer a "battery limit" mode in firmware for exactly this reason.

Avoid sustained high temperatures. Heat is the single biggest accelerant of battery aging. A battery stored or operated at 40°C degrades roughly twice as fast as one kept at 25°C. Keep vents clear, avoid soft surfaces that block airflow, and avoid leaving the laptop in a hot car.

Avoid frequent full discharges. Li-ion does not have a "memory effect" (that was NiMH). Deep discharges are more stressful than shallow ones. Topping up from 50% is better for the battery than running it flat.

Charge slowly when possible. Fast charging generates more heat inside the cell. If time permits, using a lower-wattage charger (or a USB-C charger below the laptop's rated input) charges the battery more gently. This is why your 45 W rated charger may deliver 27 W — the battery management system accepts less than the maximum to balance speed against heat.

Charge rate vs. rated wattage. Your charger's rated wattage is the maximum it can deliver. What the battery actually receives is negotiated between the charger, the USB-C power delivery controller, and the battery management IC in real time. The BMS limits charge current based on temperature, current state of charge (charge rate always slows near 100%), and the health of the cell. A lower actual wattage than the charger's rating is normal and does not indicate a problem.

All data is stored locally in ~/.local/share/battery-logger.db. Nothing is sent anywhere. The schema:

CREATE TABLE stats (
    timestamp           TEXT    NOT NULL,   -- YYYY-MM-DD HH:MM:SS (local time)
    capacity            INTEGER NOT NULL,   -- 0–100 %
    status              TEXT    NOT NULL,   -- Charging / Discharging / Full / Unknown
    energy_now          INTEGER,            -- µWh, current stored energy
    energy_full         INTEGER,            -- µWh, current maximum capacity
    energy_full_design  INTEGER,            -- µWh, factory design capacity
    power_now           INTEGER,            -- µW, instantaneous power flow
    voltage_now         INTEGER             -- µV, terminal voltage
);

Energy values are in microwatt-hours (µWh) and power in microwatts (µW) — these are the raw kernel units. BatteryScope converts them to watts and watt-hours for display by dividing by 1,000,000.