1 Reply Latest reply on Sep 29, 2019 9:51 PM by DheerajP_41

    Bluetooth Mesh Messaging : About Set Message


      Dear All,,,


      I'm testing cypress mesh solution the below environment.


      -. KIT : CYBT-213043-MESH

      -. IDE : ModusToolbox 1.1

      -. BT SDK 1.4

      -. Code Example : Download BT SDK 1.4 example from GIT

      -. Test : mesh location client / server among snip folder in code example.


      About Bluetooth mesh messaging, I can see the below.



      Acknowledged vs. Unacknowledged
      As the name suggests, acknowledged messages require a response from the node that it is addressed to. The response confirms that the message was received and it may also return data back to the sender (e.g. in response to a GET). If a sender does not receive the expected response from a message it may resend it. Messages must be idempotent so that a message received more than once is no different than if it had only been received once.

      All access messages are of the three broad types of GET, SET, and STATUS.
      GET messages request a state value from one or more nodes. A GET message is always acknowledged.
      SET messages are used to change the value of a state. A SET message can be either acknowledged or unacknowledged.
      STATUS messages are sent in response to a GET, and acknowledged SET, or may also be sent by a node independently, for example, periodically using a timer. A STATUS message is always unacknowledged. Therefore, if a node sends a GET message but never receives a STATUS return message, it may resend the GET message.


      Questions :

      If then, In case of SET message, How do I distinguish between sending acknowledged and unacknowledged set messages?
      Maybe, Is it related to the reply field of the wiced_bt_mesh_event_t structure?
      For example, is it acknowledged set message if the reply field is true, or is it unacknowledged set message if the reply filed is false?

      struct wiced_bt_mesh_event__t

          struct wiced_bt_mesh_event__t *p_next;              /**< Pointer to the next event in the queue */

          void            *complete_callback; /**< pointer to the send complete callback */

          uint16_t        company_id;     /**< Company ID for the Model ID */

          uint16_t        model_id;       /**< Model ID */

          uint16_t        opcode;         /**< Opcode of the message to be transmitted or that has been received */

          uint16_t        hci_opcode;     /**< HCI Opcode received of the message from the MCU being processed */

          uint8_t         element_idx;    /**< Element Index of the source or destination of the message */

          uint8_t         ttl;            /**< Time to leave to be used when transmitting or as received from the peer */

          uint16_t        src;            /**< Address of the source mesh node */

          uint16_t        dst;            /**< Address of the destination mesh node */

          uint16_t        app_key_idx;    /**< Application key index used to decrypt when message was received or which should be used to encrypt to send the message */

          uint16_t        num_in_group;   /**< number of devices in the group list */

          uint16_t        *group_list;    /**< If dst is a group address, this points to the array of with individual unicast addresses */

          uint16_t        data_len;       /**< Length of data corresponding to the event */

          uint8_t         credential_flag;/**< Value of the Friendship Credential Flag */

          uint8_t         retrans_cnt;    /**< Number of retransmissions for each message. Should be <= 0x7f. It is ignored using 0 value or if it is reply (reply == WICED_TRUE). */

      #define RETRANSMIT_TIMER_TICK 50

          uint8_t         retrans_time;   /**< Interval between retransmissions in 50-millisecond steps */

          uint8_t         reply;          /**< If TRUE the reply is expected */

      #define REPLY_TIMER_TICK 50

          uint8_t         reply_timeout/**< Time to wait for the peer model layer acknowledgment in 50-millisecond steps */

      #define TX_STATUS_COMPLETED 0

      #define TX_STATUS_FAILED 1

      #define TX_STATUS_ACK_RECEIVED 2

          uint8_t         tx_status;      /**< Transmission failed or timeout occurred waiting for peer reply */

          wiced_timer_t   timer;

          uint16_t        friend_addr;    /**< core sets it to friend address when calls complete_callback if segmented message has been sent and acked by the friend OnBehalfOf LPN. Otherwise it is 0 */

          uint8_t         send_segmented; /**< if non-0 then core uses segmentation to send that message even if it fits into unsegmented message. */

          int8_t          rssi;           /**< RSSI of the received message */

      } wiced_bt_mesh_event_t;



        • 1. Re: Bluetooth Mesh Messaging : About Set Message

          HI PILHEON CHOI,


          You are right. If reply field is TRUE then acknowledgement is expected. And if it is false then it is un-acknowledgement message.

          On client side you have to set the field properly and then send the message.


          If you want to learn more about the usage, may be you can refer the source code MeshClient/MeshClientControl (available along with the SDK). If checkbox called 'reliable' is marked, then it is for ack messages and otherwise it is un-ack messages.




          1 of 1 people found this helpful