• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 3124 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 126574
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How is CONFIG_OPCODE_COMPOSITION_DATA_GET handled by a Bluetooth mesh server?

SørenHN

I am writing a bluetooth mesh application with a server and client. Provisioning is working, but the configuration of the server is giving me problems.

I have based my application on the Light Switch example from the Mesh SDK v0.10 and can't seem to figurer out how the configuring is handled on the server.

When calling config_client_composition_data_get() from the client, the configuration times out.

How does the server handle the CONFIG_OPCODE_COMPOSITION_DATA_GET message? Is it handled by one the deeper layers or should the application handle the answering? And what could course this error?

Edit 1: After some testing, it seems like the provisioner might be the cause of the problem. Are there anything I should be aware of before calling config_client_composition_data_get() from the provisioner? Like any variables that should absolutely be set before the function call?

Edit 2: After some further testing I am now very sure it is the provisioner who is not sending the message. How do i test what goes wrong in the provisioner? And again, what could the problem be?

Parents
  • 0

    To check if the packet is actually sent and what is sent, you can go deeper in to access layer, all the way down to packet_tx() function. Have you made sure the publication address of the client when you call config_client_composition_data_get() matches with the unicast address of the server ?

    When do you call that function in your project ? Have you tested with access layer directly? that you are sure you can send data between the 2 nodes? For example, have you tried to call access_model_publish() to send a test message ?

    When there is a packet arrive mesh_msg_handle() inside access.c will be triggered, and if you turn on LOG at level DBG1 you can see "RX: " message printed on RTT

Reply
  • 0

    To check if the packet is actually sent and what is sent, you can go deeper in to access layer, all the way down to packet_tx() function. Have you made sure the publication address of the client when you call config_client_composition_data_get() matches with the unicast address of the server ?

    When do you call that function in your project ? Have you tested with access layer directly? that you are sure you can send data between the 2 nodes? For example, have you tried to call access_model_publish() to send a test message ?

    When there is a packet arrive mesh_msg_handle() inside access.c will be triggered, and if you turn on LOG at level DBG1 you can see "RX: " message printed on RTT

Children
No Data
Related