I would like to build (ideally based on ESPHome) a device with a buzzer I can trigger remotely via the network.


I have several systems built around my home automation system:

  • Home Assistant to keep state and trigger action on devices
  • AppDaemon where I code my automations
  • two kind of "hardware triggers":
    • 433 MHz wall switches, which signals are picked up by a 433 Mhz to Wi-Fi bridge (and then to MQTT)
    • Zigbee switches managed though Zigbee2MQTT
  • various sensors
  • various services around a dashboard I wrote myself

I am listing all this to show that I have, so far, two major kind of operations:

  • getting data from sensors / Google calendar / Meteo services / various other APIs → and displaying their values
  • sending a message from a wall switch, ultimately resulting for a Wi-Fi enabled device (such as a Sonoff Basic) to do some action

What I am missing

I now would like to build an IoT device that would accept data from my Wi-Fi network and trigger a module attached to it. You can see this as some kind of poor man alarm clock - where all the logic of the alarm is offloaded to a service, and the device just receives the order to buzz.

What is the right approach to build such an IoT?

I have NodeMCU modules, or Wemo D1s. I could flash them with ESPHome, bringing in the WiFi communication and the ability to connect to GPIOs.

What I do not understand is how the Wi-Fi stack interacts with the GPIOs, exactly. Do I need to write a specific module to be added during the compilation? (it's been 20 years I did not code in C, last time was for my PhD - but this is something I could get into). Or is there a module that does the bridge already?

Generally speaking, what is the approach when I want to send a message to a ESPHome, Wi-Fi enabled device in order to access its GPIOs.

Please note that I know how to do it the other way round: I have added existing ESPHome modules to a Weemo D1 and they are correctly exposed in Home Assistant or the built-in web server. But this is a case where such modules already exist (for specific hardware) and just send data out.


If you are looking for something custom on the ESP8266 end, you a likely going to want to write a program to do what you want it to do. If you are already using MQTT, then you might consider using MicroPython on the NodeMCU. The toolchain is a bit simpler, and the development iterations are a lot quicker than flashing a C program.

  • Thank you - this is very good news as I both use MQTT and Python extensively. When you mention "The toolchain is a bit simpler" - what is the typical development pattern? Develop locally (on a PC) and test by flashing the NodeMCU (and see whether it works)? Or using an emulator? I read several articles about MicroPython and they focus on the language (which is good) but not really on the typical development process. – WoJ Sep 4 '20 at 6:33
  • It kind of depends on the IDE you use. Some are able to flash files directly to the ModeMCU module via USB right from the editor. If your code needs are simple, give Thonny a try, it's installable via PIP and has a nice file manager and REPL built in. Otherwise Pycharm with MicroPython plugin or VSCode with PlatformIO work too. I usually test right on the device with it connected to the IDE. – John S Sep 4 '20 at 8:28

It looks like there is a provision in ESPHome for that:

I would be very much interested in other (different / better / more typical) approaches to the problem

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.