> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/device-management/create-new-device.md). # Devices The inventory of all devices in a workspace, and the detail view of a single device. **Devices** is the inventory of a workspace. It lists every device with its current state, and it is where you create, import, search for, and open devices. {% content-ref url="/pages/-MWEZ2jDmLrbRO0bjxqF" %} [Device](/device-management/create-new-device/devices.md) {% endcontent-ref %} ## The device list

Each row shows the state of one device:

Column	What it shows
Name	The device name. Opens the detail view.
CS	Connection state. Shows whether the device has sent data within its offline timeout.
Device ID	The identifier the device sends data with, such as its DevEUI.
Tags	The tags assigned to it, in their colors.
SQI	Signal quality of the last uplink, if the connectivity reports it.
Data Flow	The data flow that processes its uplinks. Opens the data flow.
Last Message Time	When the last uplink arrived. This is the quickest way to check whether a device still sends data.

[Custom fields](/device-management/managing-a-workspace/custom-fields.md) can be added as additional columns. Above the list are the search field, the filter, and the controls for selecting columns and refreshing the list. Most columns can be sorted. ## Adding devices


Create a device	Add one device, assign its data flow, and fill in its connectivity parameters.	Connect a Device
Bulk import	Create many devices from a CSV file, and edit, register, or delete devices in bulk.	Bulk actions
Device Simulator	Generate uplinks without hardware to build and test a data flow.	Device Simulator
Device Setup Assistant	Configure devices on site by scanning a QR code.	Overview

## The device detail view The detail view shows everything akenza has recorded about a device: its identifiers, its data flow, its tags and custom fields, the data it has sent, and the uplink metrics of its last message.

### Connectivity details What is shown under **Connectivity Details** depends on the connectivity, and for LoRaWAN on the carrier. All carriers show the standard LoRaWAN details. Devices on Swisscom Actility and generic Actility networks also show:

Detail	What it is
Motion Indicator	The movement expected of the sensor. In most cases this is Near static.
Connectivity Plan	The plan the device is billed under on the carrier.
Data Route	How an uplink is forwarded and who can send a downlink. It is set automatically if the device is created with a data flow.
Boot Profile	Information about the device model.

### Downlinks Downlinks can be sent manually from the detail view, or triggered by a [rule action](/device-management/rule-engine/rule-actions/downlink.md). **LoRaWAN downlinks** require a port and a payload. The port has to be zero or positive, and most carriers require it to be positive. The payload is a hex string. The *confirmed* toggle requests a confirmation that the downlink was sent. If the data flow of the device uses a [device type](/device-management/your-data-flow/device-type.md) with a downlink script, the hex payload is replaced by a JSON object. The script translates it into a hex string during processing, and it can also override the port and the confirmed flag. **MQTT downlinks** require a JSON object as the payload and can have an optional topic. The topic has to start with `/` and is appended to the default downlink topic. The payload can be any valid JSON. A downlink script in the device type can override the topic. --- # 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.akenza.io/device-management/create-new-device.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.