ESPHome is getting a new access point mode for the ESP32. With ap_mode: wisp, the board joins your router as an ordinary Wi-Fi client and at the same time runs its own access point, routing that network's clients to the router through NAT. Pull request #13633 describes it as "a small WiFi repeater for guest or IoT networks". It was merged into the development branch on 14 October 2026, with the documentation in the next branch of esphome.io, so it targets ESPHome 2026.11.

wifi:
  networks:
    - ssid: !secret wifi_ssid
      password: !secret wifi_password
  ap:
    ssid: Repeater
    password: !secret ap_password
    ap_mode: wisp
    dns_servers: [1.1.1.1]  # optional

No longer just a fallback hotspot

Until now the ap: block in ESPHome has been a fallback: the hotspot comes up when the device cannot join Wi-Fi, usually together with the captive portal, so you can enter new credentials. In WISP mode the access point stays up for its clients whatever the state of the upstream connection. That is why captive_portal is rejected in this mode. ap_timeout changes meaning as well: it becomes the wait before another attempt after a failed start, and it cannot be 0s.

DNS and requirements

Devices on the ESP32's network get their DNS servers through DHCP. You can set them with dns_servers; otherwise ESPHome passes on the ones the board received from the router and updates them when they change. Without dns_servers the access point does not start until the upstream connection has a DNS server, so no client is ever handed the ESP32's own address instead. If the upstream network uses manual_ip, dns1 has to be set. A second DNS server requires ESP-IDF 6.0.

WISP mode works only on the ESP32 with ESP-IDF 5.1 or newer. It needs at least one upstream network and a password on the access point, so an open repeater is not an option. Every client packet passes through the Wi-Fi driver, so the mode turns on the driver's high-performance settings (more buffers and frame aggregation). The lwIP TCP settings stay at their defaults, because none of the forwarded traffic uses the device's own sockets.

Where it fits

The obvious use is a separate network for a few devices that sit just outside the main router's range, or that you would rather keep away from the main network. As with any NAT, those devices get addresses from the ESP32's DHCP server rather than from the router, and nothing on the main network can open a connection to them directly. That matters for anything Home Assistant has to connect to, ESPHome nodes on the native API included.

The pull request gives no throughput figures and no limit on the number of clients. Until someone measures it, treat WISP mode as a way to bridge a handful of low-traffic devices, not as a replacement for a proper range extender.