Часть 2: Создание пользовательского интерфейса на дисплее Guition с ESPHome и библиотекой LVGL

Привет, Habr! Продолжаем развивать интерфейс ^[1] дисплея Guition на ESPHome с использованием LVGL. Изначально планировалось просто добавить пару виджетов, но в процессе работы появилась идея кардинально изменить структуру проекта: сделать виджеты подключаемыми, вынести сущности в переменные для шаблонизации и максимально упростить использование прошивки для конечного пользователя.

Реализованный функционал

Основные возможности:

1. Главный экран: время, дата, погодные условия и температура

2. Системная информация: блокировка экрана, отображение 3 сенсоров (можно добавить больше)

3. Виджет освещения: управление 4 сущностями света с дополнительными настройками при длительном нажатии (3 режима, управление яркостью)

4. Медиаплеер: полноценное управление воспроизведением

5. Пылесос: управление роботом-пылесосом

6. Термостат: управление отоплением (используется реле устройства)

7. Кондиционер/вентиляция: климат-контроль (используется реле устройства)

8. Рольставни: управление (легко адаптируется для ворот или штор)

Настройки:

• Мультиязычность: автоматические переводы из Home Assistant для состояний погоды, пылесоса, термостата, кондиционера/вентиляции, рольставней

• Подсветка экрана: настройка яркости

• Энергосбережение: таймер отключения экрана

Необходимые компоненты

Для работы прошивки требуется установка кастомного компонента ^[2], который обеспечивает:

• Получение переводов

• Отображение обложек для медиаплеера

Есть также кастомный компонент ^[3] для получения фронтенд-переводов при разработке собственных интерфейсов для Home Assistant (например, на Vue), если кому интересно.

Основные ограничения и проблемы

Аппаратные ограничения

Главная проблема заключается в том, что возможности железа этого устройства крайне ограничены. Текущие микроконтроллеры (ESP32-P4 уже значительно лучше) не очень подходят для тяжелых графических задач. Несмотря на все первоначальные амбиции, приходится сталкиваться с ограничениями как по железу, так и по самому ESPHome, который изначально не задумывался для подобных задач, хотя в последнее время активно расширяет свой функционал.

Проблема динамических сущностей

Изначально хотелось сделать сущности выбираемыми из экранного меню, чтобы пользователю не приходилось править код. Удалось даже реализовать список с получением сущностей из ESPHome и вызов служб (например, включение/выключение света).

Однако проблема поджидала в сенсорах: ESPHome не умеет динамически подписываться на сущности и вообще не может отписываться от них, поскольку такой функционал не предполагался концепцией. Можно написать кастомный компонент, но, как сказал разработчик ESPHome, это потребует изменений в ядре ESPHome и ядре Home Assistant. В итоге от этой идеи пришлось отказаться.

Ограничения памяти

Следующая проблема — память. Несмотря на наличие почти 8 МБ PSRAM помимо SRAM, всё равно приходится ограничивать и оптимизировать ресурсы.

Пример: пришлось убрать красивые картинки рольставней и заменить их на глифы, поскольку одна картинка занимает около 200 КБ памяти (300×300×2 + накладные расходы на прозрачность). При необходимости использовать 11 таких картинок общий объем превысил бы 2 МБ из доступных 8. Сильно уменьшить разрешение нельзя, так как картинки используются в виде слайдера.

Синхронность vs асинхронность

ESP32 в ESPHome работает в синхронном потоке ("main loop"). Если что-то не позволяет обработать цикл за 5 секунд, ESP32 считает устройство "зависшим", срабатывает watchdog, происходит перезагрузка и так по кругу.

Проблемная ситуация: множество сенсоров (sensor, text_sensor для различных атрибутов) при загрузке начинают получать данные по API от Home Assistant. В большинство сенсоров добавляются действия при получении данных — это могут быть сложные скрипты (парсинг, вычисления). Да, сами скрипты работают асинхронно, но в этом тоже есть свои плюсы и минусы. Большое количество асинхронно выполняющихся скриптов может вызывать переполнение памяти, а при синхронной обработке нам просто не хватит времени до срабатывания watchdog.

Проблема "задвоенности" скриптов

Еще одна проблема — дублирование выполнения скриптов при восстановлении процессов после отключения питания:

• on_boot (при загрузке ESP32)

• on_client_connected (при подключении к API)

Особенность: при перезагрузке устройства срабатывают оба события, но при прошивке — только on_boot (API при перепрошивке не теряется!). И если в скриптах прописывается изменение состояния, то наличие скрипта и в on_boot и в on_client_connected приведет к совершенно другому результату, чем ожидалось.

Оптимальное решение — использовать только on_client_connected для готовой прошивки, но на этапе тестирования приходится использовать on_boot или каждый раз перезагружать устройство после прошивки.

Планы на будущее

В ближайшее время планируется работа с новым устройством ^[4], которое уже получено, но инструментарий для ESPHome пока не готов. Характеристики самого устройства отличные:

• ESP32-P4 — мощный микроконтроллер

• 32 МБ PSRAM

• RGB888 (наконец-то нормальные градиенты и тени!)

• Микрофон и динамик

• Ethernet

Хотелось бы видеть PoE или питание 220В вместо RS485 и DC, но пока довольствуемся тем, что есть.

Заключение

⚠️ Важно: Прошивка находится в стадии беты. Присутствуют некоторые баги, а отдельные виджеты тестировались на демо-сущностях из-за отсутствия реальных устройств.

Буду рад получить обратную связь от сообщества! Если проект окажется полезным, буду благодарен за звездочку на GitHub.

Ссылка на проект ^[5]