Платформа Home Assistant считается одним из лучших решений для умного дома, однако регулярные обновления нередко привносят изменения, способные нарушить привычную работу системы. Одной из таких проблем для пользователей со сложными конфигурациями стало появление системных и пользовательских панелей управления по умолчанию, представленных в релизе 2025.12. Данное нововведение оказалось удобным для простых домашних сетей с одним пользователем, но создало трудности для тех, кто задействует сразу несколько экранов на разных устройствах. После обновления исчезла возможность закреплять конкретные панели за определенными устройствами, а создание отдельной учетной записи для каждого экрана выглядело избыточным.
Первоначальный поиск решения привел к материалам сообщества Home Assistant, где предлагался пользовательский боковой элемент на базе JavaScript-файла. Скрипт нужно было поместить в директорию config/www/dashboard/ и зарегистрировать через параметр panel_custom в конфигурации. Этот метод позволял сформировать выпадающее меню со списком доступных панелей, сохранять выбор в локальном хранилище браузера и сбрасывать серверные настройки по умолчанию, возвращая систему к старому методу определения предпочтений. На практике готовое решение оказалось сырым и содержало четыре скрытых бага.
Четыре ошибки в скрипте и способы их устранения
Первая проблема заключалась в сохранении старого значения по умолчанию на уровне системы. Платформа Home Assistant проверяла этот параметр раньше, чем локальное хранилище браузера, поэтому остаточные данные всегда перекрывали изменения. Вторая ошибка крылась в коде инициализации, который считывал LitElement из прототипа customElements.get(«ha-panel-lovelace»). Этот элемент регистрировался только после открытия реальной панели Lovelace в текущей сеансе, из-за чего прямой переход настраивал пустую страницу и генерировал ошибки в консоли.
Третий сбой касался компонента выпадающего списка ha-select, который обновился в системе и стал распознавать только автогенерируемые элементы через события нового компонента Web Awesome. Наконец, четвертой проблемой стало агрессивное кэширование файлов со стороны Home Assistant, из-за которого браузер продолжал выполнять старую версию скрипта на протяжении срока до 31 дня, игнорируя принудительное обновление.
Исправление ошибок и настройка кэширования
Для устранения этих багов потребовалось поочередно выполнить ряд ручных операций. Остаточное значение default_panel было удалено с помощью прямого WebSocket-вызова к frontend/set_system_data с последующей проверкой. В вопросе инициализации ссылку изменили так, чтобы элемент LitElement запрашивался из home-assistant-main, который присутствует в оболочке приложения независимо от способа навигации.
Выпадающий список потребовал переработки с передачей доступных панелей через свойство .options компонента ha-select, а выбор считывался через ev.detail.value. Проблема с кэшированием решилась добавлением суффикса ?v=2 к параметру module_url в конфигурационном файле configuration.yaml с последующим перезапуском системы, что заставило все устройства загрузить актуальную версию скрипта.
Модифицированный скрипт, конфигурационный фрагмент и подробный разбор возможных трудностей опубликованы в репозитории на GitHub. Для большинства пользователей достаточно скопировать файл device-default-dashboard.js и добавить необходимые строки в конфигурацию либо установить решение через менеджер HACS. Несмотря на то что данный метод остается неофициальным обходным путем, он возвращает гибкость при работе с несколькими экранами умного дома.
Релиз Home Assistant 2025.12 принес системные и пользовательские панели по умолчанию, которые отлично подошли для простых конфигураций с единственным пользователем. Однако для пользователей со сложными экосистемами, управляющих несколькими экранами на различных гаджетах, обновление превратилось в серьезную проблему из-за утраты функции привязки дефолтной панели к конкретному устройству.
Попытка решить задачу через создание отдельных учетных записей под каждое устройство выглядела нелогичной, поэтому энтузиаст обратился к комьюнити-форуму Home Assistant. Там нашлось потенциальное решение в виде кастомной боковой панели — JavaScript-файла device-default-dashboard.js, размещаемого в каталоге config/www/dashboard/ и регистрируемого через panel_custom.
Данный инструмент добавляет в боковое меню выпадающий список со всеми доступными панелями управления. При выборе конкретного варианта скрипт сохраняет выбор в локальном хранилище браузера (local storage) и одновременно очищает новые серверные настройки по умолчанию. Это заставляет Home Assistant переключаться на старый, проверенный метод определения пользовательского представления для каждого отдельного браузера, который поддерживается и в актуальной версии платформы.
Тем не менее, найденный в открытом доступе скрипт работал некорректно и содержал сразу четыре скрытые ошибки, которые маскировали друг друга:
- Устаревшее системное значение по умолчанию. Платформа сохраняла старый параметр default_panel, заданный для учетной записи до установки скрипта. HA всегда проверяет этот серверный параметр в первую очередь, поэтому локальное хранилище браузера игнорировалось.
- Проблема с инициализацией (bootstrap). Исходный код считывал LitElement через прототип customElements.get(«ha-panel-lovelace»). Этот элемент появляется в памяти браузера только после того, как пользователь предварительно откроет стандартную панель Lovelace за текущую сессию. Прямой переход на кастомную панель из свежей вкладки приводил к пустой странице и ошибкам TypeError в консоли.
- Некорректная работа компонента ha-select. Разработчики Home Assistant переписали этот компонент, привязав его к новому внутреннему решению Web Awesome. Обновленный элемент распознает исключительно собственные автогенерируемые дочерние элементы и реагирует на событие wa-select, в то время как старый скрипт пытался строить список вручную.
- Агрессивное кэширование на стороне сервера. Платформа раздает файлы из директории /local/ с кэшированием сроком до 31 дня. Динамический импорт ES-модулей далеко не всегда корректно реагирует на принудительное обновление страницы (hard refresh), из-за чего браузер продолжал выполнять устаревший код.
Для устранения этих багов потребовался комплексный подход и пошаговая отладка:
- Остаточное значение default_panel было стерто с помощью прямого WebSocket-запроса frontend/set_system_data, после чего корректность удаления проверили повторным чтением системных данных.
- Для обхода проблемы с загрузкой ссылку на LitElement перенаправили на home-assistant-main. Этот компонент гарантированно присутствует в общей программной оболочке приложения независимо от того, как именно пользователь открывает страницу.
- Выпадающий список переписали: доступные панели передаются через собственное свойство .options элемента ha-select, позволяя компоненту самостоятельно генерировать элементы интерфейса, а выбранное значение считывается через ev.detail.value, аналогично официальному селектору панелей в Home Assistant.
- Проблему с кэшем решили добавлением суффикса ?v=2 к параметру module_url в конфигурационном файле configuration.yaml с последующей перезагрузкой системы. Это заставило все гаджеты в сети запросить новый URL вместо загрузки старых файлов из кэша.
Модифицированный файл скрипта, пример конфигурационного фрагмента и детальный разбор возможных подводных камней автор опубликовал в отдельном репозитории на GitHub. Установить исправление можно как вручную (скопировав файл и обновив конфигурацию), так и через менеджер пакетов HACS.
