دمج ملحق RS-485
حالة الاستخدام
استخدم هذا النمط عندما يحتاج جهاز WLTE يدعم RS-485 إلى تبادل بايتات خام مع ملحق. توفّر OpenAPI نقلًا شفافًا (passthrough)؛ ولا تنفّذ تلقائيًا حزمة بروتوكول Modbus كاملة.
خدمتك مسؤولة عن بناء حمولة بروتوكول التطبيق، وCRC عند الحاجة، وتفسير الاستجابة، وتطبيق قواعد إعادة المحاولة الخاصة بالجهاز.
التدفق الموصى به
- اقرأ
deviceTypeللجهاز المستهدف من سرد الأجهزة (بالإنجليزية). - ابحث عن الملف الشخصي (profile) المطابق في سرد تعريفات نوع الجهاز (بالإنجليزية).
- اعرض النقل الشفاف فقط عندما تحتوي
supportedOperationsعلىdevice.rs485.transceive. - إذا كان إعداد سرعة النقل مطلوبًا، تطلّب
device.rs485.baudRate.setبشكل منفصل واقرأ القيمة الحالية من الحصول على إعداد الجهاز (بالإنجليزية). - أرسل الطلب الخام مع
Idempotency-Keyجديد واحتفظ بمعرّف الأمر المُعاد. - حلّل
command.result.responseHexفقط بعدSUCCESS. إذا كانت الحالةSENT، استعلم عن نتيجة الأمر.
التنفيذ خطوة بخطوة
1. التحقق من القدرة والإعداد
لا تستنتج دعم RS-485 من اسم الجهاز أو من طراز آخر. استخدم supportedOperations. تتطلب تغييرات سرعة النقل صلاحية device:config؛ ويتطلب النقل الشفاف صلاحية device:control.
تقبل نقطة نهاية سرعة النقل النطاق والوحدات الموثّقة في تعيين سرعة نقل RS485 (بالإنجليزية). يجب أن يستخدم الملحق والجهاز القيمة نفسها.
2. بناء الطلب الخام
عبر REST، أرسل requestHex إلى أمر نقل بيانات RS485 (بالإنجليزية). يقبل العقد الحالي سلسلة سداسية عشرية متواصلة من 1 إلى 30 بايتًا، دون مسافات، أو بادئة 0x، أو فواصل.
إذا كان الملحق يستخدم Modbus RTU، يجب أن يبني تطبيقك العنوان، والوظيفة، والبيانات، وبايتات CRC. تعيد OpenAPI توجيه البايتات وتُعيد بايتات الاستجابة الخام؛ ولا تتحقق من سجلات Modbus أو دلالة الوظيفة.
3. معالجة نتيجة الأمر
SUCCESS: حلّلresult.responseHexوفقًا لبروتوكول الملحق.SENT: استعلم عبر الحصول على نتيجة أمر (بالإنجليزية).FAILED: توقّف واعرض الفشل المؤكَّد.TIMEOUT: لم تصل استجابة مطابقة ضمن نافذة الانتظار. لا تفترض فشل الكتابة عند الملحق.
عند استخدام WebSocket، تظهر البيانات المطابقة في رد العملية. قد تصل بيانات RS-485 المتأخرة أو غير المطلوبة عبر device.rs485.received (بالإنجليزية)، التي لا تملك إعادة تشغيل تاريخية.
الواجهات والأحداث الرئيسية
| الغرض | المرجع |
|---|---|
| تأكيد قدرة الجهاز | سرد تعريفات نوع الجهاز (بالإنجليزية) |
| إرسال بيانات خام عبر REST | أمر نقل بيانات RS485 (بالإنجليزية) |
| إرسال بيانات خام عبر WebSocket | نقل بيانات RS485 (بالإنجليزية) |
| إعداد سرعة النقل | تعيين سرعة نقل RS485 (بالإنجليزية) |
| قراءة الإعداد الحالي | الحصول على إعداد الجهاز (بالإنجليزية) |
| استقبال بيانات غير مطابقة | حدث بيانات RS485 (بالإنجليزية) |
الفشل والتعافي
- أعِد استخدام مفتاح التماثلية الأصلي فقط عند إعادة محاولة طلب النقل نفسه بعد نتيجة HTTP غير معروفة أو حد تكرار.
- عامل
TIMEOUTكنتيجة نهائية غير مؤكدة للأمر الأصلي؛ إعادة استخدام مفتاحه لا تُعيد إرسال البيانات. ولّد مفتاحًا جديدًا فقط عندما تكون محاولة فعلية أخرى آمنة لأمر الملحق. - تحقّق في محلّلك الخاص من طول الاستجابة، وصحة البروتوكول (checksum)، والعنوان، والوظيفة قبل تطبيق البيانات.
- خزّن البيانات غير المطلوبة أو المتأخرة فورًا إذا كان فقدانها غير مقبول؛ لا تُعاد أحداث WebSocket.
- احترم حدود التكرار الخاصة بعملية الجهاز بدلًا من إطلاق طلبات نقل متوازية إلى الجهاز نفسه.
اعتبارات الإنتاج
- احتفظ بطابور طلبات واحد منسّق لكل ناقل RS-485 فعلي أو لكل جهاز.
- احجب الحمولات الحساسة إذا كانت بيانات الناقل الخام قد تحتوي قيمًا سرّية.
- سجّل معرّف الأمر، ومفتاح التماثلية، وأطوال الطلب والاستجابة، والحالة النهائية، و
requestId؛ تجنّب تسجيل بيانات الاعتماد أو access token. - اختبر سلوك انتهاء المهلة والاستجابات المكررة مع الملحق الفعلي قبل تفعيل إعادة المحاولة التلقائية.
الخطوات التالية
- حدود التكرار وإعادة المحاولة (بالإنجليزية)
- الحصول على نتيجة أمر (بالإنجليزية)
- حدث بيانات RS485 عبر WebSocket (بالإنجليزية)