Skip to main content

Gateway Provisioning and Cloud Connection

A Physical Gateway is provisioned as a real AirNgin Device. The server issues the complete credential set, which firmware persists and reuses.

Server-issued credentials​

  • projectCode
  • DeviceSerial
  • MQTT Username
  • MQTT Password
  • MQTT ClientId
  • encryptionKey
  • broker information

ClientId is opaque to firmware. The Backend may construct it from internal metadata, but firmware must never parse or rebuild its prefix or bucketCode.

Brokers​

Primary:  mqtt.airngin.com
Fallback: mqtt.airngin.ir

Main MQTT endpoints:

1883  MQTT
8883  MQTT over TLS
8443  WSS: wss://webapp.airngin.com:8443/mqtt

Reconnect behavior​

  • KeepAlive: 30s
  • Socket timeout: 15s
  • three attempts on Primary, then Fallback
  • after prolonged failure, periodic retry starts from Primary
  • reconnect is non-blocking
  • subscriptions are restored after reconnect
  • temporary network failure never erases valid credentials

When is reprovisioning required?​

  • required credentials are missing
  • factory reset cleared AirNgin identity
  • Project identity changed or was invalidated
  • the broker/server confirmed authentication rejection

DNS failure, router changes, Internet outages, or broker timeouts alone do not require reprovisioning.

ClientId handling​

Firmware follows one rule:

receive complete ClientId from server
→ persist exactly
→ reuse exactly

Never create a new ClientId from DeviceSerial, MAC address, chip ID, or random data.