I am new to this tech. I’ve successfully used ESP32 (Dev) boards for stand-alone projects. After reading about ESP-NOW, I envision trying to have a ‘Provider’ board send (outdoor) temperature/humidity information to a ‘Consumer’ board. The ‘Consumer’ board would record (indoor) temperature, and display both indoor and outdoor temperatures. My first (stumbling) steps are to design a simple setup for board to board communication. I’m using ESPHome to write code.
Currently, I have two ESP32 (Dev) boards mounted onto a breadboard, powered by a stand-alone 5V PSU. The ‘Provider’ board is equipped with AHT20 temperature sensor. The ‘Consumer’ board is equipped with a ssd1306 (128X64) display. I have functional files for each board (running independently). That is, the ‘Provider’ properly reports temperature/humidity values, and I can access and display miscellaneous text on the ‘Consumer’ display. However, I have not been able to transfer data from ‘Provider’ to ‘Consumer’.
I have found a number of (‘simple’) ESP-NOW sketches on the internet. But, when I attempt to duplicate the code (using ESPHome) the file finds errors and fails to validate. It would appear that over time, some ESP-NOW parameters may have changed, and are no longer valid.
Can anyone point me to a ESP-NOW reference that defines current parameters? Or shed some light on why I feel like I’m just wandering around in the dark.
Thanks,
Grizz952
I suggest you share the yaml of your two devices for a start.
Have you read this thread?
What are you trying to achieve with ESPNOW?
Is there a reason you aren’t just using Wi-Fi. I have Wi-Fi devices that are 30 to 60 feet away (outside) in my barnyard. They work fine.
ESPNOW is not (yet, at least) in the easy (as in plug and play) category. On the other thread there were people that were really excited about it, but I never heard anything that sounded like a game changer.
I use premade BT temperature and humidity sensors that are battery powered and a BT gateway. They are fairly inexpensive and work well and look decent and have a local screen to show current conditions. The range on them has been decent too.
If you are experimenting for the “fun” of it, that is great. If your goal is to get temperature readings, there are easier ways.
There’s always BlueTooth if you cannot get ESPNow working… Oh wait, nevermind!
Espressif, the makers of your ESP32 chips and creators of the ESPNow protocol have extensive documentation on their website. You may find their IDE and examples may get you going, and you can apply the concepts you have learned to a working version using ESPHome.
@zoogara asked for your efforts so far. A peek at your yaml code, suitable formatted </> for readability, may give us the opportunity to offer hints to steer you on the right path.
Further reading, including discussion and sample code to get you going, ESPNow support being released a year ago for ESPHome. Please note these refer to vendor notes and current ESPHome documentation, not outdated information found on the Internetz. I strongly recommend the vendor documentation as the best source - they know what their products do!
Thanks for the responses gents. I had reviewed the recommended string. I initially thought ESP-NOW might be an elegant way of effecting a simple communication protocol. Perhaps that was naive. Although several folks (on the internet) spout successful ESP-NOW projects, I have been unable to work through even the simplest rendition of this project. Attempting to read between the lines of your responses seems to indicate that ESP-NOW may not be sufficiently mature, to allow ‘novice’ usage. I plan to continue pursuit of this project, but will likely seek an alternate communication protocol.
I just got it working for my test case. I’m trying to get a battery powered ESP battery voltage sensor that uses deep sleep (the ESP-NOW Sender) to report to HA, from a location that’s causing it to regularly fail because of the distance. I have an existing ESP (the ESP-NOW Receiver) that’s powered by USB that sits between my WiFI AP and the battery sensor, so my plan is to use ESP-NOW to relay the sensor data from the sender to the receiver. Below is my YAML for both sender and receiver that only sends the uptime for testing. I still need to add code for the actual battery voltage and deep sleep, and solder everything up to confirm that it works better than WiFI.
Some important points:
- You can either hard code the MAC addresses of the peers in both Sender and Receiver, or use a broadcast MAC in the Sender and “auto_add_peer: true” in the Receiver.
- You must specify the WiFi channel in both Sender and Receiver, and that needs to be the same channel that the Receiver uses to connect to your router/AP using WiFI.
- The exact name of the Sender hostname must be specified as the provider name in both the packet_transport: and any Senders sensors in the Receivers YAML.
- You don’t need any api:, wifi: or ota: code in the sender since it’s not using any of those.
Sender YAML:
esphome:
name: esp-now-sender
friendly_name: ESP-Now Sender
name_add_mac_suffix: false
on_boot:
priority: -100
then:
- component.update: sender_uptime
esp32:
variant: esp32
framework:
type: esp-idf
debug:
update_interval: 5s
logger:
level: DEBUG
espnow:
channel: 1
peers:
# - "DC:B5:D9:10:51:C0" # The MAC Address of receiver
- "FF:FF:FF:FF:FF:FF" # The MAC Address of receiver
packet_transport:
- platform: espnow
# peer_address: "DC:B5:D9:10:51:C0"
peer_address: "FF:FF:FF:FF:FF:FF"
update_interval: 5s
sensors:
- id: sender_uptime # Transmits this Senders hardware reading to the Receiver
sensor:
- platform: uptime
name: Sender Uptime
id: sender_uptime
update_interval: 5s
Receiver YAML:
esphome:
name: esp-now-receive
friendly_name: ESP-Now Receive
name_add_mac_suffix: false
esp32:
variant: ESP32S3
framework:
type: esp-idf
debug:
update_interval: 5s
logger:
level: DEBUG
api:
encryption:
key: **************************************************
ota:
- platform: esphome
password: "*****************************************"
espnow:
# channel: 1 No need for this if you're sure the connection between receiver and router is fixed to the senders channel
auto_add_peer: true
# peers:
# - "AC:0B:EB:00:36:64" # REPLACE with your Sender's actual physical MAC Address
packet_transport:
- platform: espnow
update_interval: 5s
providers:
- name: esp-now-sender # Must match the esphome: name of your sender node
wifi:
ssid: !secret iot_wifi_ssid
password: !secret iot_wifi_password
power_save_mode: NONE
post_connect_roaming: true
fast_connect: false
reboot_timeout: 0s
use_address: 192.168.20.127
manual_ip:
static_ip: 192.168.20.127
gateway: 192.168.20.1
subnet: 255.255.255.0
sensor:
- platform: uptime
name: Receiver Uptime
update_interval: 5s
- platform: packet_transport
provider: esp-now-sender
remote_id: "sender_uptime"
name: "Sender Uptime"
internal: false
I use ESP‑NOW for projects where I just need fast communication between ESP devices. The big advantage for me is that it doesn’t rely on Wi‑Fi at all. Sleeping devices wake almost instantly, whereas Wi‑Fi requires reconnecting to the network, which can take a few seconds.
All my ESP‑NOW projects have been written in the Arduino IDE. When ESPHome added ESP‑NOW support I looked at it but never switched because the Arduino workflow was simpler for what I needed.
Why are you connecting the receiver to Wi‑Fi? That may be the root of your problem. Once a device joins Wi‑Fi, the AP can change channels, and ESP‑NOW will break because both devices must stay on the same fixed channel.
My receiver is connected to WiFi because it’s the relay that needs to report the senders sensor data to HA. In my case, the receiver is always on channel 1 because it’s outside and the only AP it can access is locked to channel 1.
I could see in the logs that setting the channel in both the sender and receiver caused the receiver to try to scan and switch channels as soon as the sender connected (it always ended up on channel 1 anyway). I have since removed the channel reference from the receiver since it’s always on channel 1 and everything is working as expected.