Pull to refresh

Comments 31

Одни технологии, такие как Zigbee и Z‑Wave, Thread, ориентированы на построение устойчивых и масштабируемых Mesh‑сетей, в то время как другие, например Matter и Wi‑Fi

Не совсем так. Espressif предлагает для WiFi поддержку ESP-MESH и ESP-MESH-LITE. При этом я вижу устойчивую дальность в своей деревне до 600 метров. Так что для загородного применения, когда участок 20 соток или более, WiFi, особенно с ESP-NOW, может быть заметно предпочтительней, чем ZigBeе или BLE.

Благодарю за весьма интересный опыт, не сталкивался с заводскими интерпретациями mesh сетей для IOT тройств на основе wi-fi, поделитесь своими впечатлениями от использования данной прошивки:

  1. Какие у вас в ней устройства, стоятельные собранные на Arduino подобных конструкторах компонентов или перпрошитые заводские вроде SONOFF?)

  2. Как много устройств, не будут ли 10-20 устройств замедлять и создавать помехи в основную wi-fi сеть, они же вероятно забивают все свободные каналы и опрашиваются каждые N секунд.

  3. Что думаете об использовании подобных решений в многоквартирных домах? По моей практике часто wi-fi устройства вроде терморегуляторов или умных выключателей света обладают крайне слабым приёмником и будучи установлены куда-нибудь в подрозетник бетонной стены с арматурой могут терять связь с роутером уже через две комнаты.

За городом бывает использую единичные Wi-Fi устройства для удаленных точек, вроде откатных гаражных ворот, но не в режиме Mesh а в обычной Wi-Fi сети.

Если уж совсем дотошно подходить и нужно добивать сигнал в дальние концы участка, в условную беседку с освещением, у того же Shelly есть модули с LoRa, работающие в отличном от Wi-Fi диапазоне частот и не забивающие основную сеть.

не сталкивался с заводскими интерпретациями mesh сетей для IOT тройств на основе wi-fi

Я тоже. Так как до сих пор отсутствует поддержка EPS-MESH/ESP-MESH-LITE в HA/ESPHome. Если с ESP-MESH проблема понятна, то в ESP-MESH-LITE каждый узел получает свой IP адрес у роутера, пусть даже через корневой узел. Так что я затрудняюсь сказать, что мешает реализовать его поддержку в ESPHome.

Какие у вас в ней устройства

Сейчас все устройства на ESP32-C3 и все прошитые моим же кодом. Управление пока только по HTTP непосредственно через веб-сервер в ESP32.

Как много устройств, не будут ли 10-20 устройств замедлять и создавать помехи в основную wi-fi сеть, они же вероятно забивают все свободные каналы и опрашиваются каждые N секунд.

Тестировал пока только 10 ESP32-C3 так больше у меня нет. Опрос из js каждую секунду в 10 вкладках браузера, вполне совмещался с полной загрузкой WiFi торрентом с ноутбука. Но у меня они не пересекаются, так как ноутбук 802.11ac 5ГГц, а ESP32 802.11g 2.4ГГц.

Видно, что AP в узлах ESP-MESH-LITE предпочитают другие каналы, чем у WiFi роутера. Соответственно, мешать ему они ему вряд ли могут.

Сам Espressif пишет следующее:

Below are some common performance metrics for the ESP-MESH-LITE network:

  • Provisioning time: < 60 seconds

  • Repair time

    Root node disconnection: < 50 seconds

    Child node disconnection: < 45 seconds

  • Per-Hop delay: 8 to 12 ms

Notes

  • The test conditions for the above performance metrics are shown below.

    • Number of test devices: 50

    • Maximum number of downstream connections allowed: 6

    • Maximum number of layers allowed: 6

Что думаете об использовании подобных решений в многоквартирных домах?

Смотря насколько забит диапазон 2.4ГГц. Где-нибудь в общежитии с гипсокартонными стенами это может быть проблемой.

По моей практике часто wi-fi устройства вроде терморегуляторов или умных выключателей света обладают крайне слабым приёмником и будучи установлены куда-нибудь в подрозетник бетонной стены с арматурой могут терять связь с роутером уже через две комнаты.

Сам Espressif именно на это и упирает.

По моей практике часто wi-fi устройства вроде терморегуляторов или умных выключателей света обладают крайне слабым приемником и будучи установлены куда-нибудь в подрозетник бетонной стены с арматурой могут терять связь с роутером уже через две комнаты.

У меня есть два типа карточек с esp32c3. Одна карточка с нормальной антенной, а вторая с миниатюрной керамической. Керамическая в разы хуже. Хотя в интернете я видел как припаять 3.5 мм длинны антенну к керамической, то тогда прием становится более адекватным.

С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов. А вот такой и такой модули до 600 метров прямой видимости цепляются к AP и работают устойчиво даже сквозь лобовое стекло автомобиля, лежа на торпеде.

Я как раз говорил про эти карты.

Про керамическую антенну есть интересный ролик на youtube

https://www.youtube.com/watch?v=UHTdhCrSA3g&t=1s

при помощи кусочка провода и паяльника можно существенно улучшить прием/передачу.

А смысл? Ради 20 рублей экономии тратить время на такой колхоз не оправдано даже школьнику или пенсионеру. Я понимаю ещё тех, кто уже нарвался на такое чудо. Но зачем намеренно искать себе приключения?

Не в обиду будет сказано, но ваш ответ мне напоминает ответ чиновников, которые говорили, зачем нам развивать промышленность, у нас полно нефти. Мы все купим.

А написал я тот комментарий для информации, думал вам интересно будет. Мне это показалось интересным. Но видимо вам нет.

Не в обиду будет сказано, но я даже не предполагал, насколько дешево Вы цените собственное время.

Исходя из того, что изготавливать и паять антенну, как минимум 5 минут, то получается, что час Вашей работы стоит не более 240 рублей. Напишите в личку. По такой часовой ставке я найду для Вас просто море работы паяльником.

думал вам интересно будет

Вы знали, что это не так, так как я написал: "С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов."

но является закрытой платформой с ограниченным набором функций и привязкой оборудования к региону

Aqara активно выпускает новые устройства и обновляет старые для поддержки Matter и Thread

Для поддержки Thread устройство должно обладать соответствующим радиочипом, а по Matter да, акаровские шлюзы умеют общаться транслируя собственные устройства.

А теперь представим простую ситуацию чтобы добавить Matter регулятор теплого пола в систему с акарой. И настроить на нем расписание работы. Возможно сделать калибровку датчика. Увы пока что это так не работает.

Не говоря уже о более сложной инженерии, вроде систем вентиляции, канальных кондиционеров, внутрипольных конвекторов отопления с вентиляторами, да даже просто проводных, скрытых в коллекторе отопления термоголовок для обычных радиаторов батарей, чтобы не обслуживать их каждые полгода.

Так что по моему опыту - Акара это больше для готового ремонта самые базовые функции. Хотя беспроводные датчики у них симпатичные, бесспорно.

Для поддержки Thread устройство должно обладать соответствующим радиочипом

Это одни и те же радиочипы. Zigbee, Thread деривативы IEEE 802.15.4, конкретный протокол определяется прошивкой. Напрмер в терминах Nordic это все soft device

добавить Matter регулятор теплого пола в систему с акарой. И настроить на нем расписание работы. Возможно сделать калибровку датчика. Увы пока что это так не работает.

Что именно не работает? Увы нет у меня теплого пола что бы проверить. Но по ченьжлогу обновлений М3 хаба каких только типов устройств не видел.

Теория это все конечно хорошо. Но вы видели хоть один пример заводского обновления прошивки у Zigbee устройства, чтобы оно стало поддерживать новый стандарт Thread? Смею предположить что и не увидите.

Как раз пишу в статье что не только базовыми типами устройств системы едины, но и дополнительными настройками внутри датчиков и исполнительных модулей, которые пока что в основном работают в рамках только своей экосисиемы.

Поэтому автор и предлагает подход использования фирменных хабов с заведомо совместимыми устройствами со всеми дополнительными настройками, применяя технологию Matter для транслирования этих устройств на внешние центры управления вроде умных колонок, используя хаб в режиме моста. Так оно дешевле и надежнее получается, пока что.

Похоже кто-то топит за "пропиетарные облака". Ну т.е. НА плохой потому что за него отвечать надо, а что-то работающее где-то держат на своих плечах придуманные атланты :).

"Нет - нам этого не нать" :)

Облака по большей части сейчас используются для пуш уведомлений и удаленной работы мобильного приложения, основная логика взаимодействия устройств в основном находится на самих хабах. За исключением специфических функций вроде расчета времени заката на основе территориального расположения пользователя и некоторых других вещей. Также такие хабы умеют отдавать данные локально по протоколам Matter и HomeKit и подключаться к умным колонкам и центрам управления без облака.

Конечно, это не отменяет существования DIY-сегмента и возможности поднимать собственные серверы. Но важно делать это осознанно — понимая все риски, принимая на себя ответственность за стабильность и готовность тратить время на поддержку такой системы в рабочем состоянии.

Часто ко мне обращаются люди без технического бэкграунда, но с запросом реализовать «открытую систему», без понимания, как она устроена внутри. Уверен, среди читателей тоже найдутся те, кто только начинает свой путь в умном доме — надеюсь, статья и комментарии помогут составить полную картину того как оно работает.

Никакой умный дом не сможет быть умнее, чем тот кто его обслуживает. Бесспорно "деньги сами себя не заработают" и приходится продавать что-то и тем, у кого нет технического бэкграунда и желания в это всё вникать. И даже не всегда всё это будет навыброс. Даже с пропиетарными системами можно жить. Но это как повезет. И повезет или нет от вас увы не зависит.

Полная картина проста: если вы хотите контроля и надежности - вам придется вникнуть. И лучше бы собрать всё на открытых решениях. Ну т.е. если вам нужна долговременная стабильность. И да, придется всё это обслуживать.

Если вы не хотите вникать и обслуживать, то лучше ничего не покупать, а потратить деньги на что-то другое. Если "очень надо", то можно купить что-то "как бы готовое" но с полным пониманием, что окирпичиться может в любой момент, и вряд-ли проживет более 3-5лет.

И да, придется всё это обслуживать.

И за чей счёт банкет? С точки зрения поставщика решения, обслуживать открытые решения существенно дороже, чем закрытые проприетарные. Хотя бы потому, что пользователь рано или поздно влезет туда своими шаловливыми ручками. Ведь всё открыто и доступно.

Если вы не хотите вникать и обслуживать, то лучше ничего не покупать

Вот только есть пользователи, которые не хотят вникать и обслуживать, но хотят покупать. Предлагаете им отказывать?

Люди разные. Потребности, возможности, желания и навыки у людей тоже разные.

Кто-то согласен жить с тем же ESPHome, потому что ему не сильно мешает одна из полутора тысяч известных проблем и не требуется одна из полутора тысяч новых возможностей (количество смотрю по GitHub).

А мне и без открытых решений хорошо, так как мне проще написать свой код и его поддерживать, чем разбираться с исходниками тех же HA и ESPHome, чтобы туда коммитить. Зато обхожусь без центрального сервера и у меня нет единой точки отказа.

А кто-то просто хочет, чтобы у него всё работало и готов платить за поддержку, чтобы самому не вникать. Точно так же, как не вникают в работу системы вентиляции и кондиционирования, домофона или автоматического шлагбаума.

Конечно ваш банкет оплатит пользователь. Тот самый, который не хочет вникать и у которого потом всё окирпичится и вы ему все тоже самое второй раз продадите :). Выж хороший, а это вендоры плохие....

При таком подходе любые открытые решения - это огромная опасность. Можно недополучить кучу денег...

Совершенно не понимаю, когда поводом для гордости начало быть "я не вникаю"....

Если пользователь захочет платить в разы больше за поддержку открытого решения, то почему бы и нет? Как раз наоборот, это возможность существенно увеличить выручку. Вот только таких пользователей слишком мало, чтобы даже десятикратное увеличение стоимости поддержки смогло окупить содержание собственного отдела разработки.

Сами посчитайте. Стоимость содержания отдела разработки - 2-3 миллиона рублей ежемесячно. А большинство внедренцев имеют клиентскую базу до тысячи заказчиков. Вы сами согласитесь платить за поддержку 3-5 тысяч рублей ежемесячно, чтобы не вникать и только пользоваться IoT, как домофоном или шлагбаумом?

Это лекарство очень дорогое, поэтому мы продадим вам другое, подешевле. Правда оно совершенно не лечит, но это ваши, а не наши проблемы...

Это лекарство очень дорогое

Вы лично готовы вложить 30-40 миллионов рублей в такой бизнес, чтобы продержаться хотя бы год до весьма маловероятного выхода на самоокупаемость? Если нет, то почему Вы считаете, что кто-то другой должен это сделать?

совершенно не лечит

Врать не надо. Проприетарные решения работают у миллиардов людей. И у Вас в том числе. Или у Вас в автомобиле open source прошивка в ЭБУ? )))

Вы так и не поняли основной пойнт? Он в том, что некоторую работу нельзя сделать хорошо. Поэтому лучше за нее денег не брать и ее не делать...

Про авто я многое мог бы сообщить. Но сухой остаток простой: лучше бы он был аналоговым. Гораздо лучше... Это как-раз пример того, в какую жопу попадают люди доверившись пропиетарным решениям...

Ответьте на заданные мной вопросы, а после этого я буду отвечать на Ваши.

А у меня нет к вам никаких вопросов. Мы уже прояснили ситуацию как вы и хотели.

Ну что же, я рад, что до Вас наконец-то дошло, что поддержка open source обходится намного дороже, чем поддержка вендора. Что, собственно говоря, и объясняет, почему тот же Linux в корпоративных кругах широко распространен, а в SOHO встречается очень редко. Первые могут позволить себе содержать штат для поддержки open source решений, а вторые - нет.

К сожалению ни одна готовая экосистема из описанных в статье не позволяет закрыть все потребности автоматизации, например нет счётчиков воды, электричества (поверенных), тепла, а отсюда и DIY устройства, HA.

У меня в доме HA и более 30 WiFi устройств, в основном eshome, но это для "тех кто в теме". А вот сыну в квартиру пытаюсь собрать систему на zigbee и Яндексе, чтобы автоматизацию счётчиков сделать через tasmota matter и не ставить HA

Что вы имеете ввиду под автоматизацией счетчиков? Автоматическую передачу данных в личные кабинеты поставщика электроэнергии и водоканал? Для этого есть специализированные решения вроде SAURES.

А в современных ЖК счетчики устанавливаются за пределами квартиры в красивых нишах с декоративными дверцами и подключены в систему самой управляющей компании, в более простом исполнении сами сотрудники делают ежемесячный обход и вносят значения вручную, без привлечения жильцов.

Zigbee

Популярный стандарт связи для умного дома, работает в сети Mesh (каждое устройство может ретранслировать сигнал).

Вот прям каждое? Вы не знаете или случайно написали?

ТОП производителей умного дома

Акара и Туя - не производители, а провайдеры экосистем. И если акара еще следит за производителями, то Туя просто предоставляет сервис, железяки могут быть сильно разные по качеству.

Соноф - не только вайфай, у меня сонофовские зигби-датчики есть.

ХА - не производитель вообще.

Пассаж про проблемы с обновлением ХА - мимо. Не хочешь проблем и все устраивает - не обновляйся. Обновляешься - делай бекап средствами ОС, если не пошло - откатись полностью.

Благодарю за внимание к деталям и формулировка в статье, внес уточнения. Все же статья и так получилась довольно большой и имеет ознакомительный характер чтобы углубленно вдаваться в принципы маршрутизации внутри Mesh сетей с зависимостью от типа устройства, схемы его питания и версии протокола. Не говоря уже про особенности ODM производства оборудования.

В остальном соглашусь с вами, что нужно вдумчиво подходить к выбору элементов оборудования умного дома и не гнаться за дешевизной NoName датчиков, даже если на них стоит логотип совместимости с определенной системой.

У Сонофф действительно есть зигби датчики, также как у других производителей есть вайфай устройства, но все же основная часть оборудования этой экосистемы на вайфай с открытым АПИ, в этом фишка данной системы и облегченность интеграции ее в другие платформы. Аналогично у Шелли, но дороже, зато более функциональнее.

ознакомительный характер чтобы углубленно вдаваться в принципы маршрутизации внутри Mesh сетей 

Это важно. Идет человек по дому, рассыпает батарейные датчики в надежде что они меш. А они нихрена не меш, они клиенты. Ну ок, начитался особо умного интегратора что надо добавить проводных устройств чтоб были роутерами. Поставил реле без ноля - хоп, а они тоже чисто клиенты. А если бы сразу прочитал что функционал роутера только у устройств с постоянным питанием - не гадил бы себе на голову.

Не говоря уже про особенности ODM производства оборудования.

А это тоже важно, особенно если строишь сеть на проприетарных решениях. Потому что туя туе точно рознь.

У Сонофф действительно есть зигби датчики, также как у других производителей есть вайфай устройства

И снова это важно. Не для соноффа, им кажется не диайвайщики не пользуются, а вот для акары - точно. У меня был знакомый, который купил вайфайную лампочку и дивился почему она не роутит зигби.

Хотелось бы увидеть примерную архитектуру умного дома с сопряжением сети wi-fi для выхода в интернет и локальной сети zigbee.

Sign up to leave a comment.

Articles