Hello!
Thank you for the excellent SDKs and documentation on the NRF52. I am developing several user devices on the NRF52 DK PCA10040 and my own boards using the Garmin module which uses the NRF52832 SOC. Currently I am using the Mesh SDK nrf5_SDK_for_Mesh_v5.0.0 with Segger Embedded Studio.
I have had good luck on building and using the level client and server examples. A couple weeks of field testing shows both devices based on the examples to be stable and to work every time. Again, thank you!
The mesh network I am using will have level servers controlling led lighting, on off servers controlling water circulating pumps and sensor servers monitoring environmental conditions.
I have chosen to use a separate MCU to do the actual user device control functions. The message handlers on the NRF52 send short simple strings to the separate MCU over the NRF52 UART. Though the NRF52832 SOC is very capable and has lots of HAL support for SPI, I2C etc, for now I leaving the NRF52 to just handle the mesh networking.
Question: I am building a user device with one node that will collect and display network device status information on a given group of node devices, items such as temperatures, pump states and lighting levels. It seems to me that the mesh way of doing this is to implement a node with client models subscribing to the group address of the corresponding server model types. That is to say a multi element node with a level client model, on off client model , scene client model and sensor client model. Is this strategy of multiple elements with different client model types on one node reasonable? The lightness example has several server model types on one node but I am not finding a client node example that has different client model types.
Using the light switch example I am able to get as far as increasing
CLIENT_MODEL_INSTANCE_COUNT (3)
and
DSM_NONVIRTUAL_ADDR_MAX (ACCESS_MODEL_COUNT + 1)
then trying:
static void models_init_cb(void)
{
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Initializing and adding models\n");
for (uint32_t i = 0; i < CLIENT_MODEL_INSTANCE_COUNT; ++i)
{
m_clients[i].settings.p_callbacks = &client_cbs;
m_clients[i].settings.timeout = 0;
m_clients[i].settings.force_segmented = APP_FORCE_SEGMENTATION;
m_clients[i].settings.transmic_size = APP_MIC_SIZE;
//David Carlin
//Perhaps perhaps adding an element to the nrf_mes_config and bringing in sensor_client_init
//will create a element with a sensor client
switch(i)
{
case 0:
case 1:
ERROR_CHECK(generic_onoff_client_init(&m_clients[i], i + 1));
break;
case 2:
ERROR_CHECK(sensor_client_init(&s_clients[0], i + 1));
break;
}
}
}
The result is:
app_error_weak.c, 115, Mesh error 14 at 0x000269A3
The error occurs on:
ERROR_CHECK(sensor_client_init(&s_clients[0], i + 1));
When the same pattern is used with generic_on_off client as the third model, the application runs and can be provisioned by the Android app.
I am sure there is more code to add or change to accommodate the different client model but before I go down that path I would like to know if my approach makes sense. Perhaps there is a more standard way of achieving status monitoring of different model types from a single node.
Second Question:
Does Nordic recommend migrating to NRF Connect and Visual Code at this time? I am happy with Segger Embedded studio but have noticed that the NRF Connect SDK seems to have support for Time and Scheduler models.
Your thoughts would be appreciated.
Regards,
David Carlin
