Generic ESP32/ESPNow remote - new protocol - any comments?


I suspect this is super niche, but I thought I’d throw it up here in case there are any opinions I could take on board…

I’m a huge fan of ESP32s and I’ve just got both WLED to build on my dev system (and work!), and I’ve also managed to program an ESP32 (Firebeetle dev board) to send ESPNow packets that WLED understands and acts upon (Wizmote protocol).

I have an application for room lighting (addressable LED tape) where WLED fits really well, but I need a remote that has way more options than the Wizmote.

So I thought I’d roll my own. As part of this, I envisage adding a new ESPNow protocol to WLED (letting it auto detect the Wizmote one or the new one).

espremote-ng would have the following features:

  1. Bilateral pairing
  2. Remove the cruft that the Wizmote protocol has (8 bytes, 4 bytes unknown-method checksum, 3 unknown bytes, “program” byte which is just another command)
  3. Add a more generic and extensible protocol with option for lots of controls.


  1. Bilateral pairing: If the ESPNow remote is able to target a specific MAC address of the WLED device, then it benefits from being able to receive an ACK packet and thus know that delievery was successful. This means that after the remote is paired, it can solve the “AP moves the wifi channel” problem like this:

If delivery is successful, then go back to sleep until next button pushed.

If delivery is unsucessful, cycle through all the 2.4GHz channels once until it succeeds, then note that in non volatile storage.

Pairing would work like this:

  • Remote will send to the broadcast address with a pairing packet (a non command packet that specifically requests pairing).

  • WLED will as usual, display the Remote’s MAC in the Last Seen web form in the WIFI config section.

  • When paired at the WLED end, the remote can be put into pairing mode again (or remain in it). This time, WLED will respond with a Pairing Accepted packet directed back to the remote. This enables to Remote to obtain the WLED Mac address and store that in its own non volatile config - and thus it can now benefit from delivery confirmations and deal with WLED moving wifi channels.

What I don’t want is an obtuse and fiddly operation to tell the Remote what WLED’s MAC address is which would need a display and much button pushing, or (worse) need it to be plugged into a USB serial terminal and configured through a text screen.

  1. I had considered overloading the Wizmote protocol to allow more button commands (there’s a whole byte for this, so 256 is possible). But given half the protocol is unknown and appears unused in this application, PLUS we have the pairing protocol above, we might as well just make a new clean protocol that is easily distinguished from Wizmote, allowing WLED to use either with zero config.

  2. Covered above.

Well, there’s either going to be zero interest in this (a forum search suggests ESPNow is pretty niche), or people are going to be horrified and shout at me a lot.
In which case, no problem, I’ll run a personal fork for my application.

But on the off chance that this post sparks some interest, I’m open to thoughts, comments etc…

All the best!

0.15 add a possibility to remap buttons and accepts any number of buttons using JSON configuration file.
Pairing remote to a particular ESP is useless IMO. There is no need for remote to know “state” of delivery, you press the button until device reacts. :wink: