Wire colour map

Two worlds that never meet. On the control side the colours are triggers and everything shares one ground. On the isolated fob side the same colour is that button's signal and one grey serves the shared common. Red and black are power only.

One channel, end to end

D23 high → IN1 → the coil pulls in → the contact closes COM-to-NO, bridging the Arm button's signal pad to the fob's common pad. That's exactly the short a continuity probe makes across those two points to press the button. The other three channels are identical, each with its own colour.

Where everything plugs in

Your hardware, annotated

The two ends of the isolated side, drawn onto your own photos. Positions are close, but always confirm against the silkscreen and a continuity check before you commit a joint.

The finished bridge

Built, wired, and driving the real alarm — the isolated relay quietly presses the fob on command.

The road here

Build order

How it's driven now — a hardwired serial link

The firmware became a pure serial build. logger: baud_rate: 0 frees UART0 — the same GPIO1/GPIO3 the USB port uses — and a 30 ms loop reads whole-line commands (ARM, DISARM, PART, PANIC, PING), presses the matching button and acknowledges each (OK ARM, PONG, or ERR). The hold times live here too: a 600 ms tap for arm and part-arm, a longer 2 s for disarm (the fob wants ~1.5 s), and a 3.5 s hold for panic.

esphome:
  name: alarm-remote-bridge
  on_boot:
    priority: -100
    then: [ lambda: 'id(cmd_uart).write_str("READY\n");' ]
esp32:
  board: esp32dev
  framework: { type: arduino }

# NO wifi / api / ota — the control path is the wired USB serial line to the Pi.
logger:
  baud_rate: 0            # free UART0 (GPIO1/3 = the USB port) for our own use

uart:
  id: cmd_uart
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 115200

globals:
  - { id: cmd_buf, type: std::string }

# relay outputs — LOW at boot, so a reset can never fire the alarm.
output:
  - { platform: gpio, id: out_arm,    pin: GPIO23 }
  - { platform: gpio, id: out_disarm, pin: GPIO22 }
  - { platform: gpio, id: out_part,   pin: GPIO21 }
  - { platform: gpio, id: out_panic,  pin: GPIO19 }

# each button carries an id so the serial loop can press it
button:
  - { platform: template, id: btn_arm,    name: Arm,      on_press: [ output.turn_on: out_arm,    delay: 600ms,  output.turn_off: out_arm ] }
  - { platform: template, id: btn_disarm, name: Disarm,   on_press: [ output.turn_on: out_disarm, delay: 2000ms, output.turn_off: out_disarm ] }
  - { platform: template, id: btn_part,   name: Part-arm, on_press: [ output.turn_on: out_part,   delay: 600ms,  output.turn_off: out_part ] }
  - { platform: template, id: btn_panic,  name: Panic,    on_press: [ output.turn_on: out_panic,  delay: 3500ms, output.turn_off: out_panic ] }

# read whole-line commands off USB serial and act on them, acking each one
interval:
  - interval: 30ms
    then:
      - lambda: |-
          while (id(cmd_uart).available()) {
            uint8_t c; id(cmd_uart).read_byte(&c);
            if (c == '\n' || c == '\r') {
              std::string cmd = id(cmd_buf); id(cmd_buf) = "";
              if      (cmd == "ARM")    { id(btn_arm).press();    id(cmd_uart).write_str("OK ARM\n"); }
              else if (cmd == "DISARM") { id(btn_disarm).press(); id(cmd_uart).write_str("OK DISARM\n"); }
              else if (cmd == "PART")   { id(btn_part).press();   id(cmd_uart).write_str("OK PART\n"); }
              else if (cmd == "PANIC")  { id(btn_panic).press();  id(cmd_uart).write_str("OK PANIC\n"); }
              else if (cmd == "PING")   { id(cmd_uart).write_str("PONG\n"); }
              else if (!cmd.empty())    { id(cmd_uart).write_str(("ERR " + cmd + "\n").c_str()); }
            } else if (id(cmd_buf).size() < 16) {
              id(cmd_buf) += (char) c;
            }
          }

The Pi side — a presser daemon, with a failsafe

One small Python service on the Pi (gg-esp-presser) is the only thing that holds the serial port. Home Assistant publishes arm / disarm / part / panic to an MQTT topic; the daemon writes the command down the wire, waits for the ESP's OK (three tries), and pings every 30 s so a binary_sensor shows the link live. Opening the port resets the ESP, so it's opened once and kept.

Flashing: because the control path is the serial port, there's no OTA — reflash over USB, and stop the gg-esp-presser service first (it holds the port). D23/D22/D21/D19 are still chosen deliberately: they sit low at boot, so the ESP can never ghost-press a button while it resets.

Sanity checklist before the first live press

Parts — pennies on top of a spare ESP32

The idea, in firmware

This ESP sits at the panel with Wi-Fi, so — unlike the serial bridge — it can run ordinary ESPHome and publish straight to Home Assistant. It doesn't decide on the first edge: it counts pulse widths, waits for the sound to stop, then classifies. Three tuned numbers, learnt once from the log.

substitutions:
  disarm_min_ms: "600"      # one solid tone this long → DISARM
  disarm_max_ms: "1500"
  pulse_min_ms:  "40"       # a "blip" is between these
  pulse_max_ms:  "300"
  arm_pulses:    "3"        # ≥3 blips in the window → ARM
  window_ms:     "1500"
  ignore_after:  "4500"     # still sounding? countdown / siren → ignore

# GPIO27 = opto collector (inverted, debounced)
#   rising edge  → start / continue a burst
#   falling edge → count a pulse if 40–300 ms wide
#   ~1.5 s after the last edge, decide:
#      one tone 600–1500 ms       → DISARM
#      ≥3 short pulses, then quiet → ARM
#      anything past 4.5 s          → ignore
# then a short cooldown so the alarm strobe can't retrigger it.

# exposes to Home Assistant:
#   binary_sensor.panel_confirmed_armed
#   binary_sensor.panel_confirmed_disarmed
#   text_sensor.last_tone_decision   (ARM / DISARM / ignored)

When it's built — the bench order