Changing mesh_id results in nodes still connecting to old mesh_id when given new one on boot (AEGHB-1095)

[BR-Coding-cmd]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

Initial boot connects x nodes on mesh_id '25'

After setting new id into NVS via any method, my chosen method is MQTT, after a power cycle the mesh should come back online on new mesh_id and create mesh with that id and disregard any other mesh_ids

Code below regarding how it is set on boot

esp_mesh_lite_config_t mesh_lite_config = ESP_MESH_LITE_DEFAULT_INIT();

    // Mesh ID
    if (nvs_open("MeshUID", NVS_READWRITE, &nvsHandle) != ESP_OK) {
        mesh_lite_config.mesh_id = CMSN_MESH_ID;
    } else {
        uint8_t mesh_id = 0;
        err = nvs_get_u8(nvsHandle, "MeshUID", &mesh_id);
        if (err == ESP_OK) {
            mesh_lite_config.mesh_id = mesh_id;            // esp_mesh_lite_set_mesh_id(mesh_id, true);
            esp_mesh_lite_set_mesh_id(mesh_id, true);
        } else {
            ESP_LOGW(TAG, "Problem bringing up MeshUID from memory");
            mesh_lite_config.mesh_id = 25;            // esp_mesh_lite_set_mesh_id(CMSN_MESH_ID, true);
            esp_mesh_lite_set_mesh_id(25, true);
        }
    }
    ESP_LOGW(TAG, "Mesh ID: %d", mesh_lite_config.mesh_id);
    nvs_close(nvsHandle);

    esp_mesh_lite_init(&mesh_lite_config);

    ESP_LOGW(TAG, "Calling softap init");
    app_wifi_set_softap_info();

    ESP_LOGW(TAG, "Mesh has started");
    esp_mesh_lite_start();

my setting of mesh_id in my own nvs memspace is done like so below by parsing a JSON packet from MQTT

        if(strcmp(keys[i],"meshUID") == 0){//MeshUID
            err = nvs_open("MeshUID", NVS_READWRITE, &HANDLER);
            if (err != ESP_OK) {
                //printf("Error (%s) opening NVS handle!\n", esp_err_to_name(err));
            } else {
                MeshUID = atoi(values[i]);
                err = nvs_set_u8(HANDLER, "MeshUID", MeshUID);
                err = nvs_commit(HANDLER);
                // free(MeshUID);
            }
        }

my SDKConfig is as below for the mesh_lite

#define CONFIG_MESH_LITE_ENABLE 1
#define CONFIG_MESH_LITE_VENDOR_ID_0 71
#define CONFIG_MESH_LITE_VENDOR_ID_1 87
#define CONFIG_MESH_LITE_ID 10
#define CONFIG_MESH_LITE_MAX_ROUTER_NUMBER 3
#define CONFIG_MESH_LITE_MAXIMUM_LEVEL_ALLOWED 5
#define CONFIG_MESH_LITE_NODE_INFO_REPORT 1
#define CONFIG_MESH_LITE_REPORT_INTERVAL 300
#define CONFIG_MESH_LITE_MAXIMUM_NODE_NUMBER 50
#define CONFIG_JOIN_MESH_WITHOUT_CONFIGURED_WIFI_INFO 1
#define CONFIG_JOIN_MESH_IGNORE_ROUTER_STATUS 1

Actual behavior (suspected bug)

Initial boot brings x nodes on mesh_id '25'

set new id in NVS for change of id on re-boot

New id confirmed to have been set via ESP_LOGW on re-boot

log of new parent for the device is a parent on mesh_id '25'

Error logs or terminal output

Log of id taking

W (25332) main: Calling Mesh init func
I (25333) [vendor_ie]: Mesh ID: 30
W (25336) main: Mesh ID: 30
I (25340) Mesh-Lite: esp-mesh-lite component version: 1.0.1
I (25346) ESPNOW: espnow [version: 1.0] init
I (25350) [vendor_ie]: Mesh-Lite commit id: 454ded1
I (25356) [vendor_ie]: Mesh ID: 30 

changed mesh_id nodes parent MQTT JSON (mac = fc:01:2c:cc:ce:cc)
{"myLevel":2,"myParent":{"mac":"94:a9:90:27:c0:5d","rssi":-46}}

old mesh_id parent's MQTT JSON after change over
{"myLevel":1,"myParent":{"mac":"10:27:f5:68:9a:be","rssi":-62},"myChildren":[{"mac":"fc:01:2c:cc:ce:cc"}]}

Steps to reproduce the behavior

set nvs via timer or otherwise

bring up nvs between init func and struct call as shown above

reboot device, observe the ID change and behaviour

Project release version

v5.3.2

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Windows

Operating system version

Windows 11

Shell

PowerShell

Additional context

No response

[BR-Coding-cmd]

an additional note, I've added in

uint8_t tempID = esp_mesh_lite_get_mesh_id();
ESP_LOGW(TAG, "Set Mesh ID: %d", tempID);

this also returns new value, for this it returns 30

edit:
after changing the original mesh's mesh_id, the nodes in the "new mesh" still connect to the parent they connected to before regardless of different mesh IDs

[tswen]

Do your post-restart logs contain "[Unexpected restart]"? If so, it indicates you didn't execute esp_mesh_lite_erase_rtc_store() before esp_restart. Without this call, the device will first attempt to reconnect to its previous parent node (without checking Mesh ID) after esp_restart.

[tswen]

Additionally, the second parameter of esp_mesh_lite_set_mesh() determines whether to save the configuration to NVS. If set to true, you should avoid repeatedly calling this interface to reconfigure the settings on every power-up.

[BR-Coding-cmd]

you should avoid repeatedly calling this interface to reconfigure the settings on every power-up.

Would you then recommend I retain the use of altering the config without it? Only on a call of esp_restart() can the mesh_id change.

I'll add in the call of esp_mesh_lite_erase_rtc_store() when the esp_restart() is called as suggested

thank you!

[tswen]

not need restart

[BR-Coding-cmd]

Just to confirm then, if I ...erase_rtc_store() then call esp_mesh_lite_set_meshid(123, true); I don't need to restart..?

what I've seen is that if I use esp_mesh_lite_erase_rtc_store() then set the id in NVS - restart and call the new mesh_id on boot, it still connects up to the old parent. I'm guessing this is because I'm calling the esp_mesh_lite_erase_rtc_store() before the restart and not on boot?

[tswen]

After calling:

esp_mesh_lite_set_mesh_id()
esp_mesh_lite_erase_rtc_store() 
esp_restart()

Will the device still directly reconnect to the original parent node after reboot? Has the mesh ID actually changed? Could you provide logs before and after the restart?

[BR-Coding-cmd]

esp_mesh_lite_set_mesh_id()
esp_mesh_lite_erase_rtc_store()
esp_restart()

After calling this and setting the new ID to 50 and then calling the above code, on boot the ESP will still be on meshID 25. code used below

void mesh_init_func(void){
    esp_err_t err;

    esp_mesh_lite_config_t mesh_lite_config = ESP_MESH_LITE_DEFAULT_INIT();

    ESP_LOGW(tags.main.mesh, "Mesh ID: %d", mesh_lite_config.mesh_id);

    mesh_lite_config.join_mesh_ignore_router_status = true;
    mesh_lite_config.join_mesh_without_configured_wifi = true;
    esp_mesh_lite_init(&mesh_lite_config);

    ESP_LOGW(tags.main.mesh, "Calling softap init");
    app_wifi_set_softap_info();

    ESP_LOGW(tags.main.mesh, "Mesh has started");
    esp_mesh_lite_start();
    esp_mesh_lite_core_log_enable(true);
}

in app main call

mesh_init_func();
xTaskCreate(delayed_id_set, "delayedSetID", 3 * ONE_KILOBYTE, NULL, 5, NULL);

delayed func

static void delayed_id_set(void) {
    while (1) {
        vTaskDelay(30000 / portTICK_PERIOD_MS);

        const uint8_t delayedMeshID = 50;
        const uint8_t delayed_id = esp_mesh_lite_get_mesh_id();

        esp_mesh_lite_set_mesh_id(delayedMeshID, true);
        ESP_LOGW(tags.main.mesh, "mesh_id now : %d", esp_mesh_lite_get_mesh_id());

        if(delayed_id == delayedMeshID) esp_mesh_lite_set_mesh_id(25,true);
        

        esp_mesh_lite_erase_rtc_store();
        esp_restart();
    }
}

Logs

mesh id changing via mesh_lite_set_id.txt

[BR-Coding-cmd]

I've seen that it does change the data

esp_mesh_lite_set_mesh_id();
esp_mesh_lite_erase_rtc_store();
esp_restart();

however, if you were to change the id without forcing it into NVS say, by changing the config id on boot, then surely you'd want it to go to the new changed id?

[tswen]

esp_mesh_lite_set_mesh_id()
esp_mesh_lite_erase_rtc_store()
esp_restart()

After calling this and setting the new ID to 50 and then calling the above code, on boot the ESP will still be on meshID 25. code used below

void mesh_init_func(void){
    esp_err_t err;

    esp_mesh_lite_config_t mesh_lite_config = ESP_MESH_LITE_DEFAULT_INIT();

    ESP_LOGW(tags.main.mesh, "Mesh ID: %d", mesh_lite_config.mesh_id);

    mesh_lite_config.join_mesh_ignore_router_status = true;
    mesh_lite_config.join_mesh_without_configured_wifi = true;
    esp_mesh_lite_init(&mesh_lite_config);

    ESP_LOGW(tags.main.mesh, "Calling softap init");
    app_wifi_set_softap_info();

    ESP_LOGW(tags.main.mesh, "Mesh has started");
    esp_mesh_lite_start();
    esp_mesh_lite_core_log_enable(true);
}

in app main call

mesh_init_func();
xTaskCreate(delayed_id_set, "delayedSetID", 3 * ONE_KILOBYTE, NULL, 5, NULL);

delayed func

static void delayed_id_set(void) {
    while (1) {
        vTaskDelay(30000 / portTICK_PERIOD_MS);

        const uint8_t delayedMeshID = 50;
        const uint8_t delayed_id = esp_mesh_lite_get_mesh_id();

        esp_mesh_lite_set_mesh_id(delayedMeshID, true);
        ESP_LOGW(tags.main.mesh, "mesh_id now : %d", esp_mesh_lite_get_mesh_id());

        if(delayed_id == delayedMeshID) esp_mesh_lite_set_mesh_id(25,true);
        

        esp_mesh_lite_erase_rtc_store();
        esp_restart();
    }
}

Logs

mesh id changing via mesh_lite_set_id.txt

Your code sets it to 25.

[tswen]

In your scenario, does the root node not need to connect to a router? If router connection is required, mesh_lite_config.join_mesh_ignore_router_status cannot be set to true - it must remain false by default. This configuration is specifically designed for no_router scenarios.

[raspi404]

In your scenario, does the root node not need to connect to a router? If router connection is required, mesh_lite_config.join_mesh_ignore_router_status cannot be set to true - it must remain false by default. This configuration is specifically designed for no_router scenarios.

这个问题我最近也意识到了！
以前总是在一些改动后，连接能力下降，还出现有些设备无法加入mesh。
现在发现，原来是已经组网成功的设备，在代码内动态更改 mesh_id （可能也包含 vendor_id）后，重启调用 esp_mesh_lite_init 有些配置并不会生效（esp_mesh_lite_get_mesh_id()获取到的还是旧的 mesh_id ），还是用的老配置。不过，在这期间如果没有设备擦除 flash 数据，那所有的设备还是能连接的（可能出现连接性能下降的情况），一旦某个设备擦除flash，那他重启后就再也加入不了 mesh 了，直到所有设备都擦除 flash