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

Enhancements
1

Hi,

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.

Explanations

  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!

2

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:

3

Hi Tim,

I’m very interested in this project. Have you or anyone else made any headway? The wizmote is great, it’s just very limited as far as how many zones and presets one can have.

4

As mentioned in 0.15 you can put a remote.json file on the esp’s filesystem (see the IR remote doc for examples) with the button number as key, that way you can have 256 buttons.

5

So this is being done using wifi, not an IR remote?

6

It’s not exactly wifi, it uses the wifi channels but without being “a network” and doesn’t need an AP. Just sends the same as a wizmote does, simply with more button numbers.

7

Gotcha! I’m still running into the problem of finding an off the shelf remote that uses the UDP or TCP protocol to get this done. The BTF lighting remote seems like a great option, but I don’t think that will work in this scenario unfortunately.

8

Yeah unfortunately don’t know of any ready-made product like the wizmote but with more buttons… haven’t seen a teardown of the BTF thing.

But DIY is possible :slight_smile:

9

I would really love to be able to create state-machine-like user menus like this example. This allows to design user friendly interfaces, as you have a simple basic menu that any “digital immigrant” understands, and also the possibility to “go deeper” as you like.
Another UI feature I really miss, is the option to handle groups of lights easier. So witching between groups would be awesome.
cheers
KeLvin

ui (1)
ui (1)870×701 53 KB

10

Some of that is possible using OLED and rotary encoder.

11

you can do almost exactly that with my new ESPNow remote code: the rotary encoder part supports “levels” that pretty much do what you have drawn:
https://wled.discourse.group/t/diy-espnow-remote-wizmote/