How Do You Decide Which Protocol to Use in an IoT Application?

[EVblog1]

I made a small IoT project just for fun to explore how IoT applications work.

The setup is simple. A temperature sensor is connected to an ESP32. The ESP32 reads the temperature and sends it over my Wi-Fi network using HTTP/TCP/IP through my home router. On my laptop, I wrote a small server that receives the data. The server stores the readings in a MySQL database, and I created a simple dashboard to display the room temperature. Everything works as expected.

Now my question is not about getting it to work. it already does. What I'm trying to understand is whether I'm using the right technologies for the job. I know the same project could also be implemented using MQTT, WebSockets, or other communication methods. Since my project is simple, HTTP worked fine, but I'm not sure  how experienced engineers decide which approach is the best for a particular application.

When do you choose HTTP, MQTT, or WebSockets? Are there any general rules or factors you consider

I'm not asking for a comparison table. I'm more interested in understanding the thought process behind choosing one communication method over another in real projects.

[abeyer]

First, I'll go out on a limb a bit here and assert that IMHO websockets are pretty rarely the right answer here. They're fine for browser based apps, but unless that's what you're building I wouldn't reach for them.

A few things to consider:

• What are your compute and power budgets?
• Do you have a full networking stack available on the device?
• Do you need one-off messages, persistent connections, or some hybrid?
• How many devices will you support, and how many receivers need to get that data?
• What kind of reliability/recovery guarantees do you need?

[EVblog1]

First, I'll go out on a limb a bit here and assert that IMHO websockets are pretty rarely the right answer here. They're fine for browser based apps, but unless that's what you're building I wouldn't reach for them.

You mentioned that WebSockets are rarely the right choice unless it's a browser-based application.

Could you explain the reasoning behind that? what limitations or disadvantages make WebSockets less suitable for most IoT applications.

[5U4GB]

Is WebSockets ever the right thing? It's emulated TCP over HTTP over actual TCP, created because... well buggered if I know. Someone was bored?  Y'all watch this?

To reply to the original question, it depends what you want to use it with.  If it's something like HA you can't go wrong with MQTT.

[EVblog1]

Is WebSockets ever the right thing? It's emulated TCP over HTTP over actual TCP,

Yes,  HTTP, MQTT, and WebSockets can all implemented over TCP/IP

To reply to the original question, it depends what you want to use it with.  If it's something like HA you can't go wrong with MQTT.

You mentioned that MQTT is a good choice for Home Assistant. both HTTP and MQTT establish a TCP connection before exchanging data. With HTTP, communication follows a request-response model where the client sends a request and the server returns a response. With MQTT, the client first connects to an MQTT broker, and once the connection is established, it can publish messages to topics or subscribe to topics to receive messages. So, in both cases, a connection is established before data is exchanged, but the communication models are different.

What characteristics of MQTT make it a better fit in that case compared to HTTP

[ejeffrey]

Web sockets are basically a way to do similar to TCP sockets in a browser based javascript application.  But if your client isnt a browser they just add extra overhead and complexity compared to regular TCP.

[ledtester]

I made a small IoT project just for fun to explore how IoT applications work.

The setup is simple. A temperature sensor is connected to an ESP32. The ESP32 reads the temperature and sends it over my Wi-Fi network using HTTP/TCP/IP through my home router. On my laptop, I wrote a small server that receives the data. The server stores the readings in a MySQL database, and I created a simple dashboard to display the room temperature. Everything works as expected.

If you want to reduce network traffic I would consider using UDP. It's connectionless so the ESP32 can just send a packet when it wants to without all of the TCP handshaking and HTTP overhead.

Also, I haven't used it but maybe look into ESPnow. Your temperature ESP32s would talk to a central ESP32 via ESPnow and the central ESP32 would send data to your computer via a serial port or whatever.

[5U4GB]

What characteristics of MQTT make it a better fit in that case compared to HTTP

HTTP is just an awkward transport mechanism. Once you've got that you're barely better than using TCP, just with more overhead. So once you've got HTTP, or TCP, or Websockets, or CONS for that matter, you still need to figure out what to run over that.

MQTT OTOH is a structured-data communications mechanism with a pile of extra functionality if you care about it (QoS, auto-discovery, etc). It's a complete solution, not a starter set for getting data from A to B.

[EVblog1]

I often see people recommend MQTT over HTTP, with efficiency being one of the main reasons.

I'm trying to understand what makes MQTT more efficient than HTTP in practice. Could you explain where that efficiency comes from and in what kinds of applications it makes a noticeable difference?

[5U4GB]

They're totally different things.  HTTP is a transport protocol, essentially a wire from A to B (with a bit of framing), MQTT is a full IoT comms mechanism.

[abeyer]

I often see people recommend MQTT over HTTP, with efficiency being one of the main reasons.

I'm trying to understand what makes MQTT more efficient than HTTP in practice. Could you explain where that efficiency comes from and in what kinds of applications it makes a noticeable difference?

from this article which does some quantitative comparison (unfortunately it is no longer live, and fidgety to load even via waybackmachine due to its use of javascript that breaks the archive... but you can get it to work if you block script or hit escape as the content first flashes up)

The real advantage of MQTT over HTTP occurs when we reuse the single connection for sending multiple messages in which the average response per message converges to around 40 ms and the data amount per message converges to around 400 bytes. Note that in the case of HTTP, these reductions simply aren’t possible.

I'd add, though, that both of these are reasonably 'heavy' options given they need at least a full TCP/IP stack and likely TLS... so given that, the relative perf differences might not seem that relevant overall.

I also think that a bigger argument in favor of something like MQTT is that the broker model introduces a logical and functional decoupling between your client devices and backend services which often becomes necessary as systems grow. Better to go the well trod path than try and roll your own on top of http.

[rteodor]

I often see people recommend MQTT over HTTP, with efficiency being one of the main reasons.

I'm trying to understand what makes MQTT more efficient than HTTP in practice. Could you explain where that efficiency comes from and in what kinds of applications it makes a noticeable difference?

MQTT was born out of stringent efficiency needs. It was developed to monitor oil pipelines and the data was supposed to be sent by satellite. Which at the time, about a quarter century ago, was very expensive. Along with the advantages enumerated on its Wikipedia page it gets you to a bit higher level in the OSI stack than TCP/UDP. HTTP can put a lot of data into complicated structures and you don't want that because packing/unpacking of that data consumes the scarce resources available on a MCU. Simple measurements data like you have there, can be put in the much more simple structures that MQTT provides. That is what MQTT was made for and its good at that. HTTP was made for something else and it too is good at what it does since you can read my crappy post.

[paulca]

HTTP is "point to point".  Websockets are a hack to get around it's request/response nature.  Wrong protocol for an "Event based system" like IoT.

MQTT is a "Message bus".  Perfect for event based systems.  MQTT is one to many (or many to many if you are brave/careless).

So how that works is... your temperature sensor "publishes" it's data on a "topic".  It can (and I do on mine) set these to "retained".  This means that any subscriber to the topic will recieve the last message sent when it first subs.  It's handy for "seeding" on restart.

Why it matters.  You currently have one script which is only interested in the temp sensor.  If you keep going, you 100% will end up in a place where 3 or 4 different components are interested in the temp sensor and it would be ideal if they all agreed...  you will also have components interested in a whole range of different things from other sensors and other automation outputs.

This is where HTTP will start to be painful.  Especially considering if each component is "polling" on HTTP then each component can get a slightly different value than the others.  It's almost guaranteed.  That is not nice to try and model.  MQTT one component "publishes" to the topic and the components interested have subscribed, they each receive a carbon copy of that published data.  The only reason they can get different values is if things are VERY congested and a component simply misses an event.  Even then, it won't be wrong it will just be more up to date.

It does not have to be MQTT it could be RabbitMQueue, JMX, Kafka.  However.  MQTT is fairly standard in the sector.  So you will find more gadgets, more software and more documentation specfic to IoT with MQTT.

There is another reason.  When you start to look for more and more sensors/gadgets etc.  The "off the shelf" "smart home" garbage looks attractive and some of it does work fine.  If you value your privacy and safety.  I recommend NOT using ANY "Wifi based" smart home garbage.  The most robust / secure solution is "Wired" however "Wired" gets expensive very, very fast.  For "RF" you can use old-school RF 433/435Mhz and MQTT converters.  This works fine, but the devices supported by that protocol are basically just buttons.  Zigbee and ZWave are more IoT focused wireless mesh protocols.  Far more stable than Wifi, mains powered devices automatically assume the role of router for battery powered devices and select by proximity/signal.  (In the case of Zigbee anyway).

"Zigbee2Mqtt" is a tiny little server which converts most common Zigbee devices to MQTT devices, removing the need for ANY cloud based hub.  You can totally DIY the hub.

HTTP will find it's way in there, yes.  I have several devices which only provide data via a periodic HTTP POST, so I just "bridge" those onto the MQTT bus.  My boiler and radiator smart switches speak HTTP, so a "Controller" which receives MQTT does the HTTP part for it.

On "Saving the results to MySQL".

Firstly.  I assume you mean MariaDB?  If you installed MySQL I would uninstall it.  It's not what you think it is.

Besides.  It's the wrong tool and will cost you in terms of maintenance and become a BEAST to maintain if you want to retain any data volume or duration.  The better tool is a "TimeSeries" database.  Influx, Prometheus etc.  They are specifically designed to store nano-second timing data and designd for huge amounts of metrics per second.  At small scales they barely register on CPU, but will consume as much of your memory as they like apparently.  Influx/Prometheus then open the door to "Grafana" or similar graphic/reporting/alerting front end.

With all of that in place.  Your "UI" front end can pick any way it wants to intergrate.  I put a REST-MQTT bridge onto mine.  It can query the bus over that to update the values.  It can also publish data, like temporary boosts or change the target temps or schedules.

[EVblog1]

On "Saving the results to MySQL".
Firstly.  I assume you mean MariaDB?  If you installed MySQL I would uninstall it.  It's not what you think it is.

I had MySQL installed on my Windows 11 laptop and was using it to store the sensor data. I have since uninstalled it because I noticed it was making my system

If you use only MQTT and don't use HTTP, how would you view the dashboard? As far as I understand, a web browser can't access MQTT directly, so wouldn't you still need HTTP to serve the dashboard?

[paulca]

Protocol breakdown:

HTTP - Request response - Transactional - Synchronous - Has a return code.  Keep Alive is available, but un-desired for many reasons.
Websockets - A hack invented to get around the problems from the above and "Polling loops" in web front ends.

Scenario.  You hit "Pay Now" on a checkout and a spinner appears.  The process has been launched "Async" on the server and the front end now just has to twiddle it's thumbs until its completed.  With HTTP alone you would either need to hold the connection open with keep alive until it completes (undesired for many reasons), or "poll loop it".  "Are we there yet? Are we there yet? Are we there yet? Are we there yet?"  Forever if the other end never answers YES.

So websockets were invented to reverse/invert the protocol.  Now the front end in the browser can just put an event handler on the websocket and when the backend is ready it will send an event over it.  This wakes up the front end from effectively Thread.sleep() and says, "YES" or "NO".

The trouble is... it's a bit hacky and solves the "Persistent synchronous connection" by creating an async connection in the background.  They are well know for being dropped by URL filters and application firewalls.  Maintaining the fake connection means complex JS libraries client side.

MQTT - Async - non-transactional - "Fire and forget" - Publish/Subscriber - Producer/Consumer.  Many to many.

When you have a complex set of "producers" ie, sensors which send data whenever they like and consumers which want to be notified about data updates or refreshes.  An async message bus is almost always the way to go.

The only catch is... it will force you completely into the "Asynchronous" landscape.  This brings concurrency traps if you are not paying attention.  However these will also occur in HTTP pooling setups where they are un-expected and usually therefore more damaging.

[Kalvin]

First, I'll go out on a limb a bit here and assert that IMHO websockets are pretty rarely the right answer here. They're fine for browser based apps, but unless that's what you're building I wouldn't reach for them.

A few things to consider:

• What are your compute and power budgets?
• Do you have a full networking stack available on the device?
• Do you need one-off messages, persistent connections, or some hybrid?
• How many devices will you support, and how many receivers need to get that data?
• What kind of reliability/recovery guarantees do you need?

I would add one more item to this list:

• Are you constrained with limited network traffic?

If you must minimize the network traffic for any reason (cost, power budget, etc.) you want to consider some other protocol that is not TCP-based. For example Coap and Lwm2m are UDP-based protocols, therefore they do not waste bytes for TCP handshaking. If the network traffic needs to be encrypted and the devices need to be authenticated, DTLS layer will help with that. DTLS is using UDP, and handshaking is very lightweight compared to TLS or similar protocols.

Addition: MQTT-SN is also using UDP protocol.

[Siwastaja]

Generic answer:
By understanding what you need, and by understanding what the protocols you name actually are. This two-piece understanding is mandatory; after that, the answer is obvious.

Forcing protocols, libraries, frameworks etc. which are designed for a totally different kind of problem is a relatively common issue which happens when someone decides the "tech stack" for company policy reasons, not technical reasons. It's very hard to make the wrong tool work. For example, if you want to transfer data between two small embedded devices, you can do it with websockets, but it will be quite a ride to do so, when maybe a simple UART-based text protocol would have been the right solution. And then again, if you have a web server and web browser and want to show real-time changing data, then websockets is meant for that.

[paulca]

On "Saving the results to MySQL".
Firstly.  I assume you mean MariaDB?  If you installed MySQL I would uninstall it.  It's not what you think it is.

I had MySQL installed on my Windows 11 laptop and was using it to store the sensor data. I have since uninstalled it because I noticed it was making my system

If you use only MQTT and don't use HTTP, how would you view the dashboard? As far as I understand, a web browser can't access MQTT directly, so wouldn't you still need HTTP to serve the dashboard?

For your "Grafana" dashboard or a custom dash board yes.

I got claude to create me a front end.  As I mentioned the secret was just making a "bridge".  HTTP REST requests for "value on topic" or "publish value to topic" from things like GET /topics/blah and POST /topics/blah - they integrate pretty well in that direction.  Just not great for "event response".  My dashboard still "polls" ever 5 seconds.  So does grafana technically.

In my setup...
MQTT is the "realtime" core data fabric.  All sensors, services, components and automations share the same data.  This is stateless (beyond what is retained on the bus) and emphemeral - it disappears when you switch it off and on again.  There is no "past" only "present".

Data is exhausted at roughly 3000 metrics per minute to InfluxDB for "Historical records".  This is actually HTTP too, batch metric publish over REST to InfluxDB.

Grafana dashboards are used to create pretty dashboards for the data with "At a glance", "Alarms" and "Historical" views up to 30 days in all cases and some go as far as 5 years.

A custom 'react' front end that can tweak config data etc.  A hint there.... put ALL your config data into topics as well.  Seed them on boot from defaults, but this permits a UI or app or service to change the config at runtime.  If your components subscribe to their config, a published update to teh config can be acted on immediately.

Any IoT system with more than a few sensors and actors will become a mess very rapidly if you don't maintain some form of rules and discipline.  I choose the classic MSA - no the botched modern version, just the "Each service is selfish and believes it is the only one".  One task/responsibility = One service.  When you write a service you should only be concerned with you "Input topics" and your "Output topics".  Nothing else exists.  This keep things "sane" and manageable.

On scaling.  I left that out, as I assumed you are dealing with "Home IoT" not "Massive sensor fleet of millions" scale.

Those 3000 metrics come from 24 micro-services and about 30 IoT devices publishing about 1500 values a minute, the 3000 is a not-quite-lie artefact of cascades.  The entire stack, including Zigbee to MQTT will run on a raspberry PI.  I run it in 2 VMs.  One for influx+grafana which is fairly beefy at 8Gb RAM.  One for the MQTT servers and python scripts.  1Gb.  Oh... and a x86 SBC running Zigbee2Mqtt in another 1Gb VM.  If you moved them all to one server it would need 8Gb of RAM and be fine.  InfluxDB memory mapping is the biggest load of all.

[EVblog1]

My temperature logging project is quite simple, so I understand that HTTP is probably sufficient. However, I have another project in mind that is much larger, and I'd like to know whether my design approach makes sense.

Suppose we're building an employee attendance system for a company with three office branches. Each branch has around 3,000 employees, so the total number of employees is roughly 10,000.

At each office entrance, an employee taps an RFID card to gain access. The hardware consists of an RFID reader, an MCU, an Ethernet interface, and the other required peripherals.

When an employee scans an RFID card, the reader returns only the employee's unique code. The MCU uses this code and creates an attendance record containing the employee ID, employee name, branch name, shift time, and the scan timestamp. This record is then sent to the central office server, where it is stored in a database. Admin, HR, and employees can later view the records through a web dashboard.

When we send sensor data to a server over a WiFi network using TCP/IP. I believe IP and TCP are two different protocols. IP is responsible for connecting devices using IP addresses. Once the connection is established, TCP works on top of IP

Now I'm thinking about the communication architecture and the order in which the protocols are used.

At the physical interface , we have several options, such as Ethernet or Wi-Fi. I would choose Ethernet because I think a wired connection is more secure and generally more reliable than a wireless connection

Once the Ethernet protocol is implemented , the next protocol I would implement is IP, which provides addressing so devices can communicate across the network.
Above IP, I would choose TCP rather than UDP because I don't want to lose attendance records. Although UDP has lower overhead, I think reliability is more important than speed in this application.

Once TCP provides a reliable connection, I then need to choose the application protocol. My current thinking is to use MQTT for sending attendance records from the MCU to the server, while using HTTP for the web dashboard since users will access it through a browser

Does this seem like a reasonable architecture?

This is simply one design approach that came to mind while trying to understand how protocol selection works in IoT applications. I'm not suggesting this is the best or only way to build such a system.

My goal is to check whether my understanding and thought process are on the right track. If I've misunderstood something , I'd really appreciate any corrections. I intentionally chose this larger example because I thought it would be more interesting to discuss the protocol choices and the reasoning behind them than my simple temperature logging project.

[5U4GB]

At the physical interface , we have several options, such as Ethernet or Wi-Fi. I would choose Ethernet because I think a wired connection is more secure and generally more reliable than a wireless connection

LA smog-signal networks are more reliable than some WiFi connections.

Above IP, I would choose TCP rather than UDP because I don't want to lose attendance records. Although UDP has lower overhead, I think reliability is more important than speed in this application.

I would use UDP for that, provided you can fit the message into a single packet. If you've got 10,000 people, presumably with many tagging in/out at the same time, you don't want to start dropping connections due to TCP overhead.  With UDP, just do the standard delay-fallback and remember to fail closed if you don't get a response after (say) five retries.

More empirically, test it with an SDN (software-defined network) where you can set latency and packet loss, and see what happens when 1,000 users all tag on at once.

[Psi]

IMHO the protocol would depend on what system you intend to use to control/read the IOT device.

If you wanted to use it in Home Assistant for example you might use MQTT or ZigBee or Matter or you could even just flash ESPhome to the ESP32 and use that out of the box.

[xvr]

When an employee scans an RFID card, the reader returns only the employee's unique code. The MCU uses this code and creates an attendance record containing the employee ID, employee name, branch name, shift time, and the scan timestamp. This record is then sent to the central office server, where it is stored in a database.

It sounds like you need some business logic, not just a data/event store (like in MQTT). If you plan to run a server to handle these requests, you might want to consider using higher-level protocols like gRPC.

[EVblog1]

It sounds like you need some business logic, not just a data/event store (like in MQTT). If you plan to run a server to handle these requests, you might want to consider using higher-level protocols like gRPC.

The scenario is only there to provide some context. I simply explained my thought process and why I selected those protocols. At the moment, I'm trying to understand how these protocols work together internally

[peter-h]

If I wanted the most dirt simple way of remotely reading a temperature sensor, with an embedded box, I would create a simple HTTP web page on the LAN say 192.168.1.200, and then open a port on the router and port forward incoming traffic, port 80, to 192.168.1.200.

The simplest possible web server is one which grabs packets from a socket, looks for "GET" at some short offset in the packet, and then sends back an HTTP page, which can be very simple. That page can self refresh (HTML does that) etc. I've done this, a simple HTTP server which has a pile of features including file upload and download (that needed some javascript).

Then you can see the temperature with a browser, which is probably what you want, but making stuff come up on a browser is never going to be totally trivial because the comms is driven by the browser i.e. it will go to public IP/index.html and see what comes back to it. A browser does not work unless presented with a properly formed HTTP page.

The security will be crap because that open port will be discovered by the chinese and russkies in hours... but what can they do? There are no credit card details to steal. HTTPS does not help with this.

If you do not need to use a browser, there are other ways e.g. use a GSM modem and send out an SMS every x mins I've done all that too. I even used to sell a product which transmitted a fax In the old days there were boxes like the Siemens/Cinterion GSM modems which could send out emails, for those who didn't want to do any work.

You don't need MQTT for this.

My biggest worry would be security because it will get attacked. Probably port knocking is a good idea. But does any common router implement a firewall which does that?

[ejeffrey]

My I would choose TCP rather than UDP because I don't want to lose attendance records. Although UDP has lower overhead, I think reliability is more important than speed in this application.

Definitely. These days it essentially never makes sense to use UDP for efficiency.  You use UDP when you are more concerned about data freshness than reliability.  For instance if you are streaming realtime data and of there is packet loss you would prefer to just get the most up to date data rather than retransmit the old data.  UDP also supports broadcast/multicast, but MQTT is designed to enable many of the benefits of multicast with a reliable transport layer.

My current thinking is to use MQTT for sending attendance records from the MCU to the server, while using HTTP for the web dashboard since users will access it through a browser

That sounds totally reasonable.