Kaj SchittecatandClaude Opus 5
a96900d7ee
Yoss101 reported the beta_62/63 fix helped but did not cure it: the freezes got rarer AND longer. Rarer is the blob-delete queue working; longer is what was left, and it was always the bigger half. MAX_CONTACTS is 2000 and a contact record is 152 bytes, so saveContacts was rewriting a 304 KB file on every change, with a same-sized .tmp alongside it for the atomic swap. On a card-less V4 that is ~608 KB of peak churn on a 3.375 MB SPIFFS volume that is already carrying one blob file per contact. SPIFFS GC cost scales with how full the volume is, and GC suspends the flash cache, which stalls BOTH cores — so the fuller the table, the longer the device is simply gone. The table never actually changes in bulk: eviction replaces contacts[oldest] in place (the array is unsorted and never shifts) and an advert refresh touches one entry. So compare each record against what is already on disk and write back only the ones that differ. An eviction now writes 152 bytes instead of 304 KB, an unchanged table writes nothing, and there is no .tmp and no free-space spike. Reads never trigger GC, so the compare scan is cheap. Falls back to the full atomic rewrite whenever the mapping is not provably safe (no live file, ragged size, or a table that shrank — there is no truncate here), and never truncates or renames, so a fallback always leaves a valid list on disk. Verified against the real function source with an in-memory FS harness: steady state, eviction, growth, shrink, filtered anon slots, missing file, ragged file, and 167 scattered changes all match a full rewrite byte-for-byte. Also: the blob-delete queue silently ORPHANED a blob on overflow — nothing else ever deletes it, so it leaked flash permanently on the one metric that drives GC cost. Depth 8 -> 32, and overflows are now counted and surfaced. New About > diagnostics block "Contact store": contact count, approximate on-disk size, internal-flash used percentage, and orphaned blobs. The used percentage is the number that predicts these freezes, so a reporter can photograph it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A real touchscreen UI for your mesh radio. · open source · GPL-3.0
Touch-UI MeshCore companion-radio firmware for the LilyGo T-Deck / T-Deck Plus and Heltec V4 + TFT (ESP32-S3).
An LVGL touch UI — map, chat, contacts, channels, settings — split out of
meshcomod. The app depends on a
MeshCore fork via PlatformIO lib_deps.
Boards
See DEVICES.md for the full support matrix, install paths and per-board status.
- LilyGo T-Deck / T-Deck Plus — env
LilyGo_TDeck_companion_radio_touch(stable) - Heltec V4 + TFT + CHSC6x touch — env
heltec_v4_tft_companion_radio_usb_tcp_touch(stable) - Tanmatsu (ESP32-P4) — built from
tanmatsu/(ESP-IDF), ships via the Tanmatsu app store - Elecrow ThinkNode M9 — env
ThinkNode_M9_companion_radio_touch(beta) - RAK WisMesh Tap V2 (RAK3312) — env
rak_tap_v2_companion_radio_touch(beta)
Architecture
This repo holds only the app: the companion_radio glue, the ui-touch
LVGL UI, the two boards' glue/variants, and platformio.ini. The MeshCore
core is not vendored here — it's pulled as a library via lib_deps from the
ALLFATHER-BV/meshcomod monorepo
(the same repo as the non-touch firmware), pinned by a lean source-only core-*
git tag. The touch-app files this repo owns (TouchPrefsStore, WifiRuntimeStore,
the transports, …) are dropped from the lib via -DMC_VENDORED_TOUCH_APP so they
aren't compiled twice. The build is byte-identical to the original in-tree
meshcomod firmware.
Build
PlatformIO pulls the core fork and all libraries automatically:
pio run -e heltec_v4_tft_companion_radio_usb_tcp_touch # Heltec V4 TFT
pio run -e LilyGo_TDeck_companion_radio_touch # LilyGo T-Deck
# or just `pio run` to build both
Flash with the NVS-preserving 4-component chain (bootloader / partitions /
boot_app0 / firmware at 0x0 / 0x8000 / 0xe000 / 0x10000) so saved Wi-Fi
credentials survive — not a merged image, which 0xFF-pads and wipes NVS.
Contributing
Contributions are welcome — see CONTRIBUTING.md. One topic per PR; inbound contributions are accepted under the project's GPL-3.0 license.
License
GPL-3.0-or-later — see LICENSE. wadamesh is copyleft: anyone who distributes a build or a fork must also make their source available under the GPL. This keeps the UI open and concentrates community effort instead of fragmenting it into closed forks.
wadamesh incorporates and depends on MeshCore (MIT, © Scott Powell / rippleradios.com) and other third-party components — see NOTICE for the full list and their licenses. MeshCore-derived files keep their MIT notices; the combined work is distributed under the GPL (MIT is GPL-compatible). The MeshCore fork that wadamesh builds against stays MIT on purpose, so its Wi-Fi/BLE hooks remain upstreamable to MeshCore.