# Device Registration

## Purpose

The device registration handshake maps a factory IMEI to Banban's internal
`device_id` and `serial_number`. `msg_id=012` is the device registration
request and response. It is not the user/device binding success receipt and
does not represent the `msg_id=006` binding flow. Devices do not need to know
the assigned IDs before the first registration handshake.

## Flow

```mermaid
sequenceDiagram
  autonumber
  participant Factory as Factory Excel / import CSV
  participant Mapping as device_imei_mapping
  participant Device as TalkingQ device
  participant MQTT as MQTT broker
  participant Handler as TalkingQMQTTService
  participant Init as device_identity_initializer
  participant Auth as device_auth

  Factory->>Mapping: Insert imei, device_id, serial_number, status=pending
  Device->>MQTT: Publish device/{imei}/event msg_id=012 registration request
  MQTT->>Handler: Deliver identity init event
  Handler->>Init: initialize_by_imei(imei)
  Init->>Mapping: SELECT mapping by imei
  alt mapping missing or incomplete
    Init-->>Handler: DeviceIdentityInitializationError
    Handler-->>MQTT: device/{imei}/event_resp status=failed
  else mapping found
    Init->>Auth: SELECT device_auth by device_id
    alt no auth row
      Init->>Auth: INSERT device_id, serial_number, is_active=1
    else auth row exists and serial matches
      Init->>Auth: UPDATE is_active=1
    else serial mismatch
      Init-->>Handler: device_auth serial_number conflict
      Handler-->>MQTT: device/{imei}/event_resp status=failed
    end
    Init->>Mapping: UPDATE status=activated, activated_at=now
    Handler-->>MQTT: device/{imei}/event_resp registration success
    MQTT-->>Device: Receive device_id and device_sn
  end
```

## Registration Response

When the IMEI mapping is available, the handler returns the registration
response on `msg_id=012`:

```json
{
  "msg_id": "012",
  "params": {
    "device_id": "TalkingQ_ZHWK00002110",
    "device_sn": "TQ_ZHWK000000002110"
  }
}
```

The current V2.0 registration response does not carry an ICCID. Any ICCID
addition belongs to the separate `msg_id=006` binding-response extension; the
registration response only establishes the device identity needed by the
binding flow.

## Data Model

```mermaid
erDiagram
  device_imei_mapping {
    int id PK
    varchar imei UK
    varchar device_id UK
    varchar serial_number
    varchar status
    datetime activated_at
    datetime created_at
    datetime updated_at
  }

  device_auth {
    int id PK
    varchar device_id UK
    varchar serial_number
    varchar batch_id
    tinyint is_active
    datetime created_at
    datetime updated_at
  }

  device_imei_mapping ||--o| device_auth : activates
```

## Current ID Style

```text
device_id:     TalkingQ_ZHWK00002001
serial_number: TQ_ZHWK000000002001
```

## Source Anchors

- MQTT protocol V2.0: `talkingq-url/docs/mqtt协议_V2.0.txt`
- Bootstrap handler: `talkingq-url/handlers/mqtt_handler.py`
- Identity initializer: `talkingq-url/services/device_identity_initializer.py`
- Import script: `talkingq-url/scripts/import_device_imei_mapping.py`
- Tables: `database/talkingq_shared_schema.sql`