[PlainUser 0]

Есть пара вопросов по функционированию.

 

 

1 - может ли мобильное устройство исчезать и появляться в сети в произвольные моменты времени?

 

2 - может ли мобильное устройство исчезать в одной и появляться в другой сети?

если нет то в чем отличия мобильного от спящего , в чем вообще смысл введения сущности му?

 

3 - будет ли му в моменты исчезания из сети занимать место в таблицах (соседей) коо.

 

4 - как исключить су или му из сети и таблиц коо в момент его сна или поломки?

(например к коо подключены 32 су больше добавить нельзя, одно вышло из строя надо заменить)

 

5 - как заменить вышедший из строя координатор ?

а процессе работы доступа к конечным му и су нет.

может можно заранее как-то заготовить резервный коо?

 

 

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

[ataradov 0]

Ниже подразумевается, что МУ - это End Device. Вообще лучше терминологию оригинального языка использовать, а то и до КД-ПЗУ не долго дойти.

 

1 - может ли мобильное устройство исчезать и появляться в сети в произвольные моменты времени?

Может.

 

2 - может ли мобильное устройство исчезать в одной и появляться в другой сети?

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

 

если нет то в чем отличия мобильного от спящего , в чем вообще смысл введения сущности му?

Для сна и снижения нагрузки на сеть.

 

3 - будет ли му в моменты исчезания из сети занимать место в таблицах (соседей) коо.

Будет пока таймаут не выйдет.

 

4 - как исключить су или му из сети и таблиц коо в момент его сна или поломки? (например к коо подключены 32 су больше добавить нельзя, одно вышло из строя надо заменить)

Запись сама исчезнет после того как ED не выйдет на связь за определенное время. Просто на время сна запись убрать нельзя.

 

5 - как заменить вышедший из строя координатор ?

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

 

может можно заранее как-то заготовить резервный коо?

От стека зависит.

 

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

В этом вся суть ZigBee :)

 

 

Хотя в вашем вопросе не ясно что подразумевается под "спящими" тогда. В общем проясняйте терминологию.

[PlainUser 0]

Чипы EM357 , протокол EmberZNet PRO ZigBee , ревизия r308.

 

https://www.silabs.com/products/wireless/zi...e-software.aspx

 

A network consists of a ZigBee Coordinator (ZC) which started the network, ZigBee Routers (ZR) and ZigBee End Devices (ZED). There do not have to be any routers (other than the coordinator, which functions as a router) or end devices in any given network. Each router can support up to 16 end devices (30 on the ETRX3 series) in any combination of non-sleepy, sleepy and mobile End Devices. The network is always formed as a mesh according to the ZigBee PRO featureset of the ZigBee standard; the tree structure is not available.

By default the module joins a PAN as a router, but modifying register S0A allows you to define it as an end device. The coordinator is simply the device that first establishes the PAN, and it should not be allowed to leave the PAN as it is not possible for a node that is already joined to the PAN to take over the role of a coordinator or Trust Centre.

 

 

биты в регистре reg S0A

Bit F Bit E Device Type

-----------------------------

0 0 Router (FFD)

1 0 End Device

0 1 Sleepy End Device

1 1 Mobile End Device

 

 

 

 

Используем пока только АТ команды ибо некогда.

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

Но в настоящее время все сделано на АТ командах.

Система уже работает , но есть тонкости для дальнейшей эксплуатации.

Система без изысков один координатор и куча (одинаковых ) конечных (SED) устройств-сенсоров (ток,напряжение,температура впрочем неважно).

 

Устройства должны просыпаться раз в сутки (настраиваемый параметр от 1ч до 1недели) , рапортовать и засыпать.

Возможен вариант отсутствия постоянного координатора.

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

 

В связи с этим вопрос насчет времени таймаута после которого координатор исключит SED из сети?

Такой инфы не нашел.

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

 

Есть еще вопрос ограничения количества сенсоров присоединяемых к координатору ,но я так понял что свыше 32шт (нам возможно нужно будет до 256) решается дополнительными роутерами.

Изменено 26 февраля, 2016 пользователем PlainUser

[ataradov 0]

0 1 Sleepy End Device

1 1 Mobile End Device

Это изобретение эмбера. Стандарт определяет C, R и ED. Не знаю в чем технические различия между SED и MED, но можно предположить, что разница в длительности таймаутов для удаления устройства из таблиц.

 

Используем пока только АТ команды ибо некогда.

С этим скорее всего будут проблемы с подменой C и прочими "сложными" вещами. Хотя при использовании преконфигурированных ключей может и получиться.

 

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

В этом случае самое правильное - это покинуть сеть и пытаться подключиться раз в сутки. По успеху или неудаче подключения можно судить о наличии координатора.

 

В связи с этим вопрос насчет времени таймаута после которого координатор исключит SED из сети?

Это не определенно стандартом. По стандарту, если прошло больше 8 секунд, то координатор имеет право выкинуть все буфферизированные данные для устройства. На практике так естественно никто не делает и хранят дольше. Сам таймаут обычно просто задается извне и определяется максимальным времененм сна.

 

Есть еще вопрос ограничения количества сенсоров присоединяемых к координатору ,но я так понял что свыше 32шт (нам возможно нужно будет до 256) решается дополнительными роутерами.

Да, но если сценарий "подключился, сбросил данные, ушел", то больше 32 устройств практически никогда не будет подключено.

 

[PlainUser 0]

В этом случае самое правильное - это покинуть сеть и пытаться подключиться раз в сутки. По успеху или неудаче подключения можно судить о наличии координатора.

 

Это будет нормальный режим работы ?

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

Разницу в затратах времени не могу оценить с ходу.

(Батареек жалко , а полезных данных менее сотни байт на сеанс.)

 

И как защитить этот процесс от злых людей.

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

 

[ataradov 0]

Это будет нормальный режим работы ?

Вполне. Для таких редких просыпаний.

 

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

Проснуться и проверить, что координатор отсутствует и проснуться и попытаться найти координатор - одно и то же время и число кадров.

 

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

 

И как защитить этот процесс от злых людей.

Раздать всем заранее известный ключ. Поддерживает-ли тот стек и модуль этот режим - нужно изучать. С точки зрения ZigBee это называется Standard Security with Preconfigured Key.

 

[PlainUser 0]

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

 

Модуль выдает сообщение Lost PAN раз в секунду.

 

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

Так-что в общем пофиг.

 

Раздать всем заранее известный ключ. Поддерживает-ли тот стек и модуль этот режим - нужно изучать. С точки зрения ZigBee это называется Standard Security with Preconfigured Key.

 

 

Возможно это оно?

 

To create a secure network, use the following settings:

 

- Write your own Link Key into S09 on every device. If you do this off-line it can

never be hacked

 

- Set bit 8 of register S0A on all devices that will join the PAN (Use Pre-Configured

Trust Centre Link Key when joining)

 

- Set bits 4 and 2 of register S0A on the coordinator (Send Network key encrypted

with the link key to nodes joining; Send Network key encrypted with the link key

to nodes re-joining unsecured)

 

- (For simplicity, you can set bits 8, 4 and 2 of S0A on every device)

 

 

В какой момент использовать:

AT+KEYUPD Update the Network Key

Не очень понял.

Изменено 29 февраля, 2016 пользователем PlainUser

[ataradov 0]

Модуль выдает сообщение Lost PAN раз в секунду.

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

Так-что в общем пофиг.

Ну так в этом случае придется заново присоединяться без вариантов. Так что этот вопрос отпадает сам по себе.

 

Возможно это оно?

Не совсем, но это даже лучше.

 

Link Key - это уже не Standard Security, но если поддерживается, то замечательно. Его и использовать.

 

При создании сети в этом случае задаются 2 ключа Link Key и Network Key. Network Key передается на устройства зашифрованным Link Key при подключении к сети.

 

То-есть при настройке сети устанавливаете Link Key на все устройства и держите его в секрете.

 

При настройке координатора устанавливаете Network Key и все подключающиеся устройства получат этот Network Key только если знают Link Key.

 

Network Key используется для шифрования всего траффика.

 

В какой момент использовать:

AT+KEYUPD Update the Network Key

Не очень понял.

 

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

[A. Fig Lee 0]

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

ой

[PlainUser 0]

Ну так в этом случае придется заново присоединяться без вариантов. Так что этот вопрос отпадает сам по себе.

 

Не-не.

Включаем конечное устройство ранее заригистрированное в сети и получаем от него Lost PAN раз в секунду если оно не может найти своего координатора.

Затем включим координатор и Lost PAN сменится на JPAN:<номер канала>,<ПАН СЕТИ>. однократно.

 

Если устройство покинет сеть (по команде AT+DASSL) то оно выдаст Left PAN.

Те само оно не покидает сеть , ну по крайне мере несколько минут , дольше не ждали.

 

 

По поводу Network Key.

Я так понял что после того как мы устанавливаем бит "Send Network key encrypted with the link key to nodes joining" трафик начинает передаваться шифрованный AES128 в обе стороны?

 

Или этот бит касается только установки ключа , а процедуру его использования шифрования (обычно) нужно инициировать как-то отдельно?

Изменено 1 марта, 2016 пользователем PlainUser

[ataradov 0]

Затем включим координатор и Lost PAN сменится на JPAN:<номер канала>,<ПАН СЕТИ>.

Это и есть переподключение к сети. Никаким другим способом ED не может найти координатор если он пропал. Тем более на другом канале.

 

[PlainUser 0]

Это и есть переподключение к сети. Никаким другим способом ED не может найти координатор если он пропал. Тем более на другом канале.

 

Гм.

Но при этом ED остается в таблицах (соседей) координатора , я проверял.

А после диссассоциации at+dassl ED пропадало из таблицы координатора.

 

Наверное дело в том что у нас ED определены как спящие SED.

 

По моему в начале экспериментов я использовал просто ED и сообщений Lost PAN не видел.

 

Наверное есть разные термины для регистрации в сети и для (ну не знаю чего) включения в сеть вышедшего из спячки ED.

 

И канал после создания сети всегда остается один и тот-же.В таблицах SED он прописан , те в режиме сна он его не забывает.

 

Изменено 1 марта, 2016 пользователем PlainUser

[ataradov 0]

Но при этом ED остается в таблицах (соседей) координатора , я проверял.

Ну да, откуда им знать, что ED питание пропало. Через некоторое время записи пропадут.

 

А после диссассоциации at+dassl ED пропадало из таблицы координатора.

Тут ED активно посылает команду Network Leave, сообщая, что он уходит из сети.

 

[PlainUser 0]

Ну да, откуда им знать, что ED питание пропало. Через некоторое время записи пропадут.

 

Может все-же для спящего не пропадут ?

Или по другому более длинному таймауту.

[ataradov 0]

Может все-же для спящего не пропадут ?

Или по другому более длинному таймауту.

Пропадут. Но естественно таймауты должны быть выбраны верно. Это должно или настраиваться или документировано быть где-то. Типа максимальное время сна для устройства.

 

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