- config flow: template (A/B/F с пояснениями, значения с устройства,
определение по oem_model; для неизвестных моделей — пробинг A/B/F тремя
короткими сессиями) -> capabilities (23 тумблера с описаниями, дефолты
из device_capabilities/num_dir/ответов) -> limits (диапазон/шаг, ручная
конверсия); каждая страница с пометкой «значения определены
автоматически, можно пропустить»
- features.py: FeatureSet/LiveValues/device_default/resolve_features;
entry.data["features"] хранит выбор пользователя; reconfigure
предзаполняет; YAML-import получает дефолты
- сущности создаются только для включённых фич: climate (режимы/скорости/
swing/пресеты), switch, select заслонок (caps+num_dir), датчик комнаты;
исправлено появление select без ламелей
- trial: caps/num_dir и presence-зонды (необязательные свойства), answered;
координатор ждёт первые свойства перед созданием сущностей (feature-
дефолты без гонки)
- атрибут description у сущностей (HA не поддерживает тултипы) + описания
фич в мастере (en/ru)
- тесты: features, probing, обновлённые flow/entities/repairs; 57 components
- _corebuild.musl_platform_tag(): на musl (Alpine/HA OS) bdist_wheel
выпускает py3-none-musllinux_X_Y_<arch> вместо linux_<arch> — иначе pip
ставит glibc-сборку и dlopen падает на ld-linux-x86-64.so.2
- shared-библиотека линкуется со -static-libstdc++ -static-libgcc (gcc):
NEEDED только libm/libc (проверено readelf), меньше зависимостей у HA OS
- Gitea Actions: job build-musllinux (container python:3.12-alpine) собирает
и публикует musl-wheel; build-glibc — как раньше; общий
scripts/publish-gitea-pypi.sh с пропуском уже загруженных файлов
- тесты musl_platform_tag; RELEASE_HA §1.1-1.4 (выбор wheel, переустановка
на HA OS, ручная сборка musllinux без container:); README troubleshooting
- README компонента: проверка лога, установка pyfglair в окружение HA
(docker exec python -m pip), полный перезапуск, проверка импорта
- RELEASE_HA: та же диагностика в разделе установки
- ESPHome connect/command/импорт оборачиваются в AcceptanceError; при сбое
connect канал закрывается (loop закрыт), CLI даёт rc 2 без traceback
- self-test: connect error, command error, отсутствие aioesphomeapi через
main (rc 2) — всего 15 acceptance-тестов
- RELEASE_HA: repaired-wheel в dist/manylinux + удаление linux-тега перед
upload; README компонента — корректная ссылка на docs/RELEASE_HA.md
- translations/ru: options data «LAN-ключ»; план §2/§6 синхронизирован
- critical: README честно описывает HACS (только публичный GitHub-зеркало)
+ ручная установка копированием; RELEASE_HA — шаг зеркала и codeowners
- critical: ESPHome-канал приёмки реализован реально (aioesphomeapi:
connect/list_entities/climate_command для режима и уставки; fan/swing —
только HA); unit-тест на фейковом модуле
- major: quick/long восстанавливают исходное состояние в finally даже при
сбое; quick ждёт восстановления; ошибки шага пишутся в результат (rc 1),
а не фаталят (rc 2)
- major: RELEASE_HA — manylinux через auditwheel repair (PyPI отклоняет
linux_x86_64), build/twine, aarch64, корректные проверки .so, тег/версия
- major: полный ключ для ESPHome теперь реально виден в options flow
(«Настройка» на карточке интеграции, поле LAN IP key, можно заменить) —
README/diagnostics синхронизированы
- minor: non-JSON ответ → rc 2; CSV quick+long и инкрементальная запись;
допуск _matches в long; --settle-timeout; hacs.json homeassistant=2025.1;
brand/{icon,logo}.png заглушки; план §6/§7 уточнён
- тесты: acceptance self-test 11 (restore-after-failure, long fail, non-JSON,
esphome channel), options flow (2), всего 28+11+49
petr.polezhaev