Live UI connects, packets flow, but pose does not move correctly with 6 ESP32-S3 nodes on Windows

[Kracozebr]

Live UI connects, packets flow, but pose does not move correctly with 6 ESP32-S3 nodes on Windows

This issue describes a reproducible live-demo failure on April 13, 2026 using RuView v0.7.0 on Windows with 6 ESP32-S3 boards.

The setup reaches the point where:

• all 6 nodes are flashed and provisioned
• packets are transmitted over WiFi
• the local sensing server starts
• the UI loads successfully
• WebSocket clients connect

But the live pose in the UI still does not move correctly i.e it do not move at all.

Version and date

• RuView version: v0.7.0
• Reproduced on: April 12, 2026

Host setup

• OS: Windows
• Host IP: 192.168.1.132

Hardware setup

6 x ESP32-S3 boards connected over USB and provisioned as:

• node 0 -> COM11
• node 1 -> COM15
• node 2 -> COM14
• node 3 -> COM16
• node 4 -> COM17
• node 5 -> COM18

All boards were detected by esptool as ESP32-S3 with 16MB flash.

WiFi / target config

• target host IP: 192.168.1.132
• original device UDP target: 5005

Important firmware bug reproduced first

Before UI testing, I reproduced the known packet identity bug:

• NVS provisioning uses unique node-id values
• all 6 physical boards transmit from distinct IP addresses
• but every raw UDP packet arrives with node_id = 1

That matches the known symptom where NVS reads correctly but the packet header still uses node 1.

Host-side workaround used

To get around the packet identity bug, I used a host-side relay that:

• listens on 5005
• rewrites packet byte 4 (node_id) based on source IP
• forwards patched packets to 127.0.0.1:5007

Recovered mapping:

• 192.168.1.61 -> node 0
• 192.168.1.101 -> node 1
• 192.168.1.77 -> node 2
• 192.168.1.37 -> node 3
• 192.168.1.142 -> node 4
• 192.168.1.49 -> node 5

This workaround is confirmed to work at the transport layer:

• patched capture on 5007 shows node IDs 0..5
• /api/v1/sensing/latest shows six distinct node entries

Reproduction steps

1. Flash all 6 ESP32-S3 boards with the release binaries.
2. Provision each board with unique node-id, tdm-slot, and tdm-total=6.
3. Start the relay workaround:

cd C:\Projects\RuView_scripts
.\start_live_demo.ps1

This starts:

• relay 5005 -> 5007
• sensing server on HTTP 3000, WS 3001, UDP 5007

4. Open the UI:

• http://localhost:3000/ui/index.html
• or http://localhost:3000/ui/pose-fusion.html

5. In pose-fusion.html, switch to:

• CSI Only (WiFi)

and connect to:

• ws://localhost:3000/ws/sensing

Observed behavior

• UI page loads
• sensing and pose WebSocket clients connect
• REST endpoints respond
• server logs show active WebSocket clients
• transport is live and multi-node IDs are restored by relay

But the live pose still does not move at all.

Symptoms:

• pose appears static or barely updates
• movement does not correspond well to real motion in front of the nodes
• the UI looks connected, but the visual result is not usable as live pose estimation

Server log excerpt

Example:

INFO sensing_server: UDP listening on 0.0.0.0:5007 for ESP32 CSI frames
INFO sensing_server: HTTP server listening on 127.0.0.1:3000
INFO sensing_server: WebSocket client connected (sensing)
INFO sensing_server: WebSocket client connected (pose)

Why this is notable

This repro is past the obvious transport failures:

• not a flash failure
• not a WiFi join failure
• not a missing UI path
• not a raw node_id collision anymore, because relay restores 0..5

The remaining bug appears to be in the live pose/UI pipeline itself, or in how the sensing output is turned into live pose updates.

Logs available

I have logs for:

• probe
• flash
• provision
• serial capture
• raw UDP capture showing all packets as node_id=1
• relay logs showing patched node IDs 0..5
• patched UDP capture on 5007
• sensing server stdout
• /api/v1/sensing/latest
• /api/v1/pose/current

Relevant run directories:

• logs/20260412-221618-probe
• logs/20260412-221642-flash
• logs/20260412-221741-provision
• logs/20260412-221757-serial-capture
• logs/20260412-221905-udp-capture
• logs/20260412-231229-udp-relay
• logs/20260412-231229-udp-capture
• logs/20260412-231321-relay-server-check

Question

Given that:

• the UI connects,
• the server has live data,
• and the relay restores distinct node IDs,

what is the expected supported path for live pose visualization in v0.7.0 for a real multi-node ESP32-S3 deployment on Windows?

Is the intended live UI currently:

• index.html Live Demo,
• pose-fusion.html in CSI-only mode,
• or only the REST output at /api/v1/pose/current with no fully supported real-time visual UI yet?

[jiayi-yiyi]

您好，请问你会出现如下情况吗：”对于“实时人体姿态检测”，它总是显示两个人，实际上只有一个人在那里。对于“感知”，分类总是切换到“PRESENT_MOVING”、“PRESENT_STILL”、“缺席”。“，我现在用的是v0.5.0会出现这种情况，想知道v0.7.0改善了这种情况了没有

[Kracozebr]

您好，请问你会出现如下情况吗：”对于“实时人体姿态检测”，它总是显示两个人，实际上只有一个人在那里。对于“感知”，分类总是切换到“PRESENT_MOVING”、“PRESENT_STILL”、“缺席”。“，我现在用的是v0.5.0会出现这种情况，想知道v0.7.0改善了这种情况了没有

No improvements only i person and it's do not moving in perception the same present/absent

[ruvnet]

Your transport-layer workaround is solid — restoring node IDs 0–5 at the relay and confirming distinct entries in /api/v1/sensing/latest rules out the packet identity bug as the remaining cause.

The next thing to check is whether the pose keypoints themselves are changing. Run:

# Poll pose output every 2 seconds while moving in front of the nodes
for i in $(seq 1 10); do curl -s http://localhost:3000/api/v1/pose/current | python -m json.tool | grep -E '"x"|"y"|"confidence"'; sleep 2; done

If the keypoint coordinates are static or near-zero across all polls, the issue is upstream of the UI — the CSI-to-pose pipeline isn't producing movement from the multi-node data. If the coordinates do change but the UI doesn't reflect it, the issue is in the WebSocket→canvas rendering path.

A few things to check in pose-fusion.html CSI-only mode:

• The WebSocket at ws://localhost:3000/ws/sensing should be receiving frames — open the browser console (F12 → Console) and look for incoming message logs or errors.
• The sensing server must be started with --source esp32 (not auto) to ensure it doesn't fall back to simulation mode. Verify: curl http://localhost:3000/health should show "source":"esp32".

The known issues guide at #301 covers the multi-node setup expectations. Note that without a trained adaptive model, the 3D skeleton is driven by signal heuristics — it will show presence/motion but not accurate skeletal tracking. Full pose reconstruction requires recording labeled data and running /api/v1/adaptive/train.

---

Generated by Claude Code