Skip to main content

Crate csi_webclient

Crate csi_webclient 

Source
Expand description

§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.
  • ui: rendering modules for each tab (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 every documented csi-webserver route:

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

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

§Protocol Values Used By The Client

  • Wi-Fi modes: station, sniffer, esp-now-central, esp-now-peripheral
  • Collection modes: collector, listener
  • Log modes: text, array-list, serialized, esp-csi-tool
  • Output modes: stream, dump, both
  • CSI delivery modes: off, callback, async
  • 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

§Validation

Free-form strings sent to POST /api/config/wifi (sta_ssid, sta_password) are validated client-side to match the firmware tokenizer rules: max 32 bytes, no newlines, and not both ' and " in the same value.

§Notes

  • HTTP success is treated as status code in the 2xx range.
  • Status codes 412 / 503 / 502 / 504 / 403 are mapped to operator-friendly hints that explain whether 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.

Modules§

app
core
state
ui
UI rendering modules.