Zigbee for the little ones. Post number 1
About a month ago, Atmel ATZB-S1-256-3-0-C modules based on the ATmega256RFR2 chip combining a 2.4Mhz transceiver, an AVX microcontroller with 256 kilobytes of memory and even a chip antenna came into my possession. 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 does not understand, then using these modules it is relatively easy to build an IoT mesh network by adding to the modules only buttons, bulbs, sensors and batteries. 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 Atmelevsk Zigbee stack, the Zigbee standard itself, and the revaluation 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 for a long time, I put all the pointers and other means of managing resources and processes in the nightstand and threw out the key. Well, well ... in the world of embaddad, I had a lot of pleasant surprises.
I rolled up shorter than the sleeves, uncovered the modules, soldered the batteries, installed AtmelStudio, sat down to program, got up three days later with the understanding that I still don’t get into anything. The feeling is unpleasant, but there is nothing to do, the project will not finish itself and it is necessary to do something. The first step to fixing the error was to switch to another microcontroller that was also present in the project - STM32 which had a lot of tutorials on the Internet and which allowed me to more smoothly integrate into the embedded world. About STM32, I also wrote a similar series of posts which, it seems to me, describes in some detail the work with this microcontroller for beginners. This series of posts - “Zigbee for the smallest” will be relatively advanced compared to the STM32 series, as it seems to me,
Zigbee Standard
In this part, we will try to figure out what Zigbee is. Consider the standard in general terms, see what Zigbee application profiles, clusters and endpoints are. In the next part, we will delve into the technical details of the frame, and security in Zigbee (you may not even read it yet, but return when you need them). After reviewing the protocol, we’ll go directly to the Atmel modules and programming.
Introduction
So who is Mr. Zigbee?
At first. ZigBee is a specification of the upper layer network protocols - the APS (application support sublayer) application layer and the NWK network layer - that use the lower layer services - the MAC access control layer and the PHY physical layer, regulated by the IEEE 802.15.4 standard.
If in a simple way, Wikipedia, in my opinion, very succinctly put it into the account of this: “The cooperation between IEEE 802.15.4 and ZigBee is similar to what was 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. Responsible for transmitting and receiving bits with our transceiver.
2. MAC - media access control. Media Access Control Sublayer. For ease of remembering, you can focus on the addressing mechanism. Everyone has heard about the MAC address and it appears in this sublevel that it appears. The sublayer is responsible for ensuring that the bit is 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 network transfer application.
Secondly. Zigbee also includes (from things important for understanding) an application standardization mechanism including application profiles and libraries of standard clusters. ( Remember this tweet!)
Application Standardization Mechanism
From this part, we must derive several basic concepts:
- Zigbee application profiles
- Endpoints
- ZCL - clusters
- Server-clent separation
So, we will start with profiles . Zigbee application profile is, first of all, a class that combines different devices in one area of application. For example, the following standard profiles exist in 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)
Profiles are primarily needed in order for devices from one manufacturer to work with devices from another manufacturer in the general field of application. It is interesting that the devices can be multi-profile and some kind of bulb can for example be certified as both (HA) and (CBA). Profiles are not limited to standard profiles and the device manufacturer can come up with their own. Also, messages in Zigbee are transmitted within the same profile using the profile id - that is, the areas of application are delimited not only in code, in certification, logically, but also on the communication channel.
In standard profiles, standard types of devices are invented, 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 built-in control panel can be both “Dimmer Switch” and “On / Off Light Switch”. How is she doing this? Using a concept called endpoints . In our iron-device, we can "register" several endpoints, each of which will do its own thing and will not even know about the rest. Thus, several virtual devices are combined on one physical device.
Well, for dessert, Zigbee provides special ZCL libraries - clusterswhich should help us a lot to implement various devices. Clusters are functional bricks that carry out 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
All this distinction and standardization in theory should help a lot in software development.
Example:
The manufacturer Zingbao ltd launches a system for Philips ltd 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 bulb in the system can do what the Color Dimmable Light (HA) device should do, namely, accept color and light-force commands, the sensor must be able to do what the Occupancy Sensor (HA) is supposed to do, etc. Therefore, all parts of the system contain the code for 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. Having noticed this, enterprising Chinese hackers write their Zigbee profile"I want to know your secrets" (IWNYS) and agree with Zigbao ltd or her employee on an extraordinary update of the system. After the update, the motion sensors, in addition to the motion indication, also begin to transmit conversations (since the sensor is based on a microphone, and a new Spy senor device has been added to the firmware based on the hacker clusters Big boss detector, Speech transmitter, Secret encoder, and of course registered as an additional endpointin the motion sensor) from the Booble boss’s office through the profile (IWNYS) without any connection with (HA). For example, standard (HA) can get along well with the company profile (IWNYS). Well, to complete the example, the system works fine with Osram bulbs as certified as (HA) and installed in Booble.
Well, that’s all for today. I remind you that in the next part we will go over the technical part of the protocol - the frame structure and security settings and implementation. If anyone is bored this part can be skipped for now. In subsequent parts, we will go directly to launching Zigbee on ATmega modules and parsing the Atmel bitcloud SDK - a package for working with Zigbee and ATmega modules.
