ESP-Now slave with WiFi station+soft-AP mode

[torntrousers]

Hi, I've been trying to use ESP-Now with SDK version 1.5.3_16_04_18. I have a one one ESP-Now controller sending messages to one ESP-Now slave. This works ok when the slave is using WiFi in soft-AP mode, but if I change the slave to use station+soft-AP mode and connect to another WiFi access point then the salve doesn't receive most of the messages sent from the controller ESP8266.

Should that scenario work? The point is to be able to have a ESP-Now slave be a gateway to a WiFi access point for other ESP-Now controller nodes.

TIA.

[pratik]

Hello,

It should all work just fine as long as all the devices are connected to the same local network.
What do you get if you use esp_now_is_peer_exist() to check whether a device exists?
If your device does not receive "most of the messages", then I would expect this API to return inconsistent results.

[torntrousers]

Thanks for the reply. Trying esp_now_is_peer_exist() it seems to return 1 even when the remote peer is powered off. I think esp_now_is_peer_exist() might just be testing locally if the peer has been added with a esp_now_add_peer call?

[torntrousers]

Anyone got any further ideas on this? Has anyone else had ESP-Now working with a slave also connected to another WiFi Access Point?

[waiweng83]

I have exactly the same problem. On top of that, I also noticed that when the AP+STA device is connected to the WiFi router, the range for the ESP-NOW becomes very short like less than 1 meter.

If the device is not connected to WiFi router, the ESP-NOW connection is very stable.

[torntrousers]

I noticed that the 2.0 SDK said it had some ESP-Now fixes so I gave this another try, I had it working well yesterday, but today after tidying up the code it doesn't today !

Posting here again with what I found in case anyone else can find anything.

I don't think its that the range is short when in AP+STA i think its that there are lots of packet losses due to collisions or something but when you have the two EPS's really close together then the esp-now packets signal is so strong it drowns out the collision.

It seems like esp-now is request-response. The controller sends a message and the slave receives that and and sends an acknowledgement and the controller receives that acknowledgement and all is good and the esp-now send_cb is called with a status of 0. If the controller doesn't get the acknowledgment then the callback gets called with a non-zero status.

So if you have the controller send a message wait for the callback to be called and if the status is not 0 then retry the send again then it will eventually work. And the further away the two ESPs are the more attempts it usually takes before it works. Sometimes you see the slave does get the sent message but the controller keeps re-sending so the slave acknowledgement can get lost too.

Yesterday I wondered if using different channels made a difference and was messing about with that it started working and the messages were always going through successfully on the first send, and that was left running for a few hours sending a message every 15 seconds. But I can't recreate that today and it always takes dozens or even hundreds or retries before a successful send.

No idea. Has anyone got this working?