Перейти к содержимому

2026-03-23 — Метаданные комнат и интеграция с HA areas

23 марта — день, когда bridge начал понимать, где колонки физически находятся. Двадцать восемь RC-релизов в рамках двух стабильных тегов доставили метаданные комнат, интеграцию с реестром областей Home Assistant, контракты готовности к передаче и фундаментальное изменение в том, как Docker-контейнеры работают с правами на аудио.

Home Assistant ingress-сессии теперь могут получать реестр областей HA прямо в config UI bridge. При редактировании Bridge name устройства оператор видит подсказки комнат по одному клику, вытянутые из реальной иерархии областей HA. Bluetooth-адаптеры тоже могут подтягивать точные совпадения областей из реестра устройств HA.

Эта интеграция активируется только в режиме HA add-on, где ingress-сессии имеют необходимый доступ к Supervisor API. Подсказки настраиваемы и включены по умолчанию.

Bluetooth-устройства bridge теперь могут нести стабильные метаданные комнат: room_name, room_id, а также индикаторы источника и достоверности. Эти метаданные проходят через status-снапшоты и доступны Music Assistant, Home Assistant и MassDroid для маппинга комнат.

Система комнат намеренно проста на данном этапе — устройство знает, в какой оно комнате, и эта информация стабильна между перезапусками. Поле достоверности существует, потому что назначение комнаты может прийти из ручного ввода оператора (высокая достоверность), совпадения с HA area (средняя) или эвристического парсинга bridge-имени (низкая).

Status-снапшоты устройств теперь включают компактный контракт transfer_readiness, который отвечает на вопрос: действительно ли эта колонка готова к быстрой передаче между комнатами? Контракт проверяет состояние Bluetooth-соединения, доступность аудио-sink, здоровье daemon и полноту метаданных комнаты.

Это фундамент для будущих workflow передачи между комнатами. Вместо того чтобы начинать передачу и на полпути обнаруживать, что Bluetooth целевой колонки отключён, автоматизации и UI могут заранее проверить готовность.

Docker- и Raspberry Pi-образы теперь сохраняют init контейнера и root-настройку для Bluetooth и D-Bus, но автоматически перезапускают процесс bridge от имени AUDIO_UID для пользовательских host-аудиосокетов. Это устраняет самую частую проблему деплоя на Raspberry Pi: PulseAudio или PipeWire отказывают в подключении, потому что bridge работает от root, а аудиосервер ожидает сессию хост-пользователя.

Изменение использует модель разделённых привилегий — init работает от root для доступа к оборудованию, затем процесс bridge понижается до аудио-пользователя. Startup-диагностика и Raspberry Pi pre-flight checker теперь различают UID init и UID приложения и понятно объясняют модель.

Релизные образы ARMv7 теперь устанавливают runtime-библиотеки FFmpeg, необходимые PyAV/sendspin, а publish workflow проверяет фактический путь импорта daemon smoke-тестом. Это исправило краш libavformat.so.61, который затрагивал старое оборудование Raspberry Pi на свежих установках.

Таймлайн восстановления с расширенными фильтрами

Заголовок раздела «Таймлайн восстановления с расширенными фильтрами»

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

Руководство оператора стало спокойнее по всем фронтам. Онбординг по умолчанию не попадает в стек уведомлений на непустых установках. Групповые действия показывают предварительный просмотр затронутых устройств перед выполнением. Плотные pill-метки проблем восстановления сворачиваются в +N more вместо того, чтобы заливать экран.

MA runtime теперь может перезагружаться после изменения URL или токена без полного перезапуска bridge. Обновления auth и rediscovery применяются на месте, что важно для HA-окружений, где токены MA ротируются или IP-адрес MA-сервера меняется после перезагрузки.

Настройки устройств теперь поддерживают явный handoff_mode, где fast_handoff использует существующий keepalive-путь, чтобы поддерживать выбранные колонки в более тёплом состоянии для workflow передачи между комнатами. Runtime-события устройств обогащены контекстом комнаты и готовности, а веб-интерфейс показывает бейджи комнаты и передачи, а также ручные контролы назначения комнаты. Эта основа стала базой для полной системы null-sink standby, которая вышла позже на этой неделе.

v2.45.0 и v2.46.0 перевели bridge с device-ориентированной модели (вот ваши колонки) на room-ориентированную модель (вот где ваши колонки и готовы ли они). Интеграция с HA areas сделала этот переход практичным для большинства пользователей, у которых комнаты уже определены в Home Assistant.

Исправление Docker-аудио было, пожалуй, самым значимым изменением для новых операторов на Raspberry Pi, устраняя проблему номер один при деплое.

С метаданными комнат и готовностью к передаче на месте, следующим приоритетом стало укрепление уровней безопасности и IPC перед функциями standby и transport, которые будут строиться на этих контрактах.