Implement ESP-NOW broadcast on selected channel
ESP-NOW sync message is currently transmitted on the same channel as connected WiFi.
This will prevent other nodes, not connected to WiFi and not using the same channel (currently 1 when in AP mode or unconnected) from receiving ESP-NOW messages.
It would be much better to broadcast ESP-NOW messages on a predetermined (possibly user selectable) channel instead of the channel used by WiFi.
This might require temporarily disconnecting WiFi, sending ESP-NOW message and reconnecting WiFi.
As transmitting ESP-NOW message may take some time, it will be mandatory to prevent automatic reconnection of WiFi from WLED loop().
The unfortunate side effect will be diconnection of websockets clients. The benefit will be that you can easily use mobile WLED units that stay in sync with master regardless of being connected to WiFi or not.
In my tests, disconnecting can lead to crashes: crash happens in core library: assert failed: tcp_update_rcv_ann_wnd IDF/components/lwip/lwip/src/core/tcp.c:951 (new_rcv_ann_wnd <= 0xffff) which seems to be caused by async webserver (at least that is what I found others report when researching this error)
So using disconnect may be hard to debug/solve. Client devices hopping to find the master therefore seems to be a safer approach.
@steveeisner proposed for master to periodically broadcast its presence (hearbeat) even without sync enabled (or only then) on the WiFi channel it is connected to (if it isn't it can use selected channel). This will allow slave devices to "find" master by slowly switching channels at their pace and listening for a heartbeat signal. Once found they would/could remain locked to that channel until rebooted or (perhaps better) there is no heartbeat for extended period of time when searching should restart.
There may be an issue on slaves with how WLED handles WiFi reconnection attempts as it re-initialises WiFi stack, including ESP-NOW.
This is important in situations where slave device is configured with WiFi but was not able to connect on boot.
EDIT: Such solution would not require disconnecting WiFi on the master.
In my tests, disconnecting can lead to crashes: crash happens in core library: assert failed:
tcp_update_rcv_ann_wnd IDF/components/lwip/lwip/src/core/tcp.c:951 (new_rcv_ann_wnd <= 0xffff)which seems to be caused by async webserver (at least that is what I found others report when researching this error) So using disconnect may be hard to debug/solve. Client devices hopping to find the master therefore seems to be a safer approach.
hmmm found this while searching for exactly this error! I also get it after running for few hours in 4 ESP32-S3... with 0.15.0, the betas of 0.15.1 and also self-compiled firmware from the master :( I do not use (or even have enabled) ESP-NOW!