شرح KNX Telegram ببساطة
شرح بسيط وسريع لفكرة الـ KNX Telegram، وإزاي الأجهزة بتتواصل مع بعض على الـ KNX Bus. المقال بيوضح أهم أجزاء الـ Telegram زي الـ Source Address والـ Destination Address والـ APCI والـ DPT، وكمان إزاي تقرأ الرسائل في ETS وتستخدم الـ Group Monitor والـ Bus Monitor في الـ Troubleshooting.
شرح KNX Telegram ببساطة
في نظام KNX، كل الأجهزة بتتواصل مع بعض عن طريق رسائل اسمها Telegrams. يعني لما تدوس على زرار عشان تنور لمبة، الزرار مش بيقول للـ Actuator بشكل مباشر: "نور اللمبة"، لكنه بيبعت Telegram على الـ KNX Bus، والـ Actuator اللي مرتبط بنفس الـ Group Address بيستقبل الرسالة وينفذ الأمر.
مثال بسيط: عندنا Push Button عنوانه 1.1.1 ومتربط على Group Address اسمه 1/1/1 – Living Room Light. لما تدوس على الزرار، الجهاز ممكن يبعت Telegram بالشكل ده: 1.1.1 → 1/1/1 → GroupValueWrite → ON. الـ Actuator اللي بيسمع على Group Address رقم 1/1/1 هيستقبل الأمر ويشغل النور.
يعني إيه KNX Telegram؟
الـ Telegram هي رسالة رقمية فيها كل المعلومات اللي KNX محتاجها عشان يوصل الأمر صح. الرسالة بتحتوي بشكل مبسط على: مين بعت الرسالة، الرسالة رايحة فين، نوع الأمر، القيمة اللي اتبعتت، معلومات خاصة بالـ Routing، ومعلومات للتأكد إن الرسالة وصلت بشكل سليم.
الشكل المبسط للـ Telegram بيكون كده: Control Field → Source Address → Destination Address → Routing & Length → Data → Checksum
١. شرح الـ Control Field
الـ Control Field بيكون في بداية الـ Telegram، وبيحتوي على معلومات بتتحكم في طريقة التعامل مع الرسالة، زي الـ Priority وهل الرسالة دي Original Telegram ولا Repeat.
الـ Priority معناها أولوية الرسالة على الـ Bus، خصوصًا لو أكتر من جهاز بيحاول يبعت في نفس الوقت.
في KNX فيه أكتر من Priority، زي System وAlarm وHigh وLow. أغلب الـ Normal Telegrams اللي بنشوفها في المشاريع بتكون Low Priority.
٢. شرح الـ Source Address
الـ Source Address هو عنوان الجهاز اللي بعت الـ Telegram، وده دايمًا بيكون Individual Address.
مثلًا لو شفت:
Source Address = 1.1.25
ده معناه إن الجهاز موجود في:
Area 1 – Line 1 – Device 25
وده مهم جدًا في الـ Troubleshooting، لأن لو شفت Telegram غريب في ETS، أول حاجة ممكن تعملها إنك تبص على الـ Source Address عشان تعرف مين الجهاز اللي بعت الرسالة.
٣. شرح الـ Destination Address
الـ Destination Address هو المكان اللي الـ Telegram رايح له.
والـ Destination ممكن يكون:
Group Address أو Individual Address
في أغلب الوظائف العادية في KNX، بنستخدم Group Address.
مثلًا:
1.1.25 → 1/1/1
هنا الجهاز 1.1.25 بعت رسالة للـ Group Address رقم 1/1/1.
الميزة هنا إن الجهاز اللي بيبعت مش لازم يعرف مين الـ Actuator اللي هيستقبل الأمر، هو بس بيبعت على الـ Group Address، وأي Communication Object مربوط بنفس الـ Group Address ممكن يستقبل الرسالة.
لكن في بعض الحالات زي Programming أو Diagnostics أو Device Management، ممكن الـ Telegram يتبعت من Individual Address لجهاز تاني مباشرة.
مثال:
1.1.25 → 1.1.30
٤. شرح الـ Address Type
الـ Telegram لازم يكون فيها معلومة بتحدد هل الـ Destination الموجود جوه الرسالة هو Group Address ولا Individual Address.
لأن نفس الـ Bits ممكن يتم تفسيرها بشكل مختلف حسب نوع الـ Address.
في الـ Normal Group Communication بنستخدم Group Address، لكن في بعض وظائف الـ Programming والـ Management بنستخدم Individual Address.
٥. شرح الـ Routing Counter أو Hop Count
لو عندك مشروع كبير فيه أكتر من KNX Line، الـ Telegram ممكن تعدي من Line Coupler أو Area Coupler أو KNX IP Router عشان توصل من Line للتانية.
عشان الرسالة متفضلش تلف في الشبكة بدون نهاية، KNX بيستخدم حاجة اسمها Routing Counter أو Hop Count.
القيمة دي بتقل كل مرة الـ Telegram تعدي من Routing Device.
مثلًا ممكن الرسالة تمشي بالشكل ده:
Line 1.1 → Line Coupler → Main Line → Line Coupler → Line 1.2
الـ Routing Counter بيساعد KNX يمنع أي Telegram من إنها تفضل تتحرك في الشبكة للأبد.
٦. شرح الـ Length
الـ Telegram فيها كمان معلومة بتحدد حجم الـ Data الموجودة في الرسالة، لأن مش كل الأوامر حجمها واحد.
مثلًا:
ON/OFF = 1 Bit
Percentage = 1 Byte
Temperature = غالبًا 2 Bytes
وطريقة تفسير الـ Data بتعتمد على الـ Datapoint Type أو DPT.
٧. يعني إيه TPCI؟
TPCI اختصار لـ Transport Protocol Control Information.
الجزء ده مسؤول عن معلومات خاصة بالـ Transport Layer وطريقة التعامل مع الاتصال.
كمبرمج KNX، غالبًا مش هتحتاج تحسبه بنفسك، لأن ETS والأجهزة بيتعاملوا معاه أوتوماتيك.
لكن مهم تعرف إنه جزء من تركيب الـ Telegram، ومش كل الـ Data اللي جوه الرسالة بتكون قيمة التطبيق نفسها.
٨. يعني إيه APCI؟
APCI اختصار لـ Application Protocol Control Information.
وده جزء مهم جدًا لأنه بيحدد نوع الأمر اللي الـ Telegram بيحمله.
من أشهر الأوامر اللي هتشوفها في ETS:
GroupValueWrite: معناها إن جهاز بيبعت قيمة جديدة. مثال: Push Button بيبعت ON على Group Address معين.
GroupValueRead: معناها إن جهاز بيطلب يعرف القيمة الحالية. مثلًا Visualization بيسأل: هل النور شغال ولا مطفي؟
GroupValueResponse: دي الإجابة على GroupValueRead. يعني لو الـ Visualization طلب Status، الـ Actuator ممكن يرد بقيمة ON أو OFF.
مثلًا ممكن تشوف في ETS:
1.1.10 → 1/1/1 → GroupValueWrite → ON
وده ببساطة معناه إن الجهاز 1.1.10 بعت أمر تشغيل على Group Address رقم 1/1/1.
٩. شرح الـ Application Data
الجزء ده هو القيمة الفعلية اللي بنهتم بيها كمبرمجين.
مثلًا في Switching ممكن القيمة تكون:
0 = OFF
1 = ON
لكن في تطبيقات تانية ممكن القيمة تكون Percentage زي 50%، أو Temperature زي 23.5°C، أو Blind Position زي 75%.
هنا بييجي دور الـ DPT.
الـ DPT بيقول لـ ETS والجهاز إزاي يفسر الـ Data.
عشان كده مهم جدًا تختار الـ DPT الصح للـ Group Address.
١٠. شرح الـ Checksum
في آخر الـ Telegram فيه جزء اسمه Checksum.
وظيفته إنه يساعد النظام يتأكد إن الرسالة اتنقلت على الـ KNX Bus بدون Error.
إنت كمبرمج مش محتاج تحسب الـ Checksum بنفسك، لأن الأجهزة بتعمل ده أوتوماتيك.
المهم تعرف إن دوره هو Error Detection والتأكد من سلامة الـ Telegram.
مثال عملي على KNX Telegram
خلينا نفترض إن عندنا Push Button عنوانه 1.1.1، ومتربط على Group Address 1/1/1 الخاص بـ Living Room Light.
لما المستخدم يدوس على الزرار، ممكن تشوف في ETS:
Source: 1.1.1 | Destination: 1/1/1 | Type: GroupValueWrite | DPT: 1.001 Switch | Value: ON
ببساطة معناها:
الجهاز 1.1.1 بعت أمر تشغيل للنور المرتبط بالـ Group Address رقم 1/1/1.
شرح الـ Group Monitor
الـ Group Monitor من أهم الأدوات اللي هتستخدمها في ETS أثناء الـ Troubleshooting.
مثلًا لو المستخدم بيقول إن الزرار مش بيشغل النور، افتح Group Monitor واضغط على الزرار.
لو شفت:
1.1.10 → 1/1/1 → GroupValueWrite → ON
يبقى الزرار بالفعل بيبعت Telegram.
ساعتها تبدأ تدور في الناحية التانية: هل الـ Actuator مربوط بنفس الـ Group Address؟ هل الـ Communication Flags مظبوطة؟ هل الـ Channel Enabled؟ هل الجهاز Online؟
يعني الـ Group Monitor بيساعدك تعرف بسرعة المشكلة في الـ Sender ولا الـ Receiver.
شرح الـ Bus Monitor
الـ Bus Monitor بيديك تفاصيل أعمق من الـ Group Monitor، وبيكون مفيد لو بتدور على مشكلة في الـ KNX Bus نفسه.
ممكن تستخدمه لو عندك مشاكل زي Telegrams بتتكرر كتير، Acknowledgement Problems، Errors على الـ Bus، جهاز بيبعت Telegrams غريبة، Traffic عالي، أو Routing Problem.
ببساطة:
Group Monitor مناسب لمعظم مشاكل الـ Application والـ Group Addresses.
أما Bus Monitor فمناسب أكتر لتحليل الـ Bus Communication نفسها.
يعني إيه ACK؟
لما جهاز يبعت Telegram على KNX TP، الأجهزة اللي استقبلت الرسالة ممكن تبعت Acknowledgement.
ممكن يكون:
ACK: يعني الرسالة اتستقبلت بنجاح.
NAK: يعني حصلت مشكلة في استقبال الرسالة.
BUSY: يعني الجهاز مش قادر يتعامل مع الرسالة في اللحظة دي.
مهم تعرف إن ACK مش هو GroupValueResponse.
الـ ACK جزء من Communication Mechanism على مستوى أقل، لكن GroupValueResponse عبارة عن Telegram فيها قيمة Application فعلية.
ليه ممكن الـ Telegram تظهر أكتر من مرة؟
ممكن أحيانًا تلاقي نفس الـ Telegram ظهرت أكتر من مرة في الـ Monitor.
ده ممكن يحصل لو الرسالة الأصلية ماخدتش الـ Acknowledgement المطلوب، وبالتالي KNX ممكن يعيد إرسالها.
لو المشكلة بتحصل بشكل مستمر، ساعتها ممكن تحتاج تراجع الـ Bus Voltage، Wiring، KNX Power Supply، Connections، Bus Load، Devices، Couplers والـ Topology.
الخلاصة
لما تبص على أي KNX Telegram، حاول تسأل نفسك خمس أسئلة بسيطة:
مين بعت؟ رايحة فين؟ نوع الأمر إيه؟ القيمة إيه؟ وهل الرسالة وصلت بشكل طبيعي؟
مثلًا:
1.1.5 → 2/1/10 → GroupValueWrite → 50%
تقدر تقراها بسهولة:
الجهاز 1.1.5 بعت قيمة 50% للـ Group Address 2/1/10 باستخدام أمر GroupValueWrite.
لو فهمت الأربع حاجات الأساسية: Source Address + Destination Address + APCI + Value، هتقدر تفهم أغلب الـ Telegrams اللي هتقابلها في ETS، وده هيخلي الـ Troubleshooting في KNX أسهل بكتير.