Crate csi_webclient 

csi-webclient

Native Rust desktop client for controlling csi-webserver through REST and WebSocket APIs.

This crate ships the full application and exposes modules that keep UI code, state, and side effects separate so behavior stays maintainable as protocol features evolve.

Module Layout

• app: top-level orchestration that translates UserIntent values into core commands and applies core events back into app state.
• state: source-of-truth state models, user intents, and API-facing enum mappings.
• core: side-effect layer for HTTP requests, WebSocket receive loop, and worker runtime.
• export: host-side serialized CSI decoder and Parquet writer for local recordings.
• ui: rendering modules for each tab (devices/dashboard/config/control/stream) without direct IO.

Runtime Flow

1. UI interactions enqueue intents in state::AppState.
2. app::CsiClientApp drains intents and submits core::messages::CoreCommand values.
3. core executes HTTP/WebSocket side effects on a worker thread and Tokio runtime.
4. core emits core::messages::CoreEvent values over channels.
5. app::CsiClientApp polls and applies events to state on each frame.

This design avoids blocking work in the egui frame callback and keeps network concerns out of view code.

API Coverage

The client targets csi-webserver v0.1.5+ (multi-device API + esp-csi-cli v0.7.0 Wi-Fi modes):

• GET /api/devices
• GET /api/devices/{id}/info
• GET /api/devices/{id}/config
• GET /api/devices/{id}/control/status
• POST /api/devices/{id}/config/reset
• POST /api/devices/{id}/config/wifi
• POST /api/devices/{id}/config/traffic
• POST /api/devices/{id}/config/csi
• POST /api/devices/{id}/config/collection-mode
• POST /api/devices/{id}/config/output-mode
• POST /api/devices/{id}/config/protocol
• POST /api/devices/{id}/config/rate
• POST /api/devices/{id}/config/io-tasks
• POST /api/devices/{id}/config/csi-delivery
• POST /api/devices/{id}/control/start
• POST /api/devices/{id}/control/stop
• POST /api/devices/{id}/control/reset
• POST /api/devices/{id}/control/stats
• GET /api/devices/{id}/ws

For detailed request/response behavior and payload fields, see:

• https://github.com/csi-rs/csi-webclient-rs/blob/main/docs/HTTP_API.md

Protocol Values Used By The Client

• Wi-Fi modes: station, sniffer, wifi-ap, esp-now-central, esp-now-peripheral, esp-now-fast-collector, esp-now-fast-source (latter three require firmware ≥ 0.7.0)
• Collection modes: collector, listener
• Output modes: stream, dump, both
• CSI delivery modes: off, callback, async, raw
• Wi-Fi PHY protocols: b, g, n, lr, a, ac (a ClientProfile may add more)
• Two-device pairing presets: SoftAP lab, ESP-NOW fast simplex, ESP-NOW balanced
• PHY rates: 1m, 1m-l, 2m, 5m5, 5m5-l, 11m, 11m-l, 6m, 9m, 12m, 18m, 24m, 36m, 48m, 54m, mcs0-lgi..mcs7-lgi, mcs0-sgi

The server always delivers CSI in serialized (COBS+postcard) mode; there is no log-mode configuration.

Validation

Free-form strings sent to POST /api/devices/{id}/config/wifi (sta_ssid, sta_password, ap_ssid, ap_password) are validated client-side to match the firmware tokenizer rules: max 32 bytes, no newlines, and not both ' and " in the same value. Mode-specific fields are omitted from the JSON body when they do not apply (STA fields in station mode only, AP fields in wifi-ap only, peer MAC / HT40 in ESP-NOW modes only).

Notes

• HTTP success is treated as status code in the 2xx range.
• Status codes 404 / 412 / 503 / 502 / 504 / 403 are mapped to operator-friendly hints that explain whether the device is gone, the firmware gate is closed, the ESP32 is disconnected, or the WebSocket is blocked by the active output mode.
• API responses are parsed best-effort from either a generic envelope (success/message/data) or direct JSON payload.
• WebSocket text and binary messages are both stored as frame bytes for stream inspection.
• Local Parquet recordings use the same schema as server-side csi_dump_*.parquet files.

Modules

app

core

export

Local CSI stream export.

profile

Injectable client-behavior seam.

state

ui

UI rendering modules.