Firmware 1.18 gives contact flag 0x10 a security meaning (the contact may
run any companion CLI command over the mesh, unseen by the app), forwards a
refused remote command as a txt_type 3 DM, and serves the companion CLI over
the app link (CMD_RUN_CLI_COMMAND, fw_ver_code 14).
- Remote CLI permission is visible: red badge on the contact card and in
the DM contact-info window. Console change_flags shows flags in words,
accepts 0x.., reports old/new, warns on grant, restores the in-memory
record when the device refuses, and invalidates the contacts cache.
- txt_type 3 DMs are stored with their type, rendered as "Remote CLI
command - not executed" with the command verbatim, logged at WARNING,
and the notification says so.
- New console command `cli <command>`, gated on fw_ver_code >= 14 and on
the library having run_cli_command (2.3.9+, requirements untouched).
poweroff/shutdown refused; reboot and `set name`/`set path.hash.mode`
routed through the existing commands so caches follow.
- Re-adding a contact the device holds (a rename) starts from the device
record, so its flags and path survive instead of being reset to zero.
- Fix: approving a pending contact raised KeyError('out_path') for every
record not produced by a NEW_CONTACT event (advert-injected entries and
the DB fallback). Records are now completed before add_contact(), and a
device ERROR is reported instead of a false success.
- set_channel refuses a named slot with an all-zero key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Renaming the device in Settings changed the firmware's node name at once,
but mc-webui kept its cached copy until the next reconnect. Own messages
were stored under the old name, and their raw_packet snapshot and echo
candidates were built from it: Resend then broadcast a second packet under
the old name, and messages sent after the rename never got a repeater
badge. Open pages kept the old name in the navbar and on each message
sent, even across a container restart, until a reload.
set_param('name') now cuts the name to the firmware's 31 bytes on a
character boundary (the firmware cuts mid-character, the lib drops the
fragment on read-back), reads SELF_INFO back under the send lock - also
when the command failed or its reply was lost - and adopts the reported
name through _set_device_name(), which _connect() uses too. That updates
runtime_config and emits device_name on /chat; the page applies it to the
navbar, MC_CONFIG.deviceName and the mention rule, and loadStatus() catches
up from /api/status for a page that missed the event.
Also: send_channel_message reads the name under the send lock; the
self-echo guard no longer compares the sender's name, so a resend of a
message from before a rename is still recognised; get_device_info no
longer caches an ERROR reply as SELF_INFO; the observer reloads its MQTT
clients on a rename; Settings sends the name only when it changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The version check already worked for an installation running the published
image - CI freezes the version before building, so version_frozen.py ships
inside it - but "Update now" never appeared, because the webhook behind it
was installed from scripts/, a folder such an installation does not have.
And update.sh could not have served it anyway: it does git pull + rebuild.
- both installers accept being piped through bash (curl | sudo bash). They
then download what they need into /opt/mc-webui-{updater,watchdog} and
find the instance by looking for docker-compose.yml. A checkout install
keeps running its scripts from the checkout, unchanged
- updater.py picks the update path per request: git checkout -> update.sh,
bare docker-compose.yml -> the new update-image.sh (pull + recreate).
Resolved per request, so cloning the repo later flips it without a restart
- both update scripts end with MC_UPDATE_RESULT=updated|no_change, which
the webhook parses and /api/updater/status passes on. The UI used to
watch only for the version to change and then claim it timed out after
two minutes - the normal outcome right after a push, while the image for
that commit is still building. It now says so as soon as the run ends,
in a neutral state rather than a red cross
- the marker prints only when stdout is not a terminal, so mcupdate output
stays as it was
Also corrects the claim, in the README and in updater.py's own docstring,
that the webhook listens on localhost. It binds 0.0.0.0 - the container
reaches it over the Docker bridge - and sends no token, so port 5050 is
worth keeping off untrusted networks.
Verified: update-image.sh reports updated then no_change against a real
docker compose project; the standalone installer installs, runs and
uninstalls cleanly under systemd (WSL), with the app reaching it through
host.docker.internal and a triggered run coming back changed=false; the
resulting modal checked in a browser in both en and pl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The line under an incoming channel message showed the SNR and hop count of
the one copy the firmware decoded, while the popup listed only the copies
relayed by repeaters. With the sender in direct range that read as a
contradiction ("Hops: 0" above, "Hops: 1" on every popup entry), because
the direct copy has an empty path and was filtered out of the echo arrays.
The line is now just "Route (n): <hash size> | Region: <name>", and the
popup carries everything it used to: the echo arrays include every copy
heard, in the order heard (ties on the 1 s received_at broken by id), a
direct copy is listed as "Direct" with 0 hops and no copy/analyzer action,
and the copy the node actually decoded is marked "received" — matched on
hop count and SNR against the message row, so a copy missing from the RX
log never mis-marks the next one.
The hash size is coloured red / orange / green for 1 / 2 / 3 bytes,
semi-bold, with per-theme tokens kept at or above 5:1 on the bubble; the
whole line goes from 0.7 to 0.8 rem and --text-meta from ~2:1 to 4.5:1,
since it was hard to read on a big screen. The popup now opens to the
right of its tap target: with the route first in the line, a
right-anchored popup ran under the channel sidebar on a desktop.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The meta line under an incoming channel message used to print the first
route inline ("Route (3): 142C→1122→271C→EE6C"), which with 2- or 3-byte
hashes and a few hops crowded everything else off a phone screen. It now
names only the per-hop hash size ("Route (3): 2 bytes") and stays the tap
target for the routes popup, which lists every route as before.
The line also ends with "Region: <name>" when the packet was flood-scoped
to a region this instance knows. The region name never travels: a
TRANSPORT_FLOOD packet carries a 16-bit transport code (HMAC of the scope
key over the payload) that _on_rx_log_data used to discard. Echoes now
keep those 4 header bytes in a new echoes.transport_codes column, and the
API recomputes the code for every configured region (Settings → Channels)
to find the one that reproduces it; own messages fall back to their
raw_packet snapshot. calc_transport_code() is shared with the raw-resend
packet builder, so both sides derive the stamp from one place.
Verified against on-air packets from the test server on #mcwebui: pl,
pl-ma and pl-kra each resolved to exactly one configured region.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Adds "Move to another region" to the per-region menu. Until now the only
way to re-parent was to delete the region and add it again under a new
parent. `region put <name> <parent>` on an existing name already
re-parents it (RegionMap::putRegion), so the command was there; what was
missing was doing it safely.
Two firmware behaviours make a blind put unsafe, both confirmed live on
MarWoj Mobile Observer, and both settled by the one tree read the move
now does up front:
- The only cycle check is `region->id == parent_id`. Moving a region into
one of its own descendants is accepted, and detaches that branch from
the wildcard root: it disappears from the `region` listing entirely
(printChildRegions recurses down from the root) while still holding
table slots. Verified — after `region put zza zzb`, both vanished from
the tree while `region get zza` still answered ` zza (zzb) F`. Nothing
in the UI could then show them, let alone fix them. Forwarding is not
at risk: findMatch scans the flat array and never walks parents.
- The put branch sets `region->flags = 0`, so moving a flood-denied
region silently re-allows flood, and the reply says
`OK - (flood allowed)` without hinting anything changed. Verified: zzb
was denied before the move and came back allowed.
So the move reads `region` first, refuses self/descendant/wildcard
targets, then puts, then re-applies `denyf` when the region was denied.
A lost restore is surfaced rather than swallowed — the region has moved
but is forwarding traffic it was set to drop. The picker filters the same
descendant set client-side, so the guard is not a surprise at the end.
Moving a region carries its nested regions with it, which is the point:
verified moving zzc (holding zzb) under zza.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The backend already accepted a parent (`region put <name> <parent>`) and
the list indented nested regions correctly, but the Add form always
created at the root. It now carries an "Inside" picker listing the known
regions, defaulting to top level.
Verified end to end against MarWoj Mobile Observer: `zzpar` at the root,
`zzkid` inside it, the tree coming back as `* / pl / zzpar / zzkid` with
the child indented one level, and the firmware refusing to delete a
parent that still has children (`Err - not empty`).
Also fixes a status code this endpoint got wrong from the start. A
repeater answering `Err - not empty` or `Err - unknown region` is
enforcing its own rule, not failing as a transport, so it now comes back
200 with `ok: false` like the sibling /action and /neighbours/remove
endpoints, rather than 502. 502 was misleading and put a spurious error
in the browser console, where it could mask a real one. `dirty` is now
computed from `ok`, so a refused action can no longer mark the map as
having unsaved changes; the frontend checks both through one helper.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A repeater's flood-scope map was only reachable by typing `region`
commands into the console and reading back an indented text tree.
My Repeaters -> Settings -> Regions now renders that tree as a list with
per-region actions, an Add form, and a Default scope card.
Placed as a row at the foot of the Settings pane rather than a seventh
tile: region management is a list with its own add/remove and an
explicit save, not the scalar get/set fields the accordion is built for.
openToolPane() already accepts any descriptor, so REGIONS_TOOL reuses
the pane machinery; _paneCurrent/_paneParent make the pane back arrow
return to Settings instead of jumping two levels to the grid.
Two firmware facts shape the design, both verified against a live
repeater (MarWoj Mobile Observer, 2.2.15):
- put/remove/allowf/denyf mutate the map in RAM only and are lost on
reboot until `region save` writes flash. Edits therefore stage behind
an explicit Save with a warning banner, and leaving with changes
pending asks first. `region default` is the exception -- the firmware
calls saveRegions() itself -- so it never sets the dirty flag.
- The bare `region` reply is an indented tree (indent = depth, `^` =
home, trailing ` F` = flood allowed) capped at 160 bytes by
exportTo(reply, 160). Suffixes are stripped right-to-left because a
region may legitimately be named `F` or end in `^`, and a clipped
tail is reported rather than hidden.
The binary AnonReqType.REGIONS request stays unused: it answers with
exportNamesTo(), a flat list of allowed names with no hierarchy, deny
flags or home marker -- most of what this screen shows.
Names go through the existing is_valid_region_name() before any command
is built, which also blocks CLI injection through a name.
28 new unit tests cover the tree parser (nesting, the `F`-named-region
ambiguity, `#` stripping, truncation) and the command builder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A channel used to have two settings: every message or nothing. Now it has
three - muted, every message, or a named profile of rules (mentions me,
message contains, sender contains; any or all must match). A channel on a
profile counts only matching messages: the unread badge, the navbar bell,
the app-icon badge and the browser/Android notification all follow the same
rule. Direct messages are untouched.
- app/notify_profiles.py: rule matching (case- and diacritic-insensitive,
same table as the chat filter), validation, storage in app_settings
- read_status.notify_profile column, written together with is_muted so a
mute never leaves a profile behind; migration added
- /api/notification-profiles CRUD, PUT /api/channels/<i>/notifications;
/api/read_status and /api/messages/updates report channel_notify_profiles,
the latter counts a profiled channel's unread through the profile
- Manage Channels: the bell opens a menu (Off / Every message / profiles /
Manage profiles...) instead of toggling; profiled rows get a green badge
- Settings > Notifications: profile list with in-use counts and an editor
- app.js evaluates the same rules for socket-delivered messages, and a
state version guard stops an in-flight poll from undoing a fresh
mute/favorite/profile change
- i18n en/pl (43 keys), docs (user guide, architecture, whatsnew), tests
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Expanding a Settings section fired one `get` per field, each a full mesh
round-trip. Seven questions to a repeater four hops away, answered one at
a time, to change the one field you came for -- and often a batch that
timed out halfway and left the section blank.
Nothing is read until asked for now:
- every field has its own read button beside the control (same row, so
no extra line per field), and `Read all fields` at the top of the
section still does the whole batch
- GET /settings takes an optional `fields=` subset so a single field is a
single round-trip; the section still defines the order
- reads are queued client-side. The device already serializes CLI traffic
behind one lock, so parallel requests would only tie up server threads
waiting for it
- values are remembered per repeater in localStorage, so a section opens
with the last readings instead of empty boxes. A remembered value is a
usable baseline -- Apply writes an absolute value, so editing from a
stale reading still sets what was typed -- and is marked with a clock
per field plus a note at the foot of the section saying when it was
read. Apply and unsupported replies update the cache too
- a failed read no longer wipes what is on screen: the remembered value
stays, still editable, still marked
- field hints moved from a text block under the control into an info icon
by the field name (the pattern the app's own Settings modal uses), and
every field has one now instead of the 9 that did
Verified against a live repeater from the local container: expanding all
8 sections makes 0 requests, a single-field read sends exactly
`?section=advanced&fields=rxdelay`, the value survives a reload from cache
with the stale note, and Apply still round-trips (dutycycle rewritten to
its own value).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settings -> Advanced carried txdelay and direct.txdelay but not rxdelay,
which CommonCLI has had all along for every repeater and room server
(get + set, float 0-20, 0 = off by default). Reaching it needed a raw
CLI command.
It is a distinct mechanism from the tx delays: calcRxDelay staggers the
repeating of flood packets by packet score, so a strong copy repeats
sooner and a marginal one waits and drops the repeat as a duplicate.
Adds the field to _REPEATER_SETTINGS_FIELDS and SETTINGS_SECTIONS (the
two lists must stay mirrored) plus en/pl labels and help. `af` stays out
on purpose: dutycycle replaced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The path list is a retry order, so the same route twice means retrying a
route that has just failed while a genuinely different one waits. Both
editors (contact info and My Repeaters) POST to the same endpoint, so the
guard sits there: adding or editing a path onto a route the contact
already has is refused with 409 duplicate_path, and the modal stays open.
Paths are now normalized to lowercase on write and existing duplicates are
collapsed on startup (keeping the primary copy), which lets a unique index
back the check. The index is created in the migration rather than
schema.sql, which runs before duplicates are removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Neighbours pane could only read the repeater's list. The standard
MeshCore app offers two more commands from its overflow menu, and there
was no way to reach either from here:
- `discover.neighbors` — repeater-firmware only, so a node type that does
not have it answers with an error we surface verbatim rather than
reporting a success
- `neighbor.remove <prefix>`, with an empty prefix clearing the whole list
Remove-all deliberately gets its own endpoint instead of going through
/cli: the firmware matches `neighbor.remove ` on all 16 bytes including
the trailing space, and the CLI endpoint strips the command, so the
console cannot express it at all. The prefix is validated as hex of even
length — the firmware derives the byte count as len/2 and would silently
match a wider set than asked for.
Both actions are admin-only (the list itself needs only a login) and live
behind a kebab menu next to Refresh, which keeps the header on one line
on a phone once the Refresh label is dropped below `sm`.
Single removal goes through a detail dialog opened by selecting a row or
a map marker, rather than a trash icon per row: that row already
truncates names at 390px, and a delete button at the edge of a scrolling
list is the easiest thing in the panel to mis-tap. The dialog doubles as
somewhere to show the pubkey prefix, SNR, last-heard time and position,
which the list has no room for; guests see it without the button.
Also caps the name column at 40vw and scrolls the table in its own box,
so a long neighbour name no longer drags the whole page sideways.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A tester's cached-contacts map came up empty and Path Analyzer drew routes
across the globe. Two of his 2131 cached contacts carried garbage positions
from corrupted adverts - lat 1642 / lon -323 and lat 309 / lon -1768.
Leaflet clamps latitude when projecting but not longitude, so fitBounds()
spanned 1797 degrees, dropped to zoom 0 and centred on lon -870; all 2273
real markers were rendered several world-widths outside the viewport.
Reproduced against his DB: zoom 0, bounds -1431..-309. The device-only view
was fine because both bad rows are cache-only.
Four layers, so no single miss can blank a map again:
- app/geo.py: one definition of a usable coordinate, applied on write in
Database.upsert_contact() so the cache stops storing garbage, and on API
output so a cache poisoned by an older build heals itself with no
migration. Corrupted advert types (61, 126, 152, 210 seen in the wild)
are logged but kept raw - they already render as UNKNOWN.
- static/js/geo-utils.js: hasValidGps()/withValidGps()/fitMapToPoints()
replace eight copies of the same check across six files. Path Analyzer
had a looser variant that also accepted lon == 0, which put nodes off
west Africa and stretched routes across the map; it now shares the rule.
- Per-marker try/catch and a bounds validity check, so an entry that still
slips through costs its own pin rather than the whole map.
Verified against the tester's DB in a container: cached map 2273 markers,
lon span 1797 -> 19 degrees, centred on Poland; the route that drew the
world-spanning line (msg 29499, token 72AF) now renders as a real
Krakow-Kielce path with the bad hop left unresolved. Live local instance
regression-checked on all five map pages. tests/test_geo.py: 43 passed;
full suite 290 passed, 2 pre-existing failures unrelated to this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Sync clock" under My Repeaters sent the firmware's `clock sync`, which
sets the repeater RTC from the CLI packet's sender_timestamp. The
companion overwrites that field with its own RTC before transmitting
("Use node's RTC instead of app timestamp", companion_radio/MyMesh.cpp),
so the button copied the node's drift onto the repeater instead of the
server's time — observed as a repeater set 56 minutes slow. Send
`time <epoch>` instead: the value travels in the command text, taken
straight from the host clock and untouched in between.
The node's own clock is now checked on connect and hourly, and set from
the host whenever it has drifted more than 30s. It is only ever set by
hand today, so it free-runs: the local test device was 16 hours behind.
CMD_SET_DEVICE_TIME is refused when it would move a clock backwards, so
a fast-running device is logged loudly rather than retried in silence.
Also name the timezone wherever a clock is printed. The Status row
renders in the browser's zone, the console in the container's, and
repeaters answer their own `clock` in UTC — three unlabelled renderings
of the same instant, which is what made this look like chaos rather
than drift.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mc-webui has no login, which is fine on a LAN and not fine once the
address is handed to testers: they assume the node is theirs and rename
it, and the console is right there for anyone curious enough to type
into it.
MC_DEMO=true refuses everything that reconfigures the radio, destroys
data, reaches other people's repeaters, rebuilds the containers,
publishes to an external broker, or hands out a secret. Reading and
sending messages keep working, so the instance is still worth visiting.
The guard is default-deny: an api_bp.before_request hook refuses every
non-GET unless it is on a short allowlist, so an endpoint added later is
locked without touching this module. That mattered — six mutating
endpoints already had no frontend caller and would never have made a
hand-written blacklist. A small read denylist covers the GETs that leak
(repeater passwords, backup download, capture download, /api/logs),
which the write guard never sees.
Two paths bypass the HTTP layer and are closed separately: the console
is a Socket.IO event, not a route, so it is checked against a read-only
command set; the log viewer is refused at the connect handshake.
Access is kept two ways. MC_DEMO_TRUSTED_NETS unlocks by CIDR, and
MC_DEMO_UNLOCK_CODE unlocks by a code typed once in Settings and held in
an HMAC cookie for 30 days — stateless, and deliberately not Flask's
session, whose SECRET_KEY is a hardcoded public constant.
The trap the network list walks into: published through a tunnel, every
visitor arrives from the tunnel's address, and if the tunnel runs on the
LAN then trusting the LAN unlocks the instance for the whole internet.
An address arriving with a proxy header is therefore not matched unless
MC_TRUST_PROXY is on, and startup logs report the resulting shape.
Frontend is advisory only: demo-lock.js loads from _head_i18n.html so it
reaches all eight entry points including the six iframes, greys out
[data-demo-lock] rather than hiding it (the instance exists to show the
app off), re-applies via MutationObserver for JS-rendered buttons, and
turns any 403 demo_locked into a toast.
Verified on the local container: the rename, reboot, updater, vacuum,
cleanup and the leaky GETs all 403; sending, read markers and ordinary
reads pass; `set name` is refused over the console socket while `infos`
still answers; unlock/lock round-trips. 86 new unit tests, en/pl at 100%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MeshCore clients share contacts, channels and positions as plain text in
ordinary chat messages. Until now those arrived as unreadable raw tokens.
They now render as interactive cards in both the channel chat and DMs.
Three wire formats, none of them ours to choose — they are what the
official app emits, so share-tokens.js stays byte-compatible with it:
contact <64-hex-pubkey:type:name> (compact, not a URI)
channel meshcore://channel/add?name=&secret=®ion_scope=
location bare "lat,lon"
The contact URI form is parsed too (QR codes carry it) but never emitted:
with a name like "MarWoj 💡📱 mobile" it costs 153 bytes and cannot fit a
135-byte channel packet, where the compact token needs 91.
Parsing runs BEFORE HTML escaping, leaving private-use-area placeholders
that the later passes cannot match. Tokens do not survive the existing
pipeline otherwise: escaping breaks a URI's '&', processChannelLinks eats
a '#channel' name, processMentions an '@' in a contact name, and the
token's closing '>' collides with quote syntax.
Cards resolve their action before rendering, so the button states what
will actually happen rather than surprising the user afterwards:
contact Add / Update name to X / Already in contacts / Push to device
channel Add / Already joined / Name used by a different key
The public key is the identity — a known key under a new name is a
rename, never a second contact.
Shared contacts land in the local cache rather than device memory:
they arrive unsolicited and contact slots are limited, so promotion stays
deliberate. The card offers it inline once cached, so it costs one click
rather than a trip to the Contacts panel. New: manual-add accepts
target=cache, which needs no device connection.
Location cards add distance and bearing from our own advertised position,
plus map/copy/external-map actions. A shared channel's region scope is
carried over on join, since transmitting under the firmware default would
not match the sender.
Coordinate detection is deliberately narrow — both numbers need 3+
decimals, ranges are checked, and matches inside URLs are skipped — so
prose like "1,5 osoby" or "wersja 2,10" and Google Maps links are left
alone.
Verified against real payloads received from another device on #mcwebui,
covering all three formats plus a contact URI and emoji names: 65 parser
assertions, 57 render assertions, i18n check clean at pl 100%, and both
themes screenshotted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Firmware v1.17 changed no protocol constants and left FIRMWARE_VER_CODE at
13, so the companion protocol cannot tell a v1.16 node from a v1.17 one.
Capability is instead read from the CLI reply text, which self-describes and
works for any version and board without an extra round-trip:
`??: <field>` / `unknown config: <field>` → firmware has no such setting
`Error: unsupported` → hardware cannot do it
`> <value>` → supported
Both of the first two now yield an 'unsupported' status rather than a
failure, rendered as a muted badge with the control locked and excluded from
Apply. Without this, every field added below would read as a red error on
each repeater that predates it.
Applying to an unsupported field deliberately asserts nothing about the
stored value: v1.17 persists radio.rxgain before it learns the radio cannot
apply it, so the old value may or may not still hold. The baseline is
dropped instead of being reasserted, and only Refresh reveals the truth.
Also guards a pre-existing trap: up to v1.16 the `radio.rxgain` getter was
compiled out on non-SX126x radios, and `get radio.rxgain` fell through to
the `radio` branch (its memcmp has no trailing space), answering with the
radio parameters. That parsed as a valid reply and silently rendered the
switch as off. An on/off field that answers neither on nor off is now
treated as absent.
New fields: cad (v1.17+), flood.max.unscoped and flood.max.advert (both
present since v1.16, previously just undocumented upstream).
New action: poweroff (v1.17+). Unlike reboot it cannot be undone over the
mesh, so it takes a typed repeater name rather than a confirm(), checked
server-side as well as in the UI.
Telemetry: the MCU temperature v1.17 appends to channel 1 is labelled as
silicon rather than as an environmental reading. Absent stays absent —
boards without a usable sensor emit nothing, and a zero would be a lie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The path dialog could send a node back to FLOOD or push a configured
path, but Direct — the firmware's third mode, zero hops — had no button;
getting there meant clearing the path from the Console.
A new POST /api/contacts/<key>/paths/set_direct sends an empty path hex,
which makes the firmware store out_path_len = 0, the state
_format_path_display() already renders as "Direct". Configured paths are
untouched, same as Restore FLOOD.
The button is wired in both places paths are managed: the DM contact info
dialog and the My Repeaters path modal. Both button rows get flex-wrap so
the third button wraps instead of overflowing at 360px.
Verified against the local test device: the endpoint moved a repeater
from 5E34→EE6C to Direct and back, and both dialogs render correctly in
en/pl at 1280px and 360px.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Restarting the node meant opening the Console and typing `reboot`, or
reaching the hardware. Device > Info now carries the same action as a
button, with a confirm that says what it costs: the device leaves the
mesh for a few seconds and anything addressed to you in that window can
be lost.
POST /api/device/reboot wraps the DeviceManager.reboot_device() the
console command already used. The firmware acknowledges nothing and the
companion link goes down with it, so a 200 means "command written", not
"device is back" - the reconnect is _on_disconnected()'s job, and it
takes about five seconds over TCP.
The button is rendered by loadDeviceInfo() rather than sitting in
base.html, so it only exists on the branch where the device answered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Some faults cannot be diagnosed from a screenshot on a server we have no
access to. The one that prompted this: a sent channel message gets no
repeater badge, and nothing in the database distinguishes "nobody in
earshot repeated it" from "the repeat came back over the air but the
firmware dropped the RX-log frame before the app ever saw it".
Settings > Diagnostics records a bounded window into a zip: every RX-log
frame, the echo correlator's decision (with the pending-send list that
explains a non-match), what each send expected to hear back, the
application log at DEBUG, and the device's own packets.recv counter at
both ends of the window. That last comparison is the whole point - it
turns the firmware's silent 4-frame queue overflow into a measurement
instead of a hypothesis.
scripts/diag_report.py reads a capture offline and prints the verdict.
Captures can be downloaded, or uploaded to a Zipline instance once the
user pastes a token handed to them out-of-band. The URL ships as a
default; the token never does, because this repository is public.
- Hot path follows observer.py's contract: one deque append, no locks,
no I/O. The log handler uses a no-op lock object rather than
lock = None, which raises under Python 3.13's `with self.lock` in
Handler.handle() - latent on the 3.11 container, fatal on 3.13
- Caps: 5/15/30/60 min, 25 MB, 10 stored captures. All enforced by the
writer thread, so a user stop and an auto-stop finalise identically
- The capture contains the text of messages received while it runs; the
UI states this and confirms before any upload
Also drops a redundant function-local `from flask import current_app` in
get_status(): it shadowed the module-level import for the whole function
and broke /api/status as soon as anything referenced current_app above
it. Found by the capture tool, in its own change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Groundwork for translating the interface. No strings are extracted yet — this
stage only adds the mechanism, so the UI is byte-identical in English.
Translations are one flat JSON file per language. An admin can add a language by
dropping <lang>.json into $MC_CONFIG_DIR/translations/ and picking it in
Settings > Appearance — no rebuild, no restart, no compile step. A drop-in file
overrides a built-in one of the same name. Built-ins: en (source) and pl.
How it works:
- app/i18n.py loads and merges catalogs over en.json, so per-key English
fallback is baked in server-side and the JS runtime needs no fallback logic.
Catalogs are fingerprinted with stat() per render, so a dropped-in file is
live on the next refresh rather than the next restart — which matters,
because restarting drops the device connection for up to 60s.
- Template text renders server-side via t()/t_html()/tn() from inject_globals(),
so the first paint is already correct. That context processor covers every
render_template() in the app, including the six standalone iframe pages, so
routes/views.py needed no changes.
- JS text comes from /i18n/<lang>.<hash8>.js, a blocking immutable script shared
by all 8 entry points. The hash is in the path, not a query string, so
intermediary caches and the service worker bust reliably.
- Language = per-browser mc_lang cookie over a server-wide DB default. The
cookie is what makes iframes work: they are same-origin, so they send it
automatically and the existing modal-open reload wiring needs no changes.
t() deliberately does not escape — Jinja autoescape handles that, and escaping
here would double-escape every French apostrophe. t_html()/tHtml() escape their
params but trust catalog markup.
Also fixed along the way:
- save_ui_settings() replaced the whole settings blob instead of merging, so a
language-only POST would have wiped the toast settings. It worked before only
because the one form always submitted every key.
- `const t = document.getElementById(...)` in populateUiSettingsForm shadowed
the global translation helper; same for `var t` in six theme IIFEs.
scripts/i18n_check.py now fails the build if that pattern comes back.
- Removed app/templates/contacts.html, dead since the contacts pages were split
(no render_template reference anywhere), and two stale CSS comments.
Verified locally: catalog route headers/security, drop-in without restart,
malformed catalogs logged and skipped rather than offered in the picker,
cookie propagation into iframes, and 360px layout. Python and JS agree on
interpolation, escaping and Polish plural categories.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/api/status is polled by every open page (on load, every 60s, and on
visibility resume) and cost ~266-450ms in-container while doing no device
I/O at all — check_connection() is just an attribute read, and /health
returns in ~1ms, so all of it was SQLite.
Two calls were over-fetching:
- get_stats() ran COUNT(*) over 11 tables to answer a question about 2.
COUNT(*) FROM echoes alone was ~200ms over 19k rows and the result was
discarded. That table only grows, so the endpoint kept getting slower.
- get_channel_messages(limit=1) was a SELECT * fetching every column,
raw_packet included, to read one timestamp. ORDER BY timestamp has no
usable index (idx_cm_channel_ts leads with channel_idx), so the plan
was a full SCAN through two temp B-trees. MAX(timestamp) is served off
that index as a covering scan instead.
Replaced with Database.get_status_summary(): three scalar subqueries on
one connection. ~371ms -> ~46ms for the DB work; endpoint median ~57ms
in-container, ~78ms from the page. Response verified byte-identical.
This does not address the multi-tab congestion — at one poll per tab per
60s /api/status was never that cause — but it removes a recurring cost
and re-baselines the probe those measurements are taken with.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every incoming echo triggers a sweep of the whole rendered message list, and
refreshMessagesMeta() awaited one /api/messages/<id>/meta per message inside
the loop. Messages that never gain a route (nothing heard them) never stop
qualifying for the sweep, so the same ~180 messages were re-fetched every few
seconds: 7,500 requests in nine minutes on a single tab, each opening its own
SQLite connections. The single-threaded werkzeug server — the same one
production runs — had no room left for anything else, so the UI hung on
"Loading messages..." / "Connecting..." while the device was in fact connected.
Add GET /api/messages/meta?ids=... resolving the whole sweep with a handful of
queries, batching the row and echo lookups, and have the client collect ids
first and fetch them in chunks. The per-message endpoint stays for forced
single refreshes; both now share _build_message_meta() and the existing
_build_channel_secrets / _get_row_pkt_payload helpers, so the payload is
unchanged (verified byte-identical against the old response).
Measured on the local container, 500 messages rendered / 181 needing meta:
one 273 ms request in place of 181 sequential ones at ~82 ms each.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The app already knew exactly which build was running - a calendar version
of commit date plus short hash - but nothing gave a release a name users
could quote, and the repo had no tags at all.
Adds a VERSION file as the single source of truth for a SemVer release
number, read by app/version.py alongside the existing build string rather
than replacing it: the number is for people, the build is for pinning down
a deploy, and both ship in /api/version and the template context. The menu
shows the release first with the build underneath. #versionText still holds
the build string, because the remote-update poller compares it to detect
that the server came back on a new build.
Resolution order is unchanged (frozen file > git > fallback), and a frozen
file written before this change still yields a correct release number, so
an already-deployed server does not need re-freezing to stay sane. The
container has no git, hence COPY VERSION into the image - otherwise a plain
'docker compose build' reports 0.0.0.
scripts/release.sh cuts a release from main: it refuses a dirty tree, a
wrong branch, a malformed number or an existing tag, extracts the notes
from the matching whatsnew section, then tags, pushes and publishes via gh.
Numbering starts at 2.1.0 rather than 1.x: the v2 line has been in
production since March and 'v1' is the archived pre-migration branch, so
1.x would have been ambiguous. Sections in whatsnew before 2.1.0 keep
their date-only headings - they were never tagged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Login retry prompt now prefills the saved password (a wrong stored
password and an unreachable repeater are indistinguishable, so a
connection-caused failure no longer forces retyping). Adds
GET /api/repeaters/<pk>/password for the trusted local UI.
- Repeater list: "last login" moves to its own line so a long path keeps
the full row width on narrow phones.
- Settings -> Location: "Pick from map" button opens a Leaflet picker;
clicking the map fills lat/lon and marks the section dirty.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace per-message get_echoes_for_message() calls (N+1, up to 500
queries per request) with a single get_echoes_for_payloads() batch
query. With connection-per-call over a Windows bind mount each query
cost ~66 ms, making the endpoint take 33 s and time out in the UI;
now it completes in ~0.5 s.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-screen iframe panel wired per the add-fullscreen-panel checklist:
- /path-analyzer Flask view + standalone template (theme bootstrap before
CSS, local vendor assets, Leaflet included for the stage-5 map view)
- path-analyzer.js: days selector (1/3/5/7), message table (time, channel,
sender, preview, copyable packet hash, hops, echo count), spinner/empty
states, local toast helpers fed from /api/ui/settings
- #pathAnalyzerModal in index.html, iframe src set on show.bs.modal for
fresh data each open; FAB button + purple gradient class
- menu entry in #mainMenu (Tools) + placement radio row in Settings ->
Appearance; registered in ITEM_PLACEMENT_DEFS/DEFAULTS (default: menu)
- style.css: #pathAnalyzerModal added to all three narrow-viewport
fullscreen-override selector lists
Verified live via Playwright at 1280px and 390px, light + dark: modal
fills the viewport exactly, placement radios move the entry both ways,
iframe reloads on every open.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- New GET /api/path-analyzer/messages?days=N endpoint: returns channel
messages from ALL channels for the last N days (clamped 1..30) with
echoes attached per message (path, snr, hash_size, direction,
received_at), channel names and packet hashes included.
- New db.get_echoes_for_payloads(): chunked IN-clause batch fetch
(<=500 params per query) instead of one query per message.
- Extracted _build_channel_secrets() and _get_row_pkt_payload() helpers
from get_messages(); /api/messages behavior unchanged (verified live:
field set identical, packet hashes and echo paths match the new
endpoint for the same messages).
- Legacy rows with uncomputable pkt_payload degrade to packet_hash null
+ empty echoes instead of being dropped.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- POST /api/repeaters/<pk>/action {action}: whitelisted one-shot commands
via repeater_cmd_wait — zerohop_advert (advert.zerohop), flood_advert
(advert), clock_sync (clock sync), reboot; admin-gated
- Replies surfaced verbatim with an ok flag (reply starts with OK), so
firmware refusals like "ERR: clock cannot go backwards" show as-is
- reboot special case: the firmware restarts without ever replying, so a
clean send followed by silence reports success ("Reboot command sent")
- Actions pane: action rows with inline result lines, flood advert
styled as warning ("Not recommended - high network load"), Danger zone
card with confirm()-guarded Reboot and a muted note that erase is only
available on the USB serial console (firmware restriction)
Verified live against PL-KRA Wegrzce 2: zero-hop advert replied
"OK - zerohop advert sent" and the advert arrived back at our device
(log: Advert from 'PL-KRA Wegrzce 2' type=2); clock sync surfaced the
firmware refusal; reboot confirm-cancel path checked in Playwright
(reboot itself intentionally not executed).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- GET/POST /api/repeaters/<pk>/settings?section=X: sequential text-CLI
get/set batches via repeater_cmd_wait; per-field values/errors on read,
per-field ok|failed|reboot_required classification on write (reply
starting ok/password now = ok, mention of reboot = reboot_required);
admin-gated via new _require_repeater_admin helper (also reused by /cli)
- Settings pane: accordion with 8 sections (Basic, Radio, Location,
Features, Network health, Advertisement, Operator info, Advanced),
lazy-loaded on first expand (each field is one mesh round-trip),
per-section Refresh/Apply, dirty tracking with header badges
- Field types: on/off switches, 0/1 switches, select (loop.detect),
composite radio (freq,bw,sf,cr) with reboot warning + confirm dialog,
write-only admin password (updates the saved password on success),
owner.info textarea with pipe-to-newline mapping
- Failed writes keep the field dirty and surface the firmware reply
(e.g. "Error: interval range is 60-240 minutes") under the input
- Strip "%" suffix when loading number fields (get dutycycle -> "70.0%")
Verified live against PL-KRA Wegrzce 2: all 8 sections read cleanly,
flood.max 64->63->64 write round-trip, firmware range rejection surfaced
per-field, radio confirm-cancel path, dutycycle % parsing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Remote text console for the managed repeater. Core mechanism:
repeater_cmd_wait() sends the command and synchronously waits for the
reply — CLI replies arrive as CONTACT_MSG_RECV txt_type=1 with no
protocol-level correlation, so correlation = repeater lock (single
command in flight) + sender-prefix match. A single-slot waiter is
checked at the top of _on_dm_received: matched CLI replies are
consumed there and never stored as chat DMs; unmatched ones (e.g.
console fire-and-forget cmd) keep the legacy DM behavior. Wait time
derives from the device-suggested timeout (10-45 s clamp).
POST /api/repeaters/<pk>/cli is admin-gated (403 for guest sessions:
firmware silently drops guest text commands, which would look like a
timeout). Pane: dark terminal styled after the Console module, quick-
command chips, Enter to send, per-repeater arrow-key history in
localStorage, elapsed-time line, inline timeout errors (lost replies
happen over radio — a manual retry typically succeeds).
Settings (stage 7) and Actions (stage 8) will reuse repeater_cmd_wait.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
List view: all zero-hop neighbours (fetch_all_neighbours paginates the
firmware's ~14-entry pages), rows show resolved contact name (or
[pubkey prefix] for unknown repeaters), heard-ago and SNR; count in
the toolbar. Names/positions are enriched server-side by prefix-
matching device contacts with the DB contact cache as fallback.
Map view (List/Map toggle, shown only when something is mappable):
Leaflet with the managed repeater as a red marker, positioned
neighbours in green, dashed connection lines labeled with permanent
SNR tooltips, and a footnote counting neighbours without a known
position. Toggle hidden entirely when no coordinates exist.
Verified live on PL-KRA Wegrzce 2: 37/37 neighbours fetched, 20
mappable, SNR labels rendered.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All Cayenne LPP channels shown at once (no channel dropdown like the
standard app): one card per channel with typed rows — icon, name,
value and unit (voltage V, temperature °C, current A, power W,
humidity %, GPS lat/lon+alt, etc.). Channel 1 is labeled 'device'
(repeater's own vitals). Refresh + updated-ago label; timeout renders
inline with a retry button (exercised for real on a 2-hop repeater —
first attempt timed out, retry succeeded with 2 channels).
Backend: repeater_req_telemetry in device_manager (serialized under
the repeater lock; the old name-only request_telemetry stays for
sensor nodes) + login-gated GET /api/repeaters/<pk>/telemetry.
GPS values arrive as {latitude, longitude, altitude} objects from
meshcore 2.3.7 — formatter handles both object and array forms.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First management tool. The Status tile auto-fetches on open and shows
a compact three-section table (not MO's oversized tiles):
- System: battery %/V (linear 3.3-4.2 V estimate), uptime, repeater
clock, queue length, debug/error events
- Radio: last RSSI/SNR, noise floor, TX/RX airtime
- Packets: sent + received (flood/direct split), duplicates, RX
errors, channel utilization computed client-side as
(tx_air+rx_air)/uptime (matches the firmware's own 10.09% reading)
Refresh button + "updated Ns ago"; errors render inline with retry.
Backend: GET /api/repeaters/<pk>/status and /clock, both gated on an
existing login session (401 need_login) to fail fast instead of a
2-min timeout. Clock loads as a follow-up request so the table
appears immediately, then the clock row fills in.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
/repeaters/manage?pubkey=... — per-repeater management panel opened
automatically after login from the My Repeaters list:
- header card: name, shortened pubkey with copy, current path,
location, ADMIN/GUEST badge from the captured login session
- tools grid (Status / Telemetry / Neighbors / CLI / Settings /
Actions) with pane placeholders; CLI+Settings+Actions are locked
for guest logins (firmware accepts text CLI from admins only)
- auto-login with the saved password when the in-memory session is
gone (e.g. after app restart), password-modal fallback with retry
- REST: GET /api/repeaters/<pk> (merged entry + session state),
GET .../session, POST .../logout
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
/api/observer/settings (GET/POST, partial updates, IATA + advert
interval validation), /api/observer/brokers CRUD (passwords never
returned; omitted password stays, empty string clears) and
/api/observer/status. Every mutating endpoint hot-reloads the
ObserverManager so config changes apply without a restart.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Letsmesh Analyzer is now a regular analyzers row, seeded once via an
app_settings flag on first startup. It can be renamed, disabled, or
deleted like any user entry. The frontend drops the special built-in
pseudo-row and the built-in slot in the chooser.
Click resolution updated: 0 enabled → toast "No analyzer configured";
1 enabled → open directly; multiple with a default → open default;
multiple without default → chooser.
The row switch and the edit modal now show "Enabled" (checked = active),
which matches intuition. The DB column remains is_disabled so no data
migration is needed — the UI simply inverts the value on read/write.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
/api/messages was dropping channel_messages.id when building the response
dict. The frontend therefore had msg.id=undefined for history-loaded rows,
so createMessageElement's "typeof msg.id === 'number'" guard suppressed
the raw-resend button, and refreshMessagesMeta couldn't find the wrappers
either (data-msg-id only gets set when msg.id is truthy). End result: the
raw-resend button only appeared on messages sent in the current session
and was lost on every channel switch or page reload.
Surfacing id costs nothing — the field already exists on the row — and
also unblocks any future per-message UI that needs to address the row
directly. createMessageElement already handles undefined id correctly for
older clients, so this is a one-way frontend benefit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
A test resend was producing 1-byte hash entries despite the device being
configured with path_hash_mode=1 (2-byte). Surfacing the cached values
in /api/status makes it possible to verify from the client whether the
device_info fetch at connect actually populated the cache, without
shelling into the container.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
CMD_SEND_RAW_PACKET (0x41) was introduced in companion-v1.16.0
(FIRMWARE_VER_CODE bump 11 → 13). Older firmware returns
ERR_CODE_UNSUPPORTED_CMD with no useful context for the user.
Capture fw_ver_code from the DEVICE_INFO event at connect (re-using the
existing send_device_query call) and expose a supports_raw_resend
property. The resend endpoint now refuses early with a clear message
("Firmware too old for raw resend, need ≥1.16, device reports
fw_ver_code=N") and /api/status surfaces both fw_ver_code and the
supports_raw_resend flag so the UI can hide or disable the button on
older firmware.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PR #3 of 5. Adds POST /api/messages/<msg_id>/resend, which re-broadcasts an
own channel message verbatim using the raw_packet bytes captured at send
time. Pushes the wire bytes directly through companion command 0x41
(CMD_SEND_RAW_PACKET), bypassing the higher-level send paths so repeaters
dedupe by packet hash via Mesh::hasSeen — only previously-unreached nodes
will pick up the resend.
Returns 404 for unknown msg_id, 400 for not-own / missing snapshot /
disconnected device, 500 for unexpected device errors.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The /api/channels/<idx>/scope route rejected idx>=8 with "Channel index
out of range (0-7)" even though current firmwares expose up to 40 slots
(send_device_query reports max_channels=40 in our logs). Users couldn't
set a region scope on channels like #ubot (idx 8) or #swietokrzyskie
(idx 15) — the UI showed the modal but Save returned 400.
Use device_manager._max_channels (set from send_device_query at connect)
as the upper bound, with 8 as a safe fallback if the DM is unreachable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Long-lived TCP against the meshcore-proxy can degrade in a way the socket
can't see: some commands (set_flood_scope_key with all-zero key) start
timing out while RX events and other commands keep working. The 5 s
execute() timeout fires with concurrent.futures.TimeoutError() — whose
str() is empty — so the UI showed "Could not set region scope (none):"
with no error text, and only channels with a mapped region could send
because their non-zero scope_key happened to keep working.
Two recovery paths:
- send_channel_message now detects the timeout case (set_flood_scope_key
surfaces timed_out=True) and runs force_reconnect() + one retry before
failing. The user sees a brief delay instead of a cryptic error and
having to restart the container.
- A new _liveness_watcher_loop task runs on the DM event loop and forces
a reconnect when no RX event has arrived for HEALTH_STRICT_MAX_RX_STALE_SEC
(5 min). /health/strict now also reports rx_stale for TCP (previously
serial/USB only), so an external watchdog could act on it too.
force_reconnect() runs on the DM loop via run_coroutine_threadsafe with
a 20 s cap, a 30 s cooldown to avoid churn under fire, and a
_reconnect_lock to prevent concurrent attempts. mc.disconnect() fires
DISCONNECTED — _intentional_disconnect tells _on_disconnected to skip
its own reconnect loop so the two don't race.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The reverse proxy fronting mc.wojtaszek.it closes idle HTTP responses
after ~30 s, so the manual Optimize endpoint timed out client-side
even though SQLite finished VACUUM and the Flask handler logged a 200.
The user saw "Optimize failed" while the DB had actually shrunk.
Split the endpoint into kickoff + polling: POST /api/db/vacuum spawns
a daemon worker thread, stores state in a module-level dict guarded by
a lock, and returns 202 immediately. GET /api/db/vacuum/status returns
{running, elapsed_seconds, ...} so the UI can poll every 2 s and show
the same "freed X bytes in Y s" toast once the worker is done. A
second POST while a VACUUM is in flight returns 409 instead of starting
a parallel rewrite.
Client polls for up to 10 minutes (300 × 2 s) before surrendering with
a "still running" warning — well past any real VACUUM duration we'd
expect, but bounded so a server-side crash can't leave the UI
spinning forever.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
SQLite DELETE marks pages free but doesn't shrink the file, so the
new retention job would keep DBs at their bloated size forever without
a follow-up VACUUM. Add db.vacuum() that runs PRAGMA-free VACUUM and
reports size_before/size_after/elapsed so callers can surface results.
The retention job now calls vacuum() automatically when it deleted at
least 1000 rows. Threshold avoids the multi-second VACUUM cost on quiet
days. Failure is logged, not raised — a missed VACUUM never crashes
the scheduler.
Power-user override: new "Optimize now" button in the Database Backup
modal triggers VACUUM on demand via POST /api/db/vacuum, alongside a
GET /api/db/size that drives the live "Current size" label. This way
users don't have to wait until 03:30 to reclaim space after the first
big retention pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The container watchdog only restarted on three legacy "device clearly dead"
log lines, so today's failure mode (firmware briefly stalls and get_stats_*
/ get_battery commands time out with an empty error while passive RX
keeps working) never tripped it — leaving the user with 10-15 s freezes
several times a day and no automatic recovery.
DeviceManager now tracks two liveness signals:
- _last_rx_at, bumped on every RX_LOG_DATA event
- _consecutive_stats_failures, incremented on get_stats_* / get_bat
exceptions and cleared on success
New /health/strict endpoint exposes these to the watchdog. It returns 503
when the device is connected but has 5+ consecutive stats failures, or
when no RX event has been seen for over 5 minutes on a serial transport.
The cheap /health endpoint keeps its lenient behavior so Docker's
healthcheck doesn't suddenly start tripping.
The watchdog's check_device_unresponsive() gains a "soft" pattern class
with a count threshold of 5 in the last 2 minutes — matching against
get_stats_core/radio/packets failed:, Failed to get battery:, and
Failed to get channel. Hard patterns still trigger on a single hit.
Deploy note: the watchdog runs as a host-level systemd service and is
NOT restarted by mcupdate, so after deploy run:
sudo systemctl restart mc-webui-watchdog.service
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The retention/cleanup scheduler was throwing "Working outside of application
context" on every boot because init_*_schedule() and the APScheduler jobs
themselves call api.get_*_settings(), which reads current_app.db. Pass the
Flask app into archiver.manager via set_flask_app() and decorate every
scheduled job with @_with_app_context so the context is active when the
worker thread runs. Wrap the init calls in main.py in app.app_context() too.
Extend cleanup_old_messages() to also delete from echoes, paths and acks
(the diagnostic tables — 191k echo rows account for the bulk of the 85 MB
DB). Each diagnostic table has its own retention window, defaulting to
min(days, 30) so debug data is purged on a tighter schedule than
user-visible messages.
Switch RETENTION_DEFAULTS to enabled=True with 90/90/60/30 days for
channel_messages/DMs/adverts/diagnostics; user opted in explicitly. First
run scheduled for 03:30 local. SQLite DELETE only marks pages free —
file size won't shrink until a manual VACUUM is run separately.
Archive job stopped working the day the device was renamed to include an
emoji ("MarWoj 💡"): the meshcore library strips non-ASCII when writing
the .msgs file, but our archiver still built /data/{device_name}.msgs and
hit ENOENT every night at 00:00. Add a tolerant fallback that globs the
data dir for a single non-archive .msgs file when the expected path is
missing — mirroring how migrate_v1 already handles this.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add a Settings > Analyzer tab letting users CRUD custom MeshCore Analyzer
services with a star-toggle default and inline disabled switch. The chart
icon under each group-chat message now resolves at click time: built-in
Letsmesh when no enabled customs, the default when set, or a chooser
modal otherwise. Backend stops shipping the prebuilt analyzer_url and
emits packet_hash instead — the frontend substitutes {packetHash} in the
chosen URL template.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
