IoT MQTT Solutions

Zunch Labs is dedicated to staying up to date with all of the latest IoT developments, including MQTT‘s introduction to the IoT space.

The new lightweight IoT Protocol

With the Internet of Things constantly growing and gaining popularity, new protocols are being introduced to make development and implementation easier. Zunch Labs is dedicated to staying up to date with all of the latest IoT developments, including MQTT‘s introduction to the IoT.

MQTT was first developed in 1999 for monitoring of an oil pipeline that ran through the desert. The goal of this was to have a bandwidth-efficient protocol that uses as little battery power as possible. This is because the devices were connected by satellite, making it very expensive at the time.

MQTT protocol uses a publish/subscribe architecture instead of the typical HTTP request/response paradigm. Publish/Subscribe is an event driven architecture that allows messages to be pushed to clients, with the central communication point being the MQTT broker which includes a topic into the message. Each client that wants to receive messages subscribes to a certain topic, and then the broker will deliver all the messages with a matching topic to the client. With this said, the clients don’t have to know one another, they only need to communicate over the topic. This process and architecture allows for incredibly scalable solutions with the regular dependencies between data, consumers, and producers.

This is in contrast to HTTP where a client will pull the information it needs. Instead, the broker pushes the information to the client when there is something new and has a permanently open TCP connection.  In the event that this connection is interrupted, the broker will buffer the messages and wait for a stable connection to send them to the client.

The uses for this in the IoT can be described by how MQTT dispatches messages as topics. A topic is a string that can have more hierarchy levels which are separated by slashes. For example, if you were building a smart home with MQTT, the hierarchy for sending and receiving data to the living room could look something like this.

House/living-room/temperature

The client can subscribe to the topic exactly or by using a wildcard. For example, the plus sign (+) is a single level wild card that can be used for one arbitrary hierarchy,

House/#

This multi-level wild card provides a simple way to subscribe to all topics within that level.

House/+/temperature

This will result in all messages from temperature senders located around the house. This enables you to collect data based on a single hierarchy. However, there is also a method that can grab multiple subtrees at once. The multi-level wild card is defined by #. For example, you can subscribe to all underlying hierarchy levels by entering.

Eclipse Patho

As a quick note, we will quickly describe Eclipse Patho. Eclipse Patho was founded under the Eclipse foundation during 2012, which served to provide open IoT protocol implementations. This has become the de-facto reference for the implementation of MQTT and is available in C/C++, JavaScript, Python, Lua, Java, and will soon include C#.

MQTT clients are Simple to Implement

As MQTT is an open protocol, it is very easy to adopt for a wide variety of IoT devices, operating systems, and platforms. In fact, many applications of MQTT can be developed simply by adding the PUBLISH, SUBCRIBE, CONNECT, and DISSCONNECT control packets. MATT client libraries are also made available through the Eclipse Patho project.

With this said, combined with our engineering expertise and cost-effective development solutions, having access to free and open-source libraries can cut costs even further while reducing time spent in development.

With MQTT, we can ensure –

  • Constantly Lower Latency
  • Fast Transaction Rates
  • Extensive Scaling

Quality of Service for MQTT

Qualities of Service (QoS) levels are used to determine how every MQTT message is delivered. With QoS, each message must be specified when being sent through MQTT. It’s vital to choose the proper QoS value for every message, because it will determine how the server and client communicate with each other. By using 3 types of QoS, message deliver can be achieved using MQTT.

  • QoS 0 (At most once) – This is used when messages are delivered depending on the best efforts of the operating environment. However, message loss can occur.
  • QoS 1 (At least once) – Messages will dependable arrive, but duplicates can occur.
  • QoS 2 (Exactly once) – Messages will arrive exactly once

When considering what level to use, you have to take into consideration the performance impact of each level. Generally speaking, the higher the QoS level, the lower the performance. Zunch Labs will use the appropriate QoS depending on your application that will meet your functional and environmental requirements.

Ideal for Constrained Networks

With MQTT, control packet headers are kept as small as possible. Each packet is made of three parts –

  • Fixed Header
  • Variable Header
  • Payload

The control packets each have a 2 byte fixed header; however, not all of the packets contain variable headers and payload.

The variable header contains the packet identifier if it is being used by the control packet and a payload of 256 MB can be attached to the packets. With such a small header overhead, it makes this protocol an excellent option for the IoT.

Zunch Labs and MQTT form a Winning Combination

Our engineers already have extensive experience building solutions for the IoT and M2M. By including the MQTT protocol into our repertoire, this opens up even more possibilities for IoT development. Additionally, with open source frameworks and libraries, Zunch Labs can further reduce the cost of development and speed up production. MQTT is only one of the tools we use for IoT development; Contact Us Today to learn what IoT solutions we can build for you.

Arrow Double Up Red