Skip to main content

DeviceSerial and ClientId

Why DeviceSerial matters​

Every AirNgin device has a unique serial identity. DeviceSerial is the primary device identity used throughout registration, security, routing, and device management.

For the canonical identity format, AirNgin uses a 14-character serial composed of the producer/center code plus a 10-digit unique number.

What the serial is used for​

Precise device identification​

A device uses its identity to determine whether a command or configuration message belongs to it. This prevents one device from applying another device's traffic.

Communication isolation​

Each registered device has its own identity and receives only the traffic that is scoped to it.

MQTT identity relationship​

DeviceSerial is part of the server-side identity information used when issuing MQTT credentials. Firmware must not construct the complete ClientId itself; AirNgin provisioning returns a complete server-authoritative ClientId, which the device persists and reuses.

Benefits for producers​

A stable unique serial helps with activation tracking, support, product authenticity, after-sales service, installation history, and product analytics.

Serial example​

Producer/Center code: AIRN
Unique device number: 1234567890
DeviceSerial: AIRN1234567890

Important rules:

  • Every serial must be unique.
  • The canonical AirNgin serial is exactly 14 characters: a 4-character producer code plus a 10-digit number.
  • Only device identities registered/authorized by AirNgin can participate in the platform flow.
  • Do not use native addresses such as Modbus slave IDs, BLE addresses, Zigbee addresses, or CAN node IDs as DeviceSerial.

What is ClientId?​

In MQTT, ClientId identifies an MQTT client connection to the broker. In AirNgin, the complete MQTT ClientId is issued by the Backend during provisioning together with the other MQTT credentials.

From firmware's point of view, ClientId is an opaque credential:

  • persist the exact issued value;
  • reuse it across normal reconnects, reboots, and broker failover;
  • do not derive it from MAC address, DeviceSerial, ProjectCode, or random data;
  • do not parse its internal segments as a firmware contract.

A project/security-context change may require reprovisioning according to the provisioning and security lifecycle.