ESP-Now support for ESP32 (and ESP8266)

[mekanixms]

For espnow to work with the build above you need both interfaces up, acc to my tests

[mekanixms]

OK, after reading about on_recv() I wonder if your issue is the amount of data you are trying to send through ... before processing it. For recv(), irecv() and the e0 singleton example you only have rxbuf size 516 bytes.

Have you tried increasing that?

Haven't looked into that but I doubt my scripts were using 516 bytes. Moreover, as soon as I activated both STA and AP, everything worked just fine.
My suspicion is that the issue is related to espnowInstance.peers_table being empty. Once I had both interfaces up, peers_table was updated and scripts ran as a charm

[davef]

Tried making both STA an AP active and it made no difference to my issue.

[davef]

Hi Glenn,

Didn't get an opportunity to get to the repeater for those two tests. However, I have noticed that the message comes from the remote, through the repeater and down to the local the first time the remote is powered-up. Then after that no more messages.

Dave

[davef]

Hi Glenn,

Finally, the rain let-up. Wettest July since records started!

Managed to perform all the tests again as follows:

1) all ESP32 Generic
2) it returns True for the first message after a remote re-boot then always False. The repeater also shows the first message then no more.
3) No
4) did w0.config('ps_mode'), at the repeater, even though not connected to WiFi and got ps_mode = 1.

When I tried sending a message from the repeater to the remote I got:
Error during execution: (-12393, 'ESP_ERR_ESPNOW_NOT_FOUND')

Is ps_mode = 1 at the repeater correct? It seems to know what the local unit is set to.
Something seems to change in the internal configuration at the remote after sending the first
message. Just my "theory".

[glenn20]

Shouldn't peers_table be automatically populated when I add an user with add_peer??

I am running the code on STA_IF, both sender/receiver on the same channel (wlan interfaces but in espnow module, set the channels to 2, as you can see above)

The peers_table is populated by incoming espnow packets. Ie. you have to receive a message from the other device before it shows up in peers_table. The peers_table is mainly used for tracking the RSSI signal of received packets.

[glenn20]

And on the repeater:

Code: Select all

e0.add_peer(local)

because local is on channel 6 (WiFi) does that mean e0 is still on channel 0?

There is no channel 0 in 2.4Ghz wifi. Channel 0 in add_peer()/get_peer() means to use whatever channel the wifi radio is currently set to (ie. Channel 6 in your case). For the details see: https://docs.espressif.com/projects/esp ... red-device

[glenn20]

In my prev post I tested with STA active, AP if disabled; same issues with AP enabled and STA active

After further testing, I see that the espnowObject.peers_table is only populated, with the new macs from add_peer, when both AP and STA interfaces are active (STA if can be disconnected but should be active, and of course same channel for all devices on the AP if).
This way it works well, sends the messages without errors.

Question: is this a bug? Shouldn't it work on either one of the interfaces, not necessarily both active in the same time ?

It might be a bug. On my devices, I can see the entries in peers_table without setting AP active. BUT, it is only populated for INCOMING messages from the peer (because that is where we get the RSSI values from).

[glenn20]

1) all ESP32 Generic
2) it returns True for the first message after a remote re-boot then always False. The repeater also shows the first message then no more.
3) No
4) did w0.config('ps_mode'), at the repeater, even though not connected to WiFi and got ps_mode = 1.

When I tried sending a message from the repeater to the remote I got:
Error during execution: (-12393, 'ESP_ERR_ESPNOW_NOT_FOUND')

That error means you forgot to do add_peer() before send() .

Is ps_mode = 1 at the repeater correct? It seems to know what the local unit is set to.
Something seems to change in the internal configuration at the remote after sending the first
message. Just my "theory".

ps_mode=1 (WIFI_PS_MIN_MODEM) is fine if not connected to wifi (which is OK for the repeater). If it is connected to wifi as well, it is not good.

You might want to try w0.config(ps_mode=network.WIFI_PS_NONE) on the repeater, but it should not make any difference.

If send() returns False on the remote, that means it thinks it has sent the packet fine, but the peer did not respond.

That could be because the packet was not really sent (unlikely - but one cause MIGHT be that the device is underpowered - once the wifi turns on, the device draws more power which can cause issues with the radio) or that the repeater is really not receiving and responding to the message.

If you share your code, I can try it on some of my devices.

[glenn20]

If you share your code, I can try it on some of my devices.

I've just tested the minimalist case of two peers exchanging espnow packets over channel 6 - with no wifi (which is what your remote-repeater case is) and it works fine. I can keep sending messages many times and it works fine. I can also change one device to another channel and send() will return False as expected. I change the other device to the new channel and send() now returns True and the packet is received.