MQTT IoT Framework overview

Lightweight frameworks for IoT applications, based on MQTT / CoAP.

Moderator: longwang

MQTT IoT Framework overview

by longwang » Thu Oct 23, 2014 6:05 pm

We always face with some applications which needs to just send some data to a server. To start thinking about MQTT-based framework, here’s the application scenarios:
What’s MQTT
MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios.

Pub/Sub Model
Figure: Pub/Sub pattern

In a pub/sub model, the producer acts as publisher, and consumer acts as subscriber. Using the publish – subscribe pattern in application can dramatically simplify its design and improve testability.

In a distribute IoT system, basically you just have some part(s) of your device subscribe to a particular topic and have some other part(s) of your device publish messages with that topic. Messages sent will be delivered to all registered handlders (aka listeners, also receivers) for a given topic(one-to-many broadcast).

We implement the following parts:

MeshBee is a low-cost, community-supported, programable zigbee wireless development platform, aim at mesh network applications. It’s simple enough to send a heartbeat to the Coordinator installed on Gateway. Visit here to get some programming guide.

1.1 Generate a heartbeat in AUPS
every node can produce something, adc value, temperature etc.

Edit ups_arduino_sketch.c:

Code: Select all
ANALOG_T adc_pin;

void arduino_setup(void)
    //Init your device here
void arduino_loop(void)
    uint8 tmp[sizeof(tsApiSpec)]={0};
    tsApiSpec apiSpec;

    int16 temper = vHAL_AdcSampleRead(E_AHI_ADC_SRC_ADC_3);
    sprintf(tmp, "gas:%ld\n", temper);
    PCK_vApiSpecDataFrame(&apiSpec, 0xec, 0x00, tmp, strlen(tmp));

    /* Air to Coordinator according to mac address */
    uint16 size = i32CopyApiSpec(&apiSpec, tmp);

    if(API_bSendToMacDev(0x00158d000035529c, 1, 1, tmp, size)){
        suli_uart_printf(NULL, NULL, "<HeartBeat%d>\n", random());

In example above, we sample pin AD3 periodically, and call “bSendToMacDev” to send the value to the Coordinator(mac address of coordinator is ’0x00158d000035529c’).

The heartbeat format gateway requires is key-value pair string (KVP).

“key:value” + ‘\n’

eg: “temperature:23 \n”

Heartbeat is sent with no ack.


Figure: Network Topology

1.2 Active MCU mode
When we finished the heartbeat generator module in AUPS, we must activate the MCU mode to send heartbeat.

Type “+++” at AT console.

Setting interval of AUPS thread by “ATMF xx”

Enter MCU mode by “ATMC”


Figure: Gateway software architecture

Gateway is written by pure Python, which makes it more pithy to implement the software components.

It consists of four parts:

1. Exchange component is one of the core components of the gateway project. It acts as a protocol converter between MQTT and PAN;

2. Data filter component provides some static filter, such as LinearFilter, EnumFilter etc. Once a filter is activated by user, each incoming/outgoing data frame will be filtered by it.

3. Plugin usually contains some user-defined business logic, such as sending a heartbeat, processing sensor data etc. Because every single data frame will pass to it, user can do anything they want according to the incoming data. Click here to get a depth understanding of the plugin developing.

4. PAN device Driver is a layer used for communication between Pan Device and Host CPU. Usually, the physical connection is a serial port. Now, it supports MeshBee v1.0.4 firmware and XBee.

Main features:

1. Can be ported to any platform that supports Python.

2. User-defined Qos, which ensure the reliability of data transmission.

3. Message forwarding is handled by Broker. User can focus on their application developing.

4. Pub/Sub model, one-to-many message deliver.

5. light-weight messaging protocol over TCP. It is designed for connections with remote locations where a “small code footprint” is required and/or network bandwidth is limited.

6. Support plugins expanding.

7. Support data filter.

8. Support any device that has a serial port.

9. Build-in Sqlite Database.

Getaway running flow
The following flow provides some basic procedures of how a gateway engine run.


Gateway configuration

Gateway program will read its configuration files at startup. We create a yaml file in root directory. Modify the following items to meet your request.

1. yaml['pan']['port']

Pan device serial port device ID in /dev.

2. yaml['pan']['baudrate’']

Baudrate of pan device serial port device.

3. yaml['pan']['driver_class']

Specified pan device driver

4. yaml['mqtt’']['client_id']

Gateway client ID

5. yaml['mqtt’']['host']

Broker Url

6. yaml['mqtt’']['port']

Broker TCP port number.
Posts: 3
Joined: Tue Oct 14, 2014 9:53 am

Who is online
Users browsing this forum: No registered users and 1 guest