How does MQTT work in IoT projects?

 

If you think that the internet has changed your life, think again. The IoT is about to change it all over again!

What Is IoT?

The Internet of Things, or IoT, refers to the billions of physical devices around the world connected to each other via the Internet. Collecting and sharing data. Connecting up all these different objects and adding sensors to them adds a level of intelligence to these devices, enabling them to communicate real-time data without involving a human being. These devices range from ordinary household objects like bulbs, thermostats to sophisticated industrial tools, computers, etc. Previously Bluetooth and RF (radio frequency) were used to control IoT applications, but they were limited to a short distance. Adding MQTT capabilities can help in overcoming inter-communication problems by securely automating IoT appliances.

What Is MQTT?

MQTT is one of the most commonly used protocols in IoT projects. MQTT (Message Queuing Telemetry Transport) is a messaging protocol that works on top of the TCP/IP protocol. MQTT can also run on SSL/TLS. SSL/TLS is a secure protocol built on TCP/IP to ensure that all data communication between devices is encrypted and secure. MQTT is a lightweight protocol that uses publish/subscribe operations to exchange data between clients and the server. Furthermore, its small size, low power usage, minimized data packets and ease of implementation make the protocol ideal for the “machine-to-machine” or “Internet of Things” world. Unlike HTTP’s request/response paradigm, MQTT is event-driven, and clients receive published messages. This type of architecture decouples the clients from each other to enable a highly scalable solution without dependencies between data producers and data consumers.

How does MQTT work?

MQTT uses your existing Internet home network to send messages to your IoT devices and respond to the messages.

At the core of MQTT is the MQTT broker and the MQTT clients. The broker is responsible for dispatching messages between the sender and the rightful receivers. An MQTT client publishes a message to a broker and other clients can subscribe to the broker to receive messages. Each MQTT message includes a topic. A client publishes a message to a specific topic and MQTT clients subscribe to the topics they want to receive. The MQTT broker uses the topics and the subscriber list to dispatch messages to appropriate clients. If the connection from a subscribing client to a broker is broken, then the broker will buffer messages and push them out to the subscriber when it is back online. If the connection from the publishing client to the broker is disconnected without notice, then the broker can close the connection and send subscribers a cached message with instructions from the publisher.

MQTT Components:

In MQTT there are a few basic concepts that you need to understand:

Broker – The broker is the server that distributes the information to the interested clients connected to the server. This is the heart of the publish/subscribe protocol. The MQTT Broker is optimally designed to handle many thousands of concurrently connected MQTT clients.

Client – The device that connects to broker to send or receive information. The MQTT Client, be it Subscriber or Publisher (or both in one device) is any device from small Microcontroller up to a fully-fledged server, that has an MQTT library running and is connected to an MQTT Broker over any kind of network.

Topic – Messages make their way from a publisher, through a broker, to one or more subscribers using topics. Topics are hierarchical UTF-8 strings. Clients publish, subscribe, or do both to a topic. In other words, topics are the way you register interest for incoming messages or how you specify where you want to publish the message.

Publish – Clients that send information to the broker to distribute to interested clients based on the topic name.

Subscribe – Clients tell the broker which topic(s) they’re interested in. When a client subscribes to a topic, any message published to the broker is distributed to the subscribers of that topic. Clients can also unsubscribe to stop receiving messages from the broker about that topic.

QoS – Quality of Service. Each connection can specify a quality of service to the broker with an integer value ranging from 0-2. The QoS does not affect the handling of the TCP data transmissions, only between the MQTT clients.

1. specifies at most once, or once and only once without requiring an acknowledgment of delivery. This is often referred to as fire and forget.

2. specifies at least once. The message is sent multiple times until an acknowledgment is received, known otherwise as acknowledged delivery.

3. specifies exactly once. The sender and receiver clients use a two-level handshake to ensure only one copy of the message is received, known as assured delivery.

How to Use MQTT in Home Automation?

In today’s world, automation has become important and is being used in many applications in our daily life. A Home Automation System (HAS) is a system where in home appliances or environment is controlled without much human involvement. It saves power, time and efforts and is more efficient than the conventional systems. Home environmental monitoring is a major Internet of Things (IoT) application, which involves monitoring the inside and outside environment of the home. By using IoT technology, user can create advanced Home Automations Systems that can improve the quality of the life.

Let’s take one such example.

Example:

Let’s say our Home Automation System consists of an electric light bulb that can be controlled with the help of a mobile device. User will use mobile application to toggle light switch and this state will be sent to the mqtt broker. On the other side, electric light bulb with help of microcontroller receives the state sent by user. For this to happen, the mobile device will first define the topic it wants to publish on, then only it will publish the message. Meanwhile, the microcontroller attached to the light bulb subscribes to the same topic. Then once it receives the message that the device has published, it toggles light based on the state. It might also want to publish to another topic so that other clients can monitor the state of that light. Again, the broker role here is to take the message and deliver it to subscribed clients.

Topics are the way you register interest for incoming messages or how you specify where you want to publish the message. Topics are represented with strings separated by a forward slash. Each forward slash indicates a topic level. And also remember topics are case-sensitive. If you want to control multiple light across multiple rooms, you will need to come up with unique topic for these lights. Let’s suppose If we want to toggle bedroom light, the topic will be home/bedroom/lamp.

Now that we have 2 clients the first mobile application will publish to the topic “home/bedroom/lamp” with a message of “on” or “off” every time we push a button from app. In our demo we are using “MyMqtt” app from google play store. The second client will subscribe to “home/bedroom/lamp” and respond to the message by turning a light bulb on or off. And later it will publish with a message of “on” or “off” to another topic like “bedroom/lamp/state” so that other clients can monitor the state of that light.

Cloud for MQTT brokers?

MQTT on-premise broker is a rather time-consuming and demanding solution for any project. If we are talking about the quick launch of the solution for the Internet of things, then launching your own data center with a server for the MQTT broker will require resources for the initial launch and installation. Plus, expanding and scaling the on-premises broker creates a lot of problems when migrating to new servers.

Now let’s compare this solution with a cloud service, where for a minimal cost you can quickly connect your project to high-quality service and start using the MQTT protocol. With a cloud service, you also get support for your project and an already configured security system on the server and the ability to increase your capacities almost without limit. Placing the MQTT broker in the cloud can be a successful strategy both for small projects and for corporate-level projects.

Cloud-based MQTT brokers are many, like:

• Amazon
• Cloud MQTT
• Google Cloud IoT Core
• Heroku
• IBM
• Microsoft Azure IoT

Conclusion

MQTT is a communication protocol based on a publish and subscribe system. It is simple to use and it is great for Internet of Things and Home Automation projects. On the other hand, choosing a right cloud provider to service MQTT also gives you a lot of options now and you can use the message broker in your existing cloud, or choose the most suitable for your task.

How to find the right digital partner for your Enterprise

This post is a companion to our earlier blog on What is digital transformation. These articles, together, will help an enterprise evaluate the need for a digital transformation and how to go about finding a partner for the same. In this article, we present important objective & measurable ways to select your technology partner. We highlight certain requirements that are mandatory and a few “good to have” traits. As we highlighted here , Digital transformation is the planning, analysing, conducting & support of business operations via technology.

An enterprise can be considered as “Digitally compliant” if it has the following traits.

1. Customer experience, which is digital all the way. From inquiry to after-sales
2. Continuous improvement based on analytics which is powered by AI-based tools
3. Backend architecture which is almost entirely in the cloud or with minimal. on-premise/hybrid systems
4. Internal business process and core business practices which are highly automated
5. Tie-ups and collaboration with tech partners at an organisational level

Selection of a digital partner can be subjective and/or objective.

Subjective reasons to select a digital partner

1) Confidence in a particular partner because they are local and hence trusted

2) Mandated by law to provide opportunities to a specific group in your country, state etc

3) Personal relationship of any kind or previously committed to them

4) Recommendation by a trusted authority or partner

5) Influenced by size, scale, turnover and other factors and many more…

Subjective reasons are just that, and hence we wont get too much into discussing that. Whether subjective or objective, there are some mandatory checks to be done while selecting a technical partner

Mandatory Checks before selecting a partner

1) Technical competency

2) Legal checks

3) Communication modes, times, channels

4) Certified, Compliant within the context of your requirement

For the sake of brevity, let us consider that you have reached a decision to induct and infuse new technology or more technology into your business. You have your reasons, you made your decision and hence you are in the deep end now. Maybe you want to open up a new sales channel or you might want to save costs on existing IT infrastructure. Perhaps you want to take a final decision on setting up the new plant or improve training programs for your staff

1) Ask your potential digital partner “Why do I need to go the digital way?” and “How best should I leverage technology?”

Ultimately, you are trying to solve a problem or provide a service or build/change a new order or an existing order.

And you are hoping technology,

“THE ENABLER”,

will help you do so. But how?

A potential partner, and an able one, will see your existing working, identify pitfalls, understand challenges and suggest a remedial course of action or a new course of action which will not just fix or build your existing issues/process, but also help you generate new value from it.

In simple terms, they should present you a road map of taking your business to its next version. And they should help you understand how in a simple manner without a bucket load of tech jargon. The clearer they are in convincing you about solutions, proposing alternatives etc, the better they are. The quality of the answers can be gauged by simple questions likes

What modifications are required to go this route as proposed by the potential digital partner?

How sustainable is this solution they are proposing?

Is this long term?

Are there alternatives? Have they considered the competition?

Will this solution add more value?

2) Look for a domain specialist or one with relevant experience in your domain

 Consider this. Your domain or business vertical is very diverse. It has a plethora of products, services, legacy data, use cases, govt rules around those, compliance laws, trade rules, etc. What you are essentially doing is trying to take this entire ecosystem of your service or business and take it to the next level with technology. A technology service provider might not be able to understand your domain as well as you do. For a variety of reasons of course. Prior experience of a particular domain gives a unique blend of understanding and know-how.

For example, Confidentiality of patient data in a health care solution is not a “good-to-have” feature. It’s mandatory! A tech partner who has knowledge of a compliance policy like HIPAA, will be able to deliver better solutions to the customer. Depending on your need, a tech partner who is a domain expert or has experience in a similar domain might be the most important factor in driving your business forward.

3) Partnerships

In addition to providing the core requirements you have, your potential technology partner should be able to evaluate the areas where digital transformation can make a positive impact, i.e provide measurable outcomes. A digital partner should be able to highlight a diverse range of portfolios strung together in partnerships with other customers. Partnerships represent trust. And repeat business from the same partnerships implies quality plus trust.

4) Work culture

Work culture is a very good barometer of a vendor’s working style and more importantly Integrity. A vendor that creates a work culture which draws its employees to its workplace is a happy workplace. And it’s no secret that a happy workplace is a productive workplace. Work culture is the representation of the organization’s

values, beliefs and ethics. It is necessary to highlight that choosing a vendor with a work culture that is successful, might not necessarily work for you. But rather, choose a vendor with a work culture or belief system similar to yours.

5) Adaptability and Flexibility

Process in execution helps an organisation define a measurable scale. This defines the right way of execution and it measures any deviation from the defined path. In general terms, processes exist to help deliver better quality results. Whatever be the endeavour. While these are wonderful qualities in an organisation to have, not all tasks and processes can be defined with precision. Sometimes an organisation has to deviate from the normal order of execution because the situation demands it.

For ex, Imagine an overnight change in the laws of a country which increases quality checks for a said product. All things considered equal, a flexible and adapting vendor will be able to execute the process within the ambit of the new laws, on the promised timelines without getting rigidly bound to a fixed way of working. For e.g. Executing the steps in the quality check process concurrently wherever possible

6) Look for a partner, not a vendor

Finally, whatever you seek to accomplish will be driven by a group of people. Process, documentation, prior track record, compliance, recommendations etc are good measurable metrics for selecting the right partner. But as with any partnership or agreement, whether civil or business, look for a partner who believes in your goals.

What drives them or excites them? A need to make lasting change?

Does your requirement motivate them? How?

Can they find any value in this partnership which is not based on money?

Do they believe in your vision? And if so why?

If the answer to these questions is mostly yes, there is a good chance you met your perfect technology partner

Finally, a technology partner doesn’t just build solutions and leave. The right technology partner is a co-passenger in your journey. A technology partner begins by evaluating, understanding your business. They share your vision and passion. Then they provide a long term roadmap with measurable outcomes. They are engineers and designers at heart. Finding the right partner is thus a combination of right people having right knowledge with strong values

Protocol oriented programming

Protocol oriented programming(POP) is a paradigm that has come into the limelight with the advent of Swift. Different languages over different periods have had some flavor of POP in them, but there are some traits unique in the POP central to Swift, which gives them a measurable advantage over OOP. That is not to say that OOP is flawed and or POP is the knight in the shining armor. POP simply extends OOP with a few new additions that help in writing better code ergo, better systems

Contents

a. Existing system example

b. Problem with Inheritance

c. Enter protocols

d. Protocol Extensions

e. Protocols & Value types

---

1. Existing system example

Let’s take a simple example to see how OOP and POP work on the same problem. Consider that we are contracted to build a vehicle that can be driven. The requirement is we will be asked to build many vehicles that will have different colors, number of wheels, different engine capacity, etc. Coming from the OOP world, the core of the solution would be something like this

Everything works fine. SmallCar, RaceCar both can be driven. They also can have their unique traits.(noOfSeats(), nitroBoosterCapacity() etc). No paradigm maps the real world as efficiently as OOP, and hence we can apply principles of real-world like inheritance in object modeling. That’s the beauty of it.

However, the real world is far from perfect, and that seeps into its derivative like OOP. Consider the same example above. The customer has now contracted you to build the ability to have wipers for the existing category of vehicles. So now Vehicle can be modified to have the ability to wipe

Courtesy, inheritance, all the categories of vehicles created hitherto can wipe its screen. RaceCar or SmallCar can simply call wipe() and startDriving() safely in the rains! The customer is now happy and since you are so awesome in building systems he now asks for introducing a new class of vehicle, A two-wheeler known as a motorcycle. The first reaction would be to subclass Motorcycle from Vehicle. In this case, Vehicle would not be useful. Why? Semantically a motorcycle is a vehicle so we should be able to use the Vehicle class. But the problem is if a Motorcycle inherits from Vehicle it would also inherit the ability to wipe(). Needless and absurd as well! So if we don’t extend Motorcycle from Vehicle, all the complex logic and business rules which are available through Vehicle namely in startDriving() will not be available to a Motorcycle. We could simply argue that ignore the ability to wipe() in a Motorcycle, but that’s knowingly introducing an association in the system which is not required. So what’s wrong with our design?

OOPs, OOP has done it again!

A subclass may not need all the features from its parent class. A child who has a rich, alcoholic father will happily choose to inherit his wealth but would keep his distance from his father's drinking vice(hopefully!). Similarly, a subclass may not require all the traits of its superclass. Since most of the languages do not support multiple inheritances we cannot break the superclass features into multiple smaller classes and have the subclasses inherit from the required ones.

OOP does not do a great job when it comes to this.

2. Problem with Inheritance

Inheritance is a great mechanism to reuse code and build software, but it is not particularly great when it comes to a selective association. The class that gets inherited is imbibed in the DNA of the subclass whether it likes it or not. It’s like a mobile data plan which comes with a host of great features that you are interested in but also with a few meh! features which you would have rather not wanted if sold individually. But since it’s part of the package you can’t escape it.

3. Enter protocols

Protocols have been in existence since OOP itself and it offers another way of designing and modeling classes. Let’s consider the above example of vehicles and how we could design the same using protocols

As we can see, with protocols we have been able to break the dependency enforced by Inheritance on the class Motorcycle when it inherited Vehicle. Now any new category of Vehicle which does not require wipers won’t be burdened with the same. It simply does not conform to it. Don’t need it, don’t ask for it and so not burdened with it! For e.g. a scooter. The protocol used in Swift generally is implemented as an abstraction (virtual class, interface so on and so forth) in many other languages. Nothing really new there. Readers would have noticed here that the need to define the logic of driving is now on the concrete class which implements Vehicle i.e both RaceCar and SmallCar now has to define how to startDriving(). This can lead to the repetition of code and logic. Besides if protocols have been available in many other languages what’s so special about POP in Swift? The answer is Protocol extensions.

4. Protocol Extensions

The cornerstone for POP is protocol extension. Swift (v2.0 onwards) allows a protocol to have a generic behavior that can be overridden as well. This generic behavior allows every implementation to “inherit” this by default. If they don’t like the generic behavior, well, simple, change it i.e., override it.

For e.g. the above example can now be written as

This is exactly like inheritance with the extra association of startWiper() now broken down to a need basis. Every implementation of Vehicle now has the complex startDriving() logic available by default i.e it has “inherited” the same from the protocol. Plus motorcycle does not have any association with Wipers. Thus protocol extensions help implementation to have the ability to “inherit” from a protocol and keep the dependency to an atomic level. i.e A protocol should contain only those contracts which an implementation or concrete object has to implement. Otherwise, it exhibits a fat interface problem. For e.g., Vehicle was a fat interface because it contained startWiper() which was not required for all subclasses.

5. Protocols & Value types

Swift advocates using value types over reference types wherever applicable. The use cases, benefits of both are well documented and won’t be covered here in this post. Value types like struct, enum can extend Protocols as well thus extending the benefits of designing using Protocols to even value types. This is one of the main reasons why Apple evangelizes using protocols over classes.

Bottom Line

POP extends OOP to provide another level of abstraction which helps a developer to write better code and design reusable components. Everything has its place under the sun and OOP is certainly not to be totally replaced with POP. Only where required. The decision to use POP or OOP can be context-specific