• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 3106 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?

  • 0

    The opcode is handled on the config_server in handle_composition_data_get()

    Which issue do you have when calling config_client_composition_data_get() on the client ? Have you checked if the packet actually sent ?

  • 0

    When config_client_composition_data_get() is called on the client, nothing happens on the server. And after half minute or so the client receives a timed-out message from the config_client.

    I have tried to test my client with the light switch server and the light switch client and my server. When i tried my server and the light switch client, i could i did receive the composition data.

    How do I best test that the packets are actually sent?

  • 0

    I have just tested the client sending the message and config_client_composition_data_get() returns NRF_SUCCESS when called.

    How do i test that the server receives the message?

  • 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

  • 0

    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 ?

    Thank you for this question. I tried to use address 0x0001.

    In the light switch example a UNPROV_START_ADDRESS of 0x0100 is used instead as the first address. After changing to 0x0100 it seems work.

    @Hung Bui, can you give a short description of why 0x0001 cannot be used as an unicast address? I can't seem to find any information on this topic.

Related