When people start sending sensor readings to the internet, they often ask whether they should use HTTP or MQTT. The honest answer is that for a typical home project it does not matter much, and the simpler one wins. Here is how to tell when it does matter.
What each one asks of you
| HTTP | MQTT | |
|---|---|---|
| What you need on the receiving end | Any web server | A broker that is always running |
| Code on the sensor | One request, no extra library on most boards | A client library and a connection to manage |
| Message size | Headers can add several hundred bytes | As little as 2 bytes of header |
| Connection | Opened for each report | Kept open, or reopened after sleeping |
| Direction | Sensor asks, server answers | Either side can send at any time |
| Several receivers for one reading | You send it more than once | Built in |
| Works through strict firewalls | Almost always | Sometimes blocked on unusual ports |
Choose HTTP when
- You report every minute or less often. At that pace the extra size of a request does not matter.
- The sensor sleeps between readings. A board that wakes, sends one request and goes back to sleep gains nothing from a connection that is kept open.
- You want the fewest moving parts. There is no broker to install, secure and keep running.
- You send the reading to a service you do not run yourself. Almost every online service accepts web requests, and few accept MQTT.
- Your board has little memory. A basic request needs less code than an MQTT client.
Choose MQTT when
- You have many devices and several programs that want the same readings, such as a dashboard, a logger and an automation rule.
- Devices need commands as well as readings. Switching a relay on from a phone needs a message in the other direction, and MQTT does that naturally.
- You send many small messages per minute and want to save bandwidth or battery on a link that stays up.
- You already run Home Assistant or another hub. It probably has a broker, and your devices may already be using it.
- You want the last known value available instantly, which retained messages give you, or you want to know when a device vanishes, which the last will feature gives you.
A common middle path
Many setups use both. Devices around the house publish to a local MQTT broker, because that works even when the internet is down and keeps things fast. One small program then forwards the readings you care about to an online dashboard over HTTP. The devices stay simple and local, and the dashboard receives plain web requests, which any hosted service can take.
That is exactly how SensorConsole is meant to be used with MQTT. The dashboard takes web requests, and a short script bridges the two. We give a working script in this guide.
Two myths worth dropping
- "HTTP is too heavy for small boards." An ESP32 or ESP8266 sends web requests without effort. Only the smallest boards without Wi-Fi struggle, and they need a different link anyway.
- "MQTT is more secure." Neither is secure by itself. Both can run over encrypted connections, and both can be left wide open. What protects you is using TLS where the board allows it, using strong credentials, and not exposing services you do not need to.
A rule of thumb
If one device reports to one place every minute or so, use HTTP. If a group of devices shares readings with several programs and takes commands, use MQTT. If you are unsure, start with HTTP. Switching later costs an afternoon, and you will have learned what you actually need.