2026-03-23 — Метаданные комнат и интеграция с HA areas
23 марта — день, когда bridge начал понимать, где колонки физически находятся. Двадцать восемь RC-релизов в рамках двух стабильных тегов доставили метаданные комнат, интеграцию с реестром областей Home Assistant, контракты готовности к передаче и фундаментальное изменение в том, как Docker-контейнеры работают с правами на аудио.
Что вошло в релиз
Заголовок раздела «Что вошло в релиз»Интеграция с реестром областей Home Assistant
Заголовок раздела «Интеграция с реестром областей Home Assistant»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-аудио
Заголовок раздела «Пользовательский Docker-аудио»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 приложения и понятно объясняют модель.
Исправление runtime для ARMv7
Заголовок раздела «Исправление runtime для ARMv7»Релизные образы ARMv7 теперь устанавливают runtime-библиотеки FFmpeg, необходимые PyAV/sendspin, а publish workflow проверяет фактический путь импорта daemon smoke-тестом. Это исправило краш libavformat.so.61, который затрагивал старое оборудование Raspberry Pi на свежих установках.
Таймлайн восстановления с расширенными фильтрами
Заголовок раздела «Таймлайн восстановления с расширенными фильтрами»Диагностический инструментарий восстановления получил сохраняемый таймлайн восстановления с расширенными фильтрами по серьёзности, области, источнику и временному окну. Продвинутые пользователи теперь могут отслеживать события восстановления во времени, а не видеть только текущее состояние. Это сделало пост-инцидентный разбор практичным без ручного анализа логов.
Более спокойное руководство оператора
Заголовок раздела «Более спокойное руководство оператора»Руководство оператора стало спокойнее по всем фронтам. Онбординг по умолчанию не попадает в стек уведомлений на непустых установках. Групповые действия показывают предварительный просмотр затронутых устройств перед выполнением. Плотные pill-метки проблем восстановления сворачиваются в +N more вместо того, чтобы заливать экран.
Живая перезагрузка Music Assistant
Заголовок раздела «Живая перезагрузка Music Assistant»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, которые будут строиться на этих контрактах.