ESP-Now support for ESP32 (and ESP8266)

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
napo7
Posts: 6
Joined: Wed Sep 22, 2021 7:14 am

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

Post by napo7 » Wed Sep 22, 2021 7:24 am

glenn20 wrote:
Sat Aug 28, 2021 1:04 pm
  • Announces itself with a specific "discovery" message on broadcast (unencrypted) asking for a service name (eg. "broker") and waits for responses for a few seconds
  • Any of my "broker" nodes that receive the message add the new device as an unencrypted peer and responds with an "Announce" response.
Hi Glenn,

Thanks very much for your work on EspNow on MicroPython ! I was about to do a project on C, but python might help having something easier to code !

However, I'm trying to use ESPNow in python, and I'm stuck at the begining.
I must implement a system where there will be a master node, and 10 slave nodes.
Idealy, slaves should not have to know the master node MAC, and I would like to make them register automatically.

I thought of some algorithm to do so, but I'm stuck in an endless loop : The master node can listen to broadcast messages (listen to any unknown peer), but I can't find a way to make any slave send broadcast messages ?

Am I missing a part ?

I'm very interrested of how you did what you talk earlier (see quote), nodes sending discovery messsage on broadcast ?
PS : I had a look on a C library to be used with platformio and ESP32, which was called "ESPNOW flooding mesh library". Obviously it was using ESPNow, and it abstract all the stuff around espnow, so you just have to setup a master slave, slaves nodes, a cypher key, and everything runs smoothly ! Might be a good idea to reimplement it in python :) If I can make espnow work on micropython, I might give it a try !

Regards

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

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

Post by glenn20 » Wed Sep 22, 2021 8:45 am

napo7 wrote:
Wed Sep 22, 2021 7:24 am
Thanks very much for your work on EspNow on MicroPython ! I was about to do a project on C, but python might help having something easier to code !
This should def be true - I find it just so much quicker to code apps on micropython than in arduino or IDF. The python apparatus provides so many high-level useful abstractions, containers and methods it is more than worth the runtime and memory overheads (for what I do anyway ;).
Am I missing a part ?
You should be able to send a broadcast (from an ESP8266 or ESP32 device with):

Code: Select all

from esp import espnow
e = espnow.ESPNow()
e.init()
bcast = b'\xff'*6
e.add_peer(bcast)
e.send(bcast, 'Hello world')   # Note you must provide the destination mac as bcast address
If the listener node is not receiving the broadcast messages, you could try checking that messages sent to the listener device's mac address are working OK, eg:

Code: Select all

peer = b'listener_mac'
e.add_peer(peer)
e.send(peer, 'Hello world')
I'm very interrested of how you did what you talk earlier (see quote), nodes sending discovery messsage on broadcast ?
I'm hoping to get back to that app very soon - and will try to put something up on github as I suspect it will be useful for others as well.

Like you, I didn't want to hard code mac addresses for the listener devices or the sensor nodes, so I require that my sensor nodes broadcast a message requesting a service name. Nodes which offer that "service" (the listeners) respond to the new sensor confirming they are available to offer that service. The sensors will pick one of the responding nodes to use as the server (I actually do that based on signal strength). Once discovery has been completed, the mac addresses of the chosen and other nodes are saved in meory and in None-Volatile Storage. On reboot the device will get the listener address from NVS and only repeat discovery if it is unable to reach the listener.

I also didn't want just any device be able to send messages into my sensor network, so the listeners and the sensors will only trust peers which possess a shared secret. I use the ESPNow pmk and lmk as those shared secrets.

That might be a bit overboard for what you are trying to achieve now, but it should be useful when I can manage to pack it up into a module - it works really well for me.
PS : I had a look on a C library to be used with platformio and ESP32, which was called "ESPNOW flooding mesh library". Obviously it was using ESPNow, and it abstract all the stuff around espnow, so you just have to setup a master slave, slaves nodes, a cypher key, and everything runs smoothly ! Might be a good idea to reimplement it in python :) If I can make espnow work on micropython, I might give it a try !
That would definitiely be a cool contribution. I've also been looking at the Espressif ESP-MESH capability and thinking about wrapping that in a micropython module as well.

napo7
Posts: 6
Joined: Wed Sep 22, 2021 7:14 am

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

Post by napo7 » Wed Sep 22, 2021 9:07 am

I was in fact not adding bcast address on send function, it was my missing part !
glenn20 wrote:
Wed Sep 22, 2021 8:45 am
That would definitiely be a cool contribution. I've also been looking at the Espressif ESP-MESH capability and thinking about wrapping that in a micropython module as well.
Yes, I hope too ;)
Have a look at this library, it has cool features, such as some clever message routing ensuring even the most far node receive it !!
glenn20 wrote:
Wed Sep 22, 2021 8:45 am
I've also been looking at the Espressif ESP-MESH
In facts I need this meshing feature for one of my customers (I'm a freelance) that need to connect many ESP32 together... So I might move on quickly on the ESP Flood mesh library implementation !

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

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

Post by glenn20 » Wed Sep 22, 2021 10:27 am

napo7 wrote:
Wed Sep 22, 2021 9:07 am
I was in fact not adding bcast address on send function, it was my missing part !
Yeah - that can be a trap. If it was a device MAC address you can get away with just e.send(message), but as the fineprint in the docs indicates, if you omit the peer address (or set it to None) the message will be sent to all registered peers EXCEPT broadcast and multicast addresses.
Have a look at this library, it has cool features, such as some clever message routing ensuring even the most far node receive it !!
Yeah - I have taken a quick look - looks very interesting. Thanks for pointing me at it. I'm interested in how we could leverage a mesh protocol without adding unacceptable power overhead for battery operated sensors which want to turn on the RF for the shortest possible time.
In facts I need this meshing feature for one of my customers (I'm a freelance) that need to connect many ESP32 together... So I might move on quickly on the ESP Flood mesh library implementation !
Lots of luck with that ;)

napo7
Posts: 6
Joined: Wed Sep 22, 2021 7:14 am

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

Post by napo7 » Wed Sep 22, 2021 10:31 am

glenn20 wrote:
Wed Sep 22, 2021 10:27 am
without adding unacceptable power overhead for battery operated sensors which want to turn on the RF for the shortest possible time.
That looks like a bit difficult : If the mesh network is only made of battery powered, no nodes will be capable of relaying the messages?
If there is "always on" devices, then they will be capable of transmitting messages to other nodes.

We could work together on this lib port if you want ?

napo7
Posts: 6
Joined: Wed Sep 22, 2021 7:14 am

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

Post by napo7 » Thu Sep 23, 2021 8:43 pm

Hi,

I've got a very first version of my Mesh library.

Here are the current features :
- Messages are always sent crypted, as broadcast (so we don't have to bind "known" peers)
- When a message is received, we check its TTL : if it is more than zero, we resend it so a further node can have a chance of receiving it
- Received messages IDs are stored in a list so they are not handled anymore (if received after a repeat)
- Messages can be sent to all nodes (broadcast), or targeting a specific node. Broadcast messages are repeat by all nodes.
- a CRC16 is present so we can also check message integrity when received.

There is still some features to code, but it's already useable at this stage. I have tested it with 3 ESP32 nodes to ensure that messages are not repeated forever, and that a message targeting a node is not handled by other nodes.

I don't know where should I host this lib ? On my github account ? Is there a micropython lib repository ?

davef
Posts: 811
Joined: Thu Apr 30, 2020 1:03 am
Location: Christchurch, NZ

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

Post by davef » Sun Oct 03, 2021 6:33 pm

I currently use a WiFi hotspot to relay UDP sockets from a local control to a remote. This link is marginal. Before I try to change this to ESP-Now to get better range a couple of questions:

1) will a WiFi hotspot pass ESP-Now traffic? If so,
2) do I just follow the section in the docs
There are several options to improve reliability of receiving ESPNow packets when also connected to a wifi network
Also, before tackling the ESP-Now/WiFi at the same time combination ...
1) has anything been removed from the standard ESP32 image or is ESP-Now just an addition to your images.

Thanks.

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

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

Post by glenn20 » Mon Oct 04, 2021 12:28 am

davef wrote:
Sun Oct 03, 2021 6:33 pm
I currently use a WiFi hotspot to relay UDP sockets from a local control to a remote. This link is marginal. Before I try to change this to ESP-Now to get better range a couple of questions:

1) will a WiFi hotspot pass ESP-Now traffic? If so,
If I understand the question correctly, I believe the answer is no. You will need an ESPNow device connected to wifi which receives the UDP packets via the wifi router, and relays the message via ESPNow to the target device[s] (including possibly splitting the message if the UDP packets may be more than 250 bytes long). I use this to relay messages from an mqtt server to espnow connected devices (I do that for the purposes of battery operation of the devices rather than for extended range, but it should work for your purposes as well).
2) do I just follow the section in the docs
Yes. My preferred approach is to use STA_IF and disable the power save mode on the (AC powered) relaying device (Example 1 in the docs). Note that the device will run a little warmer (and draw more current) than it would normally when connected to a wifi access point, but should be no more than if it was running in AP mode). The power saving mode turns off the radio between DTIM intervals so esp-now packets are easily missed. The esp32 only does this when you connect to an access point.
Also, before tackling the ESP-Now/WiFi at the same time combination ...
1) has anything been removed from the standard ESP32 image or is ESP-Now just an addition to your images.
No capabilities are removed from the esp32 images I provide. They just have the additional espnow module (and a few extra config options in the network module).

davef
Posts: 811
Joined: Thu Apr 30, 2020 1:03 am
Location: Christchurch, NZ

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

Post by davef » Mon Oct 04, 2021 12:57 am

Hi Glenn,

Sorry, I may have confused things by suggesting I wanted to persist with passing UDP datagrams. The intention would be to change all control traffic to the ESP-Now format as per my water tank project.

I have a WiFi hotspot mounted outside to get a good connection to my cell provider. If all remote ESP-Now devices could use this hotspot to connect to local devices running ESP-Now this would help to rationalise my overall system.

Edit: I can find the MAC address of the hotspot but it looks like it doesn't know what to do with the ESP-Now data.

napo7
Posts: 6
Joined: Wed Sep 22, 2021 7:14 am

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

Post by napo7 » Tue Oct 05, 2021 9:27 am

davef wrote:
Mon Oct 04, 2021 12:57 am
Edit: I can find the MAC address of the hotspot but it looks like it doesn't know what to do with the ESP-Now data.
As far as I know, the ESP-Now frames are vendor specific frames, and I don't think your wifi hotspot would even understand them.
Further more, ESP-Now doesn't require the ESPs to be connected to a WIFI network (it's an esp-to-esp communication protocol), so without "being a client", the wifi hotspot would have no reason of handling those frames.

Post Reply