Спасибо за детальный ответ, прослеживается большой опыт в интеграции беспроводных решений!
Поддержка современных адаптеров действительно важный критерий, с этой стороны вполне объясняется как поддержка устройств(хотя считал что софт работающий с адаптером решает эту задачу, юудто проткоол один и гораздо реже обновляется, ну лан), так и производительность в том числе.
Тут с вами согласен, но по наблюдениям шкафчик открыт или закрыт, выносная антенна или без нее, не было практически никакой разницы, возможно в других инсталляциях это было бы юолее весомым фактором, например если контроллер в щитовой, то зигби там и останется). У вас есть на примете координаторы с poe питанием? С выбором устройств тоже подностью согласен
Да
Очень интересная архитектуру вы выбираете при наладке, у вас разные сети зигби на разных каналах, разбросанные по разным частям объекта, объединены одной железкой с N usb портов и внутри крутятся несколько z2m, видимо вы на этом собаку съели. По рпи, то он на ссд.
Теперь чуть больше стал понимать работу устройств. А по поводу проводов, то мы знаем какие основные причины выбора беспровода, да и хочется уметь и иметь понимание работы, а не просто кнопки тыкать.
Да, было удивлением такое наблюдать, что есть скрипты, которые запускаются и находятся в директории которая не описана в документации. А так на wb-rules js используется))
Слышал что адаптер wb не самое надежное решение, исходя из этого выбрал сонофф, НО еще нигде не видел точного сравнения двух адаптеров. Слышал позитивные отзывы об адаптере jethome, да и сам в целом был доволен им, только на неюольших инсталляциях
Сам выбор контроллера wb или raspberry pi не имеет никакого значения, нужна была железка с портом usb. Более важным в ходе работ оказался тип монтажа, rpi можно поставить на стол)
С версиями ПО z2m согласен, одной из ошибок было установка не с гита. По поводу адаптера, слышал что обновление на вб помогает, но не в моем случае, к сожалению.
спрутхаб тоже не имеет значение во всем этом тесте, поскольку использовался только в рамках mqtt
Надеюсь вы поделитесь опытом и подскажите какие решения более релевантны.
Утилита tshark сможет смотреть что приходит с адаптера? или вы что-то другое имеете ввиду? Я написал программу которая фиксирует в эксельке linkquality всех приходящих сообщений по мктт, но это уже после работ, т.е. весь анализ построен на наблюдении.
В z2m есть функционал группы устройств, не разбирался с его работой. А под логической имел ввиду объединение устройств в сценарной машине по триггеру например.
Да, спасибо. Подскажите у вас есть понимание как этот механизм работает? Я считал что только полное отсоединение от текущего родителя сети запускает этот процесс.
В проделанной мною работе очень часто не хватало метрик, это было основной загвоздкой что отталкивает большинство интеграторов. Все сравнивал наблюдением, только после работ написал программу которая подписывается на все топики от z2m и выводит linkquality по устройствам в таблице, может пригодится:
Координатор не управляет маршрутизацией, согласен, но он включает режим сопряжения и указывает какое устройство именно будет входить в этот режим. Может вы знаете как именно принимается решение о перестройке, у меня информация что только при полном отсутствии сети и ее возобновлении. Соответственно перезапуск адаптера/софта/устройства пересоберет сеть, связанную с этим устройством.
Тут очень важным отличием является используемый софт (zha vs z2m), а также взаимное расположение устройств. Также использовал сонофф адаптер + распбери. Ксати, вспомнил что некоторые китайцы, в частности мои датчики движения, очень часто шлют сообщения, интересно есть ли возможность указать что только по изменению статуса движения необходимо отправлять сообщение? Это вполне может влиять на пропускную способность.
Я изучал этот вопрос, но не всегда устройство-триггер и устройство-исполнитель заведены в z2m, соответственно решил выбрать единую "сценарную машину". Например, кнопка на сухом контакте подключенном по GPIO в WB а свет или штора zigbee.
Да, можно в z2m указать конкретное устройство-роутер через которое планируем подключать. Но по наблюдениям версия старая v2.5.1 пыталась всячески игнорировать пожелания, тогда как в новой все строилось именно так как планировали. Отмечу что "автоматическая" перепривязка устройств происходит после полной потери устройства из сети, но более точно ответить не смогу, поскольку плотно не занимался этим. Кстати из этого вытекает интересный факт, после полного отключения того же контроллера-адаптера сеть перестроится как ей хочется(надо уточнить) и положение адаптера в географическом центре остается единственным важным фактором при перестройке.
Да, процесс перекладки топиков из формата wb в z2m сожрал все ресурсы что были.
После такого опыта у меня наоборот пропала неприязнь к zigbee, тут важно сразу учесть много факторов, как и в любом проекте. Обычно все отказывает работать, если клиент хочет подешевле, тогда по комментарию выше вероятность наладки системы резко снижается.
Спасибо за детальный ответ, прослеживается большой опыт в интеграции беспроводных решений!
Поддержка современных адаптеров действительно важный критерий, с этой стороны вполне объясняется как поддержка устройств(хотя считал что софт работающий с адаптером решает эту задачу, юудто проткоол один и гораздо реже обновляется, ну лан), так и производительность в том числе.
Тут с вами согласен, но по наблюдениям шкафчик открыт или закрыт, выносная антенна или без нее, не было практически никакой разницы, возможно в других инсталляциях это было бы юолее весомым фактором, например если контроллер в щитовой, то зигби там и останется). У вас есть на примете координаторы с poe питанием? С выбором устройств тоже подностью согласен
Да
Очень интересная архитектуру вы выбираете при наладке, у вас разные сети зигби на разных каналах, разбросанные по разным частям объекта, объединены одной железкой с N usb портов и внутри крутятся несколько z2m, видимо вы на этом собаку съели. По рпи, то он на ссд.
Тут все зависит от клиента так или иначе.
В следующей инсталляции, если таковая будет, попробую чернз группы сделать.
Теперь чуть больше стал понимать работу устройств. А по поводу проводов, то мы знаем какие основные причины выбора беспровода, да и хочется уметь и иметь понимание работы, а не просто кнопки тыкать.
Ниже jaha33 посоветовал инструкцию для сниффинга, может у вас есть своя, чем вы пользуетесь?
Да, было удивлением такое наблюдать, что есть скрипты, которые запускаются и находятся в директории которая не описана в документации. А так на wb-rules js используется))
Посмотрю, спасибо!
Большое спасибо! Обязательно проверю, а плата тут становится координатором или роутером, какая роль в сети?
Рад что благодаря мне вы успешный интегратор)
Давайте взглянем на следующее:
Слышал что адаптер wb не самое надежное решение, исходя из этого выбрал сонофф, НО еще нигде не видел точного сравнения двух адаптеров. Слышал позитивные отзывы об адаптере jethome, да и сам в целом был доволен им, только на неюольших инсталляциях
Сам выбор контроллера wb или raspberry pi не имеет никакого значения, нужна была железка с портом usb. Более важным в ходе работ оказался тип монтажа, rpi можно поставить на стол)
С версиями ПО z2m согласен, одной из ошибок было установка не с гита. По поводу адаптера, слышал что обновление на вб помогает, но не в моем случае, к сожалению.
спрутхаб тоже не имеет значение во всем этом тесте, поскольку использовался только в рамках mqtt
Надеюсь вы поделитесь опытом и подскажите какие решения более релевантны.
Каналы менял не помогло(
Спасибо большое что поделились опытом! Увеличение мощности адаптера при зашумлении плохой паттерн.
Соглашусь что проивзодитель оборудования может стать камнем преткновения и никакие настройки не помогут, но вроде получилось избежать этого.
Утилита tshark сможет смотреть что приходит с адаптера? или вы что-то другое имеете ввиду? Я написал программу которая фиксирует в эксельке linkquality всех приходящих сообщений по мктт, но это уже после работ, т.е. весь анализ построен на наблюдении.
https://github.com/Palmyra-debug/ZigLQ
В z2m есть функционал группы устройств, не разбирался с его работой. А под логической имел ввиду объединение устройств в сценарной машине по триггеру например.
Да, спасибо. Подскажите у вас есть понимание как этот механизм работает? Я считал что только полное отсоединение от текущего родителя сети запускает этот процесс.
Отредактировал, спасибо)
В проделанной мною работе очень часто не хватало метрик, это было основной загвоздкой что отталкивает большинство интеграторов. Все сравнивал наблюдением, только после работ написал программу которая подписывается на все топики от z2m и выводит linkquality по устройствам в таблице, может пригодится:
https://github.com/Palmyra-debug/ZigLQ
Координатор не управляет маршрутизацией, согласен, но он включает режим сопряжения и указывает какое устройство именно будет входить в этот режим. Может вы знаете как именно принимается решение о перестройке, у меня информация что только при полном отсутствии сети и ее возобновлении. Соответственно перезапуск адаптера/софта/устройства пересоберет сеть, связанную с этим устройством.
Тут очень важным отличием является используемый софт (zha vs z2m), а также взаимное расположение устройств. Также использовал сонофф адаптер + распбери. Ксати, вспомнил что некоторые китайцы, в частности мои датчики движения, очень часто шлют сообщения, интересно есть ли возможность указать что только по изменению статуса движения необходимо отправлять сообщение? Это вполне может влиять на пропускную способность.
Уверен на тысячу процентов что работа софта очень роляет. Адаптер использовал такой же.
Я изучал этот вопрос, но не всегда устройство-триггер и устройство-исполнитель заведены в z2m, соответственно решил выбрать единую "сценарную машину". Например, кнопка на сухом контакте подключенном по GPIO в WB а свет или штора zigbee.
Да, можно в z2m указать конкретное устройство-роутер через которое планируем подключать. Но по наблюдениям версия старая v2.5.1 пыталась всячески игнорировать пожелания, тогда как в новой все строилось именно так как планировали. Отмечу что "автоматическая" перепривязка устройств происходит после полной потери устройства из сети, но более точно ответить не смогу, поскольку плотно не занимался этим. Кстати из этого вытекает интересный факт, после полного отключения того же контроллера-адаптера сеть перестроится как ей хочется(надо уточнить) и положение адаптера в географическом центре остается единственным важным фактором при перестройке.
Да, процесс перекладки топиков из формата wb в z2m сожрал все ресурсы что были.
Ответил выше)
После такого опыта у меня наоборот пропала неприязнь к zigbee, тут важно сразу учесть много факторов, как и в любом проекте. Обычно все отказывает работать, если клиент хочет подешевле, тогда по комментарию выше вероятность наладки системы резко снижается.