Building a Hornet Device or Sensor

A Hornet device application incorporates Hornet stack plus device-specific application code. In this chapter, I will explain how the whole thing is supposed to work.

Hornet Protocol

Like Zigbee and Google’s Thread, Hornet is a wireless mesh network protocol.

From a design point of view, Hornet is more like Zigbee protocol, with subtle (and significant) differences in every layer.

Need To Knows, for Developers

Device Join

A Hornet wireless device shall join a network. It may still function partially without joining a network. For example, a wireless switch can still be turned on/off by pressing the button. However, Hornet wireless features will only work with joining a network.

Once joined to a network, a hornet device can be remotely controlled, monitored, and configured wirelessly.

The protocol stack automatically handles device join. However, developers shall implement code to tell the stack to “start the join process.” For example, whenever a user presses a button for a brand new light switch, the join process shall start.

Device Binding

From the developers’ point of view, the main function of the protocol stack is to send and receive application messages.

Nevertheless, developers can not decide where the application message shall be sent to or from which peer a device shall receive the application message. That depends on how devices are interconnected, which end users decide, not the developers.

For example,

• A light may be controlled by more than one wireless switch.
• A sensor may need to wirelessly send the readings to more than one device.

In IoT, this interconnection relationship is called “binding.” End-users usually initiate binding to meet their specific requirement. For example, on the GUI tool (smartphone), a user may specify three light switches to control one light to create a 4-way switch.

In Hornet, bindings are automatically modified wirelessly through the management protocol (ZDO). Usually, developers don’t need to do anything. MCU stores binding the table in the internal flash memory.

A Hornet device can only communicate application messages with peers in the binding table.

Life is supposed to be simple!

Message Delivery

Programmers only need to send or receive application-level messages. Hornet stack framework handles route management, failure retry, and error reporting.

App Layer - Zigbee Cluster Library

In the application layer, Hornet adopts the Zigbee Cluster Library (ZCL) as the application layer protocol.

Download ZigBee Cluster Library Specification here.

Responsibilities of Programmer

Trigger Join Process

A brand-new device from a manufacturer is not part of any network. End-users need to join new devices to their network.

End-users follow instructions on their smartphone clients to complete the join process. The joining process involves the following steps:

1. End-user clicks a button to tell the device to start the scan process. The device starts to scan the wireless network by sending requests to each channel
2. The nearby routers, once they receive the scan request, will notify the Hub (thus the smartphone) about the presence of the scanning device
3. End-user confirms the device from a smartphone; it then notifies the Hub and all routers
4. Routers tell the new scanning device to start joining the network

This above process is automatically handled by Hornet stack code. The developer must only tell the device to join once a button is clicked by calling nwk_schedule_join_or_rejoin(). It’s this simple.

Send Outgoing Messages

Once joined the network, a device may need to send out messages in case certain events happen, for example,

1. An end-user presses a button to turn on/off the light.
2. A sensor may need to send out the updated readings (time threshold or readings delta threshold reached).

Note developer is never allowed to decide where the update is sent to. It is totally up to the end-users.

End-users mandate the binding to establish the relationship among devices. A device only sends messages to peers it is bound to.

As a rule of thumb, a load device is always automatically bound to the Hub (trust center) so that Hub always receives the updates.

For more information, please read …

Process Incoming Messages

Only ZCL messages are passed to applications. Developers only need to implement the function to process the incoming message.

extern uint8_t zcl_data_indication(apsdu_in_t *apsdu,
        const zcl_header_t *header,
        const uint8_t *payload_end,
        uint8_t *status);