Сетевой координатор Zigbee или первый шаг к резервированию сервера Home Assistant
Ранее, в статье Делаем безоблачный умный дом на базе Home Assistant я описывал, как сделать USB координатор сети Zigbee в системе Home Assistant. С тех пор на рынке появилось множество готовых координаторов, к примеру Sonoff Zigbee Dongle-P на базе чипа TI CC2652P и Sonoff Zigbee Dongle-E на базе чипа EFR32. Эти устройства не требуют дополнительных программаторов и процедуры прошивки. И казалось бы вот оно наступило счастье, но у такой конфигурации есть проблема — при выключении/зависании сервера умного дома переключиться на резервный сервер с другим координатором нельзя. Решение лежит на поверхности — нужен сетевой координатор. И ребята из ZigStar это сделали
Схема резервирования проста, ее настройку планирую описать в следующих статьях. В нормальном режиме работы вся логика умного дома выполняется на основном сервере, резервный сервер периодически пингует основной (для примера, есть несколько вариантов). Аддоны Zigbee2mqtt запущены на обоих серверах к одному и тому же сетевому координатору. Команды к координатору отправляет основной сервер.
В аварийном режиме работы резервный сервер определяет, что основной не доступен и берет на себя выполнение логики умного дома, в том числе и отправку команд на сетевой координатор.
Существует несколько вариантов сетевых координаторов: ZigStar LAN Gateway работает по LAN, но требует питание по USB ZigStar LilyZig POE поддерживает два режима работы координатора: LAN или USB, питание так же либо по USB, либо POE (по сетевому кабелю Ethernet)
Второй вариант оказался для меня наиболее интересен, так как позволяет размещать координатор практически в любом месте без привязки к розеткам. Я было дернулся его заказать, но товар в РФ не доставляется, а значит будем делать сами по инструкции автора на GitHub
Итак, характеристики устройства:
— питание 802.3af PoE или USB C (нельзя подключать одновременно POE и USB)
— чип CC2652P TI усиление +20дБ
— 2 режима работы: LAN/POE координатор или USB координатор/маршрутизатор
— передача состояния устройства по MQTT (температура, )
— поддержка Zigbee2mqtt и ZHA
— обновление прошивки с помощью программы ZigStar Multi Tool без необходимости прямого доступа к устройству.
Сборка устройства
Основой выступает готовая плата LILYGO® TTGO T-Internet-POE На на ней распаян LAN/POE и WiFi модуль ESP32, обеспечивающий сетевые функции LAN, WiFi, передачи состояния устройства по MQTT и веб интерфейс
Вторым этажом идет Zigbee плата
Плату можно заказать на производстве. Ссылка на Gerber файл для заказа
На плате необходимо распаять:
Модуль Zigbee RF-STAR RF-BM-2652P1/P2 Автор рекомендует именно этот модуль и под него вверху ссылка на плату, но есть вариант с Ebyte E72-2G4M20S1E
— порт USB Type C
— чип USB to UART и обвязку к нему CH340B. Внимание, чип нужен со встроенным кварцем, в данном случае с литерой B
— датчик температуры с обвязкой DS18B20
— DC-DC преобразователь на 3.3V AMS 1117
— SMA разъем антенны Размер разъема выбирается в зависимости от толщины платы. В моем случае это 1,6мм
Ссылка на весь BOM лист. В теории его можно загрузить на LCSC, но доставка в РФ опять же сейчас не работает, поэтому идем на Алиэкспресс.
Пайка не представляет большой сложности, все SMD компоненты типоразмера 0806 и 1210, которые спокойно паяются даже обычным паяльником.
Прошивка
В готовое устройство необходимо залить две прошивки: для чипа ESP32 и для чипа RF-STAR RF-BM-2652P1/P2
Для заливки прошивки в ESP32 необходимо установить джампер в позицию, указанную на фото и подключить ВЕРХНИЙ USB к компьютеру.
Я использую NodeMCU-PyFlasher. Открываем программу, выбираем порт и файл ZigStarGW_v0.6.8.full.bin. Версия прошивки может отличаться.
Для заливки прошивки в RF-Star необходимо установить джампер в позицию, указанную на фото и подключить ВЕРХНИЙ USB к компьютеру.
Используем программу ZigStar Multi Tool. Открываем программу, выбираем порт и файл
CC1352P2_CC2652P_launchpad_coordinator_20220219.hex (дата может отличаться). Устанавливаем галочки Erase, Write, Verify и нажимаем Start.
После окончания прошивки, для использования устройства в режиме LAN необходимо установить джампер в следующую позицию.
Перезагружаем устройство и переходим в веб интерфейс. на главной странице показан статус устройства, количество подключенных клиентов zigbee2mqtt, ip адрес и атрибуты LAN подключения, статус подключения по MQTT
Подключение к Zigbee2Mqtt
Подключаем устройство в сеть, заходим в веб интерфейс ZigStar в раздел Serial. Нас интересует открытый сетевой порт. По умолчанию это 6638
Переходим в HomeAssistant, аддон Zigbee2Mqtt. В настройках прописываем сетевой адрес и порт устройства.
Внимание, при смене координатора в подавляющем большинстве случаем придется перепривязывать устройства.
Перезапускаем аддон, привязываем устройства.
Передача статуса и состояния ZigStar в Home Assistant
Устройство передает параметры состояния по MQTT, аналогично главной странице веб интерфейса. Для этого необходимо настроить MQTT подключение к брокеру умного дома.
В Home Assistant автоматически появится устройство Zig Star. Возможные команды и сенсоры показаны на скриншоте
В итоге я показал, как сделать устройство, способное работать в режиме LAN координатора с возможностью размещения в любом месте без привязки к розеткам или серверу и обеспечивающее возможность резервирования и повышения отказоустойчивости сервера умного дома Home Assistant
В заключении небольшое видео подключения устройств к сетевому координатору.
Интересно будет почитать вторую часть, я так понимаю в итоге резервирование должно получится все-таки без последующей перепривязки устройств ко второму контроллеру. Иначе это не резервирование. Я правильно понимаю- при знании ключа сети и ключей устройств перепривязка не требуется, чтобы к резервному контроллеру перейти? Или нет?
Перепривязка будет требоваться только при замене одного координатора на другой. К примеру у вас уже есть сеть с usb координатором и вы решите его заменить на новый сетевой. При резервировании координатор физически не меняется, просто к нему подключаются два сервера. В этом случае при переключении серверов конечно никакой перепривязки не нужно
А, т.е вы про то, что координатор скорее в данном случае представляет относительно тупую железяку которая служит чисто мостом между зигби и езернетом. Меня то больше все-таки интересует вопрос- что если например вытащить и забэкапировать ключ от сети и от устройств и потом если что накатать на новое устройство- устройства автоматически подтянутся или нет. Вроде кто-то так делал (помню в комментах) и оно работало.
Да, можно. Там ограничение, по-моему, должен быть тот же или сходный чип zigbee. Т.е переезжая с CC2652P на EFR32 99% что перепривязать придется даже указав ключ
Так, а вот это уже любопытней. Т.е по идее если я сейчас соберу такой координатор на 2652, то я вполне потом смогу переехать на контроллер например от jethub который внутри тоже имеет 2652 чип без перепривязки.
Чисто теоретически самый тупой вариант резервирования серверов УД — когда два одинаковых сервера завязаны на один загрузочный диск, на котором также хранится и база данных. Если при поломке первого запускается второй — он запускается с ровно тоже системой, что и первый.
Периодическое копирование на точно такой же — хорошо помогает…
Если сделать диск-зеркало загрузочным диском для второго сервера, теоретически проблема решается.
Насколько мне известно, 100% зеркальное резервирование серверов — вполне стандартный процесс. Тем более — для производственных АСУ. Только там сервера зеркалируются в горячем резерве.
То есть узким местом станвится zigbee lan координатор. При его зависании сеть ложится.
Завесить его довольно просто. Если он останется без связи на пару часов, то уходит в коматоз. Пару раз проверено лично. Причины могут быть разные: нарушение сетевой связности, падение сервера, свича, падение электричества в разных местах.
Вы этой публикацией процитировали один из старых уроков Алекса Квазиса по отказоусточивости. У него же есть и про резервирование координатора. Правда оно срабатывает не полностью. У меня часть устройств не переключалась.
Узким местом, помимо координатора, будет, к примеру, роутер, источник питания. При проектировании отказоустойчивой системы нужно оценить вероятность отказа и потери для каждого узла (упрощенно, есть множество показателей типа rto, rpo и пр). Делать систему с доступностью 100% для дома на мой взгляд неоправданно дорого и сложно. Как я написал в начале статьи, до появления сетевых координаторов резервирование сервера, работающего с zigbee устройствами было в принципе невозможно.
Я пишу статьи, основываясь на своем опыте. Видимо он совпал с опытом Алекса.
Я написал несколько о другом. В вашем варианте остается узкое место и вероятность его отказа не нулевая.
Zigbee lan coordinator прекрасно работает как «удлиннитель» свистка (чем по сути и является). Например его удобно расположить в точке выгодного радиопокрытия, либо покрыть ещё одним координатором дополнительное помещение. В таких сценариях он прекрасно работает. Пытаться натянуть на него ещё роль резервирования… ну такое себе.
Резервирование вполне возможно и без него. Две малинки, два одинаковых свистка (с одинаковыми id). Вторая стоит в слейве и молчит. RTO минуты, потом на слейве поднимается zigbe2mqtt и работа восстанавливается на резервном сервере. RPO нас не особо интересует, конфиги синхрим при изменении. На статсистику пофиг.
Но по сути появляется томагочи, за которой надо приглядывать. Гораздо проще и правильнее повысить отказоустойчивость сервера HA. Взять вместо малинки старенький ноут. В нем и батарейка какая-никакая есть — резервируется питание. И сама платформа помощнее и понадежнее. И запас производительности есть на всякие прочие домашние нужды.
Поставил эксперимент: две raspbery pi 4, два стика на чипе cc2531. Поднял сеть из 10 устройств, скопировал папку zigbee2mqtt на вторую малинку вместе с ключами, настройками и настроенными устройствами. Отключил zigbee2mqtt на первой малинке и после включил на второй.
Итог: устройства не подключились.
Можно будет попробовать на CC2652, но это видимо позже.
там желательно было бы зашить в оба стика одинаковый ieee-адрес, они об этом писали на сайте zigbee2mqtt, что при миграции со стика на стик это нужно делать.
Только есть один нюанс- вышедший из строя источник питания несложно заменить. Роутер в принципе тоже. А вот с этими всеми зигби и звэйв возникают вопросы по резервированию- первое- из-за того несколько сложнее купить железо на замену, во-вторых вероятное попадание на перепривязку устройств (с проприетарным барахлом это стопроцентное попадание, с опенсорцным как выяснили- если чипы у координаторов разные- то опять попасть можно). А это уже не просто 4 проводка переткнуть в бп или например в роутере. Я разок уже попал на такое, правда на конкурирующем с zigbee протоколом z-wave- пришлось менять на объекте контроллер на новый, ибо старый окирпичился и перепривязывать всю кучу z-wave устройств, раскиданных повсюду (а это где-то кнопки из подрозетников выкручивать например, где-то в распайки лезть, где-то к датчикам движения на потолке). Мне хватило. Больше на беспровод не тянет. Точнее было несколько вещей, которые мягко скажем мне не понравились в z-wave (впрочем для zigbee тоже целиком и полностью эти вещи актуальны):
1)Перепривязка при сдыхании центрального контроллера
2)Отсутствие более-менее приличного функционала при биндинге (т.е при прямом управлении актуатора датчиком без центрального контроллера)- максимум это связать например кнопку выключателя с лампочкой или реле например, либо термодатчик с реле, которое например при +25 будет отрубаться. Большей гибкости не видел (в том же древнем knx гораздо гибче функционал общения устройств между собой настраивается- там часто центральный контроллер особо и не нужен)
3)мягко скажем так странная логика разработчиков в большинстве устройств- есть определенное количество намертво прибитых регистров и дальше не прыгнешь. Порой встречаешь устройства куда понапихали кучу всяких функций в регистрах, которые никому никогда не понадобятся (ну нафига например реле для штор считать сколько электроэнергии потратила штора на открытие и сколько углекислоты выбросила электростанция при открытии шторы). При этом забыть про функцию- задать жестко время открытия/закрытия, а не использовать контроль по току (действительно, кроме приводов с механическими концевиками других то не существует). Я до сих пор эту историю с кучей матов вспоминаю в сторону разрабов.
4)Вопрос к удобству монтажа и безопасности устройств, например которые прячуться в подрозетники- по удобству- зачем думать как монтажник будет прятать «умное» реле в подрозетник и расключать нули и фазы чтобы подать например ноль на реле и на лампочку, а фазу на реле, на контакт реле и на кнопку- куда я те же ваги буду впихивать, если все место релюшка с кнопкой заняли??? Глубже подрозетники не предлагать (куда уж глубже))). По безопасности- вопрос к качеству клемм часто возникает (что, разработчики вообще не в курсе что скорее всего в их хлам будут пихать кабель в 2,5 квадрата например, но при этом поставим самый лютый дешман в который больше 0,75 не забьешь без молотка, но шаг контактов такой, что и нормальные клеммы можно впаять было), к тому как сделана трассировка, к тому что релюшка внутри например на 10 ампер (и то китайских) а кто-нибудь розетку захочет коммутировать и т.д и прочее.
Ох как я вас понимаю. У меня был опыт с ПЛК Wago в качестве сердца умного дома — на него заводились все выключатели и датчики, а также диммеры и релешки в качестве исполнительных устройств. Мог настроить всё — любое поведение кнопок, любые временные характеристики, буквально — всё было настраиваемым. Сейчас живу в другой квартире, в которой электрика сделана максимально просто, но ноль во всех выключателях присутствует. Решил осваивать чудный мир zigbee. Ощущение, что большинство производителей вообще не думает ни о чём, кроме как реализовать минимальный функционал, чтобы устройство соответствовало описанию, а дальше — еб@#есь, как хотите.
В большей части устройств не реализован выбор действия после подачи питания. В большинстве встраиваемых релюшек и диммеров нет возможности выбрать тип подключаемого выключателя (с фиксацией, без фиксации) и как реагировать на выключатель с фиксацией (повторять состояние, инвертировать или флипать каждое изменение). У большей части диммеров нет переключения диммирования по переднему/заднему фронту, задания минимальной яркости. У тех же диммеров управление с логикой, сделанной чужими для хищников — нет возможности из выключенного состояния сразу включить минимальный или максимальный уровень яркости, у особо упоротых с кнопочным интерфейсом — нет смены направления яркости при отпускании клавиши (понизить яркость можно только после включения на максимальную яркость). Про совместимость (вернее, её отсутствие) между разными устройствами даже и вспоминать не хочется.
В итоге получаем, что KNX — очень дорого и требуется закладывать ещё на этапе электрики. Решения на ПЛК — максимально гибко и по деньгам сравнимо с Zigbee, но также требуется проектирование на этапе прокладывания электрики. Ну и единая точка отказа в виде самого ПЛК. Zigbee -достаточно дёшево, но всё оборудование нужно выбирать крайне тщательно и всё равно потом костылять в процессе настройки. Несмотря на распределённость и теоретическую возможность локального управления без единой точки отказа, на практике, выстроить что-то приличное, что будет переживать отказ сервера, не так-то просто. Возможно, у Z-Wave ситуация с совместимостью оборудования лучше, но с учётом разницы цен с zigbee аналогами в 2-3 раза, привлекательность резко падает. Ну и функционал не факт, что сильно лучше там (сам не работал с этим протоколом никогда).
А я вот наоборот с зигби пока не сталкивался, зато с з-вейвом сталкивался, о чем собственно выше и писал. Мне не понравилось. А я ковырял устройства от fibaro, aeotec, tkbhome и еще какие-то, не помню уже. Короче барахло задорого, имхо. Хотя в среднем настроек все-же несколько побольше чем в зигбишных устройствах судя по всему. Но я уже писал про какие бывают настройки, на примере реле для штор, тьфу.
По плк- видел тот щиток ваш, да:))) Шамановский стиль:))) Кстати, у меня квартирой в полуэкспериментальном режиме плк от Beckhoff рулит:)) По сути 750 ваги от бекхоффа и произошли:))) У меня правда модули уже по современной ethercat шине с плк общаются, а не по старой k-bus шине. Но пока кроме освещения особо ничего не заведено. Хотя как-нибудь отоплением, вентиляцией, увлажнением и прочими вещами займусь.
А по зигби- я все-таки хочу поэкспериментировать, но не в качестве рабочего решения, а так, чисто на столе поиграться, хотя есть некоторое желание реализовать одну задачку, используя зигби (но при этом мне нужно 100% уверенность, что я смогу при необходимости перенести управление с одного контроллера на другой без перепривязки, т.к у меня не будет доступа к устройствам после отладки- а точнее будет весьма затруднен). А так- тут на днях друг спрашивал по оборудованию для решения своей задачки- ему надо в паре комнат поддерживать температуру, регулируя игольчатым клапаном на батареях и нет при этом возможности проложить провода- короче изучали что по головкам и по их умению работать с внешними термодатчиками (пусть и через контроллер)- в общем, теоретически рабочее решение с большинством головок будет через одно место по факту. Посмотрим что выйдет в итоге.
Беспровод типа zigbee, да ещё и разрабатываемый в режиме «все сразу», это всё-таки не про серьезное управление. Это про быстроразворачиваемые временные сети, резервные контрольные сети, макетные решения, бытовые сети без серьезного функционала и пр.
Большинство термоголовок поддерживают передачу температуры от внешнего датчика через сервер. У меня работают и z-wave eurotronic spirit и zigbee moes. Устанавливал wifi shelly trv, тоже проблем не было
Для CC2652P около 200 устройств.
Дальность в квартирных условиях метров 10. Из одного угла квартиры в другой может не добить. Надо посередине ставить.
Не забывайте, это mesh сеть. Если есть роутеры, то через них сеть расширяется сама.
напрямую к координатору/роутеру на CC2652 до 50 девайсов, до 200 устройств это если есть роутеры(обычно девайсы запитаные от сети типа выключателей с нулем), вот тут есть табличка по каждому чипу/прошивке: github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator
Ранее, в статье Делаем безоблачный умный дом на базе Home Assistant я описывал, как сделать USB координатор сети Zigbee в системе Home Assistant. С тех пор на рынке появилось множество готовых координаторов, к примеру Sonoff Zigbee Dongle-P на базе чипа TI CC2652P и Sonoff Zigbee Dongle-E на базе чипа EFR32. Эти устройства не требуют дополнительных программаторов и процедуры прошивки. И казалось бы вот оно наступило счастье, но у такой конфигурации есть проблема — при выключении/зависании сервера умного дома переключиться на резервный сервер с другим координатором нельзя. Решение лежит на поверхности — нужен сетевой координатор. И ребята из ZigStar это сделали 
Если сделать диск-зеркало загрузочным диском для второго сервера, теоретически проблема решается.
Насколько мне известно, 100% зеркальное резервирование серверов — вполне стандартный процесс. Тем более — для производственных АСУ. Только там сервера зеркалируются в горячем резерве.
Завесить его довольно просто. Если он останется без связи на пару часов, то уходит в коматоз. Пару раз проверено лично. Причины могут быть разные: нарушение сетевой связности, падение сервера, свича, падение электричества в разных местах.
Вы этой публикацией процитировали один из старых уроков Алекса Квазиса по отказоусточивости. У него же есть и про резервирование координатора. Правда оно срабатывает не полностью. У меня часть устройств не переключалась.
Я пишу статьи, основываясь на своем опыте. Видимо он совпал с опытом Алекса.
Zigbee lan coordinator прекрасно работает как «удлиннитель» свистка (чем по сути и является). Например его удобно расположить в точке выгодного радиопокрытия, либо покрыть ещё одним координатором дополнительное помещение. В таких сценариях он прекрасно работает. Пытаться натянуть на него ещё роль резервирования… ну такое себе.
Резервирование вполне возможно и без него. Две малинки, два одинаковых свистка (с одинаковыми id). Вторая стоит в слейве и молчит. RTO минуты, потом на слейве поднимается zigbe2mqtt и работа восстанавливается на резервном сервере. RPO нас не особо интересует, конфиги синхрим при изменении. На статсистику пофиг.
Но по сути появляется томагочи, за которой надо приглядывать. Гораздо проще и правильнее повысить отказоустойчивость сервера HA. Взять вместо малинки старенький ноут. В нем и батарейка какая-никакая есть — резервируется питание. И сама платформа помощнее и понадежнее. И запас производительности есть на всякие прочие домашние нужды.
Итог: устройства не подключились.
Можно будет попробовать на CC2652, но это видимо позже.
1)Перепривязка при сдыхании центрального контроллера
2)Отсутствие более-менее приличного функционала при биндинге (т.е при прямом управлении актуатора датчиком без центрального контроллера)- максимум это связать например кнопку выключателя с лампочкой или реле например, либо термодатчик с реле, которое например при +25 будет отрубаться. Большей гибкости не видел (в том же древнем knx гораздо гибче функционал общения устройств между собой настраивается- там часто центральный контроллер особо и не нужен)
3)мягко скажем так странная логика разработчиков в большинстве устройств- есть определенное количество намертво прибитых регистров и дальше не прыгнешь. Порой встречаешь устройства куда понапихали кучу всяких функций в регистрах, которые никому никогда не понадобятся (ну нафига например реле для штор считать сколько электроэнергии потратила штора на открытие и сколько углекислоты выбросила электростанция при открытии шторы). При этом забыть про функцию- задать жестко время открытия/закрытия, а не использовать контроль по току (действительно, кроме приводов с механическими концевиками других то не существует). Я до сих пор эту историю с кучей матов вспоминаю в сторону разрабов.
4)Вопрос к удобству монтажа и безопасности устройств, например которые прячуться в подрозетники- по удобству- зачем думать как монтажник будет прятать «умное» реле в подрозетник и расключать нули и фазы чтобы подать например ноль на реле и на лампочку, а фазу на реле, на контакт реле и на кнопку- куда я те же ваги буду впихивать, если все место релюшка с кнопкой заняли??? Глубже подрозетники не предлагать (куда уж глубже))). По безопасности- вопрос к качеству клемм часто возникает (что, разработчики вообще не в курсе что скорее всего в их хлам будут пихать кабель в 2,5 квадрата например, но при этом поставим самый лютый дешман в который больше 0,75 не забьешь без молотка, но шаг контактов такой, что и нормальные клеммы можно впаять было), к тому как сделана трассировка, к тому что релюшка внутри например на 10 ампер (и то китайских) а кто-нибудь розетку захочет коммутировать и т.д и прочее.
Короче не люблю я беспровод, очень не люблю.
В большей части устройств не реализован выбор действия после подачи питания. В большинстве встраиваемых релюшек и диммеров нет возможности выбрать тип подключаемого выключателя (с фиксацией, без фиксации) и как реагировать на выключатель с фиксацией (повторять состояние, инвертировать или флипать каждое изменение). У большей части диммеров нет переключения диммирования по переднему/заднему фронту, задания минимальной яркости. У тех же диммеров управление с логикой, сделанной чужими для хищников — нет возможности из выключенного состояния сразу включить минимальный или максимальный уровень яркости, у особо упоротых с кнопочным интерфейсом — нет смены направления яркости при отпускании клавиши (понизить яркость можно только после включения на максимальную яркость). Про совместимость (вернее, её отсутствие) между разными устройствами даже и вспоминать не хочется.
В итоге получаем, что KNX — очень дорого и требуется закладывать ещё на этапе электрики. Решения на ПЛК — максимально гибко и по деньгам сравнимо с Zigbee, но также требуется проектирование на этапе прокладывания электрики. Ну и единая точка отказа в виде самого ПЛК. Zigbee -достаточно дёшево, но всё оборудование нужно выбирать крайне тщательно и всё равно потом костылять в процессе настройки. Несмотря на распределённость и теоретическую возможность локального управления без единой точки отказа, на практике, выстроить что-то приличное, что будет переживать отказ сервера, не так-то просто. Возможно, у Z-Wave ситуация с совместимостью оборудования лучше, но с учётом разницы цен с zigbee аналогами в 2-3 раза, привлекательность резко падает. Ну и функционал не факт, что сильно лучше там (сам не работал с этим протоколом никогда).
По плк- видел тот щиток ваш, да:))) Шамановский стиль:))) Кстати, у меня квартирой в полуэкспериментальном режиме плк от Beckhoff рулит:)) По сути 750 ваги от бекхоффа и произошли:))) У меня правда модули уже по современной ethercat шине с плк общаются, а не по старой k-bus шине. Но пока кроме освещения особо ничего не заведено. Хотя как-нибудь отоплением, вентиляцией, увлажнением и прочими вещами займусь.
А по зигби- я все-таки хочу поэкспериментировать, но не в качестве рабочего решения, а так, чисто на столе поиграться, хотя есть некоторое желание реализовать одну задачку, используя зигби (но при этом мне нужно 100% уверенность, что я смогу при необходимости перенести управление с одного контроллера на другой без перепривязки, т.к у меня не будет доступа к устройствам после отладки- а точнее будет весьма затруднен). А так- тут на днях друг спрашивал по оборудованию для решения своей задачки- ему надо в паре комнат поддерживать температуру, регулируя игольчатым клапаном на батареях и нет при этом возможности проложить провода- короче изучали что по головкам и по их умению работать с внешними термодатчиками (пусть и через контроллер)- в общем, теоретически рабочее решение с большинством головок будет через одно место по факту. Посмотрим что выйдет в итоге.
В zigbee2mqtt EFR еще в статусе экспериментальной поддержки. Я его тестировал и часть устройств просто не смог подключить
Дальность в квартирных условиях метров 10. Из одного угла квартиры в другой может не добить. Надо посередине ставить.
Не забывайте, это mesh сеть. Если есть роутеры, то через них сеть расширяется сама.
github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator