Петр Журба

Acer Aspire One 725 Lab: как старая машина стала домашней лабораторией

Коротко

Acer Aspire One 725 сначала выглядел как обычный кандидат на роль маленького домашнего сервера: старый нетбук, SSD вместо жесткого диска, минимальный Debian, Home Assistant, Ethernet рядом с роутером и батарея как встроенный UPS.

Но именно батарея превратила задачу в полноценное исследование. Новая совместимая AL12B32/SANYO заряжалась, определялась Linux, показывала нормальную емкость, но ноутбук внезапно выключался при разряде примерно около 11.6 V. Повторяемость симптома, проверка вариантов и анализ EC/ACPI привели к выводу: проблема была не в Debian и не в Home Assistant, а в том, какой электрический профиль Embedded Controller выбирал для этой батареи.

Отдельная техническая инструкция по прошивке вынесена сюда: Кастомная прошивка AO725 для нестандартной AL12B32/SANYO батареи.

Почему вообще появилась эта задача

Изначальная цель была практичной: понять, можно ли использовать Acer Aspire One 725 как маленький домашний узел.

Базовая конфигурация:

  • Acer Aspire One 725 / AO725;
  • AMD C-60 APU, 2 ядра / 2 потока;
  • около 4 GB RAM, Debian видит примерно 3.6 GiB;
  • ADATA SU650 240 GB SSD;
  • батарея AL12B32, производитель в ACPI/sysfs определяется как SANYO.

Для современного рабочего ноутбука это слабое железо. Но для небольшого Debian-сервера, Home Assistant, легких Docker-сервисов, мониторинга или домашней панели оно еще может быть полезным. SSD снимает главный бытовой тормоз старой машины, а ограничением остается CPU.

Отсюда появилась первая архитектурная развилка:

  • ставить ли графическое окружение;
  • использовать ли ноутбук как сервер без экрана;
  • делать ли из него Home Assistant dashboard/kiosk;
  • можно ли рассчитывать на батарею как на встроенный UPS;
  • как добиться восстановления работы после пропадания 220 V.

Исследованные варианты решения

1. Минимальный Debian вместо полноценного desktop

Полноценный GNOME/KDE для AO725 не выглядит рационально. Для такой машины лучше сначала поднять минимальный Debian, SSH и базовые сервисы, а графику добавлять только если действительно нужен kiosk/dashboard.

Практический вывод:

  • серверная роль важнее внешнего удобства;
  • Home Assistant и служебные контейнеры лучше отделить от решения про экран;
  • если dashboard понадобится, достаточно легкого X/browser-стека;
  • Chromium в Docker выглядит красиво как изоляция, но для AMD C-60 может быть слишком тяжелым.

2. Ethernet вместо Wi-Fi

Для домашнего сервера Wi-Fi был проверен, но консервативный вариант оказался проще: короткий Ethernet-кабель рядом с роутером. Это снижает число переменных при диагностике Home Assistant и будущего автозапуска.

3. Автовключение после пропадания питания

Отдельная исходная боль: если 220 V пропало, батарея села, ноутбук выключился, а потом питание вернулось, хочется, чтобы он включился сам.

Были рассмотрены варианты:

  • настройка Power on AC / Restore on AC Power Loss в BIOS;
  • обновление BIOS с ветки V1.00 до V1.08;
  • Wake-on-LAN после штатного выключения;
  • MikroTik или ESP8266/ESP32 как устройство, которое после появления питания отправляет WOL;
  • аппаратная имитация кнопки Power при появлении питания.

Вывод по этой ветке: штатный BIOS AO725 не дал надежного подтверждения наличия нужной настройки. Обновление BIOS V1.00 -> V1.08 имеет смысл только как штатное обслуживание, но не как гарантированное решение Power on AC. WOL оказался полезен только в ограниченном сценарии: после штатного poweroff Ethernet PHY остается запитанным и magic packet будит ноутбук. Но после полного снятия 220 V и последующего возврата питания линк не возвращается в WOL-ready состояние, поэтому MikroTik/ESP8266 как простой WOL-отправитель не решает задачу полного обесточивания. Аппаратная имитация кнопки Power остается самым прямым, но более инвазивным вариантом.

4. Батарея как встроенный UPS

Самая полезная идея была простой: если батарея живая, ноутбук может пережить короткое отключение света сам, без отдельного UPS.

Старую батарею восстановить не удалось: она фактически была мертвой. Новая AL12B32/SANYO выглядела исправной по данным Linux:

  • модель определялась как AL12B32;
  • производитель определялся как SANYO;
  • емкость и заряд отображались нормально;
  • зарядка до 100% проходила штатно.

Но при разряде возникал повторяемый сбой: ноутбук резко выключался около 11.6 V, причем ОС не успевала выполнить нормальный shutdown. Это выглядело не как программная политика Debian, а как аппаратное отключение питания.

Как менялись гипотезы

Сначала самая простая гипотеза была бытовой: батарея плохая. Она новая, но ведет себя как дефектная - заряжается до 100%, показывает нормальные данные, а потом выключает ноутбук примерно в одной точке разряда.

Это был тот редкий случай, где "простое решение" действительно оказалось простым. Продавец без сложной переписки и споров согласился на замену. Это отдельно удивило: ожидалось, что придется доказывать проблему, спорить про совместимость или объяснять BMS, а на практике замена прошла почти буднично.

Но вторая батарея повторила тот же симптом. Это резко изменило картину. Версия "попалась одна плохая батарея" стала слабее, а вперед вышли другие гипотезы:

  • обе батареи могут быть из одной неудачной партии;
  • внутренняя BMS батареи может отключать выход около 11.6 V;
  • сам ноутбук может иметь порог отключения по батарейному входу;
  • EC может выбирать неподходящий профиль для этой батареи;
  • Linux может неверно интерпретировать заряд, но не быть причиной внезапного обрыва питания.

После повторения симптома поиск сначала ушел в прошивку. Долго искался порог: где в коде или таблицах лежат значения, похожие на 11.6 V, и можно ли понять, кто именно принимает решение об отключении. Это был полезный, но затягивающий путь: чем глубже становился анализ EC firmware, тем сильнее хотелось вернуться к простой физической проверке.

Когда анализ кода уже стал слишком глубоким для ответа на практический вопрос, появилась мысль разрядить батарею автономно, не через ноутбук, а внешней нагрузкой - лампой. Это была не красивая firmware-гипотеза, а управленческая проверка: разделить две области ответственности. Разряд лампой показал, что батарея способна отдавать энергию без такого же внезапного отключения внутри себя. Поэтому версия о внутреннем cutoff батареи/BMS стала заметно слабее, а раннее выключение стало логичнее искать на стороне ноутбука: EC, цепи питания или выбранного профиля батареи.

После этой проверки следующим важным шагом стало сравнение характеристик оригинальной и новой совместимой батареи. Снаружи обе проходят как AL12B32, но детали отличаются: старая/оригинальная конфигурация и новая батарея не полностью совпадают по заявленным параметрам, а Linux/ACPI видят новую батарею как AL12B32 / SANYO с другой практической емкостью. Это перевело вопрос из "почему новая батарея плохая" в "какой профиль ноутбук выбирает для такой реализации батареи".

После этого низкоуровневый поиск стал более направленным. Он уже не был абстрактным "разобрать прошивку", а искал конкретную связку: модель батареи, выбранный EC-профиль и пороги, похожие на наблюдаемое отключение. Так поиск постепенно вывел к таблице EC-профилей, где для выбранного профиля действительно обнаружились значения, хорошо совпадающие с cutoff.

После похожего поведения на второй батарее, автономной проверки разрядом и сравнения характеристик вероятность "две одинаково дефектные батареи подряд" стала ниже. Разряд лампой дополнительно помог исключить внутреннюю защиту батареи как главную причину. Задача сместилась от возврата батареи к анализу совместимости батареи, EC и профилей питания.

Где оказалась настоящая причина

Дальше исследование ушло в ACPI, DSDT и firmware Embedded Controller.

Важные факты:

  • батарея видна как AL12B32;
  • производитель виден как SANYO;
  • DSDT содержит код модели AL12B32 и manufacturer code SANYO;
  • runtime battery values идут через EC-поля, а не через прямой Linux-доступ к батарее по SMBus;
  • EC firmware содержит таблицу батарейных команд и профилей;
  • для AL12B32 был найден selector, который вел к профилю с порогами около 12000/11600;
  • патч менял выбор профиля с 03 на 00;
  • profile 0 имел более подходящие низковольтные пороги 9000/8700.

Иными словами, батарея не была "неизвестной". Напротив, EC/ACPI узнавали ее как штатную модель. Проблема была тоньше: для конкретной совместимой батареи выбирался неподходящий электрический профиль, из-за чего происходил ранний cutoff около 11.6 V.

Что было изменено

В подготовленном patched FD было ровно одно отличие от stock-образа:

offset 0xDA4A: 03 -> 00

Смысл изменения: для AL12B32 был выбран другой EC-профиль батареи. Не вся прошивка была "переписана", а изменен один байт, который переключал выбор профиля.

Перед самой прошивкой был важный нетехнический момент. Я уже был близок к тому, чтобы пропустить подготовку запасного пути и просто запускать прошивку, но ассистент настоял сначала потратить время на Plan B: отдельную rescue-флешку с оригинальным BIOS/EC и понятный сценарий восстановления. Это замедлило работу, зато превратило рискованный эксперимент из "нажать и надеяться" в контролируемое действие с подготовленным откатом.

Подробная пошаговая процедура и предупреждения вынесены в отдельную инструкцию: Кастомная прошивка AO725 для нестандартной AL12B32/SANYO батареи.

Результат проверки

После патча ноутбук прошел старую проблемную точку. Раньше отключение происходило примерно около 11.60 V. После изменения EC-профиля машина продолжила работать ниже этого уровня.

Финальный контролируемый цикл дошел до программного порога ОС:

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

Это подтвердило главное:

  • старый cutoff около 11.6 V исчез;
  • Debian успел выполнить штатное выключение на 30%;
  • батарея сразу начала заряжаться после shutdown;
  • повторных отключений или паузы зарядки не было;
  • глубже разряжать батарею ради доказательства уже не было смысла.

Почему это интересно как AI-assisted engineering

Этот кейс не про генерацию кода и не про "AI сам что-то починил". Наоборот, он полезен тем, что показывает управляемую работу с AI в длинной диагностике:

  • удерживать длинный контекст;
  • отделять гипотезы от подтвержденных фактов;
  • предлагать проверки, которые не ломают железо;
  • сопоставлять Linux sysfs, ACPI, DSDT, EC dump и firmware analysis;
  • вовремя останавливать опасные тесты, например не тянуть 3S Li-ion батарею до глубокого разряда, и заранее готовить rescue-флешку перед прошивкой;
  • сохранять цепочку решений в репозитории.

Но направление работы оставалось человеческим. В какой-то момент AI-разбор кода стал слишком глубоким, и практический ход вернул расследование к проверяемому физическому эксперименту: разрядить батарею отдельно от ноутбука, а затем сравнить характеристики оригинальной и новой батареи. Это важный момент для всего AI-Journey: хорошая AI-assisted работа не обязана слепо следовать за самым сложным анализом. Ею можно управлять, возвращая разговор к простым проверкам, границам риска и фактам с реального железа.

Человеческая часть здесь была ключевой: физические подключения, наблюдение симптомов, решение о риске прошивки, выбор момента остановить разряд и финальная ответственность за железо.

Что осталось на будущее

Главная оставшаяся часть проекта связана уже не с батареей, а с включением ноутбука после пропадания питания. Для Home Assistant или домашнего dashboard мало иметь батарею как UPS: если отключение оказалось длинным, батарея разрядилась и AO725 выключился, после возврата 220 V он должен снова подняться без ручного нажатия Power.

Открытые варианты:

  • еще раз проверить, не появится ли рабочий путь через BIOS/EC-настройки;
  • учитывать уже проверенное ограничение Wake-on-LAN: после штатного poweroff он работает, но после полного снятия и возврата питания Ethernet PHY не возвращается в WOL-ready состояние;
  • не рассчитывать на ESP8266/ESP32 как на простой WOL-сервер для сценария полного обесточивания;
  • рассмотреть устройство, которое при появлении питания физически имитирует короткое нажатие кнопки Power: внешний механический нажиматель, реле/оптопара или другой аккуратный аппаратный вариант.

Есть и отдельная исследовательская ветка ниже по уровню: EC firmware, похоже, читает команды 0x3C-0x3F, которые для TI bq20z-style интерфейса похожи на individual cell voltage reads. Для текущей практической задачи это уже вторично, но потенциально можно выяснить, удастся ли получить напряжения отдельных групп батареи без нового патча и без прямого вмешательства в SMBus.

Черновой вывод для сайта

Acer Aspire One 725 Lab получился не просто "старый ноутбук под Home Assistant". Это пример того, как маленькая бытовая задача постепенно стала инженерным исследованием на границе Linux, ACPI, Embedded Controller, батарейной электроники и осторожного firmware-патча.

Главный результат практичный: AO725 снова может использовать батарею как реальный резерв питания, а не выключаться в середине заряда из-за неподходящего EC-профиля.