Configuration process in nrf_mesh APP

RE: Configuration process in nrf_mesh APP

Marjeris Romero — Wed, 17 Jul 2019 12:04:42 GMT

Hi Zhengrui,

Sorry for the late answer here. To fully understand about configuration and composition data you can try out this PyAci tutorial here.

Best regards,

Marjeris

RE: Configuration process in nrf_mesh APP

zhengrui — Thu, 11 Jul 2019 03:52:48 GMT

Hi Marjeris,

There is anoher thing about model in composition data.

We can get element count in capabiliy data but it isn't including model information. Provisioner get model information of node after received composition data. I have read mesh profile about composition data and provisioner get mode information just via composition data,is it right?

In configuration process I just need to receive composition data ,add and bind app key,and set publication and subscrition address to element,is there are something wrong?

Hope you can make me clearly.

Thanks .

Zhengrui

RE: Configuration process in nrf_mesh APP

zhengrui — Thu, 11 Jul 2019 02:51:23 GMT

Hell Marjeris,

Oh,I forgot to tell the reason why I want to understand these things.

I am now developing my provisioner based on nrf_mesh APP to add other functions not only provisioning nrf MESH.So I need to change the code in nrf_mesh_light example with my PCB board.

Best wishes,

Zhengrui.

RE: Configuration process in nrf_mesh APP

Marjeris Romero — Wed, 10 Jul 2019 13:36:06 GMT

Hi zhengrui,

I am sorry but I think there is a misunderstanding, because I am not sure what you are asking for.

The configuration server model takes care of the configuration and you don't need to implement anything yourself in the application side. It should work automatically if the project is configured in the right way. The configuration is a standardize process and is taken care of by the stack. You shouldn't be modifying the stack.

If your application is not working then something else must be wrong. If it's not working you need to give us more details about what exactly is not working so we can help you better.

Have you tested the nRF mesh app together with the unmodified light switch example and confirm that it works as expected?

Best regards,

Marjeris

RE: Configuration process in nrf_mesh APP

zhengrui — Tue, 09 Jul 2019 14:21:46 GMT

Of course I know that all of thses functions is defined in the structure of access_opcode_handler_t opcode_handlers[]. But which I confused is that how to jump to the here after I received configuration messages (I mean that which function is called or where the functions are initiallized).

That's my problem.

Thanks advance.

RE: Configuration process in nrf_mesh APP

Marjeris Romero — Mon, 08 Jul 2019 13:31:22 GMT

As I pointed out in my previous answer, the configuration process is implemented and taken care of in config_server.c.

RE: Configuration process in nrf_mesh APP

zhengrui — Mon, 08 Jul 2019 08:59:56 GMT

ok，it's clear for me to understand and thnks for your answer.

But another question is that how to add and bind app key or set publish address on my nrf5 boards using codes after receive messages from APP. I can't find the connection between the received messages and appkey add/bind function in codes so I still confused about configuration. Could you point out where is to complete these work (add & bind appkey & set publish/subsccription address) in code. I just receive message but don't know how to use them.

RE: Configuration process in nrf_mesh APP

Roshan Rajaratnam — Mon, 08 Jul 2019 08:26:02 GMT

Hi zhengrui, If you are using nRF Mesh Library for Android you don't have to worry about sending/receiving block acknowledgements. This is something that is handled by the library. Usually block acknowledgements are sent/received when sending/receiving segmented mesh messages. This will confirm that certain messages are sent/received and based on this some messages are retransmitted ensuring all messages are sent/received. Whatever you see in the UI here is just displayed as information for the user based on what messages are sent and received. There are callbacks for sending/receiving block acknowledgements and based on this the UI is updated accordingly.

Just as a note nRF Mesh app autmates a few configuration steps right after the provisioning completes, so that it becomes a little bit easier for the user to not go through all the configuration steps. Based on the diagram you have attached the composition data get, app key add messages are sent right after the provisioning is completed as I mentioned above. They are all segmented messages and are sent in multiple segments. The library will respond automatically to the node with block acknowledgements to ensure each segment is received and you don't have to handle block acknowledgments yourself.

Hope this clarifies

RE: Configuration process in nrf_mesh APP

zhengrui — Thu, 04 Jul 2019 03:03:59 GMT

emm,maybe there are some misconception for us.I'm develope my own provisioner in Android based on nrf_mesh APP, using nrf5_SDK_for_Mesh_v2.2.0 and nrf_mesh APP to provision proxy_client.Now I have finished the process of provision so that I need to config it,is that right?

After APP reconnects to proxy client,there are some thing to do such as add/bind appkey and set publication address for this node.But I can't find codes in this procedure to complete the function.There is no codes point to appkey add /bind in mesh_gatt.c and proxy.c files,which is I really want to understand because I don't know how to work it out .

[quote userid="73427" url="~/f/nordic-q-a/49298/configuration-process-in-nrf_mesh-app/196301"]the documentation about GATT and Proxy provisioning here.[/quote]

It shows that we need to exchange something between Android and nrf_board as follows:

But nrf_mesh APP shows some different information in this process.It need to send block acknowledgement information,can you tell me what's function about block acknowledgement?

Best weshes,

Zhengrui.

RE: Configuration process in nrf_mesh APP

Marjeris Romero — Wed, 03 Jul 2019 13:47:47 GMT

Hi,

I am not sure I understood your question. The configuration server model is implemented by us and takes care of the configuration process. You can take a look at the implementation of the server model inside nrf5_SDK_for_Mesh_v3.1.0_src\models\foundation\config

If you want to create your own model you should take a look at the documentation in the infocenter here.

There is also a part of the documentation about GATT and Proxy provisioning here.

Best regards,

Marjeris

RE: Configuration process in nrf_mesh APP

zhengrui — Wed, 03 Jul 2019 09:18:42 GMT

the config data as follows

<t:        544>, main.c,  164, Node Address: 0x0001 
<t:     263764>, mesh_gatt.c,  709, BLE_GAP_EVT_CONNECTED:10
<t:     263767>, proxy.c,  586, Connected
<t:     268561>, mesh_gatt.c,  761, BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:23
<t:     281338>, main.c,  353, Successfully updated connection parameters
<t:     364975>, mesh_gatt.c,  743, BLE_GATTS_EVT_WRITE:50
<t:     364982>, mesh_gatt.c,  393, tx.cccd_handle: 13
<t:     364985>, mesh_gatt.c,  394, p_evt_write->data %x,%x: 0100
<t:     364988>, mesh_gatt.c,  396, TXTXTXTXTXTXTXTXTXTXXTXTXTXTTXTXTXTX
<t:     364991>, proxy.c,  613, TX ready
<t:     364992>, proxy.c,  290,  beacon_cycle_send
<t:     364995>, proxy.c,  265,  beacon_packet_send
<t:     364999>, proxy.c,  243, packet_send
<t:     365001>, mesh_gatt.c,  653,  mesh_gatt_packet_send 
<t:     365003>, mesh_gatt.c,  654,  mesh_gatt_packet_send : 010091B2
<t:     365007>, mesh_gatt.c,  126, mesh_gatt_pdu_send : 000000001701010091B257C653B9D9FD0000000055A6799862972931
<t:     365466>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57             //sending MESH_BEACON,
<t:     365475>, mesh_gatt.c,  126, mesh_gatt_pdu_send : 000000001741010091B257C653B9D9FD0000000055A6799841972931
<t:     365481>, mesh_gatt.c,  790, BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:55
<t:     365727>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     365730>, proxy.c,  627, TX complete
<t:     365736>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     365739>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 1
<t:     365743>, main.c,  353, Successfully updated connection parameters
<t:     374363>, mesh_gatt.c,  761, BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:23
<t:     447356>, mesh_gatt.c,  743, BLE_GATTS_EVT_WRITE:50
<t:     447362>, mesh_gatt.c,  417, rx.value_handle: 10
<t:     447364>, mesh_gatt.c,  418, conn_index 0
<t:     447366>, mesh_gatt.c,  421, RXRXRXRXXRXRRXRXRXRXRXXRXRX
<t:     447369>, mesh_gatt.c,  333, mesh _gatt.c 328 proxy_pdu_rx_first　　　　　　　　／／receive _NETWORK_PDU
<t:     447372>, mesh_gatt.c,  334, proxy_pdu_rx_first : 00147D36096A756E41AEAD918D5FD149A7878CC6212C
<t:     447376>, mesh_gatt.c,  341, PROXY_SAR_TYPE_COMPLETE : 147D36096A756E41AEAD918D5FD149A7878CC6212C
<t:     447380>, mesh_gatt.c,  344, mesh _gatt.c 328 evt.params.rx.pdu_type 0
<t:     447383>, mesh_gatt.c,  347, mesh _gatt.c 328 evt.type 0
<t:     447385>, proxy.c,  618, RX
<t:     447387>, proxy.c,  619, proxy 613 613 rxrxrxrxrxrxrxrxrxrxrxrxrxrxrx  -----------------------
<t:     447391>, proxy.c,  555, RX GATT PDU type 0x0, len 21
<t:     447393>, network.c,  270,  network_packet_in
 <t:     447396>, network.c,  271,  network_packet_in : 147D36096A756E41AEAD918D5FD149A7878CC6212C
 network_packet_send 
<t:     463569>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     463575>, proxy.c,  627, TX complete
<t:     463577>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     463580>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 0
<t:     463583>, proxy.c,  632, p_evt->params.tx_complete.pdu_type 0
<t:     463586>, mesh_gatt.c,  126, mesh_gatt_pdu_send : FEFFFFFF1E0014A330CB3FBFD31E4DD2E06A9ADEE2209756674C27DE520C07C0E200E4
<t:     487901>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     487907>, proxy.c,  627, TX complete
<t:     487909>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     487912>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 0
<t:     487914>, proxy.c,  632, p_evt->params.tx_complete.pdu_type 0
<t:     487918>, mesh_gatt.c,  126, mesh_gatt_pdu_send : FEFFFFFF1E0014EF82918CF72E6C726F33F82A8338E117E594E0675D36E6A76E1E761C
<t:     504132>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     504138>, proxy.c,  627, TX complete
<t:     504140>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     504143>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 0
<t:     504146>, proxy.c,  632, p_evt->params.tx_complete.pdu_type 0
<t:     504150>, mesh_gatt.c,  743, BLE_GATTS_EVT_WRITE:50
<t:     504152>, mesh_gatt.c,  417, rx.value_handle: 10
<t:     504155>, mesh_gatt.c,  418, conn_index 0
<t:     504157>, mesh_gatt.c,  421, RXRXRXRXXRXRRXRXRXRXRXXRXRX
<t:     504159>, mesh_gatt.c,  333, mesh _gatt.c 328 proxy_pdu_rx_first
<t:     504162>, mesh_gatt.c,  334, proxy_pdu_rx_first : 00147766EF42BEE03959758379C7943F9FF0F896C5B7B13A21
<t:     504167>, mesh_gatt.c,  341, PROXY_SAR_TYPE_COMPLETE : 147766EF42BEE03959758379C7943F9FF0F896C5B7B13A21
<t:     504171>, mesh_gatt.c,  344, mesh _gatt.c 328 evt.params.rx.pdu_type 0
<t:     504174>, mesh_gatt.c,  347, mesh _gatt.c 328 evt.type 0
<t:     504176>, proxy.c,  618, RX

<t:     552797>, mesh_gatt.c,  743, BLE_GATTS_EVT_WRITE:50
<t:     552801>, mesh_gatt.c,  417, rx.value_handle: 10
<t:     552803>, mesh_gatt.c,  418, conn_index 0
<t:     552805>, mesh_gatt.c,  421, RXRXRXRXXRXRRXRXRXRXRXXRXRX
<t:     552808>, mesh_gatt.c,  333, mesh _gatt.c 328 proxy_pdu_rx_first
<t:     552811>, mesh_gatt.c,  334, proxy_pdu_rx_first : 00140FEFC82DBC725EC610F6448B4EF4EAC57F82B9AAA6DDD3469F6F03AE
<t:     552820>, mesh_gatt.c,  341, PROXY_SAR_TYPE_COMPLETE : 140FEFC82DBC725EC610F6448B4EF4EAC57F82B9AAA6DDD3469F6F03AE
<t:     552828>, mesh_gatt.c,  344, mesh _gatt.c 328 evt.params.rx.pdu_type 0
<t:     552831>, mesh_gatt.c,  347, mesh _gatt.c 328 evt.type 0
<t:     552833>, proxy.c,  618, RX
<t:     552835>, proxy.c,  619, proxy 613 613 rxrxrxrxrxrxrxrxrxrxrxrxrxrxrx  -----------------------
<t:     552839>, proxy.c,  555, RX GATT PDU type 0x0, len 29
<t:     552841>, network.c,  270,  network_packet_in
 <t:     552844>, network.c,  271, <t:     552853>, proxy.c,  560, BLE_GATTS_EVT_WRITE:50
handle_appkey_add(***************************************
<t:     558938>, network.c,  241,  network_packet_send 
<t:     558940>, network.c,  242,  mesh_gatt_packet_send : 00AD09AF195C3DD097D992
<t:     558947>, proxy.c,  243, packet_send
<t:     558949>, mesh_gatt.c,  653,  mesh_gatt_packet_send 
<t:     558951>, mesh_gatt.c,  654,  mesh_gatt_packet_send : 1459C43A
<t:     558955>, proxy.c,  560, MESH_GATT_PDU_TYPE_NETWORK_PDU: 14C4FE52
<t:     569008>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     569014>, proxy.c,  627, TX complete
<t:     569016>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     569019>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 0
<t:     569022>, proxy.c,  632, p_evt->params.tx_complete.pdu_type 0
<t:     569025>, mesh_gatt.c,  126, mesh_gatt_pdu_send : 0200000019C01459C43A71FACF87C485A72FC22C5F162A3735430FFBFA27
<t:     585229>, mesh_gatt.c,  748, BLE_GATTS_EVT_HVN_TX_COMPLETE:57
<t:     585235>, proxy.c,  627, TX complete
<t:     585237>, proxy.c,  628, proxy 622622 txtxtxtxtxtxt  ---------------
<t:     585240>, proxy.c,  629, p_evt->params.tx_complete.pdu_type 0
<t:     585242>, proxy.c,  632, p_evt->params.tx_complete.pdu_type 0