IoT technology is taking the world by storm. Almost every latest piece of innovation works on IoT technology. It is changing the way we use our day to day objects. One of the best examples of IoT is activity tracker. A small wearable device which is equipped with sensors shows the data to the user on his mobile screen. Another use of the IoT can be found in e scooter app. Thanks to IoT, users have access to e scooters within the realms of their fingerprints. A user can get all data related to e scooters like the battery life, damage level, riding time, riding distance and its current location, on his mobile phone. User can even lock and unlock the e scooter by using his mobile phone. Coruscate Solutions has earned expertise to develop an accessibility-focused e scooter app for your startup.

Once deployed, the working of IoT seems very easy, but if we study the concepts applied for the functioning of the IoT, we come across lots of different terms and different protocols which establish the connection between two devices. In this blog, we will learn about a very popular protocol which is being used to integrate IoT technology in the e scooters.

We will chew over the MQTT protocol, its components, and properties. We will also explore how the MQTT protocol powers the e scooter app.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is the most commonly used protocol in every IoT project. It exchanges the data between the client and the server. Because of its small size, low power usage and ease of implementation, it is the most ideal protocol to enable the machine to machine communication. It works on a publish and subscribe model. By using the MQTT protocol, you can send data to multiple devices as well as receive the data from the multiple devices. MQTT protocol also supports constrained devices and low bandwidth which make it the perfect solution for the IoT applications.

The basic concepts of the MQTT that you should know, while developing e scooter app :

Before going further and understanding the working of the MQTT, it is very crucial to know a few concepts of MQTT.

Publish and Subscribe

As you can see from the image, Device 1 publishes a message to Device B, using a server. The reason why Device 1 is able to send a message to Device 2 is that Device 2 is subscribed to Device 1 to receive the messages. Messages are the nothing but the command and the data.

Topic

Topic specifies where you want to publish a message. It is generally illustrated by string and separated by slashes. These slashes denote the topic level. For example, if you want to turn on the lamp of your home office, the topic would be home/office/lamp and the message would be “on.” Since MQTT client is subscribed to receive the message, it receives the message and turns on the lamp of the home office.

It is worth noting that topics are the case sensitive.

MQTT broker

MQTT broker plays a big role. It is the server which is responsible for handling data between two machines. In a broader sense, it receives the messages, filters the messages and publishes the messages to all subscribed clients.

There are a variety of the MQTT brokers are available for use. These are Adafruit, Verne, Paho, CloudMQTT, and Mosquitto. Among all these, ‘Mosquitto’ is the most popular and commonly used MQTT broker. It is the open source, lightweight and cloud-based broker.

How does it work?

Like all other internet protocol, MQTT works on the client-server architecture. Clients make requests and the server handles those requests. To understand this in detail, let’s study an example.

Suppose, you want to turn on the light of the hallway of your home. To do so, you publish a message “on” to the topic “light/hallway”. This message will go to the MQTT broker and broker then forwards this message to the specific client. MQTT broker knows a lot about its clients. It remembers all clients with the client ID. MQTT broker also has the data of which clients are subscribed to which topics. Apart from this, MQTT broker gets ‘keep alive’ message from the clients after a certain time interval which lets MQTT broker know which clients are online and which are offline. The by default time interval to send ‘keep alive’ message in the Mosquitto MQTT broker is 60 seconds. If MQTT broker doesn’t get a message in 60 seconds, it checks the IP address of the client to see whether it is still connected or not.

Each MQTT message contains the three parts. These are the message, topic, and QoS (Quality of the service). We have already discussed the message and Topic.

If we talk about QoS, then it has three levels.

QoS 0 – Fire and Forget

In level 0, MQTT broker only sends the message to the client. It does not bother to verify whether the client has received a message or not.

QoS 1 – At least one

In level 1, the MQTT broker sends the message to the client over and over again until the client provides an acknowledgment. The problem associated with QoS level 1 is very unique and funny. If MQTT server doesn’t get the acknowledgment message from the client, it keeps sending the same message to the client. The client takes every single message as the different command and it repeats the same task.

QoS 2 – Exactly-once

In level 2, the MQTT broker sends the message to the client. The client receives the message and sends back the acknowledgment. But if MQTT broker doesn’t get the acknowledgment, the client sends the acknowledgment again, with the duplicate flag. This is how it makes sure that each message is received only once.

However, QoS holds a disadvantage too. QoS doesn’t save the message if a client is not online. That means, if a client is offline while the MQTT broker publishes a message, the client will never receive the message.

Teams of Coruscate Solutions have vanquished this problem by using the retain flag. It commands the MQTT broker to save the message for a new client which will subscribe to that specific topic in the future.

Properties of MQTT

According to data, the MQTT protocol is being used in 54.2% of the IoT projects. Properties of the MQTT which provide high scalability and high security are the reasons why most of the IoT engineers are opting for the MQTT. Let’s study all properties of MQTT in details.

One to Many and Many to One connection

As we have discussed earlier, there is no direct connection between clients. However, every client is interconnected via the broker. That means, if a client sends the message, it can reach all clients which are subscribed for that particular topic. With this unique ‘one to many’ property of the MQTT, you can get the data from multiple clients using a single message.

Similarly, MQTT supports the many to one connection too. In many to one connection model, many publishers can send the data to a receiver via the broker.

Bi-directional communication protocol

The two-way connection is another major property of the MQTT. With the two way ability to establish a connection, publishers and receivers can send the data and receive the data at the same time.

No more pinholes

In a typical system, data and the systems are coupled with each other that demand lots of connections and resources. With many open ports, every device has to look after each connection, and after making a change in one element, each device should be reprogrammed.

However, by building a system based on the MQTT, we can achieve a system which is more secure and needs less maintenance. In the MQTT architecture, MQTT broker becomes the central part and decouples the elements. By decoupling the elements, it reduces the number of open ports and assigns only one secure port. Moreover, every connected element of the system has its own firewalls which cater the ultimate security to the system.

Reliability

As we have discussed earlier that MQTT broker is the central part of the system which establishes the connection between different clients. But what if MQTT broker encounters a problem to operating? In such a case, broker software performs the automatic handover of the system to the backup broker and keeps the system running.

Which features Coruscate Solutions can add in your e scooter app by utilizing the properties of MQTT protocol?

We always work with light-weighted sensors in order to increase the power efficiency in your e-scooters. But with the light-weighted sensors, we cannot generate a quick response to the user’s request as light-weighted sensors only publish the data after certain seconds. To overcome this problem, we use the concept of the retain flag. By using the retain flag, we make sure that users don’t have to wait until the light-weighted sensor publishes its next data. We always show users the latest data.

We use level 2 of the QoS. That means, we minimize the chances of the failed connection between the mobile app and the available e-scooters. With level 2 of the QoS, we build the whole online and offline infrastructure of your e-scooter business in such a way that while booking the e-scooter, the user won’t get annoyed. He always gets what he wants.

We always put more emphasis on the security and so, we craft the most secured online environment by utilizing MQTT’s property of constructing a system which only has one open port.

To increase your capability of managing the more e-scooter requests, we entrench bi-direction communication. Bi-direction communication allows mobile app and e-scooters to receive and publish data at the same time.

Apart from this, teams of Coruscate Solutions are smart enough to add more features like GPS tracking, Geo-fencing, remote lock unlock and fare calculation. So, if you are looking for the e-scooter app development, feel free to contact us for a free consultation.