> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/devices.md). # Devices Understand IoT digital twins in Kilo: connect hardware, replace sensors, and keep an asset's measurement history together. A **Digital Twin** in Kilo IoT Server is a persistent digital device representing something you monitor or control: a refrigerator, a pump, a vehicle, or an individual sensor. Its name, measurements, history, and configuration belong to that digital record. Physical hardware supplies the readings through a connector and can be replaced without creating a new twin. This is useful whenever the equipment you care about lasts longer than the sensor measuring it. A refrigeration operator needs the temperature record for **Refrigerator 1**, even after its original probe is replaced. Building the monitoring around the refrigerator's twin keeps that record together across hardware changes.
Kilo Devices list showing the digital devices in a deployment

Each entry is a digital device with its own identity, configuration, and measurements.

## What does the Devices page show? Open **Devices** in the main menu.
The Devices page with a Search by name box, Metrics and Add device buttons, and a table of devices with Status and Creation date columns and Edit, Clone, and Delete buttons on each row

The Devices page in a demo organization. A green dot and a time such as "4 mins ago" mean the device reported recently.

* **Add device** (top right) starts the registration flow for a new device. See [Registering Devices](/devices/registering-devices.md). * **Metrics** opens the shared metric catalog. See [Metrics](/devices/metric-templates.md). * **Search by name** filters the list as you type. * The **Device name** and **Creation date** headers sort the table. The **Status** column shows when each device last reported; the time and the dot update on their own while the page is open, so you do not need to refresh. * **Edit** opens the device editor (see [Emulated Devices](/devices/emulated-devices.md#what-does-each-tab-of-the-device-editor-show) for a tour of its tabs), **Clone** creates a copy, and **Delete** removes the device after a confirmation. ## How an IoT digital twin connects to hardware Three parts work together: | Part | What it represents | Refrigerator example | | ---------------- | ----------------------------------------------------------- | ------------------------------------------------------ | | Digital device | The lasting record of the monitored object | Refrigerator 1, with its name, photo, and measurements | | Connected source | The hardware or emulator supplying data through a connector | A LoRaWAN temperature probe | | Measurements | The readings mapped onto the twin | Temperature in °C and the probe's battery level | A digital device has one connected source at a time. That source can provide several measurements. Supported source types include LoRaWAN, MIOTY, MQTT-connected equipment, vehicle trackers, and the Emulator. A protocol adapter can bring other equipment in through MQTT; the connector must receive a supported payload and the readings must be mapped. A **metric template** defines what a measurement means, including its unit and value type. A **connector key** is the field name arriving from the source. Mapping connects the two, so a probe reporting `temp_c` and its replacement reporting `temperature` can feed the same temperature measurement on the twin. See [Metrics](/devices/metric-templates.md). ## Replacing a refrigeration probe without starting over Consider a pharmaceutical refrigerator whose probe is replaced after a failure or because it no longer meets the operator's calibration requirements: 1. Register a digital device named **Refrigerator 1** and connect the installed probe. 2. Map its temperature reading to a temperature metric in °C. Add a [chart](/dashboards/adding-widgets/chart-widget/line-chart.md) and configure an [alarm](/alarm.md) for the operating limits appropriate to the installation. 3. When the probe needs replacing, open **Refrigerator 1** and detach its physical device from the **Connection** tab. 4. Bind the replacement probe to that same digital device. Reconnect its incoming fields to the existing measurement rows. 5. Check the new values and timestamps, then review a history range spanning the replacement. The refrigerator keeps its identity and existing measurement history. Dashboard and rule references to those retained measurements continue to refer to the same record. The new probe supplies future readings; it does not erase the old probe's readings or fill a gap when no probe was reporting. Follow [Replace a physical sensor](/devices/device-management.md#replace-a-physical-sensor) for the detailed procedure. Keep the existing measurement rows when changing a source: deleting and recreating them is a different operation from remapping their incoming fields. ## Build around the asset's lifecycle The same model supports more than replacement. Create the digital device before commissioning hardware, give it an asset-oriented name, and add a photo that helps the team recognize it. Use **Application** to associate it with the solution it belongs to. Use the [Emulator](/devices/emulated-devices.md) to prepare dashboards and automation with generated readings before connecting real equipment. Once hardware reports, the twin's measurements can feed dashboards, alarm conditions, and rules. Where the hardware supports it, [commands](/devices/commands.md) also let users or rules request an action and check reported feedback. Replacing an actuator requires checking its command payloads and routing against the new model, even when the twin stays the same. Across multiple refrigerators or sites, consistent metric definitions let the team compare the same kinds of readings while each asset keeps its own record. ## How long history is retained History remains subject to the retention period included in your plan or agreed for your organization. Replacing a probe does not reset that period or extend the lifetime of older readings. For longer-term refrigeration records or other compliance and operational needs, contact the team to discuss extended retention. See [Data retention](/settings/subscription.md#data-retention) for plan limits and the request route. ## Choose the source for your digital twin | Source | Start here | | -------------------------------- | ------------------------------------------------------------------------------------------------------ | | LoRaWAN sensor | [LoRaWAN Devices](/devices/lorawan-devices.md) — profiles, radio identity, decoding and first readings | | MQTT publisher or bridged sensor | [MQTT Devices](/devices/mqtt-devices.md) — connect messages to a twin and its measurements | | GPS tracker | [Tracker Connector](/connectors/tracker-connector.md) — tracker identity, model and reporting endpoint | | MIOTY endpoint | [MIOTY Devices](/devices/mioty-devices.md) — endpoint configuration and blueprint decoding | | Generated readings | [Emulated Devices](/devices/emulated-devices.md) — prepare a deployment before hardware arrives | ## In this section * [Registering Devices](/devices/registering-devices.md) — the shared registration flow, and the fields each connector type asks for. * [Device Management](/devices/device-management.md) — replace a physical sensor while keeping its twin, manage mappings, and review history. * [Device Diagnostics](/devices/device-diagnostics.md) — why a device is silent: reception status, pipeline, and the event feed. * [Metrics](/devices/metric-templates.md) — units, metric keys and templates that normalize raw sensor data across manufacturers. * [Payload Decoding and Connector Keys](/devices/payload-decoding.md) — see which fields a device reports and what values they carry. * [MIOTY Devices](/devices/mioty-devices.md) and [MIOTY Blueprints](/devices/mioty-blueprints.md) — commissioning MIOTY endpoints and decoding their payloads. * [Emulated Devices](/devices/emulated-devices.md) — devices that generate their own data, so you can build before the hardware arrives. * [Device Commands](/devices/commands.md) — defining, confirming and dispatching the actions a device can perform. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.kiloiot.io/devices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.