You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
A non-root node should not connect to ESP_Bridge when the softap_ssid in esp_mesh_lite_config_t is customized to a value other than ESP_Bridge.
Actual behavior (suspected bug)
When the softap_ssid in esp_mesh_lite_config_t is customized to MY_MESH_SSID, a non-root node still eventually connects to ESP_Bridge. This occurs when all potential parent nodes are unavailable, except for another node hosting ESP_Bridge.
Error logs or terminal output
No response
Steps to reproduce the behavior
I am testing multiple mesh networks in the same environment using this library. The issue arises under the following conditions:
The esp_mesh_lite_set_softap_ssid_to_nvs() and esp_mesh_lite_set_softap_psw_to_nvs() functions are not called on non-root nodes during testing.
The esp_mesh_lite_erase_rtc_store() function has been called to clear any previously stored data.
Despite the above setup and the softap_ssid being explicitly configured to MY_MESH_SSID, a non-root node eventually connects to ESP_Bridge when all potential parent nodes are unavailable, leaving only a node hosting ESP_Bridge.
This behavior undermines the ability to maintain separate mesh systems when multiple networks coexist in the same space.
Steps to Reproduce
Configure the softap_ssid in esp_mesh_lite_config_t to a custom value, such as MY_MESH_SSID.
Ensure that esp_mesh_lite_set_softap_ssid_to_nvs() and esp_mesh_lite_set_softap_psw_to_nvs() are not called.
Call esp_mesh_lite_erase_rtc_store() to wipe any stored data on non-root nodes.
Set up multiple mesh systems with overlapping coverage, ensuring some nodes are configured with ESP_Bridge.
Observe the behavior of non-root nodes when parent nodes are unavailable.
Checklist
How often does this bug occurs?
always
Expected behavior
A non-root node should not connect to
ESP_Bridge
when thesoftap_ssid
inesp_mesh_lite_config_t
is customized to a value other thanESP_Bridge
.Actual behavior (suspected bug)
When the
softap_ssid
inesp_mesh_lite_config_t
is customized toMY_MESH_SSID
, a non-root node still eventually connects toESP_Bridge
. This occurs when all potential parent nodes are unavailable, except for another node hostingESP_Bridge
.Error logs or terminal output
No response
Steps to reproduce the behavior
I am testing multiple mesh networks in the same environment using this library. The issue arises under the following conditions:
The
esp_mesh_lite_set_softap_ssid_to_nvs()
andesp_mesh_lite_set_softap_psw_to_nvs()
functions are not called on non-root nodes during testing.The
esp_mesh_lite_erase_rtc_store()
function has been called to clear any previously stored data.Despite the above setup and the
softap_ssid
being explicitly configured toMY_MESH_SSID
, a non-root node eventually connects toESP_Bridge
when all potential parent nodes are unavailable, leaving only a node hostingESP_Bridge
.This behavior undermines the ability to maintain separate mesh systems when multiple networks coexist in the same space.
Steps to Reproduce
softap_ssid
inesp_mesh_lite_config_t
to a custom value, such asMY_MESH_SSID
.esp_mesh_lite_set_softap_ssid_to_nvs()
andesp_mesh_lite_set_softap_psw_to_nvs()
are not called.esp_mesh_lite_erase_rtc_store()
to wipe any stored data on non-root nodes.ESP_Bridge
.Project release version
master branch
System architecture
ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)
Operating system
MacOS
Operating system version
15.1 (Sequoia)
Shell
ZSH
Additional context
(如果您偏好使用中文回覆也行!)
The text was updated successfully, but these errors were encountered: