/unifi-clients

name: unifi-clients
description: >-
  Use when operating on UniFi clients, devices, switch ports, or DHCP: "block a
  device", "kick a client off wifi", "restart an access point", "power cycle a
  PoE port", "move a device to a different VLAN", "my device is on the wrong
  subnet after I changed the port", "set a DHCP reservation", "change DHCP DNS
  servers", "forget an old client", "why did my PUT reset all the other ports",
  or reading UniFi events and alarms. Covers full-object PUT discipline, the
  wired VLAN migration trap, and where events moved. Assumes unifi-connect. Not
  for firewall policy between zones (unifi-firewall), radios and SSIDs
  (unifi-wifi).
compatibility: >-
  UniFi Network with adopted devices. Verified on UniFi OS 5.1.19 / Network
  10.4.57. Port and DHCP object shapes are version-sensitive.

UniFi Clients and Devices

Day-to-day operations, and the two ways they go wrong: **partial writes that silently destroy config**, and **VLAN changes that appear to work and do not.**

Full-object PUT discipline

The rule that prevents most damage on this API:

> `rest/*` endpoints replace the object. GET it, modify the one field, PUT the > whole thing back.

A partial PUT does not merge. It writes what you sent and drops the rest. The consequences scale with the object:

• `rest/networkconf`: PUT `{"dhcpd_dns_1": "..."}` and you can lose the network's

DHCP range, domain name, and VLAN assignment.

• `rest/wlanconf`: you can lose the passphrase, the network binding, the band

settings.

• `rest/device` `port_overrides`: **PUT the complete `port_overrides` list.**

Sending one port's override resets every other port on the switch to defaults. On a 24-port switch carrying a segmented network, that is the whole afternoon.

# Correct shape, every time
udm raw GET /proxy/network/api/s/default/rest/networkconf/<NETWORK_ID> > /tmp/net.json
# edit /tmp/net.json, changing only what you mean to change
udm raw PUT /proxy/network/api/s/default/rest/networkconf/<NETWORK_ID> "$(cat /tmp/net.json)"

Then re-read and diff. The PUT response is not proof.

The wired VLAN migration trap

You change a switch port's native VLAN. The controller accepts it. The device behind that port is now **stranded**, and nothing tells you.

**Changing `native_networkconf_id` in `port_overrides` does not bounce the link.** The device never sees a carrier drop, so it never re-runs DHCP. It keeps its old-subnet lease, sits on a segment where that address has no gateway, and looks completely healthy until it needs to route somewhere. Then it fails in a way that looks like a firewall problem, which is where the afternoon goes.

Completing the move requires the device to issue a fresh DHCP **DISCOVER**, which means a real reboot. Lease expiry technically works and is useless: 24 hours.

**PoE devices: force it cleanly over the API.**

# Confirm the port actually draws power first
udm devices --json | python3 -c '
import json,sys
for d in json.load(sys.stdin):
    for p in d.get("port_table") or []:
        if float(p.get("poe_power") or 0) > 0:
            print(d.get("name"), p.get("port_idx"), p.get("poe_power"))'

udm devices power-cycle <SWITCH_MAC> <PORT_IDX>

`poe_power` is a **string** (`"0.00"`, `"6.42"`), not a number, so a truthiness test passes on an unpowered port. Cast it. The field is only present on switch (`usw`) port tables; APs and the gateway do not have it.

Full reboot, fresh DISCOVER, device lands on the new VLAN. Verify by reading its new address, not by assuming.

**Self-powered devices cannot be force-renewed remotely.** A link bounce makes them re-REQUEST their *old* lease (INIT-REBOOT), and when the new VLAN's DHCP server stays silent, they keep the stale address. There is no API path around this. The only reliable sequence:

1. Flip the port to the target VLAN 2. Physically power-cycle the device, unplug about ten seconds, replug

Zero-stranding variant, better if you are already standing there: unplug first, flip the port while it is off, replug. The device boots straight onto the new VLAN and is never stranded at all.

**`forward: 'disabled'` is a no-op for disabling a port.** Verified on UniFi OS 5.1.19 / Network 10.4.57: the controller accepts it, and the port stays UP. Do not build a "disable the port to force a renegotiation" plan on it.

**Cosmetic, not a failure:** after a non-default native assignment the controller normalizes `forward` from `'all'` to `'customize'` in the read-back. The port still passes native-VLAN traffic. Do not chase this.

**Plan the order.** If a batch contains both PoE and self-powered devices, do the PoE ones over the API and leave the self-powered ones for when you can physically reach them. Do not flip a self-powered device's port and walk away: leaving a security device, camera, or alarm component stranded offline is worse than not having started. Revert the port if the physical trip is not happening today.

Client operations

udm clients                       # currently connected
udm clients --all                 # including offline, the full known list
udm clients block <MAC>
udm clients unblock <MAC>
udm clients kick <MAC>            # force reassociation

`kick` is the gentle diagnostic: it makes a client re-associate, which re-runs band steering and AP selection. Useful when a device is stuck on a distant AP.

**Forgetting stale clients.** The known-client list accumulates forever. Old reservations for decommissioned hardware, VM interfaces, replaced phones:

udm raw POST /proxy/network/api/s/default/cmd/stamgr \
  '{"cmd":"forget-sta","macs":["<MAC>"]}'

Worth a periodic sweep. A reservation table full of dead entries is where a stale DHCP reservation quietly hands a live device the wrong address, and it makes the inventory in `unifi-context-map` much harder to keep honest.

**Reservations are not reality.** A fixed-IP reservation only applies if the device asks that DHC