A sensor measures something. Getting that number to a screen you can read from another city is a separate problem, and there are several quite different ways to solve it. The right one depends on how far the sensor is from the nearest internet connection, how often it reports, and how long it has to run on a battery.
This article separates two layers that people often mix up. The first is the link, the radio or wire that carries bits between two devices. The second is the protocol, the agreed format of the messages sent over that link. Wi-Fi is a link. HTTP and MQTT are protocols that usually travel over it.
The links
Wi-Fi
The most familiar link. Wi-Fi gives a sensor direct access to your router and the internet, with plenty of speed. Its weak points are range, which is a few tens of metres indoors, and power. Keeping a Wi-Fi radio awake drains a battery in days, so battery sensors that use Wi-Fi sleep most of the time and wake only to report. Most ESP32 and ESP8266 projects use this link.
Proprietary 433, 868 and 915 MHz radios
Many weather stations and garden sensors talk to their base station on one of these sub-gigahertz bands, depending on the region. The signal passes through walls better than Wi-Fi, and the sensor can run for a year or more on two AA batteries. The catch is that the format is the maker's own, so the base station or gateway has to translate it. Ecowitt and Bresser use designs of this kind, and the gateway then forwards the readings over Wi-Fi.
Bluetooth Low Energy
Very low power and built into every phone, which makes it popular for small thermometers and hygrometers. The range is short, around ten metres indoors, and a Bluetooth sensor cannot reach the internet on its own. A phone, a hub or a Wi-Fi bridge has to be nearby to relay it.
Zigbee, Z-Wave and Thread
Low-power mesh networks used by smart home hardware. Each mains-powered device repeats messages for its neighbours, so coverage grows as you add devices. They need a hub or border router to connect to the internet. Matter is a newer standard that sits on top of Thread and Wi-Fi and aims to make these devices work together across brands.
LoRa and LoRaWAN
LoRa is a radio technique for sending very small messages over long distances using very little power. LoRaWAN is the network standard built on it. A sensor sends a short packet, a gateway somewhere within range picks it up, and a network server passes it on to your application. Range is measured in kilometres in open country and a few hundred metres in a dense city. Messages are small, a few dozen bytes up to a couple of hundred, and regional rules limit how often a device may transmit. It suits farms, remote tanks and anything far from Wi-Fi. The Things Network is a community network that many hobbyists use.
Cellular
Sensors with a SIM card, often using the low-power variants called LTE-M or NB-IoT, work anywhere there is coverage. They cost more per device and need a data plan, but need no gateway of your own.
Wired links
Industrial sensors often use RS-485 cabling with a protocol called Modbus. It works reliably over long cable runs and is common in factories and solar installations. A converter or gateway brings it onto a network.
The protocols
HTTP and HTTPS
The protocol of the web. The sensor sends a request to a web address with the reading attached, and the server replies. Nearly every platform and language can do this, which makes it the lowest-friction choice. Each message carries some overhead, and the sensor has to open a connection each time. Fine for one reading a minute, wasteful for many per second.
MQTT
A lightweight publish and subscribe protocol designed for small devices on unreliable links. Sensors publish messages to named topics on a broker, and anything interested subscribes to those topics. It is very common in home automation. We explain it in what MQTT is.
CoAP
A protocol designed to give constrained devices something like HTTP, but over UDP with much smaller messages. It appears in some low-power networks and industrial products. It is less common among hobbyists.
WebSockets
A long-lived two-way connection over the web. Useful when a page needs live updates pushed to it, less common as the way a sensor itself reports.
Which to choose
| Situation | Good fit |
|---|---|
| A board in your house or garden, within Wi-Fi range | Wi-Fi with HTTP, or MQTT if you already run a broker |
| A battery sensor that must last a year | A sub-gigahertz radio with a gateway, or LoRaWAN |
| A sensor far from any Wi-Fi | LoRaWAN or cellular |
| A small thermometer to read on your phone | Bluetooth Low Energy |
| A smart home with many mains-powered devices | Zigbee, Thread or Wi-Fi |
| Industrial equipment already wired for it | Modbus over RS-485 plus a gateway |
Where SensorConsole fits
SensorConsole sits at the end of the chain. Whatever link and protocol a sensor uses locally, something has to hand the reading to the internet, and from there the dashboard needs it as a web request or a pull from the maker's cloud. A Wi-Fi gateway, an ESP32, a Raspberry Pi or a small script can all do that job. The How it connects page lists the ready-made routes.