Skip to main content

Child Onboarding

Onboarding turns a local candidate into an authorized, associated AirNgin Child.

Canonical flow​

Mobile: Add via Gateway
→ select an authorized Gateway
→ open HTML onboarding session
→ discovery or manual native configuration
→ Device lookup / Device definition
→ compatibility check
→ collect gatewayConfig
→ up/onboard/req/AES
→ Backend authorization + Project rules
→ create/activate association
→ dn/onboard/rsp/{reqId}/AES
→ local activation + sync

Discovery is not onboarding​

Discovery only finds a candidate. None of these create association authority:

  • observing a BLE advertisement
  • finding a Modbus slave
  • learning an IP or MAC address
  • Device lookup
  • an HTML temporary session

Association becomes authoritative only after Backend onboarding succeeds.

Same-Master rules​

If the Child is in another Project:

  • unassigned → may enter the target Project
  • same Master + no active association → Backend may move Project membership, then bind
  • same Master + active association → explicit unbind is required first
  • different Master → reject

Reassociation​

Gateway A active association
→ explicit unbind
→ old row becomes historical
→ authorize/onboard Gateway B
→ create new active association

The Child DeviceSerial and history are preserved.

gatewayConfig​

Per-Operation native configuration may be stored under parameterJson.gatewayConfig, for example driverKey, transport, protocol, busId, slaveId, or register.

The Backend stores this configuration but does not execute native protocol semantics; the Gateway Driver interprets it.