Evolution Of The ESP8266 Party Button

Sometimes the best part of building something is getting to rebuild it again a little farther down the line. Don’t tell anyone, but sometimes when we start a project we don’t even know where the end is going to be. It’s a starting point, not an end destination. Who wants to do something once when you could do it twice? Maybe even three times for good measure?

Original version of the Party Button

That’s what happened when [Ryan] decided to build a wireless “party button” for his kids. Tied into his Home Assistant automation system, a smack of the button plays music throughout the house and starts changing the colors on his Philips Hue lights. His initial version worked well enough, but in the video after the break, he walks through the evolution of this one-off gadget into a general purpose IoT interface he can use for other projects.

The general idea is pretty simple, the big physical button on the top of the device resets the internal ESP8266, which is programmed to connect to his home WiFi and send a signal to his MQTT server. In the earlier versions of the button there was quite a bit of support electronics to handle converting the momentary action of the button to a “hard” power control for the ESP8266. But as the design progressed, [Ryan] realized he could put the ESP8266 to deep sleep after it sends the signal, and just use the switch to trigger a reset on the chip.

Additional improvements in the newer version of the button include switching from alkaline AA batteries to a rechargeable lithium-ion pack, and even switching over to a bare ESP8266 rather than the NodeMCU development board he was using for the first iteration.

For another take on MQTT home automation with the ESP8266, check out this automatic garage door control system. If the idea of triggering a party at the push of a button has your imagination going, we’ve seen some elaborate versions of that idea as well.

13 thoughts on “Evolution Of The ESP8266 Party Button

    1. I’ve thought about doing just that and couldn’t think of a way to make it work fairly..

      Anyone have a good way to guarantee which button was pushed first? When you’re sending an MQTT signal through your wifi, one push could take 5ms and the next 3 seconds.

      1. Rather than depending on when the messages are received you could send the time with each message.
        The time doesn’t have to be exact with the real time. Just a system time.
        It might also need to be synced by wire at startup.
        This would need a RTC for each controller but would solve the problem.

        1. More on that, you could avoid the needing to be synced every time by making sure the RTCs don’t lose power. And the only time the controllers request a sync is after the RTC loses power(or a certain amount of time has passed).

          However to be safe syncing the controllers each time assures the controller times are accurate

          1. Do you know if an RTC that has a resolution better than 1 second? Imagine a game of jeopardy where player 1 pushes the button 0.9 seconds before player 2 yet player 2 wins the race. And it still wouldn’t help. Even a precision RTC like the DS3231 drifts 0.1 seconds/day. Since the worst case is 2 buttons drift opposite directions, that’s a 0.2 second/day error growing.

            NTP also doesn’t work for the exact same reason I can’t rely on the message arrival time; you don’t know how long it takes to receive the time stamp and network time can easily be out a couple of seconds.

        2. I considered syncing system time, a phototransistor on each slave and a 3-watt LED “flash” would be even easier than a wire but feels like a clunky solution. You actually wouldn’t need an RTC. Just pass the number of milliseconds since the flash with the button press message.

    1. Neat solution. A purely mechanical alternative to the relay would be a button that after pressed in has some friction so only slowly flips back up again, taking just enough time for the ESP8266 to get on the wifi and be detected.

  1. First version seems way over-engineered, and second version only marginally better. With respect to the creator of this project, really seems like they are just getting their feet wet in this kind of thing and coming up with “novel” solutions that really don’t make a whole lot of sense.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.