קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
אישורים
חלק מהקודים של ההודעות מחייבים אישור מהנמען. במקרה הזה,
המקבל צריך לשלוח אישור (ACK) או
אישור שלילי (NAK) תוך שנייה אחת מקבלת ההודעה.
שם קבוצת ההודעות
ערך
אישור
0xFF
השם של קוד האישור
ערך
ACK
0x01
NAK
0x02
יש לשלוח את האישור ישירות לאחר קבלת ההודעה כדי
השולח יוכל לפעול בהתאם. אישור צריך להכיל את קבוצת ההודעות
, את הקוד ואת המצב הנוכחי של ההודעה שאליה היא מתייחסת. לדוגמה, אם
הספק מקבל הודעה שמכילה את פעולת הצלצול (0x04010002013C),
הוא צריך לאשר את הפעולה באמצעות שליחת 0xFF0100040401013C בחזרה כאשר:
0xFF: אירוע ACK
0x01: קוד ACK
0x0004: אורך נתונים נוסף
0x0401: קבוצת הודעות הפעולה והקוד
0x013C: המצב הנוכחי של קבוצת הודעות הפעולה והקוד, מצלצלת בצד ימין
זמן קצוב לתפוגה של 60 שניות
ב-NAK, צריך לכלול גם את הסיבה בתור הבייט הראשון של ההוספה
. הסיבות למחיר יכולות להיות:
0x00: לא נתמך
0x01: המכשיר לא פנוי
0x02: לא מורשה עקב המצב הנוכחי
0x03: לא מורשה עקב קוד אימות הודעה שגוי
0x04: פעולה מיותרת במכשיר
מהדוגמה הקודמת, אם הטבעת הייתה אמורה להיות NAK במקום זאת בגלל
הספק עסוק במשימה אחרת, החבילה שמוחזרת צריכה להיות מוגדרת
0xFF02000401040100 איפה
0xFF: אירוע ACK
0x02: קוד NAK
0x0004: אורך נתונים נוסף
0x01: הסיבה ל-NAK, המכשיר תפוס
0x0401: קבוצת הודעות הפעולה והקוד
0x00: המצב הנוכחי של קבוצת הודעות הפעולה והקוד, כל הרכיבים
הפסקת הצלצול
דוגמה:
#define FP_MSG_ACK 0x01#define FP_MSG_NAK 0x02#define FP_MSG_GROUP_ACK 0xFFstaticvoidfp_msg_send_ack(uint8_tmsgGroup,uint8_tmsgCode){FP_MESSAGE_STREAMreq={FP_MSG_GROUP_ACK,FP_MSG_ACK,0,2};req.data[0]=msgGroup;req.data[1]=msgCode;fp_send((uint8_t*)&req);}staticvoidfp_msg_send_nak(uint8_treason,uint8_tmsgGroup,uint8_tmsgCode){//reason= 0x00: Not supported, 0x01: Device busy, or 0x02: Not allowed due to current stateFP_MESSAGE_STREAMreq={FP_MSG_GROUP_ACK,FP_MSG_NAK,0,3};req.data[0]=reason;req.data[1]=msgGroup;req.data[2]=msgCode;fp_send((uint8_t*)&req);}
[null,null,["עדכון אחרון: 2025-08-13 (שעון UTC)."],[[["\u003cp\u003eSome message codes require an acknowledgement (ACK) or negative-acknowledgement (NAK) response within 1 second, sent only when specified.\u003c/p\u003e\n"],["\u003cp\u003eAcknowledgements (ACKs) use the code \u003ccode\u003e0xFF01\u003c/code\u003e and should include the referenced message's group, code, and current state.\u003c/p\u003e\n"],["\u003cp\u003eNegative-acknowledgements (NAKs) use the code \u003ccode\u003e0xFF02\u003c/code\u003e and provide a reason code (e.g., \u003ccode\u003e0x01\u003c/code\u003e for Device busy) along with the message's group and code.\u003c/p\u003e\n"],["\u003cp\u003eThe acknowledgement structure includes the event (ACK/NAK), code, additional data length, and relevant message details.\u003c/p\u003e\n"],["\u003cp\u003eExample code snippets demonstrate sending ACKs and NAKs using pre-defined message group and code values.\u003c/p\u003e\n"]]],["Receivers must send an acknowledgement (ACK) or negative-acknowledgement (NAK) within one second for specific message codes. ACKs (0x01) and NAKs (0x02) belong to the 0xFF message group. Responses include the message group, code, and current state of the action, and for NAKs, a reason. Example reasons: Not supported (0x00), Device busy (0x01), Not allowed (0x02), Incorrect message code (0x03) or Redundant action (0x04). Example for ring action: `0xFF0100040401013C` or NAK :`0xFF02000401040100`.\n"],null,["Acknowledgements\n----------------\n\nSome message codes require an acknowledgement from the receiver. In this case,\nthe receiver should send either an acknowledgement (ACK) or\nnegative-acknowledgement (NAK) within 1 second of receiving the message.\n| **Note:** Not all messages require an ACK. An ACK should only be sent when the spec above recommends doing so. Unexpected ACKs should be ignored by the receiver.\n\n| Message Group Name | Value |\n|--------------------|-------|\n| Acknowledgement | 0xFF |\n\n| Acknowledgement Code Name | Value |\n|---------------------------|-------|\n| ACK | 0x01 |\n| NAK | 0x02 |\n\nAcknowledgments should be sent directly after message is received so that the\nsender can act accordingly. An acknowledgment should contain the message group\n, code and current state for the message that it is referencing. For example, if\nthe Provider receives a message containing the ring action (`0x04010002013C`),\nit should acknowledge the action by sending back `0xFF0100040401013C` where:\n\n- 0xFF: ACK event\n- 0x01: ACK code\n- 0x0004: Additional data length\n- 0x0401: The action message group and code\n- 0x013C: The current state of the action message group and code, ring right and 60 seconds timeout\n\nFor a NAK, the reason should also be included as the first byte of additional\ndata. Reasons include:\n\n- 0x00: Not supported\n- 0x01: Device busy\n- 0x02: Not allowed due to current state\n- 0x03: Not allowed due to incorrect message authentication code\n- 0x04: Redundant device action\n\nFrom the previous example, if the ring were to be NAK'ed instead due to the\nProvider being busy with another task, the returned packet should be set to\n`0xFF02000401040100` where\n\n- 0xFF: ACK event\n- 0x02: NAK code\n- 0x0004: Additional data length\n- 0x01: NAK reason, Device busy\n- 0x0401: The action message group and code\n- 0x00: The current state of the action message group and code, all components stop ringing\n\nExample: \n\n #define FP_MSG_ACK 0x01\n #define FP_MSG_NAK 0x02\n #define FP_MSG_GROUP_ACK 0xFF\n\n\n static void fp_msg_send_ack(uint8_t msgGroup, uint8_t msgCode)\n {\n FP_MESSAGE_STREAM req = {FP_MSG_GROUP_ACK, FP_MSG_ACK, 0, 2};\n\n req.data[0] = msgGroup;\n req.data[1] = msgCode;\n\n fp_send((uint8_t *)&req);\n }\n\n static void fp_msg_send_nak(uint8_t reason, uint8_t msgGroup, uint8_t msgCode)\n {\n //reason= 0x00: Not supported, 0x01: Device busy, or 0x02: Not allowed due to current state\n FP_MESSAGE_STREAM req = {FP_MSG_GROUP_ACK, FP_MSG_NAK, 0, 3};\n\n req.data[0] = reason;\n req.data[1] = msgGroup;\n req.data[2] = msgCode;\n\n fp_send((uint8_t *)&req);\n }"]]