ESP32 Forum

I ask about some explanation for choosing the correct values for _msg_len arg in ESP_BLE_MESH_MODEL_PUB_DEFINE(_name, _msg_len, _role) macro, which defines the length of the publication message. As I understand, it should be exactly the length of Access payload (3.7.3 Access payload, Mesh Profile v1.0.1) from Access layer, which includes an opcode length, 1, 2 or 3 bytes, and the length of parameters.

In an example of Generic OnOff Server _msg_len has value "2 + 3". According to the Bluetooth mesh documentation, Generic OnOff Server publishes (3.3.1.2.3 Sending a Generic OnOff Status message, Mesh Model v1.0.1) Generic OnOff Status message (3.2.1.4 Generic OnOff Status, Mesh Model v1.0.1), which has the minimum length - 1 byte, and the maximum length - 3 bytes. So, in the example of Generic OnOff Server, "2 + 3" matches the maximum possible length of the Generic OnOff Status message, which is enough to publish both mandatory and optional fields of Generic OnOff Status message. Everything seems fine, but if to look at another example, Generic OnOff Client, _msg_len has value "2 + 1". According to the Bluetooth mesh documentation, Generic OnOff Client publishes (3.4.1.2.2 Sending Generic OnOff Set / Generic OnOff Set Unacknowledged messages, Mesh Model v1.0.1) Generic OnOff Set message (3.2.1.2 Generic OnOff Set, Mesh Model v1.0.1), which has the minimum length - 2 bytes, and the maximum length - 4 bytes, but not 1, as it's defined in the example. So, tell me, please, is it a mistake or I understand something wrongly? I would like to understand clearly which length _msg_len arg in ESP_BLE_MESH_MODEL_PUB_DEFINE macro really defines.

And I have another related question. ESP-IDF contains a series of macros which serve to define Bluetooth mesh models:

• ESP_BLE_MESH_MODEL_SENSOR_CLI(cli_pub, cli_data)

• ESP_BLE_MESH_MODEL_SENSOR_SRV(srv_pub, srv_data)

• ESP_BLE_MESH_MODEL_GEN_ONOFF_CLI(cli_pub, cli_data)

• ESP_BLE_MESH_MODEL_GEN_ONOFF_SRV(srv_pub, srv_data)

• and so on.

Each of them has the first argument cli_pub, which represents "Pointer to the unique struct esp_ble_mesh_model_pub_t", according to documentation. Please, tell me, why is cli_pub argument defined as a NULL in the example of Sensor Client https://github.com/espressif/esp-idf/bl ... main.c#L73, whereas other examples like https://github.com/espressif/esp-idf/bl ... ain.c#L132, https://github.com/espressif/esp-idf/bl ... main.c#L72, https://github.com/espressif/esp-idf/bl ... main.c#L74 define this argument?

Thank you in advance for any explanation.

Is there any support of ESP-IDF here?

Does anyone know an answer?

I'm also confused with this question.

If you're interested, you can look at about the same issue https://github.com/zephyrproject-rtos/z ... sues/31836 for Zephyr RTOS, where it seemed there's allocated 1 extra byte, unlike not enough 1 byte here. I actually wanted to compare qualities of support from Espressif and Nordic Semiconductor, choosing a chip for development. And unlike Espressif, Nordic answered me immediately.