Device

What a device is in akenza, how it is identified, and which fields it has.

A device represents hardware in the field, such as a sensor, a meter, or a tracker. It sends data to akenza as uplinks, and depending on its connectivity it can also receive downlinks. Devices belong to a workspace and are managed in the device inventory.

What a device carries

akenza stores the following information for each device:

Group	What it holds
Identity	The name and description you give it, the physical device ID it sends data with, and the akenza device ID used for API calls.
Assignment	The organization and workspace it belongs to.
Processing	The data flow assigned to it, which includes the device connector and the device type that decodes its payloads.
Connectivity	How it reaches akenza, and for networked connectivity the network parameters and the integration it was provisioned through.
Your metadata	The tags and custom fields you assign.
State	Whether it is online, its offline timeout, whether it is registered on the network, and whether it is included in the lifecycle report.
Last uplink	The uplink metrics, updated with every message.

The REST API documentation lists every field of a device. This page explains what they mean.

Identifiers

A device has two identifiers:

• The device ID is set when the device is created. It is usually the physical identifier of the device, the DevEUI for LoRaWAN devices, or any suitable identifier for HTTP, MQTT, and CoAP. akenza matches incoming data on it.

• The akenza device ID is assigned by akenza and never changes.

You can change the device ID during the lifetime of a device, for example when you replace a sensor. The akenza device ID stays the same, so the device keeps its history, tags, custom fields, and dashboards. All REST API operations use the akenza device ID.

Fields depend on connectivity

The device connector in the data flow decides which fields a device has:

• Networked connectivity, such as LoRaWAN or NB-IoT, requires the parameters of the network. For LoRaWAN these are the DevEUI, the application EUI and key, the activation mode (OTAA or ABP), the device class, the frequency plan, and the LoRaWAN version. Carriers can require more. An Actility-based network also has a connectivity plan, a device profile, and a motion indicator.

• IP-based connectivity, such as HTTP, MQTT, and CoAP, has no network parameters. The device connects over the internet and authenticates with the secret of its connector.

The last step of the creation wizard asks for these parameters, which is why its content changes with the connector. For a walkthrough of creating a device, see:

Connect a Device

Online state

A device is online if its last uplink is newer than its offline timeout, which is set when the device is created. akenza only tracks whether a device has sent data, not whether it works correctly.

Set the timeout according to how often the device sends. A sensor that sends every 15 minutes with a timeout of 24 hours can stop sending for almost a day before it shows as offline. A sensor that sends once a day with a timeout of two hours shows as offline every day.

Exclude test devices and spares from the device lifecycle report so that they are not reported as problems.

Data

Devices send data to akenza as uplinks, either at a fixed interval or when an event occurs. Each uplink runs the data processing pipeline defined by its data flow.

Data can be split into topics by purpose or schema, which keeps the structure of the data. One data point is a sample, identified by the akenza device ID, the topic, and the timestamp.

Historical device data is only available if the data flow contains an akenzaDB output connector. Without it, data is processed but not stored.

Uplink metrics

Uplink metrics are recorded with every uplink. They describe the transmission rather than its content: the size of the payload, when it arrived, and, if the network reports it, how well it was received.

Which metrics are recorded depends on the connectivity and the provider.

For HTTP, MQTT, and CoAP, only the size and the time are recorded:

{
    "uplinkSize": 478,
    "timestamp": "2021-09-17T07:10:16Z"
}

A LoRaWAN uplink also contains radio and network information:

{
    "uplinkSize": 246,
    "timestamp": "2026-09-25T14:18:44Z",
    "port": 5,
    "frameCountUp": 46897,
    "frameCountDown": 1048,
    "rssi": -119.0,
    "snr": -5.75,
    "sf": 7,
    "txPower": 2.0,
    "numberOfGateways": 1,
    "esp": -125.77,
    "sqi": 2,
    "signalQuality": "MEDIUM",
    "batteryLevel": 100.0,
    "batteryLevelStatus": "GOOD"
}

Battery level

akenza reads the battery level from the sample after the device type script has run. The sample has to contain either batteryLevel or batteryPercent.

If several samples in the same uplink contain a battery value, the lowest one is stored. For passthrough data flows, the value is read directly from the uplink payload.

Signal quality indicator (SQI)

LoRaWAN uplinks usually contain enough information to calculate the SQI. It is based on snr and rssi and rates the signal quality from 1 (weak) to 3 (strong).

akenza also reads it from the sample after the script has run, from sqi, signalQuality, or signalQualityIndicator, in that order. Values have to be between 1 and 3. Decimals are rounded down, and values outside the range are ignored. If several samples in the same uplink contain a value, the lowest one is stored. For passthrough data flows, the value is read directly from the uplink payload.

The device lifecycle report is based on battery level and signal quality, so make sure your device type emits them.