Skip to main content

Drivers, Protocols, and Compatibility

Keep the three layers separate​

  • Transport: the communication carrier, such as RS485, BLE, CAN, or Ethernet.
  • Protocol: framing/semantics over that transport, such as Modbus RTU or a manufacturer-specific protocol.
  • Driver: the runtime component that translates between the AirNgin logical model and native device behavior.

AirNgin does not mandate one protocol for all Children.

GatewayDriverRegistry​

The runtime must know which Drivers are actually installed and usable, including:

  • stable driverKey
  • Driver version
  • supported transports/protocols
  • configuration schema version
  • required hardware capability
  • whether uplink is already canonical or needs Analyzer normalization
  • whether discovery is supported

driverKey is a stable machine identity, not a class name or file path.

Compatibility algorithm​

Device-definition requirements
INTERSECT
GatewayDriverRegistry
INTERSECT
actual hardware/runtime capabilities
=
compatible candidates
  • 0 candidates → incompatible
  • 1 candidate → deterministic selection
  • multiple candidates → explicit configuration or user selection

Compatibility is not authorization. A technically compatible Child may still belong to another Project or be actively bound elsewhere.

Hardware​

Compiled Driver code is not enough. If a Driver requires an RS485 transceiver, BLE radio, CAN controller, or Zigbee coordinator, the real enabled hardware path must exist.

Native address​

A native address belongs to gatewayConfig/Driver binding and is not DeviceSerial. Changing native address must not create a new AirNgin identity.