(My answer here includes some speculation (based on experience and reading various docs).)BetterAutomations wrote: ↑Fri Apr 01, 2022 1:25 amHmm. Not just callbacks. Central is intermittently not responding at all.BetterAutomations wrote: ↑Thu Mar 31, 2022 7:54 pmAnyone have a problem with intermittent firing of on_recv callbacks? Mine intermittently work, even with a bare minimum implementation. I'm working on dynamic pairing with an unencrypted peer.
I believe that receiving broadcasts is inherently more unreliable than sending messages to specific MAC addresses. When sending a message to a non-broadcast address, the underlying espressif code repeats the transmission up to 5 times till it is acknowledged as recieved.
I believe that this is not the case for messages sent to broadcast.
There are many reasons why an individual wifi (or espnow) packet may not be received by the receiving module.
In any case, I think of espnow messages like UDP messages (rather than TCP). If you want absolute reliability you need a protocol to ensure reliable transmission and ack of receipt.
For example, I use broadcasts only to register new devices to my cluster, but I repeat those broadcasts until they are acknowledged. Once I have registered a device, the cluster manager replies and the new client sends further messages to that address.
Also, note my comments in the documentation on "ESPNow and Wifi Operation" on how connecting to a wifi access point can reduce reliability of receipt of messages (just in case you are also connecitng to a wifi access point).