Ruben Laban
7eada9b8c3
MeshCore names run to 31 characters (ContactInfo::name[32]), but UIMessage::sender held 24, so every longer name was cut on the way in. d304d3f made the cut visible instead of letting it push the author into the message body; this makes it stop happening. MAX_SENDER_NAME goes to 31 — exactly the wire width, so nothing is lost. Truncation could never fix three of these. "Ack" and "Mention" insert @[<sender>] into the composer, and textMentionsMe needs the whole name followed by ']', so a mention of a long-named node never reached them. Block-by-name compares the stored name against the sender on the RX path; for ROOM posts those two came from different widths already — the check sees the untruncated 31-char author while the stored entry came from the 24-char field — so a room author with a long name has simply been unblockable. Info and the chat-list preview showed a cut name. The obvious change — widening UiHistoryMsg::sender — would have been quietly destructive, so the on-disk width is frozen at 25 instead and the overflow is APPENDED to UiSegMsg, after seq. sender sits between thread and text, so widening it in place shifts text for every record already on disk, and nothing would have caught that: the segment store is what actually holds messages now, and uiSegOpenValidated checks only magic/version/rec_size — it never consults k_ui_history_version or k_ui_history_min_version, which guard the legacy files alone. An old segment would have passed validation, prefix-read into the new offsets, lost the first 8 characters of every message body and read seq as 0 (so loadMsgsFromSegments renumbers the lot), and the next compaction would have written that back permanently. Appending at the tail is the evolution path UiSegHeader already documents, and it is correct in both directions: an old 233-byte record zero-fills the new field and yields its original short name, and older firmware reading a new 240-byte record copies the first 233 bytes and ignores the tail. That second half is why k_ui_seg_version STAYS 1 — bumping it would make older firmware reject the file outright and quarantine a history it could have read. So there is no migration, no version bump, and no wiped chat history. static_asserts now pin the offsets an already-written record depends on. TOUCH_IGNORED_NAME_LEN has to move in lockstep (28 -> 32) or blocking breaks: a slot narrower than a sender stores a cut name the full-width check can never match, and the block sits in Settings doing nothing. Its NVS blob has no header — the entry count is its length divided by the slot width — so re-slotting in place would mangle every entry after the first and the next write would make that stick. The key is renamed ign_nm -> ign_nm2 and the old blob folded in once at first read, which is unambiguous in a way that sniffing the blob length is not (28 and 32 share multiples at 224 and 448, both inside the 16-entry cap). The invariant the header only stated in prose is a static_assert now. Split/rejoin is a host-tested header next to ChannelSenderSplit, with the field-width bounds spelled out: a corrupt record can leave the name field unterminated, and the message body is what follows it on disk. Signed-off-by: Ruben Laban <ruben@tun0.nl>
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, Heltec V4 + TFT and eight other boards (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 — sideload guide for running your own build - Elecrow ThinkNode M9 — env
ThinkNode_M9_companion_radio_touch(beta) — keyboard & d-pad guide - RAK WisMesh Tap V2 (RAK3312) — env
rak_tap_v2_companion_radio_touch(beta) - LilyGo T-Lora Pager — envs
tlora_pager_lr1121_companion_radio_touch/tlora_pager_sx1262_companion_radio_touch(beta) — keyboard shortcuts - Heltec V4-R8 + Expansion Kit V2 — env
heltec_v4_r8_tft_companion_radio_usb_tcp_touch(beta) - LilyGo T-Display P4 — built from
tdisplay_p4/(ESP-IDF); AMOLED by default,WADA_P4_LCD=1for the TFT-LCD SKU (beta) - Attaky Mesh Series — env
attaky_mesh_series_companion_radio_touch(beta)
Architecture
This repo holds only the app: the companion_radio glue, the ui-touch
LVGL UI, each board's 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.
Lua apps use the on-device SDK described in LUA_APPS.md. For WAV/MP3 playback, including a ready-to-sideload transport test app and exact SD and internal-storage paths, see AUDIO_PLAYBACK_TESTING.md.
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.