A sensor is only useful if its reading gets somewhere that keeps it. That somewhere is an endpoint — and there are several honest ways to reach it, from a tiny chip pushing a single packet straight to the cloud, to a full hub running your whole place. They all work. The trick is picking the one that fits, not the one that sounds most impressive.
01Sense, push, endpoint.
Every connected sensor does the same three things. It senses — measures something real. It pushes — sends that reading out over a network. And it lands at an endpoint — a place that receives the reading and keeps it. Everything downstream, the dashboard and the alerts and the analysis, reads from the endpoint, not from the sensor.
Two things worth saying up front. First, the endpoint might be a small server at your place or a service somewhere else, yours or a provider's — and that is fine, because (as data is king puts it) ownership is about whether you can get your data back out, not about where it sits. Second, the sensor does not care what the endpoint is, and the endpoint does not care which sensor sent the reading. They agree on the reading and nothing else, which is what lets you mix and match the pieces below.
02The options.
Here are the common paths from sensor to endpoint. None is the "right" one; each fits a different situation.
A chip pushing straight to the cloud.
A small microcontroller (an ESP32 is the usual one) reads a sensor and pushes the value directly to a cloud endpoint — a single small message every minute or two. No hub in between. It is the simplest path with the fewest moving parts: a few dollars of hardware, a bit of code, and the reading is on its way. Ideal when you have one or a handful of sensors and a network where they sit.
A Home Assistant hub.
A small computer running Home Assistant sits in the middle: it collects readings from many sensors, shows them on dashboards, runs automations, and can push them onward to a cloud endpoint too. More to set up than a single chip, but it earns its keep once you have several sensors, want automations, or want one screen for the whole place. Our Home Assistant section is the depth for this route.
Hort Assistant.
OAT's own grower-shaped take on this approach — the hub pattern, tuned for the things growers actually do. See the Hort Assistant page.
And these mix: a long-range radio can carry a far-off sensor's reading to a hub that has internet; a hub can forward to the same cloud endpoint a lone chip pushes to. The endpoint does not mind how the reading arrived.
03How to choose.
The appropriate path falls out of a few questions:
- One sensor, network nearby? — a chip pushing straight to the cloud. Simplest thing that works.
- Several sensors, want automations or one dashboard? — a hub like Home Assistant or Hort Assistant.
- Sensor far from any network? — a long-range radio carrying the reading back to a hub that has internet.
- No internet at all? — a hub can still log locally; you read it on site, and your data is still yours.
Start with the smallest path that solves your problem. You can always add a hub later — the readings are the same shape either way.
04The push methods.
However the reading travels, the "push" itself is usually one of two simple methods:
- A webhook — the sensor sends a small bundle of data (a reading and its labels) to a web address, the same way a form on a website submits. Plain and universal.
- MQTT — a lightweight messaging method built for exactly this: tiny devices publishing small messages on named "topics" that anything subscribed can receive. The Home Assistant world uses a standard MQTT format that lets a new sensor announce itself automatically, which is why we lean on it.
Both are simple once you have seen one. Step-by-step depth pages for each — and ready-to-flash sketches that do the pushing — are landing in the Sketch Library as this section fills in.
Frequently asked questions.
The honest version.
What is an endpoint in IoT?
An endpoint is the place a sensor sends its readings to — a server or service that receives the data and keeps it. In a connected-sensor setup, the device senses, pushes the reading over a network, and the reading lands at the endpoint, where dashboards, alerts, and analysis read it. The endpoint can be a small computer at your location or a cloud service; what matters for ownership is that you can get your data back out of it, not where it physically lives.
How does an ESP32 send data to the cloud?
An ESP32 — a small, inexpensive microcontroller with built-in Wi-Fi — reads a sensor and then pushes the value to a cloud endpoint over the network, typically every minute or two. It usually does this one of two ways: by sending a webhook (an HTTP request carrying the reading) to a web address, or by publishing an MQTT message to a broker. Either way it is a small amount of code on the chip and no hub in between, which makes it the simplest path for one or a few sensors.
What is the difference between MQTT and webhooks?
Both are ways to push a reading from a device to somewhere that stores it. A webhook is a one-shot HTTP request — the device sends a small bundle of data to a web address, like submitting a form. MQTT is a lightweight publish-and-subscribe messaging system: devices publish small messages to named topics, and anything subscribed receives them, which suits many small devices sending frequent updates. Webhooks are simplest for occasional, one-directional sends; MQTT shines for continuous streams and for hubs like Home Assistant.
Do I need Home Assistant to monitor sensors?
No. A single microcontroller can push a reading straight to a cloud endpoint with no hub at all, which is plenty for one or a few sensors. Home Assistant — a small computer running free, open-source software — becomes worth it when you have several sensors, want dashboards in one place, or want to run automations. Think of it as a hub you add when the number of sensors or the desire for automation justifies it, not a requirement for getting started.
Can an ESP32 send data without a hub?
Yes. An ESP32 has Wi-Fi built in and can push its readings directly to a cloud endpoint — by webhook or MQTT — with nothing in between. This direct-to-cloud path is the simplest setup and works well for one or a handful of sensors that sit within reach of a network. You only need a hub (like Home Assistant) when you want to coordinate many sensors, run local automations, or have a single dashboard for everything.
What is MQTT?
MQTT is a lightweight messaging system designed for small devices sending small amounts of data, which makes it a natural fit for sensors. Devices "publish" readings to named channels called topics, and anything that has "subscribed" to a topic receives the messages, through a middleman called a broker. It uses very little power and bandwidth, handles many devices well, and the Home Assistant ecosystem uses a standard MQTT format that lets a new sensor announce itself automatically — which is why it is a common backbone for grower-built monitoring.