You shouldn't have to pick your tools to fit your sensors. The point of an open format is the reverse: point your sensors at Open Agriculture Technology, and the data speaks to whatever you already run, or to something you build yourself. Here's exactly what oat-ods works with.
01The idea.
oat-ods is the same data in a few different wrappers. The reading and the place never change; only the envelope around them does, to suit the destination. Some destinations the device can speak to on its own. Others, the ones that need a bit more bookkeeping, are reached through the Open Agriculture Technology hub, which takes your one oat-ods message and hands it on in each system's own dialect.
02Speaks it directly.
These need nothing but a URL or a broker, the device (or Home Assistant) talks to them straight:
| Home Assistant | device | Your readings arrive on the MQTT broker Home Assistant uses, one topic per reading; declare each as an MQTT sensor in YAML and it sits beside your other smart-home gear. The most common grower setup. |
|---|---|---|
| Any webhook / your own URL | device | The Open Agriculture Technology message, or a stripped-down {value}, posted to any address you choose. The easy target for a custom or AI-built endpoint. |
| An MQTT broker | device | One retained topic per reading, named for the node and the sensor's own hardware id, so any dashboard always has the latest value waiting. |
| SenML servers | device | Strict SenML for tools that already speak it (some historians, CoAP servers, IoT platforms). |
03Through the Open Agriculture Technology hub.
These platforms file each reading in its own place, with its own keys, more than a device should juggle. The Open Agriculture Technology hub does that translation. The hub is not built yet, and none of the three mappings below has been proven on our bench. They are mapped on paper, published so you can read them, and will be listed as working only once a reading has crossed into each platform and back.
| farmOS | hub | Lands as a Data Stream on the right field (Land Asset) in the open farm record. A single-sensor device can also post to farmOS directly. |
|---|---|---|
| OGC SensorThings | hub | Posted as Observations to the matching Datastream, the OGC standard used in environmental and city sensing. |
| NGSI-LD / FIWARE | hub | DeviceMeasurement entities for the EU-backed smart-agriculture data models. |
04On the device, or at the hub.
There's a simple rule for which is which, and it comes down to how many sensors a device handles:
- A device with one or a few sensors can send straight to almost anything, including the per-place platforms, one sensor, one address, no trouble.
- A device watching many sensors (say a listener tracking a dozen wireless probes) sends the simple, one-address formats and lets the hub fan out to the per-place platforms. Otherwise it would have to juggle a separate address and key for every sensor, the wrong job for a small board.
You don't have to think about this when you set a device up: it only offers the destinations it can sensibly reach. The rest are a step away through the hub.
05Standards, not silos.
Every name in those tables is an open standard or an open platform, not a walled garden we partnered with. That's deliberate. Tools come and go; an open format you can read and re-use outlasts any one of them. If a platform we've never heard of shows up next year, your data already speaks a language it can learn from, because the full spec is published openly. We bet on your data being clean and readable, not on guessing which destinations will still matter.
The short of it
Point your sensors at Open Agriculture Technology. It speaks Home Assistant, plain webhooks, MQTT and SenML today, and the open farm and sensing platforms through the hub. Read the format itself on the Data schema page.
Frequently asked questions.
Can Home Assistant automatically discover MQTT sensors?
Only if the device sends Home Assistant's discovery announcements, and the OAT sketches do not: they publish one retained message per reading on a topic named for the node and the sensor's own hardware id, and you declare each reading as an MQTT sensor in YAML, a few lines each, giving it the name and area of the place it watches. Home Assistant can also serve as the gateway itself, reading a device and forwarding the data onward with our forwarder package, though that package does not yet send exactly what a board sends (it uses Home Assistant's own units and names and sends no heartbeat).
Can I send sensor data to farmOS?
Yes. farmOS accepts sensor readings through data streams: each reading is posted to a data stream associated with the relevant asset, such as a field or a piece of equipment. A single sensor can post directly to its stream URL over HTTP. A device that watches several sensors needs a gateway or small script to route each reading to the correct stream.
How do I send sensor data to my own server or webhook?
Point the device at your endpoint URL and it sends the reading as an HTTP POST, either the full JSON message or a stripped-down value, to any server you choose. When the message format is published as an open JSON Schema, the structure is documented, so you can write a receiver in a short script and store the data wherever you like.
Will I get locked into a vendor with IoT sensors?
Vendor lock-in happens when a sensor only reports to one company's cloud in a private format. You avoid it by choosing devices that speak open standards, such as SenML, OGC SensorThings, NGSI-LD, MQTT, or plain HTTP webhooks, and platforms like farmOS or Home Assistant. Data in an open format can move to a new tool later, so it is not tied to any single vendor.