Indeed!
From Wikipedia: “IEEE 802.11 wireless networking uses ARQ (Automatic Repeat Request) retransmissions at the data-link layer.”
Data link layer is OSI layer 2 and significantly below UDP (layer 4, transport layer).
Learning never ends… 
Will report my findings on ESP-now.
MCU mass production completed.
When these are all mounted I will start implementing and testing ESP-now on them. Stay tuned…
How is it going? is there a result?
Meanwhile they are all mounted but I did not yet start to implement the point to point communication. Just give me some more time. I won’t forget to post the results here.
Oh boy!
I finally tried to implement the ESPnow integration of @moto2000 AKA motwok with its two PRs https://github.com/esphome/esphome/pull/1290 and https://github.com/esphome/esphome/pull/1306 .
To do so I cloned his repos and started to rebase them onto the current release branch of ESPHome. With the second PR this was a no-brainer. But the first PR created endless rebase conflicts!
I actually started to solve these conflicts but soon had to admit that this is far beyond my reach. @moto2000 has changed quite some existing ESPHome components. And many of these have been developed on in the release branch. I frankly don’t know enough about all background concepts of ESPHome to resolve all the resulting conflicts.
Another problem is, that I would have to do this rebasing again and again with every new release of ESPHome. Simply because the changes are not restricted to one additional component but are spread throughout other widely used components that will continue to evolve. This is definitely more than I can handle.
Bottom line:
I will drop my requirement that my smoke sensors shall sync directly and without HA.
Instead I will sync them using a central input_boolean in HA that all ESPs will import and use to communicate their alarm state.
Sorry for not completing this journey. I tried but failed.
I honestly hope that @moto2000 will be able to complete his work in a not too distant future.
I was interested in this, but took a slightly different tack. I used the ESP-now tutorials from Getting Started with ESP-NOW (ESP32 with Arduino IDE) | Random Nerd Tutorials and set up two ‘slaves’ with temperature sensors and one ‘master’ using arduino and not ESPHome. The master published the sensor readings to a webpage and this was then put into my home assistant instance. Next step was to use the webscraper tool to convert them to sensors but I haven’t got around to it.
One thing I was surprised about was the attenuation of the signal through walls. I had a sensor in my attic and a master in the downstairs room and it didn’t reach, but moving it upstairs did help. I suspect the best use case for this type of communication is open spaces not inside a house, but it could be just my boards.
I hope this helps someone.
Yepp, seems related. But unfortunately the author did not expose any details about the protocol and the infrastructure behind the scenes. I left a question in the comments of the video. Maybe he will answer.
Well, but then you have a single point of failure again.
If you are looking for a central instance that is more lightweight than HA (and so probably rock solid), why do you go that complicated way of exposing a webpage and scraping it? The perfect solution for you would surely be a stand-alone MQTT server as central instance that talks to your ESPs and to HA.
Fully agree and tried to get this coded, but for some reason I could not get the MQTT and ESPNow to play nicely together. As it can expose a website the master must be able to run ESPNow and act as an access point - which was some issues I found, It should work but…
Anyhow the battery life for this ‘slave’ has been 2 months so far on one Lithium Iron Phosphate battery with no dropouts on the ESPNow communications and still going strong.
These videos keep coming in my feed…
Here is a very informativ video of Andreas Spiess (“The guy with the Swiss accent…”) about ESP-Now.
As always Andreas is very thorough in his considerations.
