add WiFi AP hotspot + WebSocket CAN downlink for Pecan dashboard#1
add WiFi AP hotspot + WebSocket CAN downlink for Pecan dashboard#1haoruizhou wants to merge 2 commits intomasterfrom
Conversation
- New telemetry component: WiFi AP (SSID "wfr-mobo", open), WebSocket
server on port 80 at /ws
- Broadcasts all CAN RX frames as JSON arrays in legacy v1 format:
[{"time":ms, "canId":id, "data":[b0..b7]}]
- Batches frames every 100ms, drops if queue full (no backpressure)
- Enable CONFIG_HTTPD_WS_SUPPORT in sdkconfig.main and sdkconfig.debug
https://claude.ai/code/session_0117iHbd3hAwUoxxeRuyWCAF
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 54c639d381
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ESP_LOGI(TAG, "Recieved frame!"); | ||
| union CANBuffer_u rx_data; | ||
| memcpy(rx_data.array, rx_frame.buffer, 8); | ||
| telemetryQueueFrame(rx_frame.header.id, rx_data.array, 8); |
There was a problem hiding this comment.
telemetryQueueFrame is always called with a hard-coded length of 8, so any CAN frame with DLC < 8 will be serialized with extra trailing bytes that are not part of that frame. This corrupts the WebSocket downlink data for variable-length CAN traffic and can break consumers that rely on accurate payload length; pass the frame’s actual received length instead.
Useful? React with 👍 / 👎.
| ESP_LOGW(TAG, "WS client rejected, max reached"); | ||
| } | ||
| xSemaphoreGive(clientMutex); | ||
| return ESP_OK; |
There was a problem hiding this comment.
When ws_count has reached MAX_WS_CLIENTS, the handler logs a rejection but still returns ESP_OK, which allows the WebSocket upgrade to succeed for a client that is never added to ws_fds. In that state the client appears connected but never receives telemetry, and stale tracked clients can effectively block new usable sessions; return an error/close the socket when capacity is exceeded.
Useful? React with 👍 / 👎.
2 participants
server on port 80 at /ws
[{"time":ms, "canId":id, "data":[b0..b7]}]
https://claude.ai/code/session_0117iHbd3hAwUoxxeRuyWCAF