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.
Hort Assistant.
Hort Assistant is Open Agriculture Technology's hub for growers. It is built on Home Assistant, the same free, open-source software, tuned for the things growers actually do.
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. The Hort Assistant page is the grower's view; our Home Assistant section is the depth on the software underneath.
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? Hort Assistant, our grower's hub built on Home 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.
04Choosing where it lands.
Everything above gets a reading moving. It still has to land somewhere, and that is a separate choice from how it travels. Here are the honest options, side by side.
| Endpoint | Who runs it | Best for | Watch for |
|---|---|---|---|
| A server you run | You | Full control, no ongoing fee, and you do not mind the upkeep | You are the one who notices if it goes down |
| A cloud service you pay for | A provider | Near-perfect uptime with no maintenance on your end | Needs a working internet connection at the farm |
| Our live demonstration | Open Agriculture Technology | Watching the whole path work before you commit to a real one | A demo built to prove the idea, not a service to run a farm on |
| farmOS | You, or a host you choose | Growers who already keep records in farmOS | A full farm record system, not a plug-and-play dashboard |
Open Agriculture Technology does not sell you the endpoint. We set an open message every building block can speak, publish exactly what our gateways send, and run a live demonstration so you can watch a reading travel end to end. Which of the four you build on is yours to decide, and you can change your mind later without touching a single sensor, because they all speak the same reading. (Debugging your first device? The conformance sandbox shows each raw message as it arrives, checked against the standard, before you commit to any endpoint. And to test a flashed gateway end to end, point it at the Open Agriculture Technology Test Endpoint — your gateway, its sensors, and your farm appear live, no account needed.)
05What a good endpoint actually does.
An endpoint is not just a place a number lands and sits. A good one does three things, and they are worth naming, because they are the real reason a cloud service earns its keep instead of just sounding fancy.
It stays up. A real cloud service is staffed around the clock, sits behind backup power, and has more than one way onto the internet. That is a genuine advantage over a box in a barn, which has none of those things, and it is worth choosing for. The honest trade-off: a cloud endpoint still needs a working connection out of the farm, and farm internet is often the weak link. The sturdy answer is to let the edge keep working on its own, a hub or gateway that holds a reading until the connection comes back, and treat the cloud as the durable copy, not the only one.
It notices when something goes quiet. Every gateway and every Home Assistant box sends a reading on a schedule. When that schedule stops, the silence is the warning. A cooler whose sensor has not reported in twenty minutes is telling you something, whether or not the temperature itself has moved yet, and an endpoint that watches for the gap can put you ahead of a spoiled batch instead of behind one.
It shows you the whole operation, not just one piece of it. A single Home Assistant box only sees its own greenhouse. A single gateway only sees its own cooler. Neither sees the other. Point several of them, say four greenhouses on Home Assistant and ten refrigerated trucks on gateways, at one endpoint, and that endpoint becomes the only place the whole operation shows up on one screen. That works because every building block speaks the same reading, and the reading itself says which farm, which device, and what it measured, so the endpoint can sort a dozen unrelated sources back into one picture instead of a pile.
None of this requires picking the biggest option. A single cooler and a single gateway get the same honest benefit as sixty greenhouses: something watching, something remembering, in a place you chose.
06The 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 Sketches as this section fills in.
Frequently asked questions.
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.
What happens if my sensor or gateway stops sending data?
A good endpoint notices before you do. Every gateway and every Home Assistant box sends a reading on a schedule, and when that schedule stops, the silence itself is the warning, whether or not the reading you last saw looked fine. A cooler whose sensor goes quiet for twenty minutes is telling you something, and an endpoint that watches for the gap can flag it before a batch spoils instead of after.
Can one dashboard show sensors from more than one farm or site?
Yes, as long as every source speaks the same message. A single Home Assistant box only sees its own greenhouse, and a single gateway only sees its own cooler or truck, but point several of them at one endpoint and that endpoint becomes the only place the whole operation is visible at once. It works because the reading itself carries which farm, which device, and what it measured, so the endpoint can sort many unrelated sources back into one picture.
Where should I store data from farm sensors?
Anywhere you can get it back out of. Common choices are your own server, a paid cloud service, or a local hub such as Home Assistant or farmOS, and all of them work. The deciding factor is portability rather than location: if the sensors send an open, standard message format, the storage endpoint can be swapped later without touching the sensors themselves, so the choice is not permanent.