This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

End device bind without coordinator in Houme Automation Profile

Hello everyone. I apologize in advance for my English. I'm pretty sure, what can use the EZ-Mode mechanism to bind the two end devices to each other without coordinator, and not have to be a network node, such as a router. EZ-Mode the mechanism is complicated for me...

Because interested in this issue: "Can I use End Device Bind mechanism for to bind the two end devices to each other without coordinator?"

There is a standard feature:

/*********************************************************************
 * @fn          ZDP_EndDeviceBindReq
 *
 * @brief       This builds and sends a End_Device_Bind_req message.
 *              This function sends a unicast message.
 *
 * @param       dstAddr - destination address
 * @param       LocalCoordinator - short address of local coordinator
 * @param       epIntf - Endpoint/Interface of Simple Desc
 * @param       ProfileID - Profile ID
 *
 *   The Input cluster list is the opposite of what you would think.
 *   This is the output cluster list of this device
 * @param       NumInClusters - number of input clusters
 * @param       InClusterList - input cluster ID list
 *
 *   The Output cluster list is the opposite of what you would think.
 *   This is the input cluster list of this device
 * @param       NumOutClusters - number of output clusters
 * @param       OutClusterList - output cluster ID list
 *
 * @param       SecurityEnable - Security Options
 *
 * @return      afStatus_t
 */



Now it works only if the network has a coordinator. Can I do anything to make it work (bind the two end devices) when the network has only one router (for simplicity, consider: one router and two end devices) ?

    zAddrType_t dstAddr;
    dstAddr.addrMode = afAddr16Bit; // Maybe broadcast?
    dstAddr.addr.shortAddr = 0;   
    
    if (invert) {
      
      ZDP_EndDeviceBindReq(
        &dstAddr, NLME_GetShortAddr(),
         SAMPLESW_ENDPOINT,
         ZCL_HA_PROFILE_ID,
         0, NULL,
         ZCLSAMPLESW_BINDINGLIST_IN,  bindingInClusters,
         TRUE 
      );

Thanks in advance for answers

  • You can try to use ZDP_BindReq instead of ZDP_EndDeviceBindReq.
  • ZDP_BindReq Provides direct binding (I call it the "manual binding"). This is useful when the devices known addresses bindable....
    I read a little more about EZ-Mode. Since you can not through the usual EDB bind two end device without coordinator, i have to use it...
    The main thing to solve the problem.
  • А в чем конкретно проблема? Ведь узнать адрес можно и без координатора..
  • Ух тыж ничего себе... СВОИ :))))) Смотрите в чём суть. EDB привязывает два устройства друг к другу согласно модели уровня приложения, так? (ТАК :)).... Т. е. есть on/off кластер-сервер (in cluster) на одном устройстве, например в лампочке, и on/off кластер - клиент в другом (out cluster, например в выключателе) при этом для пользователя, т. е. меня, их адреса не важны, а важно совпадение в модели уровня приложения. Т. е. мне нужно чтобы в автомате привязывался выключатель к лампочке, по нажатии на них кнопок.
    Я сделал так: нажимаю на одном устройстве кнопку, генерируется EDB, на другом, тоже делается EDB, всё это координатор в автомате ловит и сравнивает модель уровня приложения, при совпадении связывает устройства. Ну как, он сам шлёт команду bind туда куда нужно и создаёт запись в таблице привязок там, где это необходимо.
    В ручной привязке нет проблем, вы правильно заметили, что можно узнать адрес и без координатора. Есть соответствующие функции для этого. Но я чёт не могу сообразить как мне реализовать автопривязку через ручные бинды.
    В голову лезет только одно:
    Поймать роутером анонс от одного конечного устройства. Сохранить его IEEE и короткий адрес.
    Затем запросить его простой дескриптор (Узнать какие там кластеры, эндпоинты и прочее). Сохранить.
    Далее сгенерировать и отловить анонс на втором устройстве. Опросить его дескрипторы.
    Затем на роутере сравнить данные и сделать ручную привязку.

    Сомневаюсь, сработает ли это.... Хочется пару функций вызвать, как с EDB и всё. А не собирать велосипед... Вы с EZ-Mode работали, оно функционирует как EDB? Просто чёт к нему куча описаний и примеров и везде одно и тоже разными непонятными фразами. Алгоритм его на картинки у них есть... Но чёт ясности особой он не вносит, как его реализовать и запустить :)
  • Свои есть всюду!!
    э-э-э... ЧЕсстно говоря я не использовал в своей работе биндинги. Но немного эксперемнтировал с ними. Но вообще задачу с привязками устройств решали. Я бы сделал так что устройство (клиент) включаеясь дает бродкаст с запрсом нужной инфы. Сервер отвечает ему с указанием своего короткого и длинного адреса. Далее биндинг. которткий и длинный адрес сохраняются на клименте в энергонезависимой памяти. Чтоб при повторном включении обойтись без бродкаста.

     Хотя можно скакатьи от лампочки - она же наверно не имеет ограничений по питанию? Тогда она времятот времени бродкастит тому кто ответит правильно.  Ну а далее все повторяется.  

  • Можно и так. Ну вобщем я надумал вот такой вариант реализовать:
    Два конечных устройства ничего не делают. Когда хотят привязаться, сразу шлют броадкаст с инфой.
    Роутер ловит такие запросы, сравнивает инфу и прописывает привязку.

    Кстати, вы случаем не в курсе, могут ли два конечных устройства слать пакеты друг другу напрямую, без использования роутера? У меня не получалось такое провернуть, как я не старался, обязательно одно из устройств являлось роутером. Т. е. я брал выключатель и лампочку прошивал их как конечные устройства, через координатор настраивал привязки, убеждался в том, что всё работает (лампочка управляется выключателем), затем выключал координатор и ВСЁ, привет лунатикам :D .... Лампочка переставала управляться. Но как только я прошил её как роутер и сделал тоже самое, всё работало....
  • Это как посмотреть.. Дело в том что насколько я понимаю конечное посылает информацию другому конечному . Информция доходит до роутера а вернее до того кто является "парентом" адресата и пересылается на адресата когда адресат проснется и проверит наличие информации для себя.(MLME Poll Request) Т.е. вот совсем напрямую врядли. Идиология сети не позволяет.
    Так что все правильно было с вашей лампочкой.
    А зачем роутеру привязки делать?? Почему не напрямую на клиенте или сервере?
  • Ну так как он всегда от кого-то принимает пакеты, пусть он и решает, кого куда привязать. К тому-же, конечные устройства должны спать, чтобы расходовать меньше энергии. Ну а вообще я же пытаюсь реализовать автопривязку. И роутер идеально подходит для своего рода моста в этой функции. Ну смотри, покрытие увеличивает, подсети создаёт, когда координатора нет, а это ещё и автопривязку будет осуществлять, вообще красота. Оперативки бы ему хватило... А то уже были случаи, когда я столько всего понареализовывал на роутере, что он просто всё время отваливался от сети и постоянно перезагружался. Там в стеке такая примочка есть, если превышаешь там лимит какой-то то код не компилируется и выдаётся одна единственная ошибка, которая устраняется флагом INT_HEAP_LEN=1700. Вот когда эта величина равна 1500 начинаются неведомые глюки в сети, которые как я выяснил связаны с нехваткой опреативки.
  • Вообщем тоже верно. Пусть работает. А насчет паямти можно ж на несколько рутеров это возложить. Особенно если топология сети к этому располагает. Мы делали "автопривязку". Но не средствами Zigbee. Да и задача чуть другая. Унас с датчиков инфа лилась на сервак. Так что там свой огород городили. Вообще используем ZNP.
    А вы свою плату разводили под радиомодуль? Или что-то готовое брали?
  • Готовый модуль. Своя плата. Лампочками щёлкаем ;D
  • Ну значит "Да будет свет!"
  • I cannot understand your discussions other than English but I hope you already get answers.
  • Problem solved. I will use Bind Request on the router.
    At first end device, which wants to bind, will send the necessary information broadcast.
    The router will catch this information and will wait for another broadcast request from another device with the right information.
    After receiving two packets from devices with the necessary information, the router will hold its analysis and decides whether to bind two devices
  • I see and it's good to know you have solution now.
  • Кстати есть еще одна мысль... МОжно  прописать нужные user_drscriptor т и дать команду ZDO_GET_USER_DESCRIPTOR  и уж оттуда выудить короткий адрес и сделать по нему биндинг. Плюс этой идеи в том что не нужны городушки с собственным броткастом.  Лишь бы эта ф-ция работала как надо. Я не смог ее толком проверетиь.

    P.S Проверил. Она странно работает с бродкастами.