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.
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.
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.
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 program will read its configuration files at startup. We create a yaml file in root directory. Modify the following items to meet your request.
Pan device serial port device ID in /dev.
Baudrate of pan device serial port device.
Specified pan device driver
Gateway client ID
Broker TCP port number.
Here is a example about running MQTT on raspberry Pi.