Postby Kaisha » Tue Apr 28, 2020 3:54 pm
Its not quite clear in the documentation how ESP-NOW and WiFi access are supposed to work, when they are both being used at the same time. The biggest issue is WiFi channel selection.
When setting up ESP-NOW you are required to supply a WiFi channel. So if I wanted to setup a simple ESP-NOW sensor network I might choose channel 1. This will work fine until I connect to a WiFi AP. Since I don't necessarily have access to the AP settings, the WiFi channel could be different than the ESP-NOW channel (in this example channel 1). If the AP used channel 3 or 4, you'd get some, but not all, of the ESP-NOW packets (some would be lost). Should the AP choose channel 11, pretty much every ESP-NOW packet would be lost.
Of course the initial solution is to pick channel 0 for ESP-NOW, except this time ESP-NOW would only work when all devices are connected to the same AP, at the same time. If you want to use ESP-NOW when a WiFi AP isn't available, you're SOL, since all the devices will not necessarily be on the same channel.
It gets even more complicated if you plan to use ESP-NOW both before a WiFi connection has been established, and after. Since channels have been switched half way through the application.
And there are even more scenarios (multiple APs, ESP-NOW peers using different channels, etc...) where things get even worse when using ESP-NOW with WiFi.
The fundamental problem is, from my understanding, that the ESP-NOW channel is directly tied to the WiFi channel. I don't know if there is some hardware requirement for this, but if there isn't the best solution for everyone is that ESP-NOW operate on a channel that is independent from the current WiFi channel (if one even exists).
Having a connectionless, simple, low-level, broadcast orientated protocol, where one can send out packets and receive them without any significant overhead, enables a whole host of awesome applications. ESP-NOW (particularly with the broadcast address peer) would fit that to a 'T', provided you can work around the channel mess.
Also the broadcast peer (mac address: 0xFFFFFFFFFFFF) should be documented, or perhaps an esp_now_broadcast(const uint8_t *peer_addr, const uint8_t *data, size_t len) function added that simply broadcasts ignoring peer data.