Peter Zhurba

Acer Aspire One 725 Lab: how an old machine became a home lab

Short version

The Acer Aspire One 725 first looked like a simple candidate for a small home server: an old netbook, SSD instead of a hard drive, minimal Debian, Home Assistant, Ethernet next to the router, and the battery as a built-in UPS.

The battery turned that simple task into a real investigation. A new compatible AL12B32/SANYO battery charged normally, was detected by Linux, and reported reasonable capacity, but the laptop suddenly powered off during discharge at about 11.6 V. The repeatable symptom, the checks we ran, and the EC/ACPI analysis led to a narrower conclusion: the problem was not Debian or Home Assistant. It was the electrical profile selected by the Embedded Controller for that battery.

The separate flashing guide is here: Custom AO725 firmware for a non-standard AL12B32/SANYO battery.

Why this task appeared

The original goal was practical: find out whether the Acer Aspire One 725 could still serve as a small home node.

Baseline configuration:

  • Acer Aspire One 725 / AO725;
  • AMD C-60 APU, 2 cores / 2 threads;
  • about 4 GB RAM, with Debian seeing about 3.6 GiB;
  • ADATA SU650 240 GB SSD;
  • AL12B32 battery, reported through ACPI/sysfs as SANYO.

For a modern workstation this hardware is weak. For a small Debian server, Home Assistant, lightweight Docker services, monitoring, or a home dashboard, it can still be useful. The SSD removes the most obvious day-to-day bottleneck of an old machine; the CPU remains the main limit.

That created the first architectural fork:

  • whether to install a graphical desktop;
  • whether to use the laptop as a headless server;
  • whether to turn it into a Home Assistant dashboard or kiosk;
  • whether the battery could be trusted as a built-in UPS;
  • how to restore operation after AC power disappears and later returns.

Options that were explored

1. Minimal Debian instead of a full desktop

A full GNOME/KDE desktop does not look rational on the AO725. The better first step is minimal Debian, SSH, and basic services, with graphics added only if a kiosk or dashboard is actually needed.

Practical conclusion:

  • the server role matters more than desktop comfort;
  • Home Assistant and service containers should be separated from the screen decision;
  • if a dashboard is needed, a lightweight X/browser stack is enough;
  • Chromium in Docker is attractive as isolation, but may be too heavy for the AMD C-60.

2. Ethernet instead of Wi-Fi

Wi-Fi was checked, but the conservative server choice was simpler: a short Ethernet cable next to the router. That reduces the number of variables while debugging Home Assistant and future power-recovery behavior.

3. Automatic power-on after power loss

One original pain point was power recovery. If AC power disappears, the battery drains, the laptop shuts down, and AC power later returns, the desired behavior is automatic startup without pressing the power button.

The options considered were:

  • Power on AC / Restore on AC Power Loss in BIOS;
  • BIOS update from V1.00 to V1.08;
  • Wake-on-LAN after a normal shutdown;
  • MikroTik or ESP8266/ESP32 sending WOL after power returns;
  • hardware emulation of the power button when power returns.

Conclusion for this branch: the stock AO725 BIOS did not provide reliable evidence of the required setting. Updating BIOS from V1.00 to V1.08 makes sense as normal maintenance, but not as a guaranteed Power on AC solution. WOL is useful only in a limited scenario: after a normal poweroff, the Ethernet PHY remains powered and a magic packet wakes the laptop. After full AC removal and return, the link does not come back in a WOL-ready state, so a MikroTik/ESP8266 as a simple WOL sender does not solve complete power loss. Hardware power-button emulation remains the most direct, but more invasive, option.

4. Battery as a built-in UPS

The most useful idea was simple: if the battery is healthy, the laptop can survive short power outages by itself, without a separate UPS.

The old battery could not be recovered; it was effectively dead. The new AL12B32/SANYO battery looked healthy from Linux:

  • model reported as AL12B32;
  • manufacturer reported as SANYO;
  • capacity and charge values looked normal;
  • charging to 100% worked normally.

But discharge had a repeatable failure: the laptop suddenly powered off at about 11.6 V, and the OS did not get time for a normal shutdown. That looked like a hardware power cutoff, not a Debian policy decision.

How the hypotheses changed

The first hypothesis was the obvious everyday one: the battery was bad. It was new, but behaved like a defective pack - charging to 100%, reporting normal data, and then shutting the laptop down at roughly the same discharge point.

This was one of those rare cases where the simple solution was genuinely simple. The seller agreed to replace it without a long argument. That was surprising in itself: I expected to have to prove the problem, argue about compatibility, or explain BMS behavior, but in practice the replacement was almost routine.

The second battery repeated the same symptom. That changed the picture sharply. The idea that this was just one bad battery became weaker, and other hypotheses moved forward:

  • both batteries could be from the same problematic batch;
  • the battery BMS could be cutting output at about 11.6 V;
  • the laptop itself could have an input voltage cutoff;
  • the EC could be selecting the wrong profile for this battery;
  • Linux could be misreading charge, but not causing the abrupt power loss.

After the symptom repeated, the work first went deep into firmware. We spent quite a while looking for a threshold: where values similar to 11.6 V lived in code or tables, and whether we could identify who made the cutoff decision. That was useful, but it also became a long tunnel: the deeper the EC firmware analysis went, the more useful it became to return to a simple physical check.

When code analysis had become too deep for the practical question, the idea appeared to discharge the battery outside the laptop with an external load - a lamp. This was not a beautiful firmware hypothesis; it was a management check: split the responsibility between the battery and the laptop. The lamp discharge showed that the battery could deliver energy without the same sudden internal cutoff. That weakened the BMS-cutoff hypothesis and made it more logical to search on the laptop side: EC, power circuitry, or the selected battery profile.

After that check, the next important step was comparing the original and compatible battery characteristics. Externally both appear as AL12B32, but the details differ: the old/original configuration and the new battery do not fully match in declared parameters, and Linux/ACPI see the new battery as AL12B32 / SANYO with a different practical capacity. That shifted the question from "why is the new battery bad" to "which profile does the laptop select for this implementation of the battery".

From there, the low-level search became more focused. It was no longer an abstract attempt to reverse the firmware; it was looking for a specific relationship: battery model, selected EC profile, and thresholds matching the observed cutoff. That search eventually led to the EC profile table, where the selected profile did contain values that matched the cutoff well.

After the same behavior on a second battery, the external lamp discharge, and the battery-characteristic comparison, the probability of two identically defective batteries became lower. The lamp discharge also helped rule out the battery's internal protection as the main cause. The task moved from returning the battery to analyzing compatibility between the battery, EC, and power profiles.

Where the real cause was found

The investigation then moved into ACPI, DSDT, and Embedded Controller firmware.

Important facts:

  • the battery is visible as AL12B32;
  • the manufacturer is visible as SANYO;
  • DSDT contains the AL12B32 model code and SANYO manufacturer code;
  • runtime battery values go through EC fields, not direct Linux SMBus access to the battery;
  • EC firmware contains a table of battery commands and profiles;
  • for AL12B32, a selector was found that led to a profile with thresholds around 12000/11600;
  • the patch changed the selected profile from 03 to 00;
  • profile 0 had more suitable low-voltage thresholds, 9000/8700.

In other words, the battery was not "unknown". EC/ACPI recognized it as a known model. The problem was subtler: for this compatible battery, the laptop selected an unsuitable electrical profile, causing an early cutoff around 11.6 V.

What was changed

The prepared patched FD had exactly one difference from the stock image:

offset 0xDA4A: 03 -> 00

The meaning of the change: AL12B32 is switched to a different EC battery profile. The firmware was not "rewritten"; one byte changed the profile selector.

Before flashing, there was an important non-technical moment. I was close to skipping the fallback preparation and just running the flasher, but the assistant insisted on spending time on Plan B first: a separate rescue flash drive with the original BIOS/EC and a clear recovery scenario. That slowed the work down, but changed the experiment from "press and hope" into a controlled action with a prepared fallback.

The detailed procedure and warnings are in the separate guide: Custom AO725 firmware for a non-standard AL12B32/SANYO battery.

Test result

After the patch, the laptop passed the old failure point. Before the patch it powered off at about 11.60 V. After changing the EC profile, it continued below that level.

The final controlled cycle reached the OS shutdown threshold:

2026-08-17 14:49:56 battery=31% status=Discharging charge=1369.000mAh current=463.000mA voltage=10.686V
2026-08-17 14:51:06 battery=30% status=Discharging charge=1360.000mAh current=463.000mA voltage=10.683V
2026-08-17 14:51:06 battery=30% threshold=30%: shutting down
2026-08-17 14:53:14 battery=31% status=Charging charge=1391.000mAh current=1488.000mA voltage=10.982V
2026-08-17 14:54:24 battery=32% status=Charging charge=1419.000mAh current=1487.000mA voltage=11.003V

This confirmed the main points:

  • the old cutoff around 11.6 V disappeared;
  • Debian had time to perform a normal shutdown at 30%;
  • the battery immediately started charging after shutdown;
  • there were no repeated cutoffs or charging pauses;
  • there was no reason to discharge the battery deeper just to prove the point.

Why this is interesting as AI-assisted engineering

This case is not about code generation or "AI fixing something by itself". It is useful because it shows controlled work with AI during a long diagnostic process:

  • holding long context;
  • separating hypotheses from confirmed facts;
  • proposing checks that do not damage hardware;
  • connecting Linux sysfs, ACPI, DSDT, EC dumps, and firmware analysis;
  • stopping dangerous tests in time, such as not pulling a 3S Li-ion battery into deep discharge, and preparing a rescue flash drive before flashing;
  • preserving the chain of decisions in a repository.

But the direction of the work remained human. At one point, AI-assisted code analysis had gone too deep, and the practical path returned the investigation to a physical, checkable experiment: discharge the battery outside the laptop, then compare the original and new battery characteristics. That matters for the whole AI-Journey idea: good AI-assisted work does not have to blindly follow the most complex analysis. It can be steered back toward simple checks, risk boundaries, and facts from real hardware.

The human part was essential: physical connections, symptom observation, the decision to accept flashing risk, the moment to stop discharge, and final responsibility for the hardware.

What remains for later

The main unfinished part is no longer the battery, but automatic startup after power loss. For Home Assistant or a home dashboard, having the battery as a UPS is not enough: if the outage is long, the battery drains and the AO725 shuts down, the laptop should start again when AC power returns.

Open options:

  • check once more whether a working BIOS/EC path exists;
  • account for the already tested Wake-on-LAN limitation: after normal poweroff it works, but after full AC removal and return the Ethernet PHY does not come back WOL-ready;
  • do not rely on ESP8266/ESP32 as a simple WOL server for complete power-loss recovery;
  • consider a device that physically emulates a short power-button press when power returns: an external mechanical presser, relay/opto-coupler, or another careful hardware option.

There is also a lower-level research branch: EC firmware appears to read commands 0x3C-0x3F, which look like individual cell voltage reads in TI bq20z-style interfaces. That is secondary for the current practical task, but it may be possible to determine whether individual cell-group voltages can be read without a new patch and without direct SMBus intervention.

Working conclusion

Acer Aspire One 725 Lab became more than "an old laptop for Home Assistant". It is an example of a small practical task turning into an engineering investigation across Linux, ACPI, Embedded Controller behavior, battery electronics, and a cautious firmware patch.

The practical result is clear: the AO725 can again use its battery as real backup power instead of shutting down in the middle of charge because of an unsuitable EC profile.