UI calls /api/v1/pose/calibrate + /calibration/status + /pose/activities but sensing-server 404s them (v0.8.3-esp32)

[deependudhe]

Summary

The bundled UI calls several /api/v1/pose/* endpoints that the Rust sensing-server does not implement — they look like leftovers from the Python wifi-densepose stack. The practical effect is that there is no way to establish a baseline, leaving the signal-derived classifier uncalibrated.

Reproduce

POST /api/v1/pose/calibrate           -> 404
GET  /api/v1/pose/calibration/status  -> 404
GET  /api/v1/pose/activities          -> 404

GET  /api/v1/pose/current             -> 200
GET  /api/v1/pose/stats               -> 200
GET  /api/v1/pose/zones/summary       -> 200

The UI wires them up in ui/services/pose.service.js:

async calibrate() { return apiService.post(API_CONFIG.ENDPOINTS.POSE.CALIBRATE); }
async getCalibrationStatus() { return apiService.get(API_CONFIG.ENDPOINTS.POSE.CALIBRATION_STATUS); }

Why it matters — the CSI separates cleanly, the classifier discards it

Controlled test on a 3-node deployment. A single stationary subject was present in the area covered by node A only; the areas covered by nodes B and C were unoccupied and verified clear:

node	area state	RSSI	variance	classification
A	occupied (stationary subject)	−59	266	presence=true, conf=0.4
B	unoccupied	−50	132	presence=true, conf=0.4
C	unoccupied	−70	87	presence=true, conf=0.4

The link crossing the occupied area carried ~3× the variance of the unoccupied one, repeatably, for a stationary subject (the hard case — only respiration modulates the path). The CSI clearly separates occupied from unoccupied.

But every node returns presence=true at a hardcoded conf=0.4, discarding that separation. With Model: Signal-Derived (no model), 0 model files, and no calibrate endpoint, the heuristic has no per-node reference for "unoccupied", so any variance reads as presence. Sampled every 15 s for 2 minutes: all three nodes returned byte-identical classification on every sample, with confidence pinned at 0.49–0.51.

Ask

Either:

1. implement /api/v1/pose/calibrate — a per-node unoccupied baseline would make the signal-derived path usable without training a model; or
2. remove the dead endpoints from the UI so it doesn't advertise a capability the server lacks, and document that a trained .rvf is required for anything beyond aggregate presence.

A note on (1): a per-node calibrate would be considerably more useful than a global one. In continuously-occupied deployments a fully-vacant baseline window may never be available, but nodes covering unoccupied areas could still be baselined correctly while another node sees a subject.

Environment

• Image: ruvnet/wifi-densepose:v0.8.3-esp32, host networking, --source=esp32
• 3× ESP32-S3-DevKitC-1 N16R8, prebuilt v0.8.3-esp32 firmware
• All nodes on a single AP, RSSI −50 / −58 / −67 dBm

[ruvnet]

This is a known Python→Rust migration gap. The /api/v1/pose/calibrate, /calibration/status, and /pose/activities endpoints existed in the Python FastAPI sensing stack but were not carried over when the Rust sensing-server was introduced. The Rust server currently handles UDP CSI ingestion, WebSocket streaming, and inference output — the calibration subsystem has not been ported.

Until these endpoints are implemented in the Rust path, there is no way to establish a room baseline through sensing-server, leaving the signal classifier running in an uncalibrated state. This is a functional regression from the Python stack.

---

Generated by Claude Code

[ruvnet]

v0.8.4-esp32 removes the advertised 404s: /api/v1/pose/calibrate and /api/v1/pose/calibration/status now alias the Rust field-model calibration API, /api/v1/pose/activities returns an honest non-persisted empty collection, and the calibration feed deadlock/wide-frame mismatch are fixed. Per-node baseline calibration remains broader follow-up work, so this issue stays open for that acceptance criterion.

[deependudhe]

@ruvnet Thanks for the update!