Alljoyn: embedded view of the developer. Part 1: Introduction

Do not think for racial prejudices, but in today's article the term “embedded development” will mean the development and programming of devices on microcontrollers using C, without any processors, Linux, Windows, Pyton and other “non-hardcore”. I deliberately made this reservation at the very beginning, so that I would not have to constantly focus on this in the future.

Alljoyn is a device-to-device communication protocol developed by the Allseen Alliance. Unlike the now widely used protocols of industrial automation (ModBus, KNX, BacNET, etc.) Alljoyn was originally designed for use in home appliances, i.e. That notorious Internet of things. Moreover, Alljoyn claims the status of a global world standard, and if you look at the list of companies participating in the alliance, it is quite possible to assume that his ambitions are not unreasonable.
Today we will try to look behind the cover of marketing statements about “universality, cross-platform and ease of use” and understand what a group of the most famous IT companies from all over the world are trying to invent.

So, Alljoyn is an open source and documentation framework. His idea was originally born in Qualcomm and eventually grew into a large alliance. Physical transport, in theory, can be any data transmission medium, provided that the TCP / IPv4 or TCP / IPv6 stack is used as a transport. But in reality, at the moment, only local networks (ethernet and Wi-Fi) are used. Declared support for all major platforms: Linux, Windows, IOS, Android, as well as the possibility of porting to microcontrollers.

This approach attracts iron developers by the fact that, in theory, they do not need to be engaged in writing applications for phones and computers to control actuators - the ironmaker makes the device and writes firmware for it, and various beautiful applications for the iPhone are drawn by specially trained people. Many will say that such attempts to create a standardized protocol have already been made many times, I personally immediately recall the difficult fate of ZigBee. Here you can only wait and hope that this time everything will be possible.

Topology

This picture can often be seen when it comes to Alljoyn, and it is really important for understanding the principle of interaction between devices. As you can see there are two basic blocks:

• APP is a block that implements business logic. It can be a physical device (such as a light bulb, air conditioning, or a television) that provides its control interfaces to the Alljoyn bus . It can also be an application on a smartphone or a computer program that converts Alljoyn-interfaces into visual user interfaces (in other words, this is an application on the phone, with which we manage Alljoyn-devices). Moreover, APP never interact with each other directly, this interaction always occurs through the Router.
• Router is a block that implements the interaction between APPs and the Alljoyn bus. It can be located as one physical device with APP, or on different ones.

Now we are gradually getting closer to the embedded part. There are 2 versions of the framework:

• Standard Core is an option designed for use in devices with operating systems (smartphones, computers, TVs, etc.)
• Thin Core - version of the framework on the "pure" C for use in embedded applications (namely, microcontrollers).

In this cycle, we will be mostly interested in the light version of Thin. So, the Router is never part of a Thin device. The simplest example of such a Thin-device is a “smart light bulb” with Wi-Fi. and the AllJoyn protocol implemented in it.
Thus, in order to control our “light bulb” there must be at least one router in the network, and as in the “light bulb”, according to the ideology of AllJoyn, it cannot be located, it turns out that there must be a separate physical device in which Router block is implemented. Attentive reader, object: let Router (since this is just a separate process in the operating system) will be in the phone, from which we launch the application to control the "light bulb". Yes, in the particular case, this option will work. But only in private.
First, the phone can have a “wrong” Router, which makes “the wrong honey” and provides routing services only for APPs that are inside the phone.

In the picture on the left, the “correct” Router receives presentation data from all APPs around, including 2 “light bulbs,” and begins to present them to the surrounding network and inwards. As a result, we are able to control the "light bulbs".
In the figure on the right, Router refuses to present the “light bulbs”; it, as conceived by the developer, serves only to output its APPs “outside”. I emphasize that the term “incorrect” does not imply incorrect functioning (the developer deliberately does not endow Router with similar functions), but only shows the impossibility of working directly with the “lights”.

')
Now we can imagine the structure of the network, in which we get a working system in any case, as follows:

Those. There must be some kind of always-on device on the network, with a Router block running on it. And with this in the current implementation of the framework will have to live. In principle, in practice this should not be some serious problem - Router, as a separate service, can be run on a physical router or on some RPi.

General principles of networking

Each AllJoyn device has a certain set of interfaces. It can be one of the basic sets, several basic sets, it can be a fixed set of one of the profiles or its own interfaces, which are necessary for this particular device.
Each device is able to announce its interfaces on the network (this happens automatically). If another device is “interested” in one of the declared interfaces, then it “asks for details”.
In addition to interfaces, each device can generate events and perform actions initiated by other devices over the network.
Technically, the very first ad about a network is done in one of three ways:

• Broadcast messages to port 9956 (outdated method used in earlier versions)
• AllJoyn multicast messages (address 224.0.0.113, port 9956)
• Multicast mDNS messages (address 224.0.0.251, port 5353)

It is allowed to use as one of the methods, and several at once.
Inside these packages, information about a TCP connection (IP address and port) is packed by which you will need to connect for the subsequent interaction. Thus, UDP is used only for acquaintance and exchange of primary information, and later work goes through a TCP socket. The announcement of "their" interfaces is already happening on TCP. Officially, AllJoyn has registered port 9955 for a TCP connection, but this rule is not mandatory, since the information about the real port is transmitted during the "acquaintance". However, I recommend using exactly 9955, because in WireShark this port is reserved for AllJoyn, and WireShark parses the packet and breaks it into separate fields in a very convenient form, which greatly simplifies life during the debugging phase.

Events and actions

Events and actions are a basic mechanism that facilitates the interaction between applications and alljoyn devices. This mechanism allows applications and devices to send events to the network that all other devices on the network will see. Similarly, applications and devices can "tell" about the actions that they can perform at the command of other devices. For example, a motion sensor can send an event if someone passes by, and a light bulb to execute an on-command action on a command from the outside. The ability to detect these events and actions allows you to create an application that turns on the light when the sensor is triggered. This simple mechanism for detecting actions and events allows applications to create dynamic responses to events.
The simplest example of this mechanism is feedback: we have 1 light bulb and 2 telephones that control it. From the first phone we turn off the light bulb, and on the screen of the second we immediately see that the light bulb is turned off.

Lighting Project

Allseen Alliance maintains and develops its protocol. One of the ways of development is “working groups” in which various projects are implemented, for example, by device profiles.
The Lighting project develops the Lighting Services Framework (LSF) library of lighting services, which implements an open and public way to interact with AllJoyn-based lighting devices, regardless of manufacturer. This project allows manufacturers of lighting devices to create devices that can communicate with each other and with other devices on the AllJoyn network, and application developers are provided with an API to communicate with lighting devices from any manufacturer.

LSF features include the open source implementation of the following features:

• Control of the state of a single lamp: on / off, hue, saturation, brightness and temperature of color
• Managing lamp groups, including creating, naming, deleting groups and managing a group as if it were a single lamp.
• Saving lighting settings, called a preset, allowing a specific state of the lamp to be saved for future use
• Apply effects, such as pulsation or transition from one state to another for some time.
• Creating lighting scenes, including individual lamps or groups of lamps, and the necessary presets and effects that can be set to create a mood and atmosphere

It is on this profile that we turn our attention to the next part of the cycle, when we’re working on the practical implementation of a “smart” light bulb on the SAMD21 microcontroller (Cortex M0) and the WINC1500 Wi-Fi module.

What is at the moment

The alliance’s website has a Product Showcase page that lists existing equipment. As far as this list is complete and relevant, you can only guess. For the global world standard, the list is very modest, but still the alliance is only at the beginning of its path. There are also various "smart" bulbs, sockets, etc. But if you look at them on manufacturers' websites, you will see that AllJoyn is implemented as an alternative protocol in addition to its proprietary one. One of the reasons for this is the almost complete absence of real mobile applications for AllJoyn.

DashBoard 14.12 . At the time of this writing, for reasons unknown to me, this application has been removed from the Play Store for Android. The application is a control panel for various AllJoyn devices.

LSF Sample App . Android application that implements the control panel for bulbs that support the LSF profile. At the moment, it can only be downloaded as an apk-file or source codes from the alliance website.

Luminaire The application that simulates on the phone screen AllJoyn "smart" light bulb. Uses Thin variant library. A great thing to debug, this light bulb is defined by the previous application (LSF) as a real light bulb. In addition, the “Right” Router is included in the Luminaire, whose services we will use later, when we will make a “smart light bulb in the gland”.