# EggBot WiFi Serial Protocol

## Scope
This transport exposes the same EggBot command protocol as serial, but over WiFi/WebSocket.

- Protocol commands and responses are unchanged.
- Framing is unchanged (`\r` command terminator, `\r\n` response lines).

## Transport Profile
- Protocol endpoint: `ws://<eggs-esp32-ip>:1337/`
- WebSocket message type: text or binary frames accepted
- Payload: ASCII command bytes

## Data Model
- Host writes command bytes to the WebSocket.
- Firmware parses incoming bytes with the same EggBot parser used for USB serial and BLE.
- Firmware sends responses as WebSocket text messages.
- Hosts must treat inbound data as a stream and parse lines by `\r\n`.

## Compatibility Rules
- A WiFi client must send commands exactly as serial hosts do.
- Each command must end with `\r`.
- Data-returning commands (`QP`, `QB`, `QN`, `QL`) return a value line before final status (`OK\r\n`).
- Unknown/invalid command format returns `unknown CMD\r\n`.

## Example WiFi Transactions
Version query:
- Send: `v\r`
- Receive: `EBBv13_and_above Protocol emulated by Eggduino-Firmware V1.6a\r\n`

Move command:
- Send: `SM,100,0,200\r`
- Receive: `OK\r\n`

Query layer:
- Send: `QL\r`
- Receive: `<layer>\r\n`
- Receive: `OK\r\n`

## Operational Notes
- The WiFi protocol endpoint is started only when ESP32 station WiFi is connected.
- Incoming WiFi bytes are queued and parsed in the main loop.
- If the WiFi RX queue overruns, excess bytes are dropped and a log entry is generated.
- WiFi transport is single active client: first connected sender is accepted until disconnect.
- USB serial, BLE, and WiFi can coexist; responses are routed to the transport that received each command.