Rooterless mesh-lite network (AEGHB-238)

[HWuest]

I want to build a mesh-lite network which works even if no rooter is available.

The mesh-lite feature list tell that this should be possible and I thought the config parameters mesh_lite_config.join_mesh_ignore_router_status and/or
mesh_lite_config.join_mesh_without_configured_wifi will do the job (therefore I wanted to switch over from wifi-mesh to wifi-mesh-lite because with wifi-mesh it also does'nt work but there it is not clear if this is realy supported).

Unfortunatly I'm not able to get it work and find no examples or documentation in the internet. Whenever the Rooter-AP is not reachable the mesh-lite network does not start building up and continously tries to connect to the rooter-ap.

When I start with the Rooter-AP reachable the network builds succecessfully but it gets disturbed when I switch of the Rooter-AP (starts continous scanning for the rooter-ap with huge delays on message recieve and warning/error messages from different sources)

My code is mainly the code from the mesh_local_control example with an additional message send/recieve registered action list to send simple test massages to client and root...

Is there a working sample code how to set up a mesh network without a Rooter-AP ?

Backround of the application is, that (without any special configuration) all devices brought in wifi range together somewhere (without other IT infratructure) should start emediatly building a mesh network automatically and communicate data between all available devices.

PS: testing is sometimes difficult because the wifi often/immediatly falls back to an internally stored rooter ssid and pw if the configured ssid is not active. So if another rooter (which had an earlier successfull connection to the board) is in range this is used instead of the configured one which is not the intention but (if not recognized) looks as if the rooterless connection worked.

For me it is not clear which wifi functions (like storage of ssid/pw in nvs) are used in wifi-mesh-lite and which I am allowed to use in my code without conflicts. Because the wifi-mesh-lite code is not open source I could not analyze deeper what to do... Will the documentation be extended? Currently many possibel topics (like rooterless working mode) are mentioned but without the description of the needed function calls / c-code or examples...

[HWuest]

Addition after some more tests: With the usage of esp_mesh_lite_set_allowed_level(1); and esp_mesh_lite_set_disallowed_level(1); I managed to get a rooterless network to be build up; Call esp_mesh_lite_set_allowed_level(1); when no mesh/rooter connection could be established after some time, call esp_mesh_lite_set_diallowed_level(1); when clients connect to the fixed root

It works also when the rooter is switched on/off later but the impact of fixing the root or disable root level at all clients is not fully clear to me. The autoconfiguration of the network would be disturbed at least...

If you can clarify the functions, the behaviour and how it should be done best would help.

[HWuest]

With the method above the client to root communication works as expceted. The root to client communication is interrupted/delayed every 10 seconds for several seconds. It seems the scanning for the AP is causing the disturbance because around the disturbance the debug/warning messages D (1062104) wifi:clear blacklist W (1065104) vendor_ie: Scanning in progress, please try again later are reported synchronously.

Switching the WiFi to WIFI_MODE_AP omits the WiFi-driver scanning (no scan messages from there any more) but the mesh-lite network driver still tries to scan for APs with the above messages and disturbance...

Our application needs short and stable communication delays fairly below 1 second which is easily achieved under normal conditions with mesh-lite but not during the scan time (sometimes above 4 seconds message delay)!

How can I prevent the scanning which is not needed in the rooterless configuration ?

For clarification, if I set up an AP where the root node connects to the communication is stable afterwards with expected short delays of some ms.

[tswen]

You can use this branch to test the no_router scenario with some internal optimizations that have greatly reduced communication latency.

[HWuest]

See my answer in #16