Smarthome Data Transfer Protocol: HTTP or MQTT?


In the process of designing my Arduino based smart home project, I had 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 reconnect and update the data continually. That is pretty inefficient, especially given the context.

I had never had any exposure to MQTT before, but after looking into it, it’s a better choice in this application. Being that MQTT is a data-centric protocol, it offers a much higher 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. That differs from HTTP where I must actually to connect the clients, or as others would say, “make them aware of each other”.

MQTT is 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 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 diagram showing connection between sensors, the server, and a phone

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.)

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.

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

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 specific 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.

The hierarchy of topics is simple. 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 and can be used for one arbitrary hierarchy. –


This will result in receiving all the messages from temp sensors located throughout the entire house. It lets 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 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 challenging approach of using an 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 operate them manually. (By using relay boards, or having a servo work 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.

TB Freelance Logo Full

Timothy Beachboard, AMA-PCM®
Digital Marketer and Web Copywriter
Wilkes Barre, Scranton Area, PA

Business Hours
Monday-Thursday: 9am - 6pm
Friday: 9am - 5pm

Facebook Link Linkedin Link Twitter Link