домашние NAS лучше в целом не открывать наружу как раз по причине безопасности данных, как говорится, если сильно захотеть, можно в космос полететь и даже современные железки сломают рано или поздно. Если и открывать, то через какие-либо middleware по типу nextcloud, чтобы не было возможности пробиться на само хранилище.
Касаемо ценовой политики Яндекса у вас есть одно важное упущение: 5940р в год это при оформлении первого года по скидке 50% как новому пользователю, далее цена уже 990\месяц, что выходит со второго года 11 880 рублей и картина уже иная.
Ну во-первых при расчетах с середины текста пошло довольно важное расхождение - диски ты посчитал 2х4Тб, а облако 1Тб. Разница в 3Тб существенная. По тарифу "для себя" доступно только до 2Тб взять, дальше тариф "для профи", который за 5Тб (по ценам с лендинга) выходит в 1583р\месяц. За 5 лет это 94 950 рубля. И тут мы по разовым платежам уже перегоняем стоимость сервера.
Старенький NAS Qnap-TS239 pro ii на б\у стоит в районе 7-14 т.р., 2 канала по 1Гбит и 2 корзины позволяют собрать аппаратный RAID1 для повышения отказоустойчивости.
Seagate Skyhawk на 4Тб с магазина стоит 16 199 ₽ x2 для рейда - 32398р. Итого на сам NAS у нас выходит 40 398 рублей. Если хотим еще и сервер приложений домой, то N100 минипк ~16 т.р. с 16Гб ОЗУ, на процессоре Ryzen (вплоть до конфигураци 8х16 ядер) ~26-30к. Полноценный сервер с большим хранилищем выйдет в районе ~ 66 398 рублей.
Qnap в активной работе потребляет до 30Вт, в простое 10-13Вт, мини-пк на Ryzen в простое 10Вт, в работе на предельной нагрузке может дойти до 40-50Вт (без участия видеочипа). Итого потребление в нагрузке всей сборки 80Вт\ч в пиковой нагрузке. В простое делим на 3. В месяц 24\7 активной нагрузки это всё сжирает 57,6кВт\ч, что при цене Московской розетки 512,64 рубля в месяц. При реальных сценариях простоя железа >50% времени в месяц цена падает еще раза в 2.
И здесь отсутствует самая важная деталь, которая на самом деле всегда будет играть в сторону домашнего хранилища: скорость доступа, безопасность данных (твой аккаунт дома не взломают, сервера не будут атакованы если не открывать порты хранилища "в слепую"), а главное, помимо простого хранилища данных эта сборка может выступить в роли медиасервера. Накатил на минипк тот же plex и у тебя есть собственный кинопоиск.
Ну и одно важное замечание: при сборке домашнего RAID1 (зеркало) нужно покупать два диска в разное время, а лучше в разных магазинах, потому что если вы купите 2 диска одновременно, будет шанс покупки дисков из одной партии, что умножает эффективность RAID1 на 0: диски одной партии будут иметь практически одинаковый срок работы, потому что RAID1 будет загружать их одинаково, что в конце их срока приведет к тому, что ваш RAID сдохнет одновременно с двух сторон.
Возможно что так ибо я например всегда на 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 устройства)
домашние NAS лучше в целом не открывать наружу как раз по причине безопасности данных, как говорится, если сильно захотеть, можно в космос полететь и даже современные железки сломают рано или поздно. Если и открывать, то через какие-либо middleware по типу nextcloud, чтобы не было возможности пробиться на само хранилище.
Касаемо ценовой политики Яндекса у вас есть одно важное упущение: 5940р в год это при оформлении первого года по скидке 50% как новому пользователю, далее цена уже 990\месяц, что выходит со второго года 11 880 рублей и картина уже иная.
Ну во-первых при расчетах с середины текста пошло довольно важное расхождение - диски ты посчитал 2х4Тб, а облако 1Тб. Разница в 3Тб существенная. По тарифу "для себя" доступно только до 2Тб взять, дальше тариф "для профи", который за 5Тб (по ценам с лендинга) выходит в 1583р\месяц. За 5 лет это 94 950 рубля. И тут мы по разовым платежам уже перегоняем стоимость сервера.
Старенький NAS Qnap-TS239 pro ii на б\у стоит в районе 7-14 т.р., 2 канала по 1Гбит и 2 корзины позволяют собрать аппаратный RAID1 для повышения отказоустойчивости.
Seagate Skyhawk на 4Тб с магазина стоит 16 199 ₽ x2 для рейда - 32398р. Итого на сам NAS у нас выходит 40 398 рублей. Если хотим еще и сервер приложений домой, то N100 минипк ~16 т.р. с 16Гб ОЗУ, на процессоре Ryzen (вплоть до конфигураци 8х16 ядер) ~26-30к. Полноценный сервер с большим хранилищем выйдет в районе ~ 66 398 рублей.
Qnap в активной работе потребляет до 30Вт, в простое 10-13Вт, мини-пк на Ryzen в простое 10Вт, в работе на предельной нагрузке может дойти до 40-50Вт (без участия видеочипа). Итого потребление в нагрузке всей сборки 80Вт\ч в пиковой нагрузке. В простое делим на 3. В месяц 24\7 активной нагрузки это всё сжирает 57,6кВт\ч, что при цене Московской розетки 512,64 рубля в месяц. При реальных сценариях простоя железа >50% времени в месяц цена падает еще раза в 2.
И здесь отсутствует самая важная деталь, которая на самом деле всегда будет играть в сторону домашнего хранилища: скорость доступа, безопасность данных (твой аккаунт дома не взломают, сервера не будут атакованы если не открывать порты хранилища "в слепую"), а главное, помимо простого хранилища данных эта сборка может выступить в роли медиасервера. Накатил на минипк тот же plex и у тебя есть собственный кинопоиск.
Ну и одно важное замечание: при сборке домашнего RAID1 (зеркало) нужно покупать два диска в разное время, а лучше в разных магазинах, потому что если вы купите 2 диска одновременно, будет шанс покупки дисков из одной партии, что умножает эффективность RAID1 на 0: диски одной партии будут иметь практически одинаковый срок работы, потому что RAID1 будет загружать их одинаково, что в конце их срока приведет к тому, что ваш RAID сдохнет одновременно с двух сторон.
Возможно что так ибо я например всегда на 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 устройства)