esp32-csi-node + sensing-server: surface the associated AP BSSID (and optionally pin it) — mesh roams silently swap the sensing link geometry

[jkuscevic]

Summary

On multi-AP (mesh) WiFi, a CSI node's association can roam between APs at any time — and when it does, the sensing link geometry silently changes while nothing in the node's published telemetry reveals it. Request: surface the associated AP BSSID in node telemetry (and ideally allow pinning it at provisioning), plus a roam event on change.

Field report

• 5× esp32-csi-node (Atom S3 Lite) on a residential eero mesh (router + extender), one node per room, ruvnet/wifi-densepose:v2051 server.
• One node was confirmed (vendor app) associated to the far mesh router — a ~5.5 m diagonal link crossing two rooms, which defined what that node sensed.
• Two days later, with the node physically untouched, the vendor app showed it associated to the other AP (short through-wall link to an adjacent room): a completely different sensing geometry.
• The roam is invisible in everything the node publishes. Reported RSSI sat at −45..−52 dBm on both links (levels overlap at this position), so there is no way to detect the swap — or even to date it — from captures or Home Assistant. Only the vendor's app showed it.

Why this matters for CSI sensing specifically

The associated AP is the TX side of the sensing link: it determines the Fresnel volume and therefore which space the node actually senses. Any calibration tied to link geometry — empty-room baselines (ADR-135), per-room enrollment/specialists (ADR-151 / wifi-densepose-calibration) — is silently invalidated by a roam, with no signal that re-baselining is needed. Mesh WiFi is the default in exactly the homes this hardware targets, so this is the common case, not an edge case.

Asks (independent, in increasing order of effort)

1. BSSID in telemetry: include the associated BSSID (and primary channel) in the node's reporting alongside rssi, and surface it through the server (/ws/sensing node_features[] and an MQTT attribute/entity per node). Firmware side is cheap: esp_wifi_sta_get_ap_info() → wifi_ap_record_t.bssid/primary.
2. Roam event: have the server emit an event when a node's reported BSSID changes, so downstream consumers (baselines, calibration banks, HA automations) can trigger re-baseline.
3. Optional BSSID pinning at provisioning: a provisioning flag to lock the station to a chosen AP (wifi_config_t.sta.bssid + bssid_set = true) for installations that prefer a stable sensing link over roaming resilience.

Relation to existing work

This is distinct from the ADR-022 multi-BSSID scanning pipeline (#46): that scans other BSSIDs for sensing input; this is about knowing/controlling which AP the CSI capture link itself is riding on.

Related deployment context: #1540, #1541 (same 5-node mesh).

[jkuscevic]

Follow-up: controlled AP-change experiment — published RSSI is provably blind to the roam — plus field data on the pinning trade-off (ask 3).

1. RSSI cannot detect the geometry change (hardens the case for ask 1)

We now have a controlled version of the original field report. The same node ran two consecutive overnight captures on two different, certain associations:

• Night A: associated to the near AP (short through-wall link) — confirmed in the vendor app immediately after that capture.
• Night B: locked to the far mesh router (~5.5 m two-room diagonal) via a local implementation of ask 3 (NVS-provisioned sta.bssid pin, verified by NVS readback).

Published RSSI across the two nights, sleep-window median: −47.7 dBm vs −48.2 dBm — statistically indistinguishable, while the sensing link geometry differed completely. So on this (typical) floor plan, roam detection from existing telemetry isn't just hard, it's impossible in principle: the BSSID itself is the only observable. Firmware-side this is one struct read away (esp_wifi_sta_get_ap_info()).

2. Pinning trade-off data (caveat for ask 3)

Pinning worked as a test instrument, but one of the five nodes — pinned to the far AP from the farthest room — runs with a chronically marginal downlink: ICMP RTT 1.3–2.1 s (vs 10–25 ms for the rest of the fleet, 0 % loss — consistent with AP-side power-save buffering), HTTP to the node works but is slow. Meanwhile its uplink CSI streaming is completely unaffected (steady 2 Hz, zero gaps overnight). A roaming station would presumably have re-associated to the healthier AP. So: pinning is valuable for reproducible experiments and calibration sessions, but asks 1+2 (BSSID telemetry + roam events, letting downstream re-baseline on change) look like the right default for real deployments — pinning shouldn't be the recommended steady-state.

3. Related association-robustness field note

After a reboot of the mesh APs (a normal customer event), all five pinned nodes kept streaming CSI uplink normally but became completely deaf on the downlink — unicast ARP/ping requests reached the AP and were never answered — until each node was individually power-cycled. Stale association state that the station never detects, since its TX path keeps working. If ask 3 is implemented upstream, it probably wants a companion no-RX watchdog in esp32-csi-node (no downlink traffic for N minutes → re-associate autonomously); the same watchdog would also self-heal the marginal-downlink situation in point 2.

[ruvnet]

Good catch, and this is a real gap — the associated AP is the actual sensing link geometry, and right now nothing captures that a roam happened, silently or otherwise.

I haven't implemented this one — the firmware side (esp_wifi_sta_get_ap_info() → wifi_ap_record_t.bssid/primary) touches esp32-csi-node's C firmware, which needs a build-and-flash validation cycle I didn't run in this pass alongside the several other fixes here, and BSSID pinning at provisioning is a larger, deliberate API surface change I'd rather not push through quickly. Given your three asks are independently valuable (telemetry → roam event → optional pinning), I'd suggest tackling #1 (surface BSSID in NodeInfo/MQTT) first since it's the cheapest and unlocks the other two being built as pure server-side/downstream logic later. Leaving this open for that follow-up rather than partially closing it.

[jkuscevic]

Ask 1 implemented and hardware-validated in #1593 (asks 2–3 left for downstream layering per your sequencing). Validating it on real nodes also uncovered why our fleet's OTA had never actually succeeded — fix in #1594.