light_switch_proxy_server of mesh sdk 2.0.0

[jowei]

Hi Nordic:

I build up an mesh network with following setting:

1. A nRF52 platform with example/light_switch/provisioner with a auto-start-provisioner

2. Another nRF52 platform with example/light_switch/proxy_server, and controlled by segger debugger.

After proxy_server node start, I saw "successfully provisioned" in RTT terminal, and then I use nRFConnect to connect proxy_server, 

I saw "app_error_weak.c,   95, Mesh assert at 0x0002C880 (:0)"

If I change this node to proxy_client, the result is same.

So, is light_switch/proxy_client or server of mesh-sdk-2.0 only experimentally?

Could you give me any hint to fix?

(thank you very much, it would be great for me to have many mesh-nodes with proxy feature, thanks!)

[Roberto Zamorano Amado]

Hello, i used the same examples, and had the same issue until i completely erased the device, i think maybe you are using an earlier soft device than 6? if you completely erase and then reprogram it should update the soft device to 6, also play with #define PERSISTENT_STORAGE 0, so it will keep the keys in ram and not flash, this way you can just reboot and provision again (easier to debug).

[jowei]

Hi Roberto

I've just check again, I erased all of the two nRF52, and program softdevice6.0 from sdk15

And program provisioner and proxy-server by segger, and result is same.

But in my environment, only IOS nRFconnect cause this assertion, but android works fine with no assertion.

Did you use IOS or andriod?

Regards.

[Roberto Zamorano Amado]

Hello, i used only the nRF provisioner in here:

examples\light_switch\provisioner

The 3rd party provisioners (android) didn't work, but the nRF did, i suspect the Android one didn't assign the proper groups. the example client needs to be provissioned with 5 virtual keys. one for the device itself, it has 2 for the first 2 light switches, and it has 2 for 2 groups (even/odd lights), if i were you i'd start with the nrf provissioner first, and maybe wait for the nRF App (iOS/Android) to be released, you can contact your local nRF sales rep for timelines (i was told maybe end of this week).

[Jui-Chou (Rick) Chung]

Hello JosephWei,

I would like to suggest you modify the mesh_gatt.c, like the following part:

        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
        {
            error_code = sd_ble_gatts_service_changed(p_ble_evt->evt.gatts_evt.conn_handle,
                                                             m_gatt.handles.service,
                                                             m_gatt.handles.service);
                                                          

            /* Those errors can be expected when sending trying to send Service Changed indication
             * if the CCCD is not set to indicate. Thus set the returning error code to success. */
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO,"sd_ble_gatts_service_changed 0x%04X\n", error_code);
            
            NRF_MESH_ASSERT((error_code == BLE_ERROR_INVALID_CONN_HANDLE) ||
                            (error_code == NRF_ERROR_INVALID_STATE) ||
                            (error_code == NRF_ERROR_BUSY) ||
                            (error_code == NRF_SUCCESS));   //Please add this line
                            
                            
            NRF_MESH_ERROR_CHECK(sd_ble_gatts_sys_attr_set(p_ble_evt->evt.gatts_evt.conn_handle, NULL, 0, 0));
            break;
        }

Please add " || (err_code == NRF_SUCCESS)" in the NRF_MESH_ASSERT()