ESP-Now support for ESP32 (and ESP8266)

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
MMliam
Posts: 121
Joined: Mon May 07, 2018 1:08 pm

Re: ESP-Now support for ESP32 (and ESP8266)

Post by MMliam » Wed Dec 22, 2021 2:40 am

I would find it difficult to believe that simply fixing a channel would require too much coding. However, a build could be created that removes channel-scanning and just have channel specification; either defaulting to a common channel, or throwing a error if not set.
Last edited by MMliam on Wed Dec 22, 2021 2:02 pm, edited 3 times in total.

Barneybear
Posts: 8
Joined: Tue Dec 21, 2021 1:30 pm

Re: ESP-Now support for ESP32 (and ESP8266)

Post by Barneybear » Wed Dec 22, 2021 12:11 pm

Thanks for the reply Dave, it is the latest generic .bin causing the issue, (tried on 3 different 8266 boards) I loaded a previous version and so far no constant reboots.

MMliam
Posts: 121
Joined: Mon May 07, 2018 1:08 pm

Re: ESP-Now support for ESP32 (and ESP8266)

Post by MMliam » Wed Dec 22, 2021 1:58 pm

Barneybear,

Are these Generic builds (posted 20-Oct) you tried?
firmware-esp8266-GENERIC.bin (This one failed)
or
firmware-esp8266-GENERIC_1M.bin (This one works on several ESP8266 units)

Barneybear
Posts: 8
Joined: Tue Dec 21, 2021 1:30 pm

Re: ESP-Now support for ESP32 (and ESP8266)

Post by Barneybear » Wed Dec 22, 2021 3:32 pm

Mmliam the firmware-esp8266-GENERIC.bin for 2m+ caused constant reboot 11112021. Once webrepl setup used. Previous version to this boots fine
All the best

User avatar
glenn20
Posts: 132
Joined: Mon Jun 04, 2018 10:09 am

Re: ESP-Now support for ESP32 (and ESP8266)

Post by glenn20 » Sun Jan 02, 2022 11:49 am

Barneybear wrote:
Tue Dec 21, 2021 1:37 pm
Hi Glenn thank you for your work, I wish to develop a project via webrepl and esp now on an esp8266. I have installed your latest .bin and everything works until I try webrepl setup which after completion makes the 8266 go into a constant reboot loop. Can the two functions coexist or is it a bug. I apologize if it has been asked before, but could not get any search hits on the matter.
All the best
Thanks for the bug report. I confess I don't regularly test webrepl against the espnow code.

I have run some tests this afternoon (which took longer than expected because I forgot that webrepl_setup fails unhelpfully if you have no boot.py!!!!) and discovered that:
  • webrepl seems to work fine with the espnow patches against the v1.17 release (20210903_espnow-g20-v1.17 using the GENERIC_1M image (that is all I can test).
  • webrepl boot loops with recent espnow images built against the master branch.
It would seem that the issue is a bug in the upstrean master branch OR some interaction between my PR and changes in the master branch. Unfortunately I don't have the time required to maintain updates to my espnow code against both v1.17 and master (there has been a fair bit of reorganisation to the ESP network code upstream since v1.17 was released) so I have chosen to prioritise maintaining compatibility with upstream since there has been some discussion about merging this PR recently. This has some risk as the master branch can be unstable between releases.

I will keep looking into this, but it might be a few weeks before I can investigate further.

(Sorry for the delayed response - I've been enjoying the sunshine of the holiday season for the past two weeks :-)).

User avatar
glenn20
Posts: 132
Joined: Mon Jun 04, 2018 10:09 am

Re: ESP-Now support for ESP32 (and ESP8266)

Post by glenn20 » Sun Jan 02, 2022 12:03 pm

Zoland wrote:
Wed Dec 08, 2021 3:09 pm
IN DOCs

1. Which values return ESPNow.write(b) ?

2. Where I can set sync parameter in ESPNow.send(mac, msg[, sync]) if I not want waiting for response?
True: (default) send msg to the peer(s) and wait for a response (or not).
ESPNow.write() is a low-level APi that I haven't fully documented yet and is intended primarily to support asyncio and the buffer protocol for optimised throughput of large messages. The return value is the number of bytes sent (including the header bytes). It will raise a ValueError or OSError exceptions if something goes wrong. You need to provide a specially crafted data packet as an argument.

In the docs, the [, sync] notation indicated that is an optional argument. As Dave pointed out, this means you can provide the sync parameter as an optional 3rd argument to the send method call:

Code: Select all

e.send(mac, msg, False)
to send the message without waiting for a response.

User avatar
glenn20
Posts: 132
Joined: Mon Jun 04, 2018 10:09 am

Re: ESP-Now support for ESP32 (and ESP8266)

Post by glenn20 » Sun Jan 02, 2022 2:01 pm

MMliam wrote:
Tue Dec 21, 2021 1:51 pm
Hi Glenn,

I've been discussing an issue with davef; that being setting a fixed channel in station-mode for an ESP8266. Dave suggested that I try your build the includes ESPNow, as there was an example posted demonstrating that it was indeed possible:
...
The error indicating that the set-channel requires Access-Point-mode, not Station-mode.

dave tried this with an ESP32 and had success; is there some limitation with the build for the ESP8266?
Thanks for the bug report. This looks interesting. I confess that most of the work I have done on the intricacies of using wifi with espnow has been on the esp32 platforms. The message OSError: AP required indicates this is an error/requirement of the underlying Espressif SDK for the esp8266. They use a completely different sdk for the 8266 to the 32* chipsets. The earlier versions of the ESP32 SDK refused to let you set the station on the STA_IF and Espressif fixed that. However, they have declared that they are not providing updates to the 8266 SDK (though they declare an intention to release a future version of the ESP32 SDK which will also support the 8266).

So.... this is unlikely to be fixed any time soon.

However, the following workaround should work (I tested it today):

Code: Select all

w0, w1 = (network.WLAN(i) for i in (0, 1))
w0.active(False); w1.active(False)
w1.active(True) # Set channel will fail unless Active
w1.config(channel=6)  # Now the AP_IF will be operating on channel 6 - and so will the STA_IF
w0.active(True)
w1.active(False)

# Now the STA_IF is ON and set to channel 6 and the AP_IF is OFF
# You can now use the espnow code to send to a device listening on channel 6.

User avatar
glenn20
Posts: 132
Joined: Mon Jun 04, 2018 10:09 am

Re: ESP-Now support for ESP32 (and ESP8266)

Post by glenn20 » Sun Jan 02, 2022 2:13 pm

MMliam wrote:
Wed Dec 22, 2021 1:45 am
Thanks dave, but drawing a blank on differences.

Who do you make feature requests to? I haven't seen any formal link. Quite frankly allowing a station to fix it's channel will make re-connection from deep-sleep much quicker, and remove the significant re-connection time variability.
If you have an issue for the wifi handling code of micropython (which is what the channel setting is) you can post an issue on the micropython github: https://github.com/micropython/micropython/issues.

However, there are limitations in the Espressif SDK for the esp8266 that it may not be possible to fix. Note also that you can significantly reduce the time to reconnect to an AP after deep sleep by using static network config on your ESPXX. Most of the time is consumed in the DHCP negotiation.

After a little digging, I discovered that I can enable Issues on my fork of micropython (Issues are not enabled by default for forks). I have done that now, and people are welcome to post ESPNOW related isues at: https://github.com/glenn20/micropython/issues.

User avatar
glenn20
Posts: 132
Joined: Mon Jun 04, 2018 10:09 am

Re: ESP-Now support for ESP32 (and ESP8266)

Post by glenn20 » Sun Jan 02, 2022 2:30 pm

I discovered this afternoon that my latest espnow-g20 builds have introduced a regression. I failed to correctly migrate some of my patches from ports/esp32/modnetwork.c to ports/esp32/network_wlan.c when the esp32 network code was reorganised on master.

This means that the 'ps_mode' and 'max_tx_power' config options are not supported on my latest images and that setting the channel on the STA_IF was no longer working.

I have fixed this on the espnow-g20 branch and will build some new images (with these fixes and the new rssi support) this week.

Barneybear
Posts: 8
Joined: Tue Dec 21, 2021 1:30 pm

Re: ESP-Now support for ESP32 (and ESP8266)

Post by Barneybear » Sat Jan 08, 2022 11:33 am

Hi Glenn been -10 c here, could do with some sunshine, I use the 4 meg esp8266 wittys, do not seem to cost me much more than the 1 meg varieties, but give me easier access to more pins, if I cut the tri colour led neg leg. If you would like me to try any revised images out please give me a shout. Again thank you for your bins.

Post Reply