Wire and interpret the value

You have a reading that belongs to nobody and an entity that declares a temperature it never receives. This step joins them, and then makes the number mean something.

Two jobs, and it helps to keep them apart. Wiring decides where a value goes. Interpreting decides how it should be read once it gets there.

Say what the value measures

Start in Data Hub and open the dataset from step three. It is still flagged as incomplete, because nothing has said what its number measures.

Pick the unit for the field. OnTwins offers the units that make sense for the values it has seen, so you are choosing from a short list rather than typing one.

This is the dataset’s unit — the unit the value is stored in. If your agent declared the unit it was sending in, and that differs from the one you pick, OnTwins converts on the way in. The field keeps working either way; you are deciding what the stored number means, not asking the agent to change.

With a unit chosen, the dataset is no longer incomplete.

Wire it to the entity

Move to Scenes Studio. Wiring takes two steps, because the place a value arrives is a thing in its own right.

First, add a mapping point to your entity: choose the entity, choose the element you are targeting — the temperature telemetry you declared on the model — and set the direction to inbound, meaning data flowing in. (Outbound is the opposite direction, for commands going out to equipment; you are not doing that here.)

A mapping point is a named socket on the entity. It exists whether or not anything is plugged into it, which is what lets you model a site completely before the data for it exists — or replace the source of a value without touching the entity.

Then wire the dataset field into that mapping point. One field, one socket.

Check that it took

Send another sample, exactly as in step three, with a new timestamp and a different value:

curl -X POST "$ONTWINS/api/v1/agent/ingest" \
  -H "Authorization: Bearer $CRED" \
  -H 'Content-Type: application/json' \
  -d '{
    "datasetId": "ds_paste_the_id_here",
    "samples": [
      { "signal": "temp", "at": "2026-10-01T09:05:00Z", "value": 22.9 }
    ]
  }'

{ "accepted": 1, "deadbanded": 0, "dropped": [], "fanout": 1 }

fanout is 1 this time, not 0. That is the wiring reporting itself: the value reached the entity’s state. Change the value between sends — an unchanged reading can be set aside as not worth storing, and then nothing moves.

Interpret it

The entity now holds 22.9. On its own that is not readable: a screen showing 22.9 tells an operator nothing about whether it is fine.

An interpretation supplies the missing part. Create one and give it a name you will recognize later, then say what it reads — your entity, its temperature element — and how to present it:

• Decimals — how many places to show. A room temperature wants one, not six.
• Scale — the range a gauge or axis should span.
• Ranges — the bands that carry judgement. 18–26 normal, above 28 too warm. This is what turns a number into a colour an operator reads without thinking.

Interpretations are named and reusable on purpose. Widgets refer to one by name rather than carrying their own formatting, so the same value is never shown as 22.9°C on one screen and 22.857 on another. Change the interpretation once and every screen that uses it follows.

---

The value now flows to the entity and knows how to be read. Next, build and publish a scene so somebody can actually see it.