ESPNow docs: trying to understand the finer points

[peterhinch]

Some queries re this otherwise comprehensive doc.:

1. I can't figure out the multicast option. How do you define a multicast address?
2. ESPNow.send(msg): the message is forwarded to the peer specified in .add_peer. What happens if multiple peers have been registered? The doc seems to imply it will go to all of them but perhaps it should be stated.
3. If ESPNow.send(msg) sends to all registered peers, what is the difference between that and ESPNow.send(None, msg)? I can't make sense of the phrase "will send to all registered peers except the broadcast address" given that (as I understand it) the broadcast address sends to every ESPNow device that is in range and using the same channel, registered or not.

[glenn20]

Thanks for the feedback on the docs Peter - getting better incrementally.

1. I can't figure out the multicast option. How do you define a multicast address?

I have never used multicast on the esp32 platform, so I am not sure how to subscribe to a multicast group (and I am unaware if that is possible with micropython), but you can treat any valid multicast MAC address like a broadcast address in terms of sending. I suspect a little more work is required to make that usable on micropython. I suspect it could be quite useful for managing cohorts of espnow devices.

2. ESPNow.send(msg): the message is forwarded to the peer specified in .add_peer. What happens if multiple peers have been registered? The doc seems to imply it will go to all of them but perhaps it should be stated.

Yes, it will send to all registered peers. I thought that was explicit, but on re-reading I see that it is not - thanks for pointing it out. I'll make an update. Note that send(msg) will return False if any of the peers don't respond.

3. If ESPNow.send(msg) sends to all registered peers, what is the difference between that and ESPNow.send(None, msg)?

These are functionally identical: "In the second form, mac=None and sync=True." where the second form refers to ESPNow.send(msg). ESPNow.send(msg) is just a convenience shortcut.

I can't make sense of the phrase "will send to all registered peers except the broadcast address" given that (as I understand it) the broadcast address sends to every ESPNow device that is in range and using the same channel, registered or not.

Yes. To send to the broadcast (or multicast) address, you have to register the broadcast (or multicast) with add_peer(), so it shows up in the list of registered peers. However, if you do e.send(None, msg) it will send to all the registered unicast peers (ie. not broadcast (or multicast addresses).

To send a broadcast message, you must set the bcast address as the peer in e.send(peer, msg).

I'l think about reformulating the statement in the docs to make it clearer. (I misunderstood this for some time as the espressif docs are not clear on this).

[peterhinch]

fx: Light dawns. Thank you. A few comments on micropower operation.

Re broadcast and multicast it's perhaps worth pointing out that these are not useful in the context of micropower nodes. This is because the node spends most of its time in deepsleep. Any communication protocol for micropower nodes needs to be half-duplex: the node wakes up and sends a message requesting a response. Any queued messages for that node are then sent in a brief time window before the node goes back to sleep.

My take on ESPNow and MQTT is that it only makes sense in the context of micropower nodes. If power consumption is not an issue you would just run an mqtt-as client and get the benefit of asynchronous full duplex operation (and more).

ESPNow is magic for micropower. With your ESP32 boot optimisations and a gateway MQTT nodes with extremely low power consumption could be built. My gateway is designed on the assumption that nodes will be micropower.

[glenn20]

Yes, my main motivation for espnow is for battery operated devices. However, there are other reasons people may and do choose to use espnow, including:

• operational independence of wifi infrastructure, isolation from wifi networks, latency, ...

For my own usage, I use broadcasts for service discovery: a new device can boot up and be admitted to a network with access to service nodes by broadcasting discovery requests for service nodes (like the mqtt gateway, ntp server or an OTA firmware update server), validating the service node via a shared app_name and key (and the service node also authenticates the new client based on the app name and key). The new node saves the service node's details in NVS or on filesystem and just uses that during normal operation (wake from deepsleep and send a sensor reading when needed). When enough sends have failed, the node will attempt rediscovery of service nodes using broadcasts.

With this approach I can replace the central service nodes or deploy failover nodes in my network and never have to physically reconfigure my remote battery nodes (till the batteries fail).

For some types of usage, broadcast may also be a good choice for very low power consumption: wake-up and send message to broadcast and return to sleep can use less power than unicast in some circumstances as there is no automatic re-transmission with broadcasts. While, I believe the differences will be marginal in practice, some users feel pretty strongly about it. There is also no configuration required on the micropower devices, just share your message with whatever devices want to listen.

[sosi-deadeye]

1. I can't figure out the `multicast` option. How do you define a multicast address?

A mac address has 6 bytes. I use b"\ff" * 6 as broadcast address.
AFIK I had to add the broadcast address to the peer, who want's to send.
I my case I did it on both devices because both are sending and receiving.

[glenn20]

Yes - that is the broadcast address. A multicast MAC address has the least significant bit in the most significant byte octet set to 1. Broadcast is a special case. With multicast you can define multicast groups and send to those groups (and join said grops too). However, the usual unix mechanism for joining a multicast group is to turn multicast option on as socket options of a UDP socket. I don't know what the lwip call is that actually causes a device to listen to multicast ethernet (not IP) messages.