Edit: Thanks to @eduperez getting me thinking in a great direction, later in this thread are ideas on how to minimize the delay between device activation and getting a "signal" to take action.
Not sure quite where this fits, but I'm looking for a battery-powered button that can connect to a nearby OpenWRT box and be used as a light switch "toggler" -- push the button, the lights turn on; push it again and they turn off.
I haven't had much luck with my Google or eBay searches, coming up with either $30-100 items, things to let you use two BT devices with a single phone, or the reverse of what I'm looking for -- a relay controlled by WiFi/BT.
I've thought about an ESP8266 (and am staring at a couple right now), but it would have to deep sleep to run off a battery and the wake-associate-send time is likely to be too long. Batteries are definitely preferred so I can just stick the thing on the wall and be done with it for a year or so.
Suggestions welcome!
(As well as BLE adapters that have driver support in OpenWRT)
Ah, the flip-flop action is the easy part. I just need a battery-operated device that communicates wirelessly to a receiver with a well-supported protocol stack (preferably on OpenWRT) that either has a momentary-contact push button already, or an accessible input pin.
I think that any WiFi device is going to have roughly the same wake-associate-send time as the ESP8266, unless you are willing to have it always powered on, and that is going to drain the batteries pretty fast. If you want to go that route, there is a simple circuit that you can build with a ESP8266 so the device only draws battery when a button is pushed; see https://www.hackster.io/iboboc/smartbutton-pro-06ce5d for an example.
May people has been using Amazon Dash buttons for this purpose (google for "amazon dash hack" for some pointers): the idea is that you configure it to join your network but not to buy any product, then run a script on the router to fire an action when the device contacts the DHCP server. Amazon also has a programmable version of the device, but it is far more expensive.
Solid idea, especially at the $2-5 price point! Knowing that I can get it associated with a "secure" WiFi AP without ordering a product makes it even more attractive. OK, so not so visually attractive, but I can accept what I'm guessing is a 2-5 second delay (some users report them being "slow") at that price point.
The "unbranded" Amazon IOT Button at $20 right now is interesting as one can build the "take action" code with AWS. However, I don't need the TLS set-up time and what I'm guessing it a four-packet MQTT transaction adding to the wake-up/associate time. The "look for the MAC address" trick still works. If I didn't already have fixed-IP hosting, I'd probably be ordering one of those instead of the Clorox Disinfecting Wipes buttons that were "on special" at $1.99 each today. For $18 I can paint over the logo!
(Yes, these will go on their own "non-routed" AP once configured)
As the coffee hits this morning, I'm glad @eduperez got me thinking. I'll look at it later, but I think that if you're willing to monitor at the WiFi media layer, you should be able to catch the probe request when the device starts to try to associate, and not even need to go any further than that.
Good news is that at least with the 2.4 GHz radio in my Archer C7, I can "see" the initial probe and save significant time triggering off that, rather than the DHCP lease.
In the setup I'm testing, there is an ESP8266 on my desk, an Archer C7 ~3 meters away, and DHCP is supplied by a wired server running kea. <CLIENT_MAC> is the colon-notation form of the ESP8266's MAC address. <SSID> is shown as a string in the tcpdump output.
The authentication appears to take around 1.5 seconds, so catching the packets at the media layer should improve responsiveness significantly.
Now to figure out How to configure a monitor interface with UCI...