پرش به مطلب اصلی

Driver، Protocol و Compatibility

سه لایه را یکی نگیرید​

  • Transport: حامل ارتباط؛ مثل RS485، BLE، CAN یا Ethernet.
  • Protocol: Framing/semantics روی Transport؛ مثل Modbus RTU یا Protocol اختصاصی.
  • Driver: Runtime componentی که AirNgin Logical Model را به رفتار Native ترجمه می‌کند.

AirNgin هیچ Protocol واحدی برای همه Childها اجبار نمی‌کند.

GatewayDriverRegistry​

Runtime باید بداند چه Driverهایی واقعاً در Firmware نصب و قابل استفاده هستند و هر Driver چه Capabilityهایی دارد:

  • driverKey
  • Driver version
  • Transport/Protocolهای پشتیبانی‌شده
  • Config schema version
  • سخت‌افزار موردنیاز
  • آیا خروجی Uplink Canonical است یا Analyzer لازم دارد
  • آیا Discovery پشتیبانی می‌شود

driverKey باید stable machine identity باشد، نه اسم Class یا File path.

الگوریتم Compatibility​

Device-definition requirements
INTERSECT
GatewayDriverRegistry
INTERSECT
actual hardware/runtime capabilities
=
compatible candidates
  • 0 candidate → incompatible
  • 1 candidate → deterministic selection
  • چند candidate → انتخاب صریح یا user selection

Compatibility با Authorization فرق دارد؛ حتی Device کاملاً compatible ممکن است به Project دیگری تعلق داشته باشد یا قبلاً به Gateway دیگری Bind شده باشد.

Hardware​

وجود Driver در Firmware کافی نیست. اگر Driver به RS485 transceiver، BLE radio، CAN controller یا Zigbee coordinator نیاز دارد، سخت‌افزار واقعی هم باید موجود و فعال باشد.

Native address​

Native address بخشی از gatewayConfig/Driver binding است و DeviceSerial نیست. تغییر Native address نباید Device identity جدید بسازد.