One ESP32 Triggering Another in ESPHome: Three Ways, and the Fix That Matters

One ESP32 Triggering Another in ESPHome: Three Ways, and the Fix That Matters. AutoMatter

A recent Home Assistant Community thread asks a question we hear from DIY-minded owners: how do you make one ESP32 trigger another? The poster has one ESPHome device that opens and closes garage doors, and is building a second one with buttons to operate it. The button press registers, but the action never fires. The answers are worth knowing before you build anything similar.

What went wrong

The poster’s automation fired on the button press, but the action was button.toggle. A reply pointed out that this is not a valid action for a button entity. The right one is button.press. The same reply suggested that the dashboard card, which also used a toggle tap action, would be better off using a perform-action with button.press.

Reading the posted snippets, there is a second thing to check. The ESPHome code on the remote calls light.toggle on a light entity, the automation triggers on a binary sensor, and the button it targets has a different entity name from the one the dashboard uses. When you chain entities across devices, a single mismatched name looks exactly like a broken action. Confirm each entity ID in Developer Tools before blaming the logic.

Way one: through Home Assistant

The thread’s starting point is the standard route. The remote device reports a button event to Home Assistant, and an automation presses the button entity on the door controller. It is easy to debug and shows up in your logs. The trade-off is that the remote does nothing if Home Assistant is down or restarting.

Way two: a shared entity, no automation

One reply describes a pattern where ESPHome devices mirror each other’s state, so turning on one light turns on the other, in both directions, with any number of lights. The author keeps the key parts in a reusable package shared across configs. It still goes through a Home Assistant entity in the background, so as they put it, it is not completely Home Assistant free. It does skip writing an automation for each pair.

Way three: ESP-NOW, device to device

Another reply uses ESP-NOW, which lets two ESPHome devices talk directly. That means the link keeps working even if Home Assistant is unavailable. In the posted example, each device lists its peers by MAC address and sends a short text message, such as one for on and one for off. The receiving device switches its relay accordingly. A small flag stops the receiver from echoing the change back and creating a loop. The poster uses it to keep lighting in sync from several switches, where only one has to drive a relay.

What this means for your system

  • Start with the entity type. Buttons are pressed, lights and switches are toggled. Use the action that matches the entity.
  • Decide how much you want Home Assistant in the path. For convenience controls, going through Home Assistant is fine. For anything you expect to work during a restart, direct device to device is the more robust idea, though it is more configuration to maintain.
  • Be careful with garage doors. The thread is about a hobby build, and it does not cover safety. Anything that moves a door remotely deserves proper safety features and a test with nothing in the way. We have not built any of these setups ourselves.
  • Remember ESPHome is build-your-own. You own the configuration, the updates and the hardware quality. That is the price of fully local control.

The thread was still young when we read it, and the original poster had not yet confirmed which fix worked. Treat the ESP-NOW example as one owner’s working setup rather than a tested recipe for your hardware, and try it on a bench device first.

Sources