Jean-Pierre MartineauandClaude Opus 5.5
19c910bbde
Joining a room moves out of Chat into a Rooms page beside Channels. It lists every room server the radio knows, joined ones first, with each room's access, unread count, last post and last-heard time. Each room has a page: join, log in again, change password, open the board, forget it, or delete its stored posts. Chat now lists only joined rooms, the way it lists only channels on a slot, and only a joined room raises the unread badge. chat join becomes rooms join, alongside rooms list and rooms forget. "No reply" told the reader nothing, because a room is just as silent for a wrong password as for a login that never reached it. Testing on hardware showed the commonest cause is neither: a login sent along the route the radio had learned met silence, and the same login by flood was accepted in eleven seconds. A silent login is now explained from what is known: how it went out, when the room was last heard, and whether this password has worked before. It offers the one next step that evidence points at: - Try by flood, after a learned route met silence. The radio forgets the route (local, nothing transmitted), then sends the login once. - Try again…, after a flood met silence. The prompt reopens with the password filled in, so Enter resends it and typing replaces it. - Add it & try again, when the radio doesn't hold the room as a contact. Every retry is a button press, and none is ever sent on its own. A password over 15 bytes is refused at the prompt, since MeshCore sends only the first 15. On the board, a failed or unfinished login used to leave the compose line taking posts the room would drop. It now opens only while we are in and may post, and otherwise says why and what to press. Opening a joined room that has gone quiet logs in in the background. ^L runs the explained flow. Underneath, the login exchange listens for the radio's own confirmation, matched to the login by its expected ack. It records whether the login went by flood or along a route, or the radio's reason for not sending it at all. This also corrects the debug log: "send unacknowledged" read the library's wait for the *answer* as the send. On hardware the radio confirms in under 0.1 s. Device.reset_route is new. The simulator learns routes, can be given a stale one, and refloods. Refs: #24 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
MeshTerm documentation
Everything that didn't belong on the front page. The README is the front door — what MeshTerm is, how to install it, and enough to get a first session running. This folder is the rest, in four parts:
| Folder | What's in it |
|---|---|
guide/ |
Using MeshTerm: what each screen does, configuring it, connecting a companion, terminals. |
cli/ |
The command line manual, and a cookbook of one-liners. |
devices/ |
Running MeshTerm on a handheld's own screen, one manual per device. |
development/ |
How the code is laid out, and a historical survey. |
Using MeshTerm
| Read | For |
|---|---|
| What MeshTerm does | Every screen the menu offers, grouped the way the menu groups them, with the command that does the same job without it. |
| Configuring MeshTerm | Preferences versus config, device profiles, and everything kept under ~/.meshterm. |
| When a companion won't connect | Bluetooth pairing on each system, finding the PIN, and every connection error MeshTerm reports, with what to do about it. |
| Terminals, icons, and the Windows console | Why the icons and charts draw on some terminals and not others, and what MeshTerm does about it on Windows. |
The command line
| Read | For |
|---|---|
| The command line | The manual. Every subcommand and option, what each prints on the plain and JSON faces, the exit statuses, and recipes built on jq. |
| The CLI cookbook | Common one-liners by task, for when you want the shape of a command rather than its specification. |
Running it on a handheld
Only if you want MeshTerm running on a handheld's own screen. A MeshCore companion on USB, Bluetooth, or Wi-Fi needs none of this.
| Read | For |
|---|---|
| MeshTerm on hardware | Start here — which manual below is yours, and what the device-side scripts do. |
| MeshTerm on the PicoCalc | A stock ClockworkPi PicoCalc to a Linux handheld with a LoRa radio soldered inside: the shopping list, the swap to a Luckfox Lyra core, Calculinux, and the radio. |
| MeshTerm on the uConsole | A uConsole (CM4 or CM5) with the hackergadgets AIO LoRa board, whose SX1262 sits on the computer's own SPI bus — MeshTerm drives it directly with --spi, or a small bridge fronts it as a companion for an always-on node. |
| MeshTerm on the Cardputer Zero | ⚠️ Not supported yet. What exists for M5Stack's Linux Cardputer, and how to try it in the desktop emulator. |
Reading the code
| Read | For |
|---|---|
| How the code is laid out | The layering, and where a new feature goes. |
| CLAUDE.md | The actual style guide — terminology, UX standards, and the reusable building blocks. Written for AI assistants, and the house rules for everyone. |
| CONTRIBUTING.md | How to propose a change, the rules on AI use, the dev install, the three checks a change must pass, and what happens to your contribution's licensing. |
Historical record
A survey of the code, kept because a project that writes down its own problems is easier to trust than one that doesn't — but it is a snapshot of a date, not a to-do list. Some of what it describes has been fixed since, and it does not mark which.
| Read | For |
|---|---|
| UI consistency survey | Everything else in the CLAUDE.md UX standard — six sweeps found nothing, which is the useful part. |
Also here
screenshots/ holds the captures the README shows and the ones
meshterm.net builds its landing page from, so a file in there is
referenced from more than one place.