---
title: how to plug a sensor stack in
canonical_url: https://ensurance.app/guide/how-to-plug-a-sensor-stack-in
markdown_url: https://ensurance.app/guide/how-to-plug-a-sensor-stack-in.md
subtitle: "bring the name you already use, the place the reading belongs to, and the way the file already leaves your system"
category: how-to
---

# how to plug a sensor stack in

*bring the name you already use, the place the reading belongs to, and the way the file already leaves your system*

You already run the stack. A sonde on a logger, a rain gauge on the ridge, a staff plate somebody reads on Tuesdays, a lab sheet that comes back three weeks later, and a canopy figure from someone else's satellite pass. The instruments are not the problem. The open question is what the readings belong to.

**Connecting environmental sensors** here means handing over a reading your stack already produces, tied to a living place, without replacing your sensors or your gateway. You bring the name you already use for the measure, the result with its unit and time, the method, and the place. The field hardware does not change.

A creek, a soil profile, a canopy, and a storm already produce a signal whether or not a network stores it. A probe, a lab assay, a camera, a radar pass, and an indicator sheet are readings of that living system. **[ensurance](/?from=guide)** keeps the reading beside what the place claims, so funding can cite the condition. It does not replace anyone's sensors, and it is not the living system.

:::johnson
**the instrument stays yours. the reading gets a home.**

Your gateway keeps decoding the radio. Your plate keeps getting read. What belongs with the place is one dated result. Today that arrives as a note, not a feed.

[tell us about your stack →](/contact?from=guide&topic=sensor-plug-in)
:::

## the shape of one reading is already decided

A reading is one dated result about one place. That shape is settled, and it is small enough to write on an index card.

| field | what it is | example |
| --- | --- | --- |
| name | the device's own name for the measure | `soil_moisture_10cm`, `stage_ft`, `canopy_pct` |
| result | the number, or the call | `0.23`, `4.81`, `detected` |
| unit | the unit that result is in | `m3/m3`, `ft`, `percent` |
| time | when it happened, and when your system wrote it | `2026-10-06T08:10Z` |
| method | a person, a lab, or a model | `staff plate, read by hand` |
| place | the parcel, reach, or station the account already claims | `lower reach, station 2` |

Two notes on that table.

**An unmapped name is still welcome.** If your probe calls it `vwc_a` and nobody here has a row for `vwc_a`, it is stored as `vwc_a`. A lookup table is a convenience, not a gate. We do not write a driver per brand, and we do not ask you to rename your fields to match a taxonomy.

**A result with no place is a note, not evidence.** A number with no unit, no method, or no place can be kept beside the place as a note, and it can be useful as one. It does not do the work evidence does, because a reviewer cannot point at the same ground. That line is covered in more depth in [a claim is not a reading](/guide/a-claim-is-not-a-reading).

## the doors a reading can arrive through

Five doors. None of them has a public URL today. Pick the one your system already uses, not the one that looks most modern.

| door | what arrives | who it suits |
| --- | --- | --- |
| a person's note | one line: the plate read 4.81 ft at 08:10, read by hand | a reach somebody walks; a seasonal read; a single arrival |
| a JSON note in the shape you already emit | your own field names, your own envelope | a platform that already posts observations somewhere |
| an OGC SensorThings feed | thing, sensor, observed property, datastream, observation | a network already standardized on the open web shape |
| a CSV | a lab return, or a season of logger rows | assays, annual soil carbon, anything batched |
| a satellite or model conclusion | canopy percent, flood extent class, labeled as a model | an earth-observation vendor or an internal model |

The SensorThings row needs one definition. The **OGC SensorThings API** is an open, royalty-free standard for exchanging IoT observations over the web; Part 1 (Sensing) version 1.1 is OGC 18-088. In its model, an observation is an act that produces a result about a property of a feature of interest, carrying a phenomenon time and a result time — the sensing model it inherits from OGC and ISO Observations and Measurements, ISO 19156:2011. Version 2.0, still in draft, retargets that model to ISO 19156:2023. If your network already speaks SensorThings, you already have every word this record needs.

**And here is the part most how-to pages would hide.** There is no public API to post readings to today. We do not host a public SensorThings server, we do not publish a webhook URL, and there is no observation log on a public page that refreshes. The table above is two things at once: the contract for when the writer is switched on, and the checklist for the note you can send now. [The place keeps the record](/guide/the-place-keeps-the-record) said the same thing to a corporate reader looking for a data login. Nothing has changed since.

## the names are examples, not a list to match

Soil moisture. Soil temperature. Rainfall. Water level. Canopy. Soil carbon. Something living was detected.

Seven names, and they are examples of the kind of thing a reading is about — not a menu you have to choose from. If you watch stream temperature, turbidity, bird point counts, a SEEA-style condition variable, an essential biodiversity variable, or a KPI row your sustainability team invented in 2019, it arrives as itself, under its own name. A framework is a list of names. We do not require anybody's taxonomy, and we do not translate your indicator into ours before storing it.

## what not to send

Do not send the raw audio. Do not send the photo library. Do not send the radar scene. Do not send the lidar point cloud.

The conclusion is the row. A ground elevation or a canopy height from a laser survey is a reading; the cloud stays with the survey. [What lidar can see](/guide/what-lidar-can-see?from=guide) is that cut. A device-side classifier that says *something living was detected, at this station, at this time, by a model* is a reading. The 40 GB of audio behind it is yours, it stays yours, and a pointer to where it lives is enough for anyone who needs to go back to it. Same for imagery: a canopy figure or a flood-extent class travels; the scene stays in your bucket. [What earth-observation data shows](/guide/what-earth-observation-data-shows) covers how those conclusions get read, and what stays labeled as a model when they do.

## when your reading and somebody else's disagree

Both stay. A satellite retrieval that says the top few centimeters are wet and a probe at 10 cm that says otherwise are two readings of the same ground, and the record keeps both, each with its own method.

There is no blended score. There is no trust number from one to ten. A sensor does not write a price. The disagreement is information for the people who rely on the claim, and flattening it into one figure throws away the part worth keeping.

## step 1: name the living system

Not the project, not the program, not the dataset. The creek, the reach, the stand, the pasture, the wetland, the basin. If it has a name locals use, use that one.

A named place can be held in its own right — that is what the accounts behind [natural assets](/natural-assets?from=guide) are: an account a place holds in its own name, able to receive funding for its own condition. A **certificate** is a share of one named place. The reading sits with the place, not with the certificate; the certificate is how someone funds the place the reading is about. You can see what that looks like on [specific ensurance](/specific?from=guide).

## step 2: name the indicator you already watch

Use your own words for it. `stage_ft` is a better answer than "hydrology." If you watch six things, name six. One indicator with a method and a place beats twelve with neither.

## step 3: say which door the reading already leaves through

A note. A CSV someone emails. A JSON payload your platform already posts to a dashboard. A SensorThings feed. A webhook you already emit for some other consumer. The answer is usually one sentence, and it is usually the thing you least want to rebuild.

Send those three things through [contact](/contact?from=guide&topic=sensor-plug-in). It sorts under sensor plug-in and gets read by someone who knows what a staff plate is.

**What happens next is a place to hold and a name for the watch** — a conversation about which living system gets an account, and which of your indicators belongs beside it. Not an ingest this week. Not a new gauge from us. If you are a conservancy or a land trust already carrying this work, `MRV & monitoring` is one of the services listed on [solutions for land stewards](/solutions/land-stewards?from=guide&topic=sensor-plug-in) — work that gets funded on a place, not a dashboard you log into.

## frequently asked questions

### how do i connect environmental sensors?

Today you connect them by describing them: the living system, the indicator name your device already uses, and the way the reading already leaves your system. There is no public endpoint to point a gateway at. The design for the row — name, result, unit, time, method, place — is settled, so the note you write now is the same note the writer will take later.

### what is the ogc sensorthings api?

The OGC SensorThings API is an open, royalty-free standard for exchanging IoT observations over the web. Part 1 (Sensing) version 1.1 is OGC 18-088. It models a thing, a sensor, an observed property, a datastream, and an observation that carries a phenomenon time and a result time. We use its vocabulary. We do not run a public SensorThings server.

### what if my indicator is not on your list?

It still has a home, under its own name. The seven examples above are examples. An unmapped name is stored as the name you gave it, and nothing is dropped for failing to match a taxonomy.

### is there an api to post readings to today?

No. There is no public observation intake, no webhook URL, and no public log of readings. The shape of the row is decided; the public writer is not switched on.

## sources

[OGC SensorThings API](https://www.ogc.org/standards/sensorthings/) — standards page for the open IoT observation interface

[SensorThings API Part 1: Sensing v1.1 (OGC 18-088)](https://docs.ogc.org/is/18-088/18-088.html) — the observation model, phenomenon time and result time, and the ISO 19156 lineage

## the series

1. [what your sensors already measure](/guide/what-your-sensors-already-measure) — a probe, a lab, a camera, a radar pass, and an indicator sheet as readings of a living place
2. [a claim is not a reading](/guide/a-claim-is-not-a-reading) — the sentence, the reading, and the useful gap between them
3. [what mrv actually is](/guide/what-mrv-actually-is) — measurement, reporting, and verification as three uses of one row
4. [the radio stays outside](/guide/the-radio-stays-outside) — instrument, carrier, record; no driver per brand
5. [what radar can see](/guide/what-radar-can-see) — weather radar, imaging radar, and why neither is the gauge
6. [how to plug a sensor stack in](/guide/how-to-plug-a-sensor-stack-in) — this page
7. [what lidar can see](/guide/what-lidar-can-see?from=guide) — a laser times a return; height is that distance