Every connected sensor you put in a greenhouse has to send its reading somewhere. The hard part was never the sensor: it was getting the data out in a shape something else can use. oat-ods is the working schema Open Agriculture Technology uses for that: one simple message, every device, the same way. We are not a standards body, and this is not a proposal for one. Our devices needed a consistent format, so we built one as a plain-spoken profile of the open standards that already exist. That is it. Use it if it fits your operation.
01Why one shared shape at all.
Most agriculture-technology projects do the exciting part well: they read a temperature, a moisture level, a CO₂ number. Then they get stuck on the dull part that actually matters: gathering that data into one place, in one shape, so a person or a program can do something with it. Every vendor invents its own format, and nothing talks to anything else.
That gap is what drove us to oat-ods. It is not a new gadget; it is the agreement about what the data looks like on the way out of every Open Agriculture Technology device, so the gathering problem is solved once instead of a hundred times. It is the practical side of Data is King: data you can actually keep and use only exists if it arrives in a shape you can keep and use.
02One message, every device.
An oat-ods message carries one reading: the value, what it measured, when, the place it came from, and the gadget that produced it. Here is the whole thing:
{ "schema": "oat-ods/0.3", "observed_at": "2026-06-25T14:30:00Z", "stream": { "id": "gh2-north-air", // the place, this never changes "name": "GH2 North Bench Air", "location": "Greenhouse 2 / North Bench" }, "measurement": "temperature", "value": 24.31, "unit": "Cel", "source": { "tier": "oat-ble-listener", "physical_id": "AA:BB:CC:DD:EE:01", // the gadget, swap it any time "brand": "Govee", "model": "H5075", "battery_pct": 88 } }
That is the entire format. A board with one probe sends it. A board with five wired sensors sends it, once per reading. A listener watching a dozen wireless sensors sends it. Write a brand-new device tomorrow and it pours into the same shape: only the value and the gadget details change. One envelope, every device.
03The data belongs to the place, not the gadget.
This is the one idea worth slowing down for. Notice the two parts of the message: a stream (the place, "North Bench air") and a source (the gadget, a specific Govee with a specific ID). The reading is filed under the place; the gadget is only noted as the thing that took it.
So when a sensor dies, and they all die eventually, you put in a new one, point it at the same place, and your history just continues. No gap, no "sensor 7 became sensor 12," no lost record. The same is true if the little computer running the show fails: you give its replacement the same name, and the streams pick right back up. The gadgets are disposable. The record of the place is what you keep.
Why it's built this way
A reading tied to a serial number is worthless the day you replace the hardware. A reading tied to "North Bench air" is yours for as long as you grow there. That is the whole reason the message is shaped the way it is.
04Two ways to send it.
oat-ods comes out of two kinds of setup, and the receiving end can't tell them apart, the message is identical either way:
| A small Open Agriculture Technology device | ESP32 | A cheap, commodity board you flash from your browser. It reads the sensors and sends oat-ods straight to your endpoint. Nothing else required. Start in the Software Library. |
|---|---|---|
| Home Assistant | Hub | Already running Home Assistant? Let it do the heavy lifting, all your Zigbee, Wi-Fi, and wired gear, and forward everything to your endpoint as the same oat-ods message. |
Because both speak the identical format, you can start with one cheap board and grow into a full hub later without changing a thing downstream. The data looks the same on day one and day one thousand.
05What it is built on.
oat-ods is not invented from scratch. Smart people already built open standards for sending sensor data; they were just too heavy or too technical for a grower to pick up and use. So oat-ods is a plain-spoken profile of the good ones. We chose them, we did not write them:
| SenML (IETF RFC 8428) | the wire | The lightweight format for sending readings from tiny devices. Our message base. |
|---|---|---|
| OGC SensorThings | the model | The idea of separating the stream (the place) from the sensor (the gadget). We use its vocabulary. |
| Eclipse Sparkplug | liveness | How a device says "I'm alive" and how the system learns it went offline. |
| farmOS | the home | The open farm record that uses the same place-vs-gadget split. oat-ods maps straight into it. |
Following standards isn't box-ticking. It means your data isn't trapped in a thing we made up, it speaks a language the wider world already understands. See exactly what oat-ods works with on the compatibility page.
06Your data stays yours.
A schema is only worth trusting if it doesn't lock you in. oat-ods is published openly: the full field-by-field spec and a machine-readable schema live at a fixed address (oat-ods-0.3.schema.json). Anyone, a developer, or an AI assistant working for you, can read it and write something that understands your data in minutes. You can point your devices at our endpoint, at a system you already run, or at one you build yourself. No gate, no lock, no permission needed.
The shortest version
oat-ods is the one open message every Open Agriculture Technology device uses to send a reading somewhere. It files data under the place, not the gadget, so swapping a dead sensor never breaks your history. The same message comes from a cheap board or from Home Assistant. It's a plain profile of open standards, published for anyone to read, and your data is never locked to us.
Frequently asked questions.
Is there an open standard for sending sensor data to a server?
Yes. SenML (RFC 8428) is an IETF format for readings from small devices, and OGC SensorThings is a widely used open data model for sensors. Most platforms also accept simple JSON over HTTP or MQTT. A single reading typically carries the value, what it measured, when it was taken, the place it came from, and the device that produced it.
If I replace a broken sensor, do I lose its history?
No: nothing is lost. Readings are filed under the place ("North Bench air"), not the sensor's serial number. You put in a new sensor, point it at the same place, and the history continues without a gap. The gadget is disposable; the record of the place is what you keep.
Can I keep control of my own sensor data instead of using a vendor cloud?
Yes. Instead of sending readings only to a vendor's cloud, you can route them to a system you already run, such as Home Assistant or farmOS, or to your own server. As long as the data uses an open format, you can store and move it yourself, which keeps control of the record with you rather than a single provider.
Can I use Home Assistant to send sensor data, or do I need a separate device?
Either works. A low-cost ESP32 board, which can be flashed from a web browser, can read the sensors and send the readings to your endpoint directly. If you already run Home Assistant, it can do that device work itself and forward the same messages. A receiving server cannot tell the two apart, so you can start with a cheap board and move to a hub later without changing anything downstream.
What open standards exist for IoT and farm sensor data?
Several open standards cover this area. SenML (RFC 8428) is the IETF format for readings from small devices. OGC SensorThings provides a data model that separates the place from the device. Eclipse Sparkplug reports device liveness over MQTT. farmOS keeps the farm record. Most sensor tools build on one or more of these rather than inventing a private format.