Zigbee for the little ones. Post number 1

About a month ago, Atmel ATZB-S1-256-3-0-C modules based on an ATmega256RFR2 chip, combining a 2.4Mhz transceiver, an AVX microcontroller with 256 kilobytes of memory, and even a chip antenna, were at my disposal. Atmel promised in turn out of the box Zigbee support for these modules and it was decided to build our mesh on them.

If someone doesn’t understand, using these modules, it is relatively easy to build an IoT mesh network by adding only buttons, lights, sensors and batteries to the modules. The main microprocessor is already in place, even with an oscillator from the transceiver.

Sounds pretty simple, right? In practice, everything turned out to be much more prosaic. The main problem was the underestimation of the technological complexity of the atmelevsky Zigbee stack, the Zigbee standard itself, and the reassessment of its own capabilities. The fact is that I myself have not programmed in C for a long time, I switched to Matlab and Python a long time ago, put all the pointers and other tools for managing resources and processes in the nightstand and threw out the key. Well ... well, in the world of ambition, many pleasant surprises awaited me.

I rolled up the shorter sleeves, uncovered the modules, soldered the batteries, installed AtmelStudio, sat down to program, got up three days later with the understanding that I still haven’t gotten into anything. The feeling is unpleasant, but there is nothing to do, the project will not finish itself and something must be done. The first step to correcting the error was to switch to another microcontroller which was also present in the project - STM32 which was a lot of tutorials on the Internet and which allowed me to more smoothly integrate into the world of embedded. About STM32, I also wrote a similar series of posts which, I think, describes in some detail the work with this microcontroller for quite beginners. This series of posts - “Zigbee for the youngest” will be relatively advanced compared to the STM32 series, as I see it, but still I will try to chew and present the material in a rather structured way that would work out as accessible as possible and you could repeat the experiment at home.
')

Standard zigbee

In this part we will try to figure out what is Zigbee. Let's look at the standard in general, see what Zigbee application profiles are, clusters and endpoints. In the next part, we dive into the technical details of the frame, and security in Zigbee (you can not even read it yet, but return when they are needed). After reviewing the protocol, we proceed directly to the Atmel and programming modules.

Introduction

So who is Mr. Zigbee?

First of all. ZigBee is a specification of top-level network protocols — the APS application-level (eng. Application support sublayer) and NWK network layer — using lower-level services — the MAC access layer and the PHY physical layer, regulated by the IEEE 802.15.4 standard.

If in simple terms, Wikipedia, in my opinion, is very succinctly expressed on the account of this: “Cooperation between IEEE 802.15.4 and ZigBee is similar to what happened between IEEE 802.11 and the Wi-Fi alliance.”

And if you chew, then everything works together like this:

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

1. PHY - physical layer. Physical level It is responsible for the transmission and reception of bits by our transceiver.
2. MAC - media access control. Sub-level access control environment. For ease of remembering, you can focus on the addressing mechanism. Everyone has heard about the MAC address here it appears in this sublevel. The sub-level is responsible for the bit being sent or received not just like that, but to a specific address on the network.
3. NWK - network layer. Network management level Responsible for packet transmission on the network — includes forwarding, routing, etc. protocols.
4. APS - application support sublayer. Commands called directly from the application for transfer to the network.

Secondly. Zigbee also includes (among the things that are important for understanding) an application standardization mechanism that includes application profiles and libraries of standard clusters. ( Remember this tweet! )

Application Standardization Mechanism

From this part we have to take a few basic concepts:

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

So we start with the profiles . Zigbee application profile is primarily a class that combines different devices into one application area. For example, in Zigbee there are the following standard profiles:

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)

Profiles are primarily needed to ensure that devices from one manufacturer work with devices from another manufacturer in the general field of application. It is interesting that devices can be multi-profile and some kind of light bulb can be, for example, certified both as (HA) and as (CBA). Profiles are not limited to standard ones and a device manufacturer can invent their own. Also, messages in Zigbee are transmitted within a single profile using a profile id - that is, the application is delimited not only in the code, in certification, logically and but also on the communication channel.

Standard profiles come up with standard device types, for example, for (HA), the following lighting devices exist:



It is important to note that this separation is functional and not physical, that is, one embedded control panel can be both “Dimmer Switch” and “On / Off Light Switch”. How does she do it? With a concept called endpoints . In our iron-weed device we can “register” several endpoints, each of which will do its own thing and will not even know about the others. Thus, several virtual devices are combined on the same physical one.

Well, for dessert, Zigbee provides special libraries ZCL - clusters that should be great to help us implement various devices. Clusters are functional building blocks that perform some simple functions from which you can create a whole working device. For example, a standard device called "Dimmer Switch" uses libraries / clusters:



But what is it? This is a plane! No, it's a bird! No, this is a superman distinction between server and client . The last basic concept that we will address today is the distinction between server / client in the code and functionality of the device. The server is usually where the information / commands come together and the client is the one who sends, so the “Dimmer Switch” is basically the client (sends commands) and the light bulb is the server (executes commands). Note also that the same “Dimmer Switch” device has a server side that is apparently responsible for the identification setting in this very switch. Almost all standard devices have something on both parts on both server and client. We also note from the example above that clusters can have both server and client functionality.

All this distinction and standardization in theory should be great help in software development.

Example:
Manufacturer Zingbao ltd produces for Philips ltd a system consisting of a light bulb, a motion sensor and an Internet portal for them. This system of course works and is certified as Zigbee (HA). By the way, this means that the light in the system is able to do what the Color Dimmable Light (HA) device should do, namely, to accept commands of color and light-power, the sensor should be able to do what is required by Occupancy Sensor (HA), etc. Therefore, all parts of the system contain the code of this profile According to its function. Next, bulbs with sensors and Internet access from Philips are delivered to the office of a large Internet company Booble. Noticing this, enterprising Chinese hackers write their Zigbee profile “I want to know your secrets” (IWNYS) and negotiate with Zigbao ltd or its employee on an extraordinary update of the system. After the update, motion sensors, in addition to indicating movement, start transmitting conversations as well (since the sensor is based on a microphone, and the Spy senor device is added to the firmware based on hacker clusters Big boss detector, Speech transmitter, Secret encoder and of course registered as an additional endpoint in the motion sensor) from the office of the head of Booble through the profile (IWNYS) without any connection with (HA). For example, a standard (HA) can perfectly coexist with a company profile (IWNYS). Well, for completeness, the system works fine with Osram bulbs that are also certified as (HA) and installed in Booble.

Well, sort of all for today. I remind you that in the next part we will go through the technical part of the protocol - the structure of the frame and the settings and security. If anyone is bored, this part can be skipped for now. In the following sections, we will proceed directly to launching Zigbee on ATmega modules and parsing the Atmel bitcloud SDK - package for working with Zigbee and ATmega modules.