mikkeli
b85a53e779
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
1.2 KiB
1.2 KiB
type
| type |
|---|
| default |
Initial plan
The scope question, first
This started as "aggregator and pusher to the tablet over USB". The pushing part may not need to exist: over USB the tablet has an IP link via RNDIS, and the architecture already says Class B devices reaching the bus over IP connect to the broker directly. A Flutter MQTT client can talk to mosquitto with no hop in between.
What does not go away:
| Job | Why it needs a gateway |
|---|---|
| Aggregation | Raw CAN at 500 kbps must never reach a display; something has to downsample |
| Nav HTTP proxy | Route requests are request/response and fit MQTT badly |
| Static assets | Serving the PMTiles basemap to the display |
| Non-IP transports | BT SPP and plain serial for ESP32 clients have no broker access |
So: build the aggregation and the HTTP surface. Do not build a telemetry relay for clients that can already subscribe for themselves.
Order
- Static file serving for the basemap — smallest useful thing, unblocks the map.
- Nav HTTP proxy to svc-nav.
- Aggregation and rate limiting, once there is real CAN traffic to aggregate.
- Serial bridge, when an ESP32 client exists.