Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Непонятки zigbee стека EmberZNet
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Wireless/Optic
doskaleti
Участвую в проекте по разработке системы "умный дом". Используется стек EmberZNet 5.7.1. Имеется кастомная плата с линуксом, где работает самописная программа EZSP, взаимодействующая с модулем ETRX357 в конфигурации Host+NCP. EZSP сконфигурирована через AppBuilder в Simplicity Studio и собрана на линуксе. Плата выступает в роли координатора zigbee-сети.

Когда датчики pjoin-ятся в сеть и их родитель – это координатор, то запись/чтение атрибутов, отправка запросов Simple Descriptor, Power Descriptor, Node Descriptor и др. шлются без ошибок, т.е. со статусом 0x00. Когда датчики pjoin-ятся через роутер (например, умную розетку), то описанные запросы выдают в консоль ошибку 0x66 (не доставлено).

1) Как в EmberZNet правильно слать запросы детям роутера?

Я попробовал следующим образом:
Код
void emberAfTrustCenterJoinCallback(EmberNodeId newNodeId,
                                    EmberEUI64 newNodeEui64,
                                    EmberNodeId parentOfNewNode,
                                    EmberDeviceUpdate status,
                                    EmberJoinDecision decision)
{
    ...

    if (decision == EMBER_USE_PRECONFIGURED_KEY || decision == EMBER_SEND_KEY_IN_THE_CLEAR) {
        ...
        if(parentOfNewNode == 0x0000 ) {
            emberSendZigDevRequestTarget(newNodeId, POWER_DESCRIPTOR_REQUEST, EMBER_AF_DEFAULT_APS_OPTIONS);
            emberSendZigDevRequestTarget(newNodeId, ACTIVE_ENDPOINTS_REQUEST, EMBER_AF_DEFAULT_APS_OPTIONS);
            ...
        } else {
            // здесь шлю запросы ребенку роутера через emAfCliServiceDiscoveryCallback
            emberAfFindIeeeAddress(newNodeId, emAfCliServiceDiscoveryCallback);
            emberAfFindClustersByDeviceAndEndpoint(newNodeId, 1, emAfCliServiceDiscoveryCallback);
            emberAfFindActiveEndpoints(newNodeId, emAfCliServiceDiscoveryCallback);
            ...
        }
    }

    ...
}


bool emberAfPreZDOMessageReceivedCallback(EmberNodeId sender,
                                          EmberApsFrame* apsFrame,
                                          uint8_t* message,
                                          uint16_t length)
{
    ...

  if (apsFrame->clusterId == ACTIVE_ENDPOINTS_RESPONSE) {
    printf ("\tEndpoint count: %x\n", message[4]);
    // send request to EP1 for getting full info about device
    emberSimpleDescriptorRequest(sender, 1, EMBER_AF_DEFAULT_APS_OPTIONS);
  }
  if (apsFrame->clusterId == POWER_DESCRIPTOR_RESPONSE) {
    ...
  }
  if (apsFrame->clusterId == IEEE_ADDRESS_RESPONSE) {
      ...
  }

  ... // и т.д.
}

В целом работает, но почти всегда одно и то же сообщение приходит несколько раз(пример на картинке), что вынуждает делать доп.проверки. Как быть?



2) Документация гласит, что родитель будет удерживать сообщение, предназначенное спящему ребенку, в течение EMBER_INDIRECT_TRANSMISSION_TIMEOUT мс, после чего сбросит его. У некоторых датчиков время LONG POLLING намного превышает это время. И что теперь, чтобы такой датчик получил emberLeaveRequest(...), надо его руками будить чтоли? Как правильно это делать? Неужели слать Alarm Message на кластер EMBER_UNICAST_ALARM_CLUSTER?
ataradov
Я не спец по стеку Ember, но знаю о ZigBee.
1. Почему не отправить напрямую по короткому адресу и дать стеку все сделать как нужно? Или эти запросы и не работают?
2. Никак. Если ED спит, то он спит и удалено его не разбудить. По спецификации родитель вообще должен хранить данные только 8 с небольшим секунд. Это известный тупняк в ZigBee и единственный вариант - это увеличивать EMBER_INDIRECT_TRANSMISSION_TIMEOUT.

Конкретно Leave, в зависимости от способа отправки (NWK Leave vs ZDO Leave) может быть обработан самим родителем, так что ребенок просто обломится при первом-же включении.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.