Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток DIY доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 87
я не понял зачем телефону USB hub для подключения к сети, у него нет wifI? Подскажите по опыту VOSK, нормально распознаёт речь? RU модель у меня работает только если чётко выговаривать прямо в микрофон. а разговорную речь не очень распознаёт у меня.
Спасибо за идею, но вот кода не хватает. Можете, пожалуйста, поподробнее, вы написали локального ИИ ассистента а-ля умная колонка с помощью другого ИИ? И если да, то можно или про архитектуру решения чуть подробнее, или просто в спойлере основной промпт показать, что в основе лежит? Спасибо.
Да, весь код полностью - вайбкодинг (использовал модель GLM-5), изначально был простенький промпт-формулировка идеи "хочу голосового ассистента на отдельном постоянно включённом телефоне", дальше уточняли технологический стек и детали архитектуры - выбирал из предложенных самой нейросетью
Полное описание архитектуры, которое было отправлено на вход кодинг-модели:
Спецификация системы: три бэкенда для Xperia XZ1
Общая архитектура
Система состоит из трёх независимых компонентов, работающих на одном устройстве (Xperia XZ1) и взаимодействующих через HTTP API:
Основной бэкенд умного дома (Central Hub) — ядро системы. Отвечает за: · Управление умными устройствами (свет, розетки, датчики и так далее). · Хранение состояния и истории. · Предоставление API для модулей и внешних клиентов. · Логику автоматизации (правила, сценарии). · Обработку текстовых команд (от голосового ассистента или других интерфейсов).
Модуль голосового ассистента (Voice Module) — обеспечивает голосовой интерфейс: · Постоянное прослушивание микрофона, детекция ключевой фразы. · Распознавание речи (Vosk) и синтез речи (TTS). · Отправка распознанного текста в основной бэкенд. · Озвучивание ответов. · Управление аудиоресурсами через аудиоарбитр.
Модуль RKHomeHub — существующий (или новый) локальный сервер для Android‑приложений: · Предоставляет API для мобильных приложений (чтение/запись локальных данных). · Работает независимо от основного бэкенда, но может интегрироваться через основной бэкенд (опционально).
Дополнительный компонент: Аудиоарбитр — встроен в Voice Module или вынесен отдельно, управляет доступом к микрофону и динамику, реализует приоритетную очередь для разных источников (Voice Module, будущие модули OpenClaw, нотифаер и тому подобное).
Основной бэкенд умного дома (Central Hub)
2.1. Назначение
Центральный сервер, который управляет всей умной домашней инфраструктурой: устройствами, автоматизациями, сценариями. Взаимодействует с модулями и внешними клиентами (мобильные приложения, веб‑интерфейс).
2.2. Функциональные требования
Управление устройствами:
· Регистрация устройств (ID, тип, имя, метаданные, состояние). · Обновление состояния устройства (вручную или через датчики). · Выполнение команд над устройствами (включить/выключить, установить значение, запустить сценарий). · Поддержка разных типов устройств: свет, розетки, термостаты, датчики (температура, влажность, движение, дверь/окно), камеры, медиа‑плееры.
Автоматизация и сценарии:
· Создание правил «если‑то» (триггеры: время, состояние устройства, событие; действия: команды устройствам, уведомления, вызов вебхуков). · Периодические задачи (cron‑подобные). · Хранение и выполнение сценариев (последовательности действий).
Голосовой интерфейс (через Voice Module):
· Приём текстовых команд (POST /api/voice/command). · Распознавание намерений (intent parsing) для преобразования естественного языка в команды устройствам. · Поддержка контекстных диалогов (сессий) — опционально. · Ответ в виде текста для озвучивания.
API для модулей и внешних клиентов:
· REST API (JSON) для всех операций. · WebSocket для реального времени (уведомления об изменениях состояний). · Аутентификация (API‑ключи или JWT) для безопасности.
Хранение данных:
· SQLite (или другая встраиваемая БД) для устройств, правил, истории событий. · Конфигурация в YAML/JSON.
Логирование и мониторинг:
· Запись всех команд, событий, ошибок. · Ротация логов (размер, время).
2.3. Примеры API (для спецификации)
Метод Эндпоинт Описание POST /api/devices/register Регистрация нового устройства GET /api/devices Список всех устройств GET /api/devices/{id} Состояние устройства POST /api/devices/{id}/command Отправить команду устройству POST /api/rules Создать правило автоматизации POST /api/voice/command Отправить текстовую команду (от ассистента) GET /api/status Статус бэкенда
2.4. Требования к производительности
· Низкое потребление RAM (< 200 МБ в простое). · Быстрый отклик на команды (< 500 мс). · Работа 24/7 без перезагрузок.
Модуль голосового ассистента (Voice Module)
3.1. Назначение
Обеспечивает голосовое управление умным домом через микрофон и динамик телефона.
3.2. Функциональные требования
Аудиозахват и детекция ключевой фразы:
· Постоянное прослушивание микрофона. · Обнаружение ключевой фразы (например, «Окей сервер» или «Слушай») без отправки звука в сеть. · После активации — захват последующей речи до паузы (таймаут тишины) или явной команды окончания.
Распознавание речи (STT):
· Локальное распознавание через Vosk (русский язык, компактная модель). · Возврат текста для отправки в основной бэкенд.
Синтез речи (TTS):
· Преобразование текстового ответа от бэкенда в речь. · Использование системного TTS Android (через termux‑tts‑speak или нативное API). · Возможность настройки голоса, скорости, громкости.
Интеграция с основным бэкендом:
· Отправка распознанного текста по HTTP в Central Hub. · Получение ответа (текст для озвучивания или команда «ничего не говорить»). · Озвучивание ответа.
Аудиоарбитр (встроенный):
· Управление доступом к микрофону и динамику. · Приоритетная очередь (приоритеты: 1 — системные модули, 2 — голосовой ассистент, 3 — уведомления). · Поддержка будущих модулей (OpenClaw, нотифаер и др.), которые могут запрашивать аудио через API арбитра. · При конфликте — сохранение контекста прерванного диалога (если нужно).
Управление состоянием:
· Запуск и остановка по требованию (может работать постоянно). · Возможность временно отключать микрофон (например, по API).
3.3. API модуля (для внешних модулей)
Модуль предоставляет HTTP API (например, порт 8082) для других модулей:
Метод Эндпоинт Описание POST /audio/request Запрос на захват аудио (с указанием приоритета, режима) POST /audio/release Освобождение аудиоресурсов POST /tts/speak Воспроизвести текст через динамик (однонаправленное уведомление)
3.4. Конфигурация
· Ключевая фраза (настраивается). · Путь к модели Vosk. · URL основного бэкенда. · Параметры TTS. · Порт для API арбитра.
Модуль RKHomeHub
4.1. Назначение
Локальный сервер для обслуживания нескольких Android‑приложений на других устройствах (например, приложение для управления умным домом, дашборд). Хранит данные, специфичные для этих приложений, и предоставляет к ним API.
4.2. Функциональные требования
Локальное хранилище данных:
· Регистрация клиентов (Android‑приложений) с уникальными ID. · Хранение произвольных JSON‑данных для каждого клиента (ключ‑значение). · Поддержка синхронизации данных между клиентами (опционально). · Автоматическая очистка устаревших данных.
API для Android‑приложений:
· CRUD операции над данными (чтение, запись, удаление, обновление). · Поддержка подписок на изменения (WebSocket или long polling). · Аутентификация по токену (простому, без сложной безопасности, так как локальная сеть).
Независимость от основного бэкенда:
· Может работать без Central Hub. · При наличии Central Hub — может интегрироваться через него (например, публиковать свои данные как устройства умного дома).
Минимальное потребление ресурсов:
· RAM < 50 МБ. · Хранение данных в SQLite или плоских файлах.
4.3. Пример API
Метод Эндпоинт Описание POST /api/client/register Регистрация нового клиента GET /api/data/{client_id}/{key} Получить значение POST /api/data/{client_id} Сохранить/обновить значение DELETE /api/data/{client_id}/{key} Удалить ключ GET /api/status Статус
Взаимодействие между компонентами
flowchart TD
subgraph Xperia XZ1
A[Central Hub<br>умный дом]
B[Voice Module]
C[RKHomeHub]
D[Будущие модули<br>OpenClaw, Notifier]
end
subgraph Внешние устройства
E[Android-приложения]
F[Пользовательский голос]
end
F -->|голос| B
B -->|текст команды| A
A -->|текст ответа| B
B -->|озвучка| F
A <-->|опционально| C
E <-->|API| C
D <-->|аудио запросы| B
D <-->|команды/статус| A
Правила взаимодействия:
· Voice Module отправляет текстовые команды в Central Hub (POST /api/voice/command). · Central Hub обрабатывает команды, управляет устройствами, возвращает ответ. · Voice Module озвучивает ответ. · RKHomeHub работает независимо, его клиенты — Android‑приложения. · Будущие модули (OpenClaw, нотифаер) регистрируются в Central Hub и могут запрашивать аудио через Voice Module (через API арбитра).
Общие требования к реализации
Платформа:
· Xperia XZ1 (Android 8+, ARM64, 4 ГБ RAM). · Root (Magisk), ACC для контроля заряда. · Termux с поддержкой termux‑api, termux‑tts‑speak, termux‑microphone‑record. · Автозапуск всех трёх бэкендов при загрузке (через Termux:Boot).
Языки и технологии (на усмотрение агента):
· Central Hub: предпочтительно Go (высокая производительность, малый размер). · Voice Module: Python (быстрая разработка, готовые биндинги Vosk) или Go (с обёртками). · RKHomeHub: Go (лёгкий, простой).
Коммуникация:
· HTTP/JSON между компонентами (локальный порт, например 8080 для Central Hub, 8081 для Voice Module API, 8082 для RKHomeHub). · WebSocket для событий реального времени (опционально).
Конфигурация:
· Единый конфигурационный файл (YAML) для всех компонентов, либо отдельные файлы. · Параметры: IP‑адреса, порты, пути к моделям, URL внешних API.
Логирование:
· Каждый компонент пишет логи в отдельный файл в /sdcard/logs/. · Ротация: размер 10 МБ, хранить 5 файлов.
Документация для агента:
· Инструкция по сборке (если требуется компиляция). · Инструкция по развёртыванию на телефоне. · Примеры API‑запросов.
Критерии успешной реализации
Central Hub запускается и отвечает на API‑запросы. Можно зарегистрировать тестовое устройство, отправить команду, получить ответ.
Voice Module активируется по ключевой фразе, распознаёт тестовую команду («включи свет»), отправляет в Central Hub, получает ответ и озвучивает его.
Аудиоарбитр корректно обрабатывает конфликтные запросы (например, одновременный запрос от Voice Module и симулированного модуля с более высоким приоритетом).
RKHomeHub позволяет Android‑приложению (симулированному) сохранить и прочитать данные.
Все три компонента работают одновременно без взаимных блокировок и утечек памяти в течение 24 часов.
Управление через ADB/SSH возможно (логи, рестарт).
Дальнейшее расширение (не требуется сейчас, но для спецификации)
· Добавление веб‑интерфейса для управления умным домом. · Поддержка MQTT для интеграции с внешними платформами. · Графический интерфейс на телефоне (через нативное приложение) — но из‑за разбитого экрана не актуально. · Локальный LLM (например, через llama.cpp) для обработки команд без интернета.
Итог для агента: Агент должен создать три независимых проекта (каждый в своей директории) с полным исходным кодом, конфигурациями, скриптами развёртывания и инструкцией. Основной бэкенд (Central Hub) и RKHomeHub — на Go, Voice Module — на Python или Go. Взаимодействие через локальный HTTP. Всё должно работать на Xperia XZ1 под управлением Termux.
Автор, пытки утюгом, кажется, гуманнее выглядят, чем вот это вот всё 🥲
Не разобрался с форматированием( попробую отредактировать
Сделай спойлер, а в нем сделай код и закинь все туда
вот так вотБлагодарю!
Скрытый текст
1. Общая архитектура
Система состоит из трёх независимых компонентов, работающих на одном устройстве (Xperia XZ1) и взаимодействующих через HTTP API:
Основной бэкенд умного дома (Central Hub) — ядро системы. Отвечает за:
Управление умными устройствами (свет, розетки, датчики и т.д.).
Хранение состояния и истории.
Предоставление API для модулей и внешних клиентов.
Логику автоматизации (правила, сценарии).
Обработку текстовых команд (от голосового ассистента или других интерфейсов).
Модуль голосового ассистента (Voice Module) — обеспечивает голосовой интерфейс:
Постоянное прослушивание микрофона, детекция ключевой фразы.
Распознавание речи (Vosk) и синтез речи (TTS).
Отправка распознанного текста в основной бэкенд.
Озвучивание ответов.
Управление аудиоресурсами через аудиоарбитр.
Модуль RKHomeHub — существующий (или новый) локальный сервер для Android-приложений:
Предоставляет API для мобильных приложений (чтение/запись локальных данных).
Работает независимо от основного бэкенда, но может интегрироваться через основной бэкенд (опционально).
Дополнительный компонент: Аудиоарбитр — встроен в Voice Module или вынесен отдельно, управляет доступом к микрофону и динамику, реализует приоритетную очередь для разных источников (Voice Module, будущие модули OpenClaw, нотифаер и т.п.).
2. Основной бэкенд умного дома (Central Hub)
2.1. Назначение
Центральный сервер, который управляет всей умной домашней инфраструктурой: устройствами, автоматизациями, сценариями. Взаимодействует с модулями и внешними клиентами (мобильные приложения, веб-интерфейс).
2.2. Функциональные требования
Управление устройствами:
Регистрация устройств (ID, тип, имя, метаданные, состояние).
Обновление состояния устройства (вручную или через датчики).
Выполнение команд над устройствами (включить/выключить, установить значение, запустить сценарий).
Поддержка разных типов устройств: свет, розетки, термостаты, датчики (температура, влажность, движение, дверь/окно), камеры, медиа-плееры.
Автоматизация и сценарии:
Создание правил "если-то" (триггеры: время, состояние устройства, событие; действия: команды устройствам, уведомления, вызов вебхуков).
Периодические задачи (cron-подобные).
Хранение и выполнение сценариев (последовательности действий).
Голосовой интерфейс (через Voice Module):
Приём текстовых команд (POST /api/voice/command).
Распознавание намерений (intent parsing) для преобразования естественного языка в команды устройствам.
Поддержка контекстных диалогов (сессий) – опционально.
Ответ в виде текста для озвучивания.
API для модулей и внешних клиентов:
REST API (JSON) для всех операций.
WebSocket для реального времени (уведомления об изменениях состояний).
Аутентификация (API-ключи или JWT) для безопасности.
Хранение данных:
SQLite (или другая встраиваемая БД) для устройств, правил, истории событий.
Конфигурация в YAML/JSON.
Логирование и мониторинг:
Запись всех команд, событий, ошибок.
Ротация логов (размер, время).
2.3. Примеры API (для спецификации)
Метод Эндпоинт Описание
POST /api/devices/register Регистрация нового устройства
GET /api/devices Список всех устройств
GET /api/devices/{id} Состояние устройства
POST /api/devices/{id}/command Отправить команду устройству
POST /api/rules Создать правило автоматизации
POST /api/voice/command Отправить текстовую команду (от ассистента)
GET /api/status Статус бэкенда
2.4. Требования к производительности
Низкое потребление RAM (< 200 МБ в простое).
Быстрый отклик на команды (< 500 мс).
Работа 24/7 без перезагрузок.
3. Модуль голосового ассистента (Voice Module)
3.1. Назначение
Обеспечивает голосовое управление умным домом через микрофон и динамик телефона.
3.2. Функциональные требования
Аудиозахват и детекция ключевой фразы:
Постоянное прослушивание микрофона.
Обнаружение ключевой фразы (например, "Окей сервер" или "Слушай") без отправки звука в сеть.
После активации — захват последующей речи до паузы (таймаут тишины) или явной команды окончания.
Распознавание речи (STT):
Локальное распознавание через Vosk (русский язык, компактная модель).
Возврат текста для отправки в основной бэкенд.
Синтез речи (TTS):
Преобразование текстового ответа от бэкенда в речь.
Использование системного TTS Android (через termux-tts-speak или нативное API).
Возможность настройки голоса, скорости, громкости.
Интеграция с основным бэкендом:
Отправка распознанного текста по HTTP в Central Hub.
Получение ответа (текст для озвучивания или команда "ничего не говорить").
Озвучивание ответа.
Аудиоарбитр (встроенный):
Управление доступом к микрофону и динамику.
Приоритетная очередь (приоритеты: 1 – системные модули, 2 – голосовой ассистент, 3 – уведомления).
Поддержка будущих модулей (OpenClaw, нотифаер и др.), которые могут запрашивать аудио через API арбитра.
При конфликте – сохранение контекста прерванного диалога (если нужно).
Управление состоянием:
Запуск и остановка по требованию (может работать постоянно).
Возможность временно отключать микрофон (например, по API).
3.3. API модуля (для внешних модулей)
Модуль предоставляет HTTP API (например, порт 8082) для других модулей:
Метод Эндпоинт Описание
POST /audio/request Запрос на захват аудио (с указанием приоритета, режима)
POST /audio/release Освобождение аудиоресурсов
POST /tts/speak Воспроизвести текст через динамик (однонаправленное уведомление)
3.4. Конфигурация
Ключевая фраза (настраивается).
Путь к модели Vosk.
URL основного бэкенда.
Параметры TTS.
Порт для API арбитра.
4. Модуль RKHomeHub
4.1. Назначение
Локальный сервер для обслуживания нескольких Android-приложений на других устройствах (например, приложение для управления умным домом, дашборд). Хранит данные, специфичные для этих приложений, и предоставляет к ним API.
4.2. Функциональные требования
Локальное хранилище данных:
Регистрация клиентов (Android-приложений) с уникальными ID.
Хранение произвольных JSON-данных для каждого клиента (ключ-значение).
Поддержка синхронизации данных между клиентами (опционально).
Автоматическая очистка устаревших данных.
API для Android-приложений:
CRUD операции над данными (чтение, запись, удаление, обновление).
Поддержка подписок на изменения (WebSocket или long polling).
Аутентификация по токену (простому, без сложной безопасности, т.к. локальная сеть).
Независимость от основного бэкенда:
Может работать без Central Hub.
При наличии Central Hub – может интегрироваться через него (например, публиковать свои данные как устройства умного дома).
Минимальное потребление ресурсов:
RAM < 50 МБ.
Хранение данных в SQLite или плоских файлах.
4.3. Пример API
Метод Эндпоинт Описание
POST /api/client/register Регистрация нового клиента
GET /api/data/{client_id}/{key} Получить значение
POST /api/data/{client_id} Сохранить/обновить значение
DELETE /api/data/{client_id}/{key} Удалить ключ
GET /api/status Статус
5. Взаимодействие между компонентами
flowchart TD
subgraph Xperia XZ1
A[Central Hub<br>умный дом]
B[Voice Module]
C[RKHomeHub]
D[Будущие модули<br>OpenClaw, Notifier]
end
subgraph Внешние устройства
E[Android-приложения]
F[Пользовательский голос]
end
F -->|голос| B
B -->|текст команды| A
A -->|текст ответа| B
B -->|озвучка| F
A <-->|опционально| C
E <-->|API| C
D <-->|аудио запросы| B
D <-->|команды/статус| A
Правила взаимодействия:
Voice Module отправляет текстовые команды в Central Hub (POST /api/voice/command).
Central Hub обрабатывает команды, управляет устройствами, возвращает ответ.
Voice Module озвучивает ответ.
RKHomeHub работает независимо, его клиенты – Android-приложения.
Будущие модули (OpenClaw, нотифаер) регистрируются в Central Hub и могут запрашивать аудио через Voice Module (через API арбитра).
6. Общие требования к реализации
Платформа:
Xperia XZ1 (Android 8+, ARM64, 4 ГБ RAM).
Root (Magisk), ACC для контроля заряда.
Termux с поддержкой termux-api, termux-tts-speak, termux-microphone-record.
Автозапуск всех трёх бэкендов при загрузке (через Termux:Boot).
Языки и технологии (на усмотрение агента):
Central Hub: предпочтительно Go (высокая производительность, малый размер).
Voice Module: Python (быстрая разработка, готовые биндинги Vosk) или Go (с обёртками).
RKHomeHub: Go (лёгкий, простой).
Коммуникация:
HTTP/JSON между компонентами (локальный порт, например 8080 для Central Hub, 8081 для Voice Module API, 8082 для RKHomeHub).
WebSocket для событий реального времени (опционально).
Конфигурация:
Единый конфигурационный файл (YAML) для всех компонентов, либо отдельные файлы.
Параметры: IP-адреса, порты, пути к моделям, URL внешних API.
Логирование:
Каждый компонент пишет логи в отдельный файл в /sdcard/logs/.
Ротация: размер 10 МБ, хранить 5 файлов.
Документация для агента:
Инструкция по сборке (если требуется компиляция).
Инструкция по развёртыванию на телефоне.
Примеры API-запросов.
7. Критерии успешной реализации
Central Hub запускается и отвечает на API-запросы. Можно зарегистрировать тестовое устройство, отправить команду, получить ответ.
Voice Module активируется по ключевой фразе, распознаёт тестовую команду ("включи свет"), отправляет в Central Hub, получает ответ и озвучивает его.
Аудиоарбитр корректно обрабатывает конфликтные запросы (например, одновременный запрос от Voice Module и симулированного модуля с более высоким приоритетом).
RKHomeHub позволяет Android-приложению (симулированному) сохранить и прочитать данные.
Все три компонента работают одновременно без взаимных блокировок и утечек памяти в течение 24 часов.
Управление через ADB/SSH возможно (логи, рестарт).
8. Дальнейшее расширение (не требуется сейчас, но для спецификации)
Добавление веб-интерфейса для управления умным домом.
Поддержка MQTT для интеграции с внешними платформами.
Графический интерфейс на телефоне (через нативное приложение) – но из-за разбитого экрана не актуально.
Локальный LLM (например, через llama.cpp) для обработки команд без интернета.
Итог для агента: Агент должен создать три независимых проекта (каждый в своей директории) с полным исходным кодом, конфигурациями, скриптами развёртывания и инструкцией. Основной бэкенд (Central Hub) и RKHomeHub – на Go, Voice Module – на Python или Go. Взаимодействие через локальный HTTP. Всё должно работать на Xperia XZ1 под управлением Termux.Понятненько. Спасибо за информацию, на будущее, кнопка спойлера - * (шестигранная звезда), она доступна, когда вы не выделили текст или просто на новой строке. При выделении блока текста становится доступно его частичное скрытие, а спойлер же доступен для текущего абзаца, где просто находится курсор.
Надеюсь, понятно объяснил.
Просто выделите весь текст.
Если нужен ИИ-голосовой ассистент с кодом - https://github.com/janvarev/Irene-Voice-Assistant - я пилю, опенсорс, есть статьи на Хабре, 1К+ Гитхаб звезд.
формат существующих сервисов меня не устроил
Чем бумажный блокнот лучше любого облачного аналога word? Или в чём состояла постановка задачи?
В существующих сервисах был не такой обширный список эмоций, а свободное время под написание своего решения таким, каким вижу его я, было - почему бы и нет
Бумажный блокнот иногда лучше тем, что он работает без интернета :) и он - твой собственный, это просто приятно
У блокнота есть несколько существенных минусов.
плохо бэкпится
по нему плохо агригируется, фильтруется и ищется ( в общем никаких без доп усилий)
у современного человека почти не бывает ситуаций когда он без мобилы, а блокнот можно и забыть
блокнот заканчивается
практически никто не готов потратить энергию, как-то в блокнотах через год покопаться, собрать интересное, сделать аналитику - а это интересные данные о себе, могут быть крайне полезными
А минусы где? ;)
Аналитику сделать только сканить.
А вот все остально профанация самой идеи блокното-терапии.
Там моторика задействована как обязательный компонент. И сейчас дополнительно - вырывание из цифровой среды только ты и блокнот.
UPD: Поправлюсь наверное. Электронно - ага база будет, аналитика и поиск будет. Заметки в дневном ритме на бегу тоже будут. Верно.
Цели конкретно в дисклеймере не будет - изменения субъекта. Просто очередной кусок информации с ярлычком. Эффективность на порядки меньше.
Я же не просто так решил прокоментировать :)
"на собтсвенном опыте"
Чем моторика печати хуже моторики писания мне не понятно, как только появилась возможность "не писать" я не пишу.
оно теряется
я не могу сам прочитать через неделю :)
остальные доводы я упомянул
Просто по моим ощущениям терапия в размышлениях и выгрузке наруже всякого лишнего и не очень для головы, чтобы снаружи это опять взять обдумать, проработать и в нужном виде, нужную часть обратно в голову положить. Честно говоря и надиктовывать вполне себе работатет, без всяких моторик - но гораздо, гораздо медленнее, а так же как и писанинан рукой напряжнее к медленности, что облегчает спрыгнуть/пропустить.
Действительно, у меня нет никаких пруфов только эмпирика:
Лет двадцать ничего не писал, психолог уже просто директивно на мое "веду все записи электронно" сказал - бери блокнот физический. Для списков с физическим вычеркиванием хотя бы. Оказалось в конкретном случае что это критично для самой методики подобного типа. Печать и чтение каких то нейросвязей не оставляет, по крайне мере в моей конструкции организма.
С надиктовыванием - опыт совпадает, работает, но возможность диктовать нейронке и смещать фокус тупо в интерактив диалога и обсуждение появилась сравнительно совсем недавно, когда LLM поумнели. Тот же NotebookLM когда ему Gemini на #3 заменили большая разница с прошлым проекта.
Я солидарен с автором. Лучше так, чем просто выкидывать вполне работоспособное железо, которое просто стало "не модным" или перестало тянуть наговнокоженный софт (это я и про андроид, и про приложения, можете кидать в меня тапками). ТТХ смартфонов уже давно перестали расти стремительным домкратом, и в ближайшее время каких-то прорывов не предвидится, вычислительных мощностей ещё долго будет хватать для решения каких-нибудь задач.
Другое дело, что трудно придумать эти задачи, но автору это видимо удалось.
Так что желаю вам продолжать в том же духе, несмотря на...
Интересно… вот вручную точно нет смысла пытаться цеплять программатор к материнке битого телефона и пытаться зашить туда всё с нуля, начиная со своего бутлодыря… что там с подписями, кстати? Многие ли докатились до огрызочного принципа «каждая прошивка расшифровывается только ключом, уникальным для каждого экземпляра процессора»? (Я считаю, что появление таких решений в общегражданской рознице должно наказываться примерно как торговля преднамеренно заминированными автомобилями — но копроратам сейчас даже уже это почти разрешили, лол).
А вот если робот наговнокодит так, что оно хотя бы заведётся, замигает лампочками, увидит внутреннюю флэшку и начнёт что-то в отладочный порт кидать — дальше уже можно всё дописать, руками поправить и так далее. В целом вполне себе подход…
копроратам сейчас даже уже это почти разрешили, лол
Насчёт загрузчика - уже не то что разрешили, а даже требуют так делать.
…именно в этом варианте? Потому что обычная залочка, не привязанная к уникальному ключу процессора, лечится методом «стереть всё в ноль и залить программатором написанное с нуля». Вместе со своим загрузчиком, который не обязан никому подчиняться.
Ну, это если мы полным набором даташитов владеем, конечно. Но это было во «вводной» %)
а вы не пробовали снести google play? У меня после этого старый планшет перестал тормозить
настроил контроль перезаряда — взрывов из-за вздувшейся батареи нам не нужно
Тут можно по-подробнее? Я видел как запитывали откинув батарею, напрямую, но там возни с три короба. Как реализовывается вышеописанное?
С батареей, программно - magisk модуль Advanced Charging Control, останавливает зарядку по достижении X%, запускает заново по падении до Y%
В некоторых кастомных ROM есть уже встроенное, например у меня Iodé OS - там есть
Ещё можно аппаратный ограничитель заряда воткнуть между устройством и зарядкой, стоят недорого
Это оно будет циклы гонять или питание от адаптера берётся ровно то, которое нужно для работы, без зарядки?
Циклами, но при значениях в рамках примерно от 60 до 90% это довольно безопасно для батареи
Батарее "безопасно", если держать её заряд не выше 40%. Ну, то есть она ВСЁ РАВНО постепенно умрёт, но при этом, скорее всего, её смерть будет тихой, без пожара и даже без раскалывания корпуса устройства вздувшейся батареей.
У литиевых аккумов два основных параметра, влияющих на срок службы (который детерминирован: после начала эксплуатации в батарее разрушается консервирующая присадка к электролиту, и батарея начинает необратимо деградировать, и помирает за 3-5 лет (без учёта прочих факторов), зависимо от исходного качества) -- температура и циклы.
Заморозка сильно и быстро портит батарею. Перегрев выше комнатной температуры ускоряет её деградацию: условно, каждая минута нахождения батареи в состоянии перегрева сокращает срок её службы на несколько минут -- с коэффициентом, примерно пропорциональным температуре (т.е. чем выше температура батареи, тем быстрее она портится)
С циклами тоже не всё просто. Если для аккумулятора производитель обещает "1000 циклов" -- это значит, что после 1000 циклов между 20 и 80%, у батареи останется не менее 80% начальной ёмкости (если производитель не врёт, если батарея не подвергалась заморозке или перегреву, и эта тысяча циклов произведена менее, чем за два года). Если расширить диапазон от 0 до 100% заряда, ёмкость упадёт быстрее -- например, после 900 циклов. Если уменьшить диапазон, скорость деградации уменьшится, но не прям уж сильно -- даже если снизить диапазон до нескольких процентов, это не увеличит число возможных циклов выше, скажем, 1500. (в этом абзаце все числа -- приблизительные)
Теперь про уровень. Чем меньше в батарее заряда, тем ниже шансы на пожар, и, вероятно, ниже риск её вздутия, не обусловленного нарушением условий эксплуатации -- во всяком случае, б/у батареи, полностью заряженные перед демонтажом, на хранении нередко вздуваются, а батареи, положенные на хранение разряженными, обычно умирают без внешних эффектов.
Короче, нет смысла искать программное решение для аппаратной проблемы. Хотите надёжности -- выбрасывайте штатную батарею из девайса и стройте нормальный бесперебойник. Хотите простое решение -- не заморачивайтесь. Просто убедитесь, что БП, от которого запитано ваше устройство, НЕ поддерживает протоколы быстрой зарядки, этого достаточно, чтоб снизить риск возгорания до пренебрежимо-низкого (не выше, чем риск возгорания любого другого электроприбора).
Не подвергая сомнению вышесказанное - а есть пруфы? Исследования с реальными цифрами и графиками. Почему спрашиваю - заморозку до минус 20 и кратковременную и на месяцы лично проверял и никакого влияния не заметил, после оттаивания ни емкость, ни внутреннее сопротивление не изменились ни на процент (это точность приборов, возможно и на десятые доли не изменились). Про безопасные 40%, влияние перегрева, зависимость количества циклов от глубины разряда тоже противоречивые данные, а сделать тысячи циклов или наблюдать годами за медленной деградацией не так просто, поэтому если есть готовые данные, не могли бы поделиться?
Вы говорите про заморозку для хранения. Заморозил положил и не трогаешь, отогрел и пользуешься - так и будет как вы написали. А если работа при низких температурах - то батарея оч быстро деградирует.
Опять же попрошу пруфы и объяснить механизм деградации. При сильной заморозке, внутреннее сопротивление увеличивается на порядок. Например видел 0.9 ома при минус 16 у 3000 мА*ч батареи, это очень много и нормальная работа часто невозможна, показываемый процент заряда низкий, а при потреблении заметного тока напряжение просаживается до порога отключения. Возможно эти эффекты путают с деградацией.
То что в процессе быстро ‘разряжается’ на морозе - это факт. Тут вы верно заметили.
Про сумму микроциклов/полные циклы заряда/разряда тут когда то было https://habr.com/ru/articles/223955/ выглядит что ограничивать есть смысл если не регулярно используешь устройство, чем ниже заряд тем меньше деградация. А телефон - лучше просто при первой возможности бросать на зарядку, и не особо париться.
Про долгое использовпние на морозе - лично у меня есть не репрезентативная выборка: люди игравшие в ингрес/покемонго зимой без павербанка. После зимы в таком режиме, когда по много часов играешь (в т.ч. чуть отогрел чтоб заработал и дальше) весной оказывалось что время жизни значительно сократилось.
но вообще достаточно легко гуглится Появление микро-трещен в электрооде, потеря до 5% сверх того что эксплуатировались при нормальной температуре https://www6.slac.stanford.edu/news/2021-08-26-how-extreme-cold-can-crack-lithium-ion-battery-materials-degrading-performance
покрытие электрода литием, что приводит к необратимой потере емкости https://pubs.acs.org/doi/10.1021/acsaem.2c00957
https://www.sciencedirect.com/science/article/pii/S1385894724097511
Ссылками зачитался, спасибо. Заметил фокус в исследованиях на электрокарах, что понятно, для них заряд и разряд на морозе намного актуальнее, чем для смартфонов. Цельной картины на составил, кое-что вообще за пэйволлом, но деградация катода точно есть, не катастрофическая, в единицы процентов и зависит от токов, от 1С и выше становится все более заметной. То есть телефонам должно быть полегче - в кармане редко ниже нуля, вне кармана в мороз они обычно недолго находятся, разве что если в сумке носить. Токи разряда больше 0.5C маловероятны, а заряд вообще обычно в тепле. Ваш случай с ингрес/покемонго любопытен, до этого встречался только с внезапными отключениями на морозе, при этом жалоб весной на просевшую емкость не было.
Есть вот такое: https://www.batteryuniversity.com/article/bu-808-how-to-prolong-lithium-based-batteries/
---
Для тех кто просто читает ветку: в модуле Advanced Charging Control есть лимит по напряжению и это imo лучше чем просто стоп на 80%.
Ещё обычно включена кнопка буферного режима: при остановке по процентам или напряжению ток потребляется с провода, сенсор на акк показывает +-1 мА. Также не будут идти циклы 60-80% или что вы там выставили.
Лимит по напряжению и буфер не работают на древних андроидах (мб нужен >=7), но продлят жизнь халявного встроенного ибп.
За ссылку на Battery University спасибо, там не не совсем то, что я ищу (тест реальной современной батареи с методикой измерений и точными цифрами), но очень интересна инфа про влияние недозаряда по напряжению на циклы.
В их "Table 2" видно, что если каждый раз разряжать от 100% до нуля, то будет 300 циклов, а если на 60% (100%-40%) то 600. По суммарному времени работы смартфона выигрыш от неглубоких циклов совсем небольшой, если принять полный цикл за 10 часов, то 3000 часов и 3600 часов соответственно, всего +20% при почти вдвое более частой необходимости в розетке. Что я и наблюдаю вокруг - кто-то ставит на зарядку часто, кто-то почти всегда разряжает до минимума и через 2-3-4 года все начинают жаловаться на батарею или меняют ее или телефон.
Но вот если ограничить заряд сверху (Table 4) напряжением 3.85 В, то полное время работы для 2400 циклов 60%-0% будет 14400 часов, в 4 (!) раза больше, чем те уже неплохие 3600 часов при 100%-40%. Что-то очень оптимистично, даже тут чуть не верится без ссылок на исследования. Конечно при использовании лишь 60% емкости придется примерно вдвое чаще заряжать и заряда чаще не будет хватать на день. Либо придется иметь вдвое большую по объему/весу батарею, чтобы оставить привычное время работы. Плюс 50 грамм и несколько миллиметров толщины в обмен на 8-12 лет до проблем с деградацией батареи и возможность изредка использовать вдвое большую емкость было бы интересным вариантом. Наверняка не все так просто и деградация батареи не от циклов, а от времени снизит эти 8-12 лет, но даже 5-7 лет - это для очень многих более чем достаточно. Жаль Advanced Charging Control без рута не работает, да и телефон не новый, а то бы немедленно попробовал.
в обмен на 8-12 лет до проблем с деградацией батареи
Крайне сомнительная цифра. За 8-12 лет даже новый, законсервированный с завода аккумулятор обычно теряет бОльшую часть номинальной ёмкости. У меня лежит старый дедов сименс-55, пару лет назад я нашёл в старых запасах новый, в заводской упаковке аккум для него, попытался поюзать... заряжается за 15 минут, телефон в режиме ожидания от него работает примерно столько же, полностью заряженный аккум разряжается саморазрядом (без нагрузки, просто лёжа на столе) до срабатывания защиты за два часа.
Это вообще без циклов и нагрузок, "нулёвый" аккум, просто пятнадцать лет пролежал законсервированным.
Мне эти теоретически расчитанные 8-12 лет тоже кажутся чем-то запредельным, поэтому как более реальные цифры предложил 5-7 лет. В конце концов есть надежные данные по Теслам, у которых за 5-6 лет и 100 000 миль снижение емкости часто не более 10% от первоначальной и это с сотнями полных циклов. И там как раз есть режим "не заряжать до упора", пользоваться которым люди намного больше финансово заинтересованы по сравнению со смартфонами, где батарею поменять дешево.
Ваш пример с Сименсом могу объяснить так - батарея там порядка 700 мА*ч, хороший производитель поставляет их заряженными на те самые 40% для безопасной транспортировки, то есть там 280 мА*ч. И в этой батарее есть плата защиты, например на основе популярного чипа DW01 с потреблением лишь 3 микроампера. Однако за 15 лет этот чип съест 0.003*24*365*15 = 394 мА*ч! И это мы еще не учитывали саморазряд самой батареи, который по разным данным составляет от 1 до 10% в год. Так что очень вероятно, что эта батарея была уже несколько лет разряжена намного ниже безопасного для лития порога в 3 вольта, что и привело к такой сильной деградации емкости и дикому саморазряду.
И у меня есть обратный пример, когда 18650 банка, выпущенная в апреле 2017 года, спустя 9 лет потеряла лишь 4% первоначальной емкости. Платы защиты у нее нет, за эти годы было несколько десятков полных (100-0%) тестовых циклов, все остальное время стояла примерно наполовину заряженной. Почти уверен, что 12 лет она может встретить не потеряв бОльшую часть емкости.
Можно же несколько раз заморозку провести, например 10 или 50. Смысл в том что сепаратор начинает разрушаться из-за циклов сжатия, как я это понимаю. Наиболее змеиный эффект будет, если батарея будет а этот момент использоваться
8 циклов заморозки проводилась, без нагрузки и с SOC (уровень заряда) 40-50%. Разница в емкости и сопротивлении в пределах погрешности. Насчет сжатия сепаратора - интересная мысль, ранее не слышал. Из подкрепленного теорией читал, что полностью заряженные батареи нехорошо морозить, получается своего рода перезаряд. Примерно поэтому же холодные батареи запрещают заряжать.
Я видел как запитывали откинув батарею, напрямую, но там возни с три короба.
Меня уже давно удивляет то, что китайцы выпускающие тонны всякой ерунды, до сих пор так и не сделали некий "батареезаменитель", позволяющий безопасно запитывать устройства, рассчитанные на аккумулятор.
Думаю, что продавался бы очень хорошо.
Он нужен 2.5 гикам. Они и сами себе могут его спаять.
Почему "до сих пор так и не сделали"? Давно уже сделали, но, преимущественно, в другом секторе: для переносных радиостанций. Так и называется: battery eliminator kit.
пример
Проблема в том, что это не может быть "универсальным" из-за проприетарности драйверов АКБ.
И одновременно с этим решение уже есть, достаточно лишь извлечь плату контроллера АКБ, выбросить (в центр утилизации конечно) литий.
1. заменить его на стандартную банку 18650
2 подвести стабильные 3.7 вольта
Уверен что их завались в виде модулей на каком-нибудь таобао.
Проблема обычно не в электронике, а в том, как разобрать-собрать современный телефон.
Был бы аккумулятор съёмный вообще не былоб проблем
А зачем какой-то СПЕЦИАЛЬНЫЙ заменитель? Не менее, чем 99% устройств, рассчитанных на питание от литиевого аккума, можно стационарно запитать от любого регулируемого БП, подключенного вместо банки аккума и настроенного на выходное напряжение в районе четырёх вольт.
Вы статистику откуда брали ?
Современные телефоны очень трепетно относятся к аккумуляторам. Боюсь что 99% не увидев показаний штатного ntc (который вы выкинули вместе с аккумулятором) работать не станут. И это лишь вершина огромного айсберга.
Еще раз повторю: эти проблемы решаемы гораздо проще, чем проблемы с сборкой-разборкой, бутлоадерами итд итп.
В целом овчинка стоит выделки только ради рукоблудства. Для использования навалом разных других платформ можно найти.
Боюсь что 99% не увидев показаний штатного ntc (который вы выкинули вместе с аккумулятором) работать не станут.
Не путайте "модуль аккумулятора" и банку, которую надо из него выкинуть.
Модуль аккумулятора -- это функционально-законченный блок, состоящий из банки аккумулятора, платы защиты от перезаряда/переразряда, иногда -- датчика температуры, и, если модуль съёмный -- корпуса.
Выкинуть нужно ТОЛЬКО банку, и вместо неё, к контактам Batt+ и Batt-, подключить внешнее питание. Плату защиты и датчики выкидывать незачем, пусть остаются. С точки зрения телефона ничего не изменится, просто аккум перестанет разряжаться.
Не сработает этот трюк только с кривыми модулями (такие встречаются в ноутбуках), у которых плата защиты лочится при отключении банок, но в телефонах, вроде, таких извращений пока нет.
Ещё, говорят, можно вместо банки аккума кондёр поставить, а питать устройство через usb, но сам я такой способ не пробовал, так что не могу ничего по этому поводу сказать.
плата защиты лочится при отключении банок
У пылесосов Dyson так же лочится. Там преднамеренное устаревание во всей красе. Там намеренно нет балансировки банок, чтобы быстрее выходило из строя.
Я удивлён, как их ещё не засудили на миллиарды за всё это и засирание природы.
Там преднамеренное устаревание во всей красе. Там намеренно нет балансировки банок, чтобы быстрее выходило из строя.
Не ищите злого умысла там, где всё объясняется глупостью и некомпетентностью (с)
Балансировки там, вероятно, нет просто потому, что без неё -- дешевле. Ну, или просто "так исторически сложилось" по каким-то совершенно пустяковым случайностям, о которых нам не известно. Например, какой-то дэффективный менеджер сэкономил на разработке и приказал взять готовую схему блока аккумулятора от другого проекта, где балансировка реально была не нужна, или осуществлялась каким-то другим способом.
Производителю пылесоса, утюга или чайника нет смысла делать "преднамеренное устаревание" -- рынок такой техники насыщен, и пользователь, недовольный быстрым отказом дорогой вещи, наверняка купит аналог на замену от другой марки, а не такую же, да ещё и всем знакомым расскажет, что недоволен этой маркой.
Без контроллера на батарее может запустится, может нет.
Спасибо за статью. Часть про управление голосом особенно интересна.
Не очень верится, что нет старого ноута, а то и не одного для тех же целей ;)
Живых нет( так бы и из них что-нибудь придумал
Думаю тут дело не в том, что нет, а в целесообразности. Это простой сервер, ему ненужно крутить локальную LLM или рендерить. Поэтому смартфона с потреблением в несколько ватт энергии, не гудящего кулерами, и стабильно работающего длительное время с отсутствием тепловыделения достаточно. Как бонус: реализованные кодеки, шумодав, отличная камера в случае использования в качестве IP видеонаблюдения
Старые смартфоны за частую гораздо лучше профильных edge устройств и всяческих "мини ПК", я использовал вообще динозавра в https://habr.com/p/1007546/
Но даже это было лучше чем распиаренный Raspberry
Все же не хватает примера взаимодействия с ии. Я далёкий от программирования. Хотелос бы видеть примеры пронтов.
В комментарии я нашёл ответ, не думал что там такие простые запросы.
Касательно старичков. Гоняю с самсунг ноте 9 18 года. На годик по моложе но работает и пока устраивает. В моем представлении старый телефон еще старше. Думал сервер на подобном запускать будут)
Телефоны, в которых все разблокировано и соответственно можно легко вырезать и добавить (пропатчить) системный софт можно пересчитать по пальцам. Увы, но тенденция такова, что “открытых” моделей становится все меньше и меньше с каждым годом. И даже те модели, которые ранее можно было разблокировать, спустя некоторое время, когда они теряют актуальность, становится нельзя, хотя казалось бы по логике должно быть наоборот (отдельное фи например “риалми” и подобным лавочкам). А без разблокировки большая часть манипуляций очень сложна или невозможна.
Интереснее бы иметь возможность докер поставить, python скрипты запускать на таком сервере
Полноценный VPS с полноценной ОС, IP, нормальным диском и CPU, бекапом по питанию, защитой от возгорания (в отличии от старого телефона на зарядке 24/7) будет стоит 150-200 рублей в месяц. Зачем нужен этот онанизм со старым телефоном?
Тут вопрос не в деньгах даже, а в интересном проекте. Думаю, на этот вопрос работает правило "если надо объяснять - значит, не надо объяснять" :)
У телефона будет ОЗУ и ядер побольше, чем за 200 рублей в месяц. Но конечно на vps будет нормальный линукс, а не какой-то андроид
Вроде как под андройдом можно запускать что то линуксовое. А если удастся перешить на линукс - совсем хорошо будет.
Ващет, андроид -- это и есть линупс с натянутой поверх средой для запуска apk. Запускать там "что-то линуксовое" -- никаких принципиальных проблем. Ну, кроме того, что большинство андроид-устройств имеют архитектуру арм, а не х86, и для них нужны бинарники, собранные именно под арм. Это может оказаться проблемой для нуба, но настоящий красноглазик даже не поймёт, почему я об этом говорю так, будто это проблема.
Или неполноценный, тут как повезет.
Колхоз дело добровольное.
Имею очень обширный опыт и в основном негативный. Такие тарифы нужны только чтобы заставить вас перейти на тариф в 5-10 раз дороже.
Крайний раз пытался разобраться почему иопс стал порядка 10 через несколько лет работы :)). Совет поддержки - да ты купи просто памяти побольше и сразу станет, наверное нормально :).
Пейлоад там потребляет 50-60мегабайт памяти максимум и в целом диск не дергает вообще. Никто годами не замечал проблем. Но когда понадобилось чуток подшаманить в консоли адские тормоза наступили.
200 в месяц -- это 2400 в год. А телефон, если нет бесплатного в ящике стола, на авито 500-1000 рублей стоит единоразово. Зачем платить, когда можно не платить?
SileroTTS для её синтеза. С последним пришлось повозиться, поскольку официально Android не поддерживается
Разве это не просто торч модели? А торч под андроид должен быть нативно
Непонятно, зачем всё это. Можно было в первоначальное приложение вместо файлов встроить хотя бы sqlite и убрать тормоза.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вторая жизнь старого смартфона в качестве домашнего сервера