ESP-NOW: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{#addbodyclass:tag_tech}} | {{#addbodyclass:tag_tech}} | ||
{{stub}} | |||
ESP-NOW is intended as for ESP-to-ESP communication, based on WiFi but not requiring association ([https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_now.html it abuses action frames]). | |||
It lets ESP devices send small packets to other ESP devices | |||
: directly (without an AP) | |||
: coexisting with the regular WiFi stack (but there are practical footnotes) | |||
...which seems to be a | Some explanations mention that you pair with a peer, | ||
and will automatically recover after restart. | |||
...which seems to be a fancy way of saying that it's stateless, | |||
that you need to send to a specific MAC, | |||
that you have to know and will probably either hardcode or somehow discover" | |||
There is also a note that you can actually use broadcasts, in which case you don't have a peer limit. | There is also a note that you can actually use broadcasts, in which case you don't have a peer limit. | ||
Limitations: | Limitations: | ||
* will use the same channel as WiFi | |||
:: so if you switch to a specific AP, ESP-now will _follow_ that, which is often not may not be predictable | |||
- | * Fire-and-forget - No ACKs | ||
* 250 bytes of payload, because it uses Action Frames | |||
* can't receive if in modem sleep | |||
** note: it can make sense to have one ESP stay awake and have others poll it between sleep, though at this point it's not too differrent from that being a real AP - in fact might you get TIM on a real AP) | |||
** there are some other things in STA mode, see e.g. esp_now_set_wake_window() | |||
* different peer limits exist in Station mode and in AP mode or AP+Station mode | |||
* Assume the sending rate is no faster than 1Mbps ''at best'' but usually slower. | |||
* you will receive whatever is sent to you. | |||
** You need to figure out that message is for your type of device, | |||
** and/or whether it is a type of message you want to respond to | |||
* no encryption in a practical sense |
Latest revision as of 16:51, 22 June 2024
✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
ESP-NOW is intended as for ESP-to-ESP communication, based on WiFi but not requiring association (it abuses action frames).
It lets ESP devices send small packets to other ESP devices
- directly (without an AP)
- coexisting with the regular WiFi stack (but there are practical footnotes)
Some explanations mention that you pair with a peer,
and will automatically recover after restart.
...which seems to be a fancy way of saying that it's stateless, that you need to send to a specific MAC, that you have to know and will probably either hardcode or somehow discover"
There is also a note that you can actually use broadcasts, in which case you don't have a peer limit.
Limitations:
- will use the same channel as WiFi
- so if you switch to a specific AP, ESP-now will _follow_ that, which is often not may not be predictable
- Fire-and-forget - No ACKs
- 250 bytes of payload, because it uses Action Frames
- can't receive if in modem sleep
- note: it can make sense to have one ESP stay awake and have others poll it between sleep, though at this point it's not too differrent from that being a real AP - in fact might you get TIM on a real AP)
- there are some other things in STA mode, see e.g. esp_now_set_wake_window()
- different peer limits exist in Station mode and in AP mode or AP+Station mode
- Assume the sending rate is no faster than 1Mbps at best but usually slower.
- you will receive whatever is sent to you.
- You need to figure out that message is for your type of device,
- and/or whether it is a type of message you want to respond to
- no encryption in a practical sense