Ansible Playbook Example: Reset WiFi on Branch Access Points

Branch offices generate a steady trickle of "the WiFi is down again" tickets, and most of them are fixed by a clean radio reset on the access points. At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed the AAP 2.7 Automation Portal's self-service template gallery, where a Branch - WiFi Reset template lets a non-technical operator click "Start" without knowing which playbook runs or how it's wired up. Here's a runnable playbook that models what that template kicks off.

Example playbook

---
- name: Branch - WiFi Reset
  hosts: branch_access_points
  gather_facts: false
  vars:
    reset_delay_seconds: 15
    reset_reason: "Scheduled remediation via Automation Portal"

  tasks:
    - name: Record pre-reset WiFi radio status
      ansible.builtin.command:
        cmd: "show wireless radio status"
      register: pre_reset_status
      changed_when: false

    - name: Disable WiFi radios on access point
      ansible.builtin.command:
        cmd: "wireless radio disable all"
      register: radio_disabled
      changed_when: radio_disabled.rc == 0

    - name: Wait before re-enabling radios
      ansible.builtin.pause:
        seconds: "{{ reset_delay_seconds }}"

    - name: Re-enable WiFi radios on access point
      ansible.builtin.command:
        cmd: "wireless radio enable all"
      register: radio_enabled
      changed_when: radio_enabled.rc == 0

    - name: Confirm WiFi radios are back up
      ansible.builtin.command:
        cmd: "show wireless radio status"
      register: post_reset_status
      changed_when: false
      failed_when: "'up' not in post_reset_status.stdout | lower"

    - name: Report reset outcome
      ansible.builtin.debug:
        msg: >
          WiFi reset completed on {{ inventory_hostname }}.
          Reason: {{ reset_reason }}.

What it does

The branch_access_points group targets every AP at a given site (defined in inventory, grouped per branch). The playbook captures radio status before touching anything, disables all WiFi radios, pauses for reset_delay_seconds so client sessions and DHCP leases fully drop, then re-enables the radios and checks that they came back up. The final debug task leaves a human-readable line in the job output — useful when the job was launched from the Automation Portal gallery rather than the CLI, since the person who clicked "Start" may never open a playbook file.

This is exactly the shape of job the Branch - WiFi Reset template is built to run: a short, self-contained, idempotent-in-spirit task that a branch manager or help desk agent can trigger without SSH access, without knowing the AP vendor's CLI syntax, and without waiting on a network engineer. The Automation Portal's job template layer supplies the survey (which branch, which AP group), the inventory mapping, and the credential — the playbook itself just needs to be reliable.

Notes / Gotchas

hosts: branch_access_points assumes your inventory groups APs by branch (e.g., branch_amsterdam_aps) and that the job template's inventory/limit narrows the run to one site — otherwise you risk resetting every branch's WiFi at once.
The command module examples above use generic vendor CLI syntax as placeholders; swap in the correct module for your AP platform (for example a vendor-specific collection, or ansible.netcommon for generic network transport) rather than shelling out in production.
failed_when on the post-reset check turns a silent failure into a visible job failure in AAP — don't skip it, since a WiFi reset that never comes back up is worse than the outage it was meant to fix.
Keep reset_delay_seconds short enough that the job template's timeout in the Automation Portal doesn't trip while it waits.
Run this against a lab AP or a single canary device before wiring it into the self-service gallery for an entire branch network.

A clean radio bounce, wrapped in a template an operator can click without touching a terminal, turns a recurring help desk ticket into a thirty-second self-service job.