Smarthome Data Transfer Protocol: HTTP or MQTT?

Http vs mqtt, which data protocol is better for smarthomes

In the process of designing my Arduino based smart home project, I was posed with the difficult decision about what protocol to use. While an HTTP based system was incredibly easy for me to set up, MQTT is very appealing.

The system I have right now is operational and working. With HTTP, all I need is the server on the Arduino itself and the app.

While that's all well and good, it does have a pretty significant drawback. If I want to pull data from the server, a client has to constantly reconnect and update the data. This is pretty inefficient, especially given the context.

I had never had any exposure to MQTT before, but after looking into it, it's clearly a better choice in this application. Being that MQTT is a data-centric protocol, it offers a much greater response time and uses less bandwidth when compared to the document-centric HTTP.

The pub/sub pattern and broker allows all of the data to be stored in one central location, and any client can subscribe to messages. This differs from HTTP where I have to actually connect the clients, or as others would say, “make them aware of each other”.

This makes MQTT the perfect solution for IoT devices, considering that we're controlling devices and getting sensor inputs. (Not sending large amounts of data, while enabling me to push data to the server without “asking” first!)

A Quick Intro to Message Queue Telemetry Transport (MQTT)

MQTT is a publish-subscribe based messaging protocol that’s lightweight and very efficient. The main benefit of this type of pattern is that a device can easily subscribe to the published information, without having to actually connect to the other devices. It’s able to do this through the use of a broker server.

What's a Broker and What Does it Do?

The broker is just a server that acts as the middleman between the clients and the app. It receives the messages, filters them, and then sends the data to every device that subscribed to the message. You can think of the communication like a spoked wheel, with the broker in the middle.

Since devices connect to the broker, your clients don’t need to know each others IP addresses. Furthermore, the broker has a permanently open TCP connection, updates messages as they change, and buffers the messages until the connection is stable.

MQTT Spoke wheel representation. Server is in the middle and communicates with all devices and sensors

Although MQTT requires a broker, the setup seems to be pretty straightforward. (At least for Linux.)

There are different brokers you can use, but a popular choice for D.I.Y’s is Mosquito. It's an open source broker provided by Eclipse. (Yup! The IDE guys.)

As a quick note, if you’re looking for a cloud based solution, click here to check out Amazon AWS. or Adafruit IO. They both seem like good choices.

Looking around, it seems many people opt to use a Raspberry Pi with Mosquito for their broker. If you already have a Pi, this may be a good choice. I’ve heard of performance issues with this setup, but as I don’t own and don’t plan on buying a Pi, I admittedly haven't looked into it that much.

I’ll be using an old Dell for my broker, with either Fedora or CentOS running Mosquito. I’m familiar with CentOS, but many other OS’s will work as well. Mosquito has a free server for testing/development to get you going, but be aware it isn’t secure.

MQTT Publish and Subscribe

When a client connects to the broker, it can start publishing messages that must include topics. Every client that wants to receive messages can subscribe to a certain topic, and then the broker will deliver all the messages with a matching topic to the client.

Topics are just UTF-8 strings, but keep in mind it’s good practice to use ASCII characters. Using UTF-8 characters can make it hard to find typos, and sometimes won’t display correctly.

If you’re familiar with HTTP, you’ll notice the hierarchy of the topics looks very similar to URLs.

For example, if I want to send and receive data from a client in the living room (turn on a light), it may look like this -


Clients can either subscribe to the topic exactly or by using a wildcard. The plus sign (+) is used as a single level wildcard that can be used for one arbitrary hierarchy -


This will result in receiving all the messages from temp sensors located throughout the entire house. This will let you collect data based on a single hierarchy.

There’s also another wildcard that can grab multiple subtrees at once. This multi-level wildcard is defined by (#). For example, you can subscribe to all underlying hierarchy levels by entering -



MQTT definitely has some clear advantages over HTTP for home automation, and it doesn't look too hard to implement either! While I’ll be taking the more “difficult” approach of using my own in-house server, using a cloud-based solution can simplify things even more.

I’d say look forward to more posts about MQTT, but next on the list is hardware! In particular, one of my biggest gripes about typical D.I.Y light switches is that they remove the ability to manually operate them. (By using relay boards, or having a servo operate the switch.)

The design I have in mind is a capacitive touch switch driven by 555’s for manual operation, bypassing the capacitive touch switch with the Arduino, and using an SSR for the actual switch. (Although, I still have to find a way to inform the Arduino and the app if the light has been switched on or off manually.)

Subscribe for News and Updates!

Like My Site?

Share it with your Friends!