Connection as Child Level 3 without Parent, long time to find Rooter (AEGHB-350)

[HWuest]

          You can use this [branch](https://github.com/tswen/esp-mesh-lite/tree/examples/add_no_router_example/examples/no_router) to test the no_router scenario with some internal optimizations that have greatly reduced communication latency.

Originally posted by @tswen in https://github.com/espressif/esp-mesh-lite/issues/16#issuecomment-1632186874

[HWuest]

I don't find my error description here in the issue system any more, so I repeat it:

I have several complex Mesh-lite applications and when I start a device (ESP32S2 mini) I often get a child connection on Level2, 3 or sometimes even 4 without an other mesh-lite device of same mesh ssid in range (so should get root node level 0). It then took several minutes until the system recognizes the configured rooter and switch back to level 1 with rooter connection but sometimes level does not change at all or jumps between levels 2/3...

As far as I could test several configurations and setups the problem seems to arise when there is another different mesh-lite network device active in range with a different ssid and/or pwd. (no messages are send/recieved between those networks but connection process seems to be disturbed)

Is there a interference in the connection/scan process between different mesh networks even when they have a different ssid/pwd ?

After a false connection after a reset I often see also the warning message: vendor_ie: [Unexpected restart]: the rtc data: level:2, ssid:DB, bssid 70:04:1d:f5:99:15 W (562) vendor_ie: Try to connect the original parent node where DB is the own mesh-ssid. No self-connection should take place to this ssid but it seems to be stored as the last active connection somwhere internally...

[tswen]

You can differentiate between different Mesh networks by setting different Mesh IDs. When the ESP32 undergoes an unexpected software reset, it will attempt to connect to the original parent node based on the information saved in the RTC memory. This strategy is a way to maintain the network topology after a reset.

[HWuest]

Thank you for the fast answer, that was my first try becouse that's the way it worked for Espressif Mesh (without lite) before.

So I tried to set a different Mesh-ID by mesh_lite_config.mesh_id = 11; in the root node before calling esp_mesh_lite_init(&mesh_lite_config);

That makes no difference, a client with another mesh_id (default 77) still directly connects to the root.

Mesh-lite Info still reports: I (553) vendor_ie: Mesh ID: 77

So change seem to have has no effect on the ID. Same for changing the config value in sdkconfig, no effect!

Can I avoid the RTC based connection after reset or explicitly clear the information when the network setup was changed by the user to avoid wrong connection during startup after the change?

Is there a way (signing an NDA or something else) to get access to the source code (sources are the best documentation) to have a chance to better understand the features (documentation and examples are rare because mesh-lite seems to be new and under develpoment)?

If interested, I can support the mesh-lite comunity by writing documentations / examples around my findings (I'm a german IT-consultant specialized on improving/rework embedded developer SW-documentations directly based on source code...)

[HWuest]

Using

esp_mesh_lite_set_mesh_id( mesh_id,true);

I managed to change the Mesh-ID successsful.

[tswen]

If you need to prevent the reconnection to the source parent node after a reset, you just need to execute esp_mesh_lite_erase_rtc_store before the esp_restart.

[HWuest]

I already found this function in the mesh_lite_core.h include but without documentation or source code it is not easy to imagine what the function exactly does and when to use it with what side effects (I think longer startup time is one effect?!?).

Since it is clear, that different bridge ssids does not automatically mean different mesh-lite networks so that a different mesh-id is needed to seperate the networks by calling esp_mesh_lite_set_mesh_id (because config paramter has no effect wich realy seems to be a bug as far as I can see) the connection process is stable again.

Our last tests have been successfull so we are ready to start the testing phase with real users, thank you for your support.