Возможно что так ибо я например всегда на ESP писал либо передачу в MQTT, либо Zigbree, EspHome потыкал, показалось, что больше ограничений, чем возможностей ибо условный датчик температуры можно и купить на али за 350р, а раз взялся за ESP, значит это уже что-то кастомное)
Касаемо наличия Supervisor - если к HA подключается Zigbee координатор (тот же Sonoff), то он и так будет требоваться для аддонов Zigbee2MQTT и собственно MQTT брокера. Скажем так, статья не для пользователя маркетплейсов, а для DIY энтузиастов.
ESPhome не предоставляет той возможности управления, что используется в этом решении, это больше про "коробочные решения" для получения информации с датчиков, а в данном кейсе мы эмулируем датчики в обе стороны.
"без возни с исходникам" - если хочется просто пользоваться данным решением, то возиться с исходниками и не требуется, достаточно просто прошить ESP32-C6 той прошивкой, что я выложил в общий доступ. Компиляция и прошивка описаны во второй части и делаются в 2 клика.
"разбираться с веб-интерфейсом" - вероятно вы не смотрели демонстрацию работы аддона в конце статьи, там одной кнопкой всё делается)
В общих красках установка данной интеграции не сложнее, чем установка Zigbee2MQTT (я напомню, что это тоже аддон, архитектура которого и бралась за основу)
"...в одно устройство на esp32 напихать еще каких-то компонентов ..." на самом деле никто не мешает сделать этого, ведь мы работаем с исходным кодом для ESP32 :) Да, конфигурация не как в ESPHome, но тем не менее с открытой прошивкой полная свобода действий, именно за этим я и выложил её в открытый доступ.
всё заработает без проблем, ESP хранит ключ соединения в EEPROM, координатор (колонка) понятное дело и не теряет его, поскольку это компьютер с адекватной системой хранения данных. Каждый раз, когда ESP подает по серийному порту команду инициализации (строку из бутлоадера), интеграция в ответ будет передавать информацию о каналах т.е. восстанавливать соединение, повторное связывание не понадобится т.к. связь устанавливается не с составными устройствами (каналами), а с физическим устройством (ESP). Для понимания ситуации, ESP не потеряла связи с колонкой спустя 11 месяцев лежания в тумбочке (как только подключил ESP в компьютер, она сразу установила связь с колонкой).
к Home Asisstant она подключается напрямую по последовательному порту через USB - ESP необходимо физически подключить к HA, как, например, Sonoff Zigbee Adapter.
На момент создания статьи (я всё же заканчивал цикл статей, который начал год назад) Matter еще не был в релизе и только выходил в свет, поэтому статья основана на методе Zigbee. Поскольку мне хватило реализации Zigbee, в сторону Matter я не смотрел, возможно сейчас это более удобный вариант. Как кстати обстоят дела с оффлайн управлением Matter устройств, есть где почитать информацию?
для понимания кейса, в рамках которого это и было придумано, прошу прочитать первую часть, она как раз вводная, где я описал "что зачем и почему". То, что вы предлагаете делать, требует соответствующего железа под нагрузку, конкретно в моём случае HA крутится внутри виртуалки на мини-ПК и обвешивать LLM и микрофонными массивами нет желания и возможности. Яндекс станция это уже голосовой интерфейс, который имеет вендорские фичи, как обработка звука, прослушивание и фильтрация звукового потока и в целом очень чувствительный массив микрофонов + к тому же, Яндекс станция это Zigbee координатор и было бы странно иметь настолько проработанное вендорское решение и оставить его только для того, чтобы слушать музыку. К тому же, станции в оффлайне прекрасно работают с командами для умных устройств, но только для Zigbee + именно канал zigbee хорошо подходит для локального взаимодействия между экосистемами, поскольку для двух сторон мы имитируем стандартизированное устройство.
В первой статье были уже подобные суждения, но вы все почему-то выпадаете из контекста, ведь Яндекс станция здесь не используется как ассистент, это именно голосовой интерфейс, задача которого понять какое устройство нужно включить\выключить, аспекты самого ассистента и его возможностей уже находятся за рамками данного кейса)
У многих станции расставлены по всему дому, почему же не использовать их как готовые микрофонные массивы для голосового управления Home Assistant? К тому же, имеющие независимую от HA обработку голоса и команд, что разгружает основную систему.
выгорание и заход в тупик в коде не дали до конца закончить это решение и статьи, но я собрался с силами и доделал всё :) Последняя статья будет скоро.
Товарищи ожидающие продолжения - что ж, я воскрес. Возможно продолжение уже мало кому нужно, но в течении недели-двух я выложу остальные части. Извиняюсь за столь долгую пропажу.
Почему реализация идет вокруг именно HA - Алиса без интернета имеет крайне ограниченный функционал, а в онлайн режиме информацию с неё можно получить только через интернет (об устройствах), что уже противоречит подходу оффлайн умного дома. Не стоит так же забывать, что УДЯ - коммерческий проект Яндекса, который крайне маловероятно будет иметь свободный доступ к корневому функционалу) Я пошел по пути "проще то, что имеет открытый код". Да, станция как хаб было бы хорошо, однако не стоит забывать банально о том, что она поддерживает так же ограниченный круг устройств, в то время, как Z2M расширяет диапазон девайсов, поэтому станция и идет как вторичное устройство, а не центральное.
Если хаб поддерживает оффлайн команды, то будет работать. У меня отдельного хаба нет, точно сказать не могу, но исходя из документации оффлайн сценарии хаб по-прежнему с Zigbee выполняет.
у самого Home Assistant уже есть встроенная поддержка голосовых ассистентов, но здесь всё же речь именно про станции Яндекс и их оффлайн работу с Home Assistant
Можно и через mqtt, я пошел по пути websocket в интеграции, потому что это сокращает время отклика, поскольку я не использую pub\sub подход, а напрямую делаю emit действие для устройства (подробнее будет во 2 части). MQTT более стандартизирован для таких дел, WebSocket дает побольше возможностей.
Есть и товарищ во 2 комменте сверху оставил на них ссылки и да, они только с интернетом работают. Я же реализую фичу Zigbee станций с оффлайн управлением (почему-то тут его все путают с локальным, но речь идет не про локальную сеть, а про отсутствие интернета для станции)
Matter интересная технология, о ней пока что еще мало что известно как для готового решения, поскольку всё же должна быть поддержка непосредственно в прошивке девайсов этой технологии. Здесь всё же более фундаментальная проблема в том, что HA и УДЯ являются роутерами, к тому же, например в данный момент УДЯ не умеет работать с bluetooth устройствами, как и с Wifi девайсами напрямую (нужен хаб). Аналогию я привел в одном из заголовков - HA и УДЯ являются разъёмами "мама-мама" т.е. напрямую мы не может их чисто технически никак связать, это устройства одного класса, они не умеют хранить какие-либо состояния как объекта, поэтому и нужна такая прослойка-ретранслятор в виде программируемого конечно девайса, который получается как переходник "папа-папа".
Matter это что-то вроде универсального SDK, как например Unity - один проект можно собрать и на пк, и на андроид, и на ios и в VR. Matter стандартизирует общение девайсов, но вроде как никаких новых фич он не привносит.
УДЯ получил поддержку Matter, но устройств, как и информации со стороны поддержки в HA у меня нет, поэтому эта тема остается неизвестной.
Быстрые команды - фича не связанная с оффлайн и локальным управлением. Это возможность выполнять команды, не вызывая помощника триггер-словом "Алиса". И увы, но быстрые команды не работают в оффлайн режиме. Как раз уточнение в конце 1 скриншота наводит на выводы, что они работают всё же не локально.
Касательно обратной совместимости - это побочная фича моей реализации) Через плату мы по сути подключаем в УДЯ много лампочек, а на стороне HA можно навешать on\off триггер на что угодно, так что да, по факту мы имеем возможность управлять вообще чем угодно, что подключено к home assistant в т.ч. локальные wifi\bluetooth девайсы.
на данный момент станция, насколько знаю, не умеет пользоваться пультом без интернета (он по wifi работает, а по документации поддержка в оффлайне только Zigbee устройства)
изначально идея как раз была именно такая, однако потом пришел к следующим выводам:
это довольно накладно по ресурсам т.к. придется для банальной передачи состояния вкл\выкл проводить инициализацию протокола 3 раза (для приема, потом для передачи и снова для приёма), что затратно по времени
Переключение между сетями делает крайне проблемным использование двух сетей, поскольку вы сможете отправлять по сути только одну команду за одну операцию, потому что после подачи сигнала одному каналу, ESP уйдет переподключаться и не будет слушать остальные команды
Банально нет необходимости в такой автономности, поскольку home assistant устанавливается на устройства с нормальными USB портами, что решает сразу две проблемы - задержки в передаче данных и питание платы.
Для реализации такого подхода придется писать прошивку с полного нуля без фреймворков, поскольку последние ориентированы на разработку конечных устройств и "из коробки" такого не умеют, что уже накладно по человеко-часам и ценности разработки.
Возможно что так ибо я например всегда на ESP писал либо передачу в MQTT, либо Zigbree, EspHome потыкал, показалось, что больше ограничений, чем возможностей ибо условный датчик температуры можно и купить на али за 350р, а раз взялся за ESP, значит это уже что-то кастомное)
Касаемо наличия Supervisor - если к HA подключается Zigbee координатор (тот же Sonoff), то он и так будет требоваться для аддонов Zigbee2MQTT и собственно MQTT брокера. Скажем так, статья не для пользователя маркетплейсов, а для DIY энтузиастов.
ESPhome не предоставляет той возможности управления, что используется в этом решении, это больше про "коробочные решения" для получения информации с датчиков, а в данном кейсе мы эмулируем датчики в обе стороны.
"без возни с исходникам" - если хочется просто пользоваться данным решением, то возиться с исходниками и не требуется, достаточно просто прошить ESP32-C6 той прошивкой, что я выложил в общий доступ. Компиляция и прошивка описаны во второй части и делаются в 2 клика.
"разбираться с веб-интерфейсом" - вероятно вы не смотрели демонстрацию работы аддона в конце статьи, там одной кнопкой всё делается)
В общих красках установка данной интеграции не сложнее, чем установка Zigbee2MQTT (я напомню, что это тоже аддон, архитектура которого и бралась за основу)
"...в одно устройство на esp32 напихать еще каких-то компонентов ..." на самом деле никто не мешает сделать этого, ведь мы работаем с исходным кодом для ESP32 :) Да, конфигурация не как в ESPHome, но тем не менее с открытой прошивкой полная свобода действий, именно за этим я и выложил её в открытый доступ.
всё заработает без проблем, ESP хранит ключ соединения в EEPROM, координатор (колонка) понятное дело и не теряет его, поскольку это компьютер с адекватной системой хранения данных.
Каждый раз, когда ESP подает по серийному порту команду инициализации (строку из бутлоадера), интеграция в ответ будет передавать информацию о каналах т.е. восстанавливать соединение, повторное связывание не понадобится т.к. связь устанавливается не с составными устройствами (каналами), а с физическим устройством (ESP). Для понимания ситуации, ESP не потеряла связи с колонкой спустя 11 месяцев лежания в тумбочке (как только подключил ESP в компьютер, она сразу установила связь с колонкой).
к Home Asisstant она подключается напрямую по последовательному порту через USB - ESP необходимо физически подключить к HA, как, например, Sonoff Zigbee Adapter.
На момент создания статьи (я всё же заканчивал цикл статей, который начал год назад) Matter еще не был в релизе и только выходил в свет, поэтому статья основана на методе Zigbee. Поскольку мне хватило реализации Zigbee, в сторону Matter я не смотрел, возможно сейчас это более удобный вариант. Как кстати обстоят дела с оффлайн управлением Matter устройств, есть где почитать информацию?
для понимания кейса, в рамках которого это и было придумано, прошу прочитать первую часть, она как раз вводная, где я описал "что зачем и почему". То, что вы предлагаете делать, требует соответствующего железа под нагрузку, конкретно в моём случае HA крутится внутри виртуалки на мини-ПК и обвешивать LLM и микрофонными массивами нет желания и возможности. Яндекс станция это уже голосовой интерфейс, который имеет вендорские фичи, как обработка звука, прослушивание и фильтрация звукового потока и в целом очень чувствительный массив микрофонов + к тому же, Яндекс станция это Zigbee координатор и было бы странно иметь настолько проработанное вендорское решение и оставить его только для того, чтобы слушать музыку. К тому же, станции в оффлайне прекрасно работают с командами для умных устройств, но только для Zigbee + именно канал zigbee хорошо подходит для локального взаимодействия между экосистемами, поскольку для двух сторон мы имитируем стандартизированное устройство.
В первой статье были уже подобные суждения, но вы все почему-то выпадаете из контекста, ведь Яндекс станция здесь не используется как ассистент, это именно голосовой интерфейс, задача которого понять какое устройство нужно включить\выключить, аспекты самого ассистента и его возможностей уже находятся за рамками данного кейса)
У многих станции расставлены по всему дому, почему же не использовать их как готовые микрофонные массивы для голосового управления Home Assistant? К тому же, имеющие независимую от HA обработку голоса и команд, что разгружает основную систему.
Алису (вообще статьи не про саму Алису, а про использование Яндекс Станций) используют далеко не только для управления умным домом.
выгорание и заход в тупик в коде не дали до конца закончить это решение и статьи, но я собрался с силами и доделал всё :) Последняя статья будет скоро.
Товарищи ожидающие продолжения - что ж, я воскрес. Возможно продолжение уже мало кому нужно, но в течении недели-двух я выложу остальные части. Извиняюсь за столь долгую пропажу.
Почему реализация идет вокруг именно HA - Алиса без интернета имеет крайне ограниченный функционал, а в онлайн режиме информацию с неё можно получить только через интернет (об устройствах), что уже противоречит подходу оффлайн умного дома. Не стоит так же забывать, что УДЯ - коммерческий проект Яндекса, который крайне маловероятно будет иметь свободный доступ к корневому функционалу) Я пошел по пути "проще то, что имеет открытый код".
Да, станция как хаб было бы хорошо, однако не стоит забывать банально о том, что она поддерживает так же ограниченный круг устройств, в то время, как Z2M расширяет диапазон девайсов, поэтому станция и идет как вторичное устройство, а не центральное.
полный бэкап системы сохраняет и данные интеграций, так что проблем не будет.
Если хаб поддерживает оффлайн команды, то будет работать. У меня отдельного хаба нет, точно сказать не могу, но исходя из документации оффлайн сценарии хаб по-прежнему с Zigbee выполняет.
у самого Home Assistant уже есть встроенная поддержка голосовых ассистентов, но здесь всё же речь именно про станции Яндекс и их оффлайн работу с Home Assistant
Можно и через mqtt, я пошел по пути websocket в интеграции, потому что это сокращает время отклика, поскольку я не использую pub\sub подход, а напрямую делаю emit действие для устройства (подробнее будет во 2 части). MQTT более стандартизирован для таких дел, WebSocket дает побольше возможностей.
Есть и товарищ во 2 комменте сверху оставил на них ссылки и да, они только с интернетом работают. Я же реализую фичу Zigbee станций с оффлайн управлением (почему-то тут его все путают с локальным, но речь идет не про локальную сеть, а про отсутствие интернета для станции)
Matter интересная технология, о ней пока что еще мало что известно как для готового решения, поскольку всё же должна быть поддержка непосредственно в прошивке девайсов этой технологии. Здесь всё же более фундаментальная проблема в том, что HA и УДЯ являются роутерами, к тому же, например в данный момент УДЯ не умеет работать с bluetooth устройствами, как и с Wifi девайсами напрямую (нужен хаб). Аналогию я привел в одном из заголовков - HA и УДЯ являются разъёмами "мама-мама" т.е. напрямую мы не может их чисто технически никак связать, это устройства одного класса, они не умеют хранить какие-либо состояния как объекта, поэтому и нужна такая прослойка-ретранслятор в виде программируемого конечно девайса, который получается как переходник "папа-папа".
Matter это что-то вроде универсального SDK, как например Unity - один проект можно собрать и на пк, и на андроид, и на ios и в VR. Matter стандартизирует общение девайсов, но вроде как никаких новых фич он не привносит.
УДЯ получил поддержку Matter, но устройств, как и информации со стороны поддержки в HA у меня нет, поэтому эта тема остается неизвестной.
Быстрые команды - фича не связанная с оффлайн и локальным управлением. Это возможность выполнять команды, не вызывая помощника триггер-словом "Алиса". И увы, но быстрые команды не работают в оффлайн режиме. Как раз уточнение в конце 1 скриншота наводит на выводы, что они работают всё же не локально.
Касательно обратной совместимости - это побочная фича моей реализации) Через плату мы по сути подключаем в УДЯ много лампочек, а на стороне HA можно навешать on\off триггер на что угодно, так что да, по факту мы имеем возможность управлять вообще чем угодно, что подключено к home assistant в т.ч. локальные wifi\bluetooth девайсы.
на данный момент станция, насколько знаю, не умеет пользоваться пультом без интернета (он по wifi работает, а по документации поддержка в оффлайне только Zigbee устройства)
изначально идея как раз была именно такая, однако потом пришел к следующим выводам:
это довольно накладно по ресурсам т.к. придется для банальной передачи состояния вкл\выкл проводить инициализацию протокола 3 раза (для приема, потом для передачи и снова для приёма), что затратно по времени
Переключение между сетями делает крайне проблемным использование двух сетей, поскольку вы сможете отправлять по сути только одну команду за одну операцию, потому что после подачи сигнала одному каналу, ESP уйдет переподключаться и не будет слушать остальные команды
Банально нет необходимости в такой автономности, поскольку home assistant устанавливается на устройства с нормальными USB портами, что решает сразу две проблемы - задержки в передаче данных и питание платы.
Для реализации такого подхода придется писать прошивку с полного нуля без фреймворков, поскольку последние ориентированы на разработку конечных устройств и "из коробки" такого не умеют, что уже накладно по человеко-часам и ценности разработки.
почему же не будет нормально работать?
Как интеграция реализует оффлайн управление устройствами Home Assistant голосом когда интернет отсутствует?
Не вводите людей в заблуждение, интеграция и моя реализация решают разные задачи.