ESPNow and connection to WiFi AP

If ESPNow is used to transfer data from several ESP32’s (Slaves) to another ESP32 (Master) that then forward the data over WiFi to a server (e.g. a MQTT broker) this configuration works only if the channel used for ESPNow is the same channel used for the WiFi connection. If ESPNow channel and WiFi AP channel are different, the ESPNow connection is not working. Example code for Slaves in ESPNow examples – Slave And here an example (adapted from ESPNow examples – Master) for an ESP32 master that receives data from slaves and forwards them to an MQTT broker:

Facebooktwitterredditpinterestlinkedintumblrmail

6 comments

  • Steven Bense

    I’m afraid I don’t see how the sample code solves the problem – it does not attempt to set the channel for the ESPNow to match that of the WiFi connection. Presumably this was the point of the work around. I have ecountered the exact same issue described and have been able to resolve it. Please could you amend the code or explain how you actually resolved the issue.

    Thank you

    Reply
    • beegee1962

      I never solved it. You had to connect to a WiFi AP that uses channel 1.
      There is a workaround somewhere in the ESP-IDF sources, but I never tested it. Specially, because I tried a mixed ESPnow network with ESP32 and ESP8266. And on ESP8266 there is no work around.

      I switched to painlessMesh which was easier to use, is not channel dependent and works on both ESP32 and ESP8266 the same way.

      Reply
  • amir

    so if i want to connect a esp32 to a esp8266 and send data from esp32 to esp8266. Simultaneously connect esp32 to WiFi to send data to a server i should use painless mesh?

    Reply
    • beegee1962

      That’s what I use now. It works fine with mixed ESP32 and ESP8266 devices in the Mesh.

      Reply
  • Enrique

    Hi
    I have resolved this problem in another way, I have define two modes: espnow mode or “wifi-client + mqtt” mode/code, when esp32 reboots, it reads a eeprom variable, this tells it what code must execute. So first it boots in espnow slave mode, then, when it receives a message, burns it in eeprom and change the state variable also in eeprom, and reboots.
    Then it wakes up and execute “wifi-client + mqtt” mode/code, reads info from eeprom and sends it. Resets eeprom state variable and reboots again.
    Cons: Lost of espnow RX during this period of time; only integer values due to eeprom
    Pros: Only a chip; it works!; it’s amazing to view the output from this gateway switching 🙂

    Reply
    • beegee1962

      Nice way to solve the channel problem. But, as you mentioned, packages will be lost.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Free Link Directory