Около месяца назад попали в мое распоряжение модули Atmel ATZB-S1-256-3-0-C основанные на чипе ATmega256RFR2 объединяющим в себе 2.4Mhz трансивер, микроконтроллер AVX на 256 килобайт памяти и даже чип-антенну. Атмель обещали в свою очередь out of the box поддержку Zigbee для этих модулей и было принято решение строить наш mesh именно на них.

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

Звучит довольно просто, не так ли? На практике все оказалось намного прозаичнее. Основной проблемой оказалась недооценка технологической сложности атмелевского стека Zigbee, самого стандарта Zigbee, ну и переоценка собственных возможностей. Дело в том что сам я давно не програмировал на C, давно перешел на Matlab и Python, все указатели и другие средства управления ресурсами и процессами давно положил в тумбочку и выкинул ключ. Ну что-же… в мире ембеддед меня ждало много приятных неожиданностей.

Закатал я короче рукава, расчехлил модули, припаял батарейки, установил AtmelStudio, сел программировать, встал через три дня с пониманием того, что я до сих пор ни во что не врубаюсь. Ощущение неприятное, но делать нечего, проект сам себя не закончит и надо что-то делать. Первым шагом к исправлению ошибки был переход на другой микроконтроллер который тоже присутствовал в проекте — STM32 на который была уйма туториалов в интернете и который позволил мне более плавно влиться в мир embedded. Про STM32 я тоже написал подобную серию постов которая как мне кажется довольно подробно описывает работу с этим микроконтроллером для совсем начинающих. Данная серия постов — «Zigbee для самых маленьких» будет относительно продвинутой по сравнению с серией про STM32 как мне кажется, но все же я постараюсь разжевывать и представлять материал достаточно структурировано что-бы получилось, как можно более доступно и можно было повторить эксперимент дома.

Стандарт Zigbee

В этой части мы попробуем разобраться что же такое Zigbee. Рассмотрим стандарт в общих чертах, посмотрим что такое Zigbee application profiles, clusters и endpoints. В следующей части углубимся в технические подробности фрэйма, и безопасности в Zigbee (можно даже и не читать пока, а вернуться когда они понадобятся). После ознакомления с протоколом перейдем непосредственно к модулям Atmel и программированию.

Вступление

Итак, Who is Mr. Zigbee?

Во первых. ZigBee — спецификация сетевых протоколов верхнего уровня — уровня приложений APS (англ. application support sublayer) и сетевого уровня NWK, — использующих сервисы нижних уровней — уровня управления доступом к среде MAC и физического уровня PHY, регламентированных стандартом IEEE 802.15.4.

Если по-простому то Википедия по-моему очень емко выразилась на счет этого: «Сотрудничество между IEEE 802.15.4 и ZigBee подобно тому, что было между IEEE 802.11 и альянсом Wi-Fi».

А если разжевать, то все вместе работает примерно так:

APS(Zigbee) <---> NWK(Zigbee) <---> MAC(IEEE 802.15.4) <---> PHY(IEEE 802.15.4)

1. PHY — physical layer. Физический уровень. Отвечает за передачу и прием битов нашим трансивером.
2. MAC — media access control. Подуровень управления доступом к среде. Для простоты запоминания можно сосредоточиться на механизме адресации. Все слышали про MAC адрес вот именно в этом подуровне он и появляется. Подуровень ответственный за то что бы бит был послан или принят не просто так, а по определенному адресу в сети.
3. NWK — network layer. Уровень управления сетью. Ответственный за передачу пакетов в сети — включает протоколы переадресации, раутинга и т.д.
4. APS — application support sublayer. Команды вызываемые непосредственно из приложения для пересылки в сети.

Во вторых. Zigbee так же включает в себя (из важных для понимания вещей) механизм стандартизации приложений включающий профили приложений и библиотеки стандартных кластеров. (Запомните этот твит!)

Механизм стандартизации приложений

Из этой части мы должны вынести несколько основных понятий:

• Zigbee application profiles
• Endpoints
• ZCL — clusters
• Server-clent separation

Итак начнем мы с профилей. Профиль аппликации Zigbee это прежде всего такой класс который объединяет разные устройства в одну область применения. Например в Zigbee существуют следующие стандартные профили:

Profile ID Profile Name
0101 Industrial Plant Monitoring (IPM)
0104 Home Automation (HA)
0105 Commercial Building Automation (CBA)
0107 Telecom Applications (TA)
0108 Personal Home & Hospital Care (PHHC)
0109 Advanced Metering Initiative (AMI)

Профили прежде всего нужны для того что бы устройства одного производителя работали с устройствами другого производителя в общей области применения. Интересно то, что устройства могут быть мультипрофильными и какая то лампочка может быть например сертифицирована и как (HA) и как (CBA). Профили не ограничиваются стандартными и производитель устройств может придумывать свои собственные. Также сообщения в Zigbee передаются внутри одного профиля с помощью profile id — то есть области применения разграничены не только в коде, в сертификации, логически и но и на канале связи.

В стандартных профилях придуманы стандартные типы устройств например для (HA) существуют следующие осветительные устройства:



Важно заметить что данное разделение является функциональным а не физическим то есть одна встраиваемая панель управления может быть одновременно и «Dimmer Switch» и «On/Off Light Switch». Как же ей это удается? С помощью концепции называющийся endpoints. В нашем железном-устройстве мы можем «зарегистрировать» несколько endpoints каждый из которых будет заниматься своим делом и даже не не будет знать про остальных. Таким образом совмещаются несколько устройств виртуальных на одном физическом.

Ну и на сладкое, Zigbee предоставляет специальные библиотеки ZCL — кластеры которые должны здорово помогать нам имплементировать различные устройства. Кластеры являются функциональными кирпичиками осуществляющими некие простые функции из которых можно создать целое рабочее устройство. Например стандартное устройство называющееся «Dimmer Switch» использует библиотеки/кластеры:



Но что это? Это самолет! Нет это птица! Нет это супермэн разграничение на сервер и клиент. Последнее основное понятие которое мы затронем сегодня это разграничение на сервер/клиент в коде и функционале устройства. Сервер это обычно то куда складывается информация/команды а клиент это тот кто посылает, таким образом «Dimmer Switch» он в основном клиент (посылает команды) а лампочка — сервер (выполняет команды). Заметим так же что у того же устройства «Dimmer Switch» есть и серверная сторона отвечающая видимо за настройку идентификации в этом самом выключателе. Почти все стандартные устройства имеют что-то на обоих частях и на серверной и на клиентской. Так же заметим из примера выше, что кластеры могут иметь как серверный так и клиентский функционал.

Все это разграничение и стандартизация по идее должны здорово помогать в разработке программного обеспечения.

Пример:
Завод изготовитель Zingbao ltd выпускает для Philips ltd систему состоящую из лампочки, датчика движения и интернет портала для них. Эта система конечно же работает и сертифицирована как Zigbee (HA). Это кстати значит что лампочка в системе умеет делать то что должно делать устройство Colour Dimmable Light (HA), а именно принимать команды цвета и свето-силы, датчик должен уметь делать то что положено Occupancy Sensor (HA) и т.д. Поэтому все части системы содержат код данного профиля Согласно своей функции. Далее лампочки с датчиками и выходом в интернет от Philips поставляются в офис крупной интернет компании Booble. Заметив это, предприимчивые китайские хакеры пишут свой Zigbee профиль «I want to know your secrets» (IWNYS) и договариваются с Zigbao ltd или ее сотрудником на внеочередной апдейт системы. После апдейта датчики движения кроме индикации движения начинают передавать еще и разговоры (благо датчик основан на микрофоне, а в прошивку добавлено новое устройство «Spy senor» опирающееся на хакерские кластеры «Big boss detector», «Speech transmitter», «Secret encoder» и конечно зарегистрированное как дополнительный endpoint в датчике движения) из офиса начальника Booble через профиль (IWNYS) без какой либо связи с (HA). Вот так например стандартный (HA) может отлично уживаться с фирменным профилем (IWNYS). Ну и для полноты примера, система отлично работает с лампочками от Osram так же сертифицированными как (HA) и установленными в Booble.

Ну вот вроде и все на сегодня. Напоминаю что в следующей части мы пройдемся по технической части протокола — по строению фрэйма и по настройкам и осуществлению безопасности. Если кому будет скучно эту часть можно пока пропустить. В последующих частях мы перейдем непосредственно к запуску Zigbee на модулях ATmega и разбору Atmel bitcloud SDK — пакету для работы с Zigbee и модулями ATmega.