Vescape Sensors: BLE link to the ESP32 sensor module - #441
Draft
KacperKozak wants to merge 10 commits into
Draft
Conversation
This was referenced Sep 13, 2026
Draft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a Sensors screen that connects to a Vescape sensor module (ESP32-S3 running the
vescape-hardwarefirmware) over Nordic UART, and shows what it reports live — distance readings as numbers, bars and scrolling charts, plus a console for talking to it directly. Android only for now.Note
Risk: Low — a new settings screen and a self-contained native link; nothing existing reads from it.
Complexity: Medium — a high-rate native stream with its own buffering, decimation and BLE lifecycle.
DB: None — nothing is persisted; the history lives for as long as the link does.
Description
The module pushes a flat JSON frame per sensor read, at a rate the app can retune from the screen (1–30 Hz, the firmware clamps what it cannot hold). At the top of that range one JS callback per notification is enough to starve the JS thread on its own, so the pipeline is native-owned in the same shape as live telemetry:
SensorLogparses, scales, clamps, keeps a 20-second window and decimates it, and publishes two events — live values ~10×/s that JS writes straight into shared values, and ready-made chart series 4×/s. JS holds no sensor logic; it adds labels, units and colors and renders. Nothing re-renders at the link's rate, so 30 Hz costs the same as 5 Hz on screen.The readings a board can take are declared rather than discovered. A ranged sensor that reads nothing is reporting "further than its reach", not absence, so its row exists from the first frame, sits at its ceiling, and never moves when the sensor drops out and comes back — which the ultrasonic does constantly.
Scan and connect are automatic for the one
Vescape-HWmodule; pressing Disconnect turns that off until Scan is pressed again.There is no iOS peer:
HardwareLinkandSensorLogare Android-only, marked withTODO(ios parity).Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.