The 'Use HTTPS' switch was disabled whenever the web client itself was
served over HTTPS, making it impossible to add a plain-HTTP node.
Keep the switch always interactive and instead show a mixed-content
warning when HTTP is selected on an HTTPS-served page.
Adds unit tests for the protocol toggle.
Dependabot's lockfile update also pulled in 8 packages published
within the minimumReleaseAge window (2 days), causing pnpm's
supply-chain policy check to fail in CI. Restore lockfile to the
parent state and apply only the minimal 4-line fast-uri change.
Co-authored-by: Hunter275 <3261295+Hunter275@users.noreply.github.com>
The root tsconfig.json referenced apps/web and packages/transport-http as
TypeScript project references, but those tsconfigs lacked the required
`composite: true` setting. Playwright 1.62.0 strictly validates tsconfig
project references when loading playwright.config.ts, causing the e2e CI
job to fail with:
Error: Failed to load tsconfig file at .../tsconfig.json:
Failed to resolve "references" path "apps/web" referenced from .../tsconfig.json
Remove the invalid references. Individual package tsconfigs already extend
tsconfig.base.json directly and remain unaffected.
* fix(randId): use crypto.getRandomValues for connection IDs
Math.random() gives ~30 bits of entropy and no cryptographic guarantees.
Switch to crypto.getRandomValues over a Uint32 buffer so device / saved-
connection IDs get full 32-bit range and don't collide across concurrent
transports.
Closes#1273
* fix: assert Uint32Array index for strict TS7 compat
Under strict + noUncheckedIndexedAccess (TS7 default), buf[0] is
number | undefined. Uint32Array(1) guarantees length 1, so assert
non-null to satisfy the number return type.
The 'Please include the following information in your report:' string
was hardcoded in the component. The matching key 'errorPage.reportInstructions'
already exists in en/ui.json — wire it up so translators actually see it.
Closes#1274
Drop the debug log inside ChannelChat's MessageSkeleton (fired on every
Suspense fallback) and gate the dev-overrides log on isDev so it stops
running at module load in prod.
Closes#1275Closes#1276
* add checks for both bluetooth and serial in the FeatureErrorMessage logic
* move the check further down and only show if neither needsSecureContext and needsFeature are empty
---------
Co-authored-by: Hunter275 <hunterthor275@gmail.com>
* fix(connections): connect to the just-added connection via the live store
addConnectionAndConnect() adds a connection and then connects to it in the
same tick, but connect() resolved the id against the memoized `connections`
closure, which is stale until the hook re-renders. The just-added id was
therefore reported as an unknown connection id and Save silently never
connected any HTTP/Serial/Bluetooth device. Read savedConnections from
useDeviceStore.getState() so the lookup always sees the live store.
* test(e2e): real-device Playwright messaging suite
Drives the actual web app in Chromium against real meshtasticd firmware over
the HTTP phone API and verifies text messaging in both directions across a
two-node mesh. Nodes mesh over the firmware's built-in UDP multicast
(224.0.0.69) with no MQTT/relay; distinct node numbers, real encryption.
- Default backend: two Docker meshtasticd sim nodes (daily-debian). The same
specs run against physical hardware via E2E_DEVICE_MODE=hardware.
- An off-browser Python meshtastic peer (e2e/peer/peer.py) drives/asserts the
non-browser node over the TCP phone API, mirroring firmware mcp-server tests.
- Coverage: connect over HTTPS, mesh->web receive, web->mesh send. Direct
messages are fixme'd (see below). CI workflow runs it on Linux.
Bugs surfaced by the suite:
- Fixed (prior commit): connect-on-save never connected (stale-closure id
lookup in useConnections).
- Not fixed: apps/web/src/core/subscriptions.ts throws 'ReferenceError:
nodeDB is not defined' on every device-metrics telemetry packet (the #1050
migration removed that store); caught per-packet, so messaging still works.
- Not fixed: direct messages are blocked by a PKI 'Keys Mismatch' (the SDK's
stored peer public key != the key presented during NodeInfo exchange), seen
even with fresh sim nodes.
* test(e2e): address Copilot review feedback
- waitForTcp(): destroy the probe socket on the error path so repeated
connection failures don't accumulate sockets/FDs across the retry loop.
- Don't remove the mesh containers in Playwright globalTeardown in CI — it
raced the workflow's failure log capture. Teardown is now gated on
E2E_DOCKER_DOWN only; CI dumps device logs on failure and tears the mesh
down in a final always() workflow step.
* fix(sdk): fold device-metrics telemetry into nodes
apps/web/src/core/subscriptions.ts called nodeDB.addDeviceMetrics() on every
device-metrics telemetry packet, but the #1050 migration removed that store —
so it threw 'ReferenceError: nodeDB is not defined' on each telemetry packet
(caught per-packet by the SDK's HandleFromRadio, so messaging still worked but
the error spammed the console).
Route device metrics into the SDK NodesClient via onTelemetryPacket instead —
mirroring the existing position handler; the Node domain already carries a
deviceMetrics field — and drop the dead app-side handler. Adds a NodesClient
test covering the fold.
* docs(e2e): accurate DM root cause + bug status
The direct-message fixme is a simulator limitation, not a web-app bug: the
keyless meshtasticd sim nodes NAK a DM with NO_CHANNEL (routing error 6) — no
Curve25519 keypair is provisioned/shared, and current firmware can't deliver a
direct message without a per-node key / decryptable channel. The app surfaces
this correctly (key-refresh dialog). Re-enable against hardware or once the sim
provisions keys.
Also: mark the nodeDB telemetry bug fixed and note the CI teardown change.
* docs(e2e): precise DM root cause (firmware/sim PKI)
Followed up on the suggestion to provision keys in config.security: the keys
ARE settable and persist (verified via admin), but on the native meshtasticd
sim they don't sync to the node's owner / NodeInfo key — owner.public_key stays
empty and the node keeps its MAC-derived num — so the two nodes never exchange
keys. Combined with the firmware refusing non-PKI DMs ('Unknown public key for
destination ... refusing to send legacy DM'), the DM is NAK'd with NO_CHANNEL.
A firmware/sim limitation; DMs work on real hardware. Spec stays fixme.
* docs(e2e): definitive DM root cause (SimRadio PKC payload limit)
Per the steer to research the firmware: PKI keygen is gated on a set LoRa
region (NodeDB.cpp:3051) and the sim boots region-UNSET — setting lora.region
via admin DOES make the nodes generate and exchange keys (verified both ways).
But a PKI-encrypted DM still can't traverse the SimRadio: the PKC overhead
exceeds its payload limit ('Payload size larger than compressed message allows!
Send empty payload'), so the packet is truncated and the receiver NAKs
NO_CHANNEL ('No suitable channel found for decoding, hash 0x0'). The firmware
skips PKC under --sim (Router.cpp:730) for exactly this reason, but --sim also
disables the config-file loading the web app needs, so they're mutually
exclusive. DMs work on real hardware; spec stays fixme with this detail.
---------
Co-authored-by: Dan Ditomaso <dan.ditomaso@gmail.com>
* chore(deps-dev): bump typescript from 5.9.3 to 6.0.3
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.9.3 to 6.0.3.
- [Release notes](https://github.com/microsoft/TypeScript/releases)
- [Commits](https://github.com/microsoft/TypeScript/compare/v5.9.3...v6.0.3)
---
updated-dependencies:
- dependency-name: typescript
dependency-version: 6.0.3
dependency-type: direct:development
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
* chore(tsconfig): align configs for typescript 6.0
Consolidate package tsconfigs to extend tsconfig.base.json and drop
options now redundant or invalid under TS 6 (strict, baseUrl,
allowImportingTsExtensions, strictNullChecks). Switch base module to
"preserve" and lib to ESNext. Fix apps/web typecheck script to invoke
tsc directly instead of recursive pnpm run tsc.
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Dan Ditomaso <dan.ditomaso@gmail.com>
#1050 (Phase C) deleted packages/core in favor of @meshtastic/sdk, but the
squash-merge hit a delete/modify conflict with #1097 (which had modified
packages/core/package.json and src/meshDevice.ts), leaving those two files
behind as a broken stub. Its package.json still declared a tsdown build
(entry: "mod.ts") while mod.ts and the rest of the source were gone, so the
'Push to Main CI' build-and-package loop failed with:
Error: Cannot find entry: "mod.ts"
Nothing depends on the workspace @meshtastic/core — the app resolves
@meshtastic/core to the JSR-published @jsr/meshtastic__core@2.6.6 — so finish
the deletion and drop the now-unused pnpm-lock importer.
Verified locally: frozen-lockfile install passes and the full build-and-package
loop builds every package green (sdk, sdk-react, sdk-storage-sqlocal, all
transports).
* feat(sdk): scaffold @meshtastic/sdk + @meshtastic/sdk-react
Adds two new packages laying the foundation for a domain-driven migration
away from @meshtastic/core.
packages/sdk
- DDD feature slices: device, chat, nodes, channels, config, telemetry,
position, traceroute, files. Each with domain/application/infrastructure/state.
- Shared kernel under core/: MeshClient orchestrator, Transport interface
(byte-compat with existing transport-* packages), EventBus (typed pub/sub),
packet codec, Queue, Xmodem, signals helpers, tslog factory.
- Signals via @preact/signals-core. Application use-cases return
Result<T,E> via better-result; legacy ports keep throwing.
- shim/ re-exports the legacy MeshDevice/Types/Utils API so
packages/web continues to build unchanged.
- createFakeTransport() under @meshtastic/sdk/testing.
- 16 vitest tests incl. end-to-end fake-transport integration.
packages/sdk-react
- MeshProvider + useSignal/useSignalValue/useClient adapters.
- Hooks: useDevice, useConnection, useChat, useNodes, useNode,
useChannels, useChannel, useConfig, useModuleConfig, useTelemetry,
usePosition, useTraceroute, useFileTransfer, useFavoriteNode, useIgnoreNode.
- jsdom-backed hook tests.
Root README rewritten with packages table, architecture, and workflow.
* refactor(web): import @meshtastic/sdk instead of @meshtastic/core
Mechanical swap across all 74 @meshtastic/core imports in packages/web/src.
The SDK's shim layer re-exports the legacy MeshDevice/Types/Utils/Protobuf
surface, so no source edits are required beyond the import path. All 294
web vitest tests still pass.
This is Phase B step 1: web now runs on @meshtastic/sdk's MeshDevice shim.
Per-slice store migrations (messageStore/nodeDBStore/deviceStore →
useChat/useNodes/useDevice etc.) land in follow-up commits.
* feat(sdk): add MeshRegistry + multi-client React providers
Phase B prep for web migration. Web holds multiple simultaneous device
connections keyed by ConnectionId, so per-slice hook migrations need a
registry-aware provider.
packages/sdk
- MeshRegistry: Map<ConnectionId, MeshClient> with signals for list/active/activeId.
create()/get()/has()/remove()/setActive().
- First-created client auto-activates.
- remove() disconnects the client and rotates active to another entry.
- 4 vitest cases covering create, auto-activate, duplicate rejection, and remove.
packages/sdk-react
- MeshRegistryProvider + MeshRegistryContext.
- useMeshRegistry, useOptionalMeshRegistry, useActiveClient, useClientById(id).
- useClient now falls back to the registry's active client when no direct
<MeshProvider> is present, so existing hooks work unchanged under a
registry-backed app.
No web-facing changes in this commit; used by follow-up slice migrations.
* refactor(sdk-react): rename useDevice → useMeshDevice
Prevents collision with packages/web's own useDevice() Zustand hook. All
internal exports + tests updated; no behavior change.
Callers migrating off @meshtastic/core should use useMeshDevice() from
@meshtastic/sdk-react going forward.
* feat(web): mount MeshRegistryProvider at app root
Introduces a single app-wide MeshRegistry in packages/web/src/core/meshRegistry.ts
and wraps the RouterProvider in <MeshRegistryProvider>. Registry starts empty;
useConnections continues to instantiate the legacy MeshDevice shim. Subsequent
slice migrations will swap useConnections over to registry.create() and move
consumers onto useMeshDevice()/useChat()/etc from @meshtastic/sdk-react.
Adds @meshtastic/sdk-react as a web dependency. No behavior change; web tests
(294) and production build still pass.
* feat(web,sdk): register per-connection MeshClient in registry
packages/sdk
- MeshRegistry.register(id, client): adopts an externally-constructed
MeshClient. Complements create() for migration paths where a legacy shim
already owns the client.
- MeshRegistry.unregister(id): drops the mapping without disconnecting, for
cases where the caller has torn down the transport itself.
- Legacy MeshDevice shim exposes its inner MeshClient as `meshClient` so
consumers can adopt it into the registry.
packages/web
- useConnections.setupMeshDevice now registers the shim's MeshClient with the
app-wide meshRegistry and marks it active on connect.
- removeConnection unregisters from the registry.
- Legacy Zustand deviceStore wiring is unchanged; follow-up commits will move
read paths to useMeshDevice/useChat etc. and remove the duplicated fields.
No behavior change visible to users. Web tests (294) + SDK tests (20) still pass.
* feat(sdk): add MessageRepository port + InMemoryMessageRepository
Lays the persistence groundwork for the chat slice migration.
- MessageRepository port defines paginated reads (loadRecent, loadBefore),
atomic writes (append, appendBatch), state updates, and retention pruning.
Conversation keyed by ConversationKey tagged union (channel | direct peer).
- RetentionPolicy: maxPerBucket + olderThanMs knobs. Consumer decides.
- InMemoryMessageRepository ships with SDK as default + test fixture.
- ChatClient accepts { repository?, retention?, initialLoadLimit? }.
Lazy-hydrates per conversation on first subscribe; writes through on every
inbound message; prunes after append when retention policy is set.
- ChatClient.loadOlder(conv, before, limit) for pagination UI.
- ChatStore.prepend() for older-first inserts.
Tests: 5 new cases for InMemoryMessageRepository (paginate, update state,
retention). 25 SDK tests total, all green. Web build unchanged.
Paves the way for @meshtastic/sdk-storage-sqlocal to implement this port
against SQLite/OPFS in a follow-up.
* feat(sdk-storage-sqlocal): SQLite WASM persistence adapters
New workspace package implementing @meshtastic/sdk repository ports against
sqlocal (SQLite WASM + OPFS) with Drizzle-typed queries.
Schema (single DB, multi-device aware via device_id column)
- messages: chat history. Indexes on (device_id, conversation_key, rx_time)
for fast pagination and on (device_id, state) for pending lookups.
- nodes: NodeDB snapshot per device (stub schema, repo lands with PR #7).
- telemetry: per-node ring buffer of readings (stub).
- _schema: migration version table.
- Hand-written DDL migrations in src/schema/migrations.ts; applied at boot.
createSqlocalDb({ databasePath })
- Opens OPFS DB, applies migrations, returns Drizzle client typed against the
schema.
- Single instance per origin; sqlocal serializes writes via OPFS file locks.
SqlocalMessageRepository
- Implements MessageRepository: paginated loadRecent / loadBefore, append /
appendBatch with onConflictDoNothing, updateState, prune (maxPerBucket via
windowed DELETE + olderThanMs).
- Optional MultiTabCoordinator broadcasts messages-changed events on append.
MultiTabCoordinator
- BroadcastChannel pub/sub for cross-tab change notifications (no-ops if API
unavailable, e.g. Node).
- acquireLock() wraps navigator.locks.request with fall-through for non-browser
contexts.
Testing
- src/testing/createMemoryDb.ts: in-memory sql.js + Drizzle, same surface as
the sqlocal connection. Lets repository tests run on Node CI.
- 6 SqlocalMessageRepository tests (pagination, retention, multi-device
isolation) + 2 MultiTabCoordinator tests pass on sql.js.
Notes
- @meshtastic/sdk pkg.json now points types at ./mod.ts so workspace consumers
resolve types directly from source. Production publish path needs a separate
follow-up to emit a stable mod.d.ts.
- Storage pkg ships ESM only; dts disabled until tsdown's hashed-name emit
is reconciled with mod.d.ts resolution. Workspace consumption already gets
full types from source.
* feat(web): persist chat history via @meshtastic/sdk-storage-sqlocal
Plumbs the SDK chat slice through the OPFS-backed SQLite repository so
inbound and outbound text messages survive page reloads, with retention
capped at 1000 messages per conversation or 90 days, whichever hits first.
- packages/sdk legacy MeshDevice shim now accepts MeshClientOptions
(chat, configId, logger). Backwards-compatible with the old
`new MeshDevice(transport, configIdNumber)` form.
- packages/web/src/core/sdkStorage.ts: lazy singletons for the shared
SqlocalDb and the cross-tab MultiTabCoordinator. The DB opens on first
call so test runs that never connect stay headless-safe.
- useConnections.setupMeshDevice is now async, awaits getStorageDb, and
passes a SqlocalMessageRepository scoped to the connection id. Falls
back to the SDK's InMemoryMessageRepository if sqlocal init fails (no
OPFS support, etc.).
- Vite worker format set to "es" because sqlocal's worker is ES-module
and rolldown rejects iife with code-splitting.
- COOP/COEP dev headers were already in vite.config.ts; no further
changes required for OPFS.
Web tests (294) and production build still green.
This is the runtime payoff of PR #5: a fresh page load populates chat from
SQLite via lazy pagination instead of rehydrating 1000 messages into memory.
The legacy Zustand messageStore is still in place for now; PR #6 (chat
slice migration) will retire it and switch UI components to useChat.
* test: testing strategy + 19 new SDK / storage / hook tests
Adds TESTING.md documenting six tiers (unit / slice / client / storage /
hook / E2E), per-package coverage gates, and the audit of where we
currently sit.
Slice tests in @meshtastic/sdk
- NodeMapper proto round-trip; NodesClient list signal updates.
- ChannelsClient indexes by channel number.
- ConfigClient merges Config + ModuleConfig variants.
- TelemetryClient latest + history per node.
- PositionClient byNode + list.
- ChatClient persistence: hydrate on first subscribe, paginate via
loadOlder, persist inbound messages through the repository. Fixes a
reverse-iteration bug in loadOlder discovered by the new test.
Hook tests in @meshtastic/sdk-react
- New tests/hooks.registry.test.tsx covers useMeshDevice, useNodes,
useNode, useChannels under <MeshRegistryProvider>, plus an active-
client switch round-trip.
Storage tests in @meshtastic/sdk-storage-sqlocal
- migrations.test.ts validates v1 DDL creates messages/nodes/telemetry/
_schema and indexes; CREATE IF NOT EXISTS is idempotent.
- MultiTabCoordinator.broadcast.test.ts proves cross-tab BroadcastChannel
delivery between two coordinators in the same process.
- New vitest.browser.config.ts + tests/sqlocal-opfs.browser.test.ts run
under @vitest/browser (Playwright provider) for real OPFS round-trip
verification. Wired as `pnpm test:browser`. Browser test files end in
`.browser.test.ts` and are excluded from the Node runner.
E2E / firmware-simulator tier (TESTING.md §"E2E / simulator") is scoped
for a follow-up — needs CI Docker for meshtasticd.
Totals after this change:
- @meshtastic/sdk: 36 tests (was 25)
- @meshtastic/sdk-react: 8 tests (was 2)
- @meshtastic/sdk-storage-sqlocal: 12 tests (was 8)
- meshtastic-web: 294 tests (unchanged)
* feat(web): MessagesPage reads chat history from SDK / SQLite
Adds an adapter hook that bridges sdk-react's `useChat` and `useDirectChat`
to the legacy `Message` shape MessagesPage / ChannelChat / MessageItem
expect. The page now renders messages directly from the OPFS-backed
SqlocalMessageRepository — page reload hydrates lazily (last 50 per
conversation) instead of pulling 1000+ rows from IndexedDB into memory.
packages/sdk-react
- useChat() gains loadOlder(before, limit) for paginated backfill.
- New useDirectChat(peer) hook covering DM conversations.
packages/web
- src/core/hooks/useChatLegacy.ts: maps SDK `Message` → legacy
`messageStore/types.ts` Message shape, including state translation
(SDK Pending → legacy Waiting).
- MessagesPage flips broadcast and direct chat reads to useChatLegacy.
getMessages call sites removed; setMessageState retained on the legacy
store for outbound bookkeeping until the next migration step.
Drafts, unread counts, activeChat / chatType continue to live in the
Zustand messageStore — they are UI-only state and stay where they are
per the locked architecture decision. The legacy store's saveMessage,
getMessages, setMessageState, and persistence path remain in place for
now; PR cleanup follow-up will retire them once outbound state and
"delete all messages" flows are switched to the SDK.
Web test suite: 294 still green. Production Vite build clean.
* feat(web): MessagesPage outbound send through SDK ChatClient
Switches the send-text path from `connection?.sendText(...)` (legacy
MeshDevice) to `client.chat.send({ text, destination, channel })` on the
active MeshClient pulled from MeshRegistry via useActiveClient().
Side effects:
- Outbound message state (Ack / Failed) is now driven entirely by the
SDK chat slice via routing-packet subscriptions; the manual
setMessageState calls are removed.
- The legacy Zustand `useMessages().setMessageState` and `MessageState`
imports are no longer used by MessagesPage. Drafts and unread counts
still live in the Zustand store.
- `getMyNode` is no longer needed in this page (was only used to label
the now-removed direct-message state updates).
Web tests (294) still green; production Vite build clean.
* feat(sdk,web): drafts persisted in SDK chat slice (SQLite-backed)
Moves per-conversation draft text out of the legacy Zustand messageStore
into the SDK chat slice so drafts share the same persistence + signal
machinery as messages. MessageInput now binds directly to the SDK; the
legacy `useMessages().getDraft/setDraft/clearDraft` API is no longer
called from the input.
packages/sdk
- New DraftRepository port + InMemoryDraftRepository default.
- ChatClient.drafts namespace: get(key) returns a ReadonlySignal<string>;
set/clear keyed by ConversationKey.
- ChatClient.send auto-clears the draft for the resolved conversation on
success (parity with prior Zustand clearDraft-on-send behavior).
- Lazy hydrate from the DraftRepository on first read of a conversation.
- 3 new tests in ChatClient.drafts.test.ts.
packages/sdk-react
- New useDraft(conversation) hook returning { text, setText, clear }.
packages/sdk-storage-sqlocal
- New `drafts` table (device_id + conversation_key composite PK, text,
updated_at). Drizzle schema in src/schema/drafts.ts.
- Migration v2 in src/schema/migrations.ts creates the table on first
open of an existing v1 DB.
- SqlocalDraftRepository implementing DraftRepository: load/save/clear/
loadAll, scoped by device_id, upsert on conflict, delete on empty save.
- 6 new tests covering save/load round-trip, empty-string deletion,
upsert, multi-device isolation, loadAll.
packages/web
- useConnections wires the SqlocalDraftRepository alongside the existing
SqlocalMessageRepository per registered MeshClient.
- MessageInput accepts `conversation: ConversationKey` instead of the
prior `to: Types.Destination` — fixes the legacy bug where every
broadcast channel shared a single draft slot.
- MessagesPage passes the appropriate ConversationKey for direct/
broadcast chats.
- MessageInput.test.tsx rewritten to mock useDraft from sdk-react.
Test counts: sdk 39 (+3), sdk-storage-sqlocal 18 (+6), web 294 unchanged.
Production Vite build clean.
* chore(web): drop saveMessage path from subscriptions, delete dead DTO
The SDK chat slice now persists every inbound/outbound text packet via the
SqlocalMessageRepository wired in useConnections, so the legacy Zustand
saveMessage path in subscriptions.ts was writing to a store no UI code
reads from.
- subscriptions.ts: removed saveMessage call + PacketToMessageDTO usage.
Unread-count increments retained as-is (cross-cutting concern, migrates
in a separate commit).
- subscribeAll's messageStore parameter retained as `_messageStore` for
callsite stability while the rest of the legacy store is being retired.
- Deleted packages/web/src/core/dto/PacketToMessageDTO.ts (no remaining
consumers; SDK has its own MessageMapper at
packages/sdk/src/features/chat/infrastructure/MessageMapper.ts).
Web tests (294) still green; production build clean.
Out of scope, queued:
- useConnections refactor (the hook is overdue for cleanup)
- Strip dead methods from the Zustand messageStore (saveMessage,
getMessages, setMessageState, getDraft, setDraft, clearDraft +
Zustand-persist + IDB wrapper). Requires a follow-up sweep of the
remaining test files that mock those methods.
- Migrate unread counts to the SDK (cross-cutting between chat + nodes).
* feat(sdk,web): ChatClient.clearConversation + clearAll; wire DeleteMessagesDialog
Rounds out the chat slice with destructive operations so the UI dialog no
longer needs the legacy Zustand deleteAllMessages.
packages/sdk
- MessageRepository port gains clearConversation(key); InMemory and
Sqlocal adapters implement it (SQL: scoped DELETE by conversation).
- ChatStore gains clearBucket(key) + clearAll().
- ChatClient.clearConversation(conv) and ChatClient.clearAll(): empty the
in-memory store, drop the hydrated-marker so a future subscribe
re-fetches fresh, then delete from the repository. Repository failures
are swallowed — UI must not get stuck behind a write error.
packages/sdk-storage-sqlocal
- SqlocalMessageRepository.clearConversation: DELETE FROM messages WHERE
(device_id, conversation_key) match.
packages/web
- DeleteMessagesDialog swaps useMessages().deleteAllMessages for
useActiveClient()?.chat.clearAll(). No-active-client path is a no-op
but still closes the dialog.
- Test file updated: mocks useActiveClient; new case covers
no-active-client safety.
Totals: sdk 39 tests unchanged (clearConversation tested transitively via
DeleteMessagesDialog; adapter-specific test queued for follow-up),
sdk-storage-sqlocal 18 unchanged, web 295 (+1).
* feat(sdk,sdk-storage-sqlocal,web): NodesRepository port + SQLite persistence
Adds SDK-side node persistence so a fresh page load rehydrates the mesh
NodeDB from disk before any device packets arrive. Web's existing Zustand
nodeDBStore continues to work unchanged in parallel — UI consumer
migration to useNodes/useNode lands in follow-up commits.
packages/sdk
- New NodesRepository port: loadAll / get / upsert / upsertBatch / remove /
clear. InMemoryNodesRepository ships as the default.
- NodesClient takes optional { repository }, hydrates on construction,
writes through on every onNodeInfoPacket, and keeps live signal +
persistence in lockstep. remove/reset clear the repository alongside the
store + drive the legacy admin message.
- MeshClientOptions exposes a `nodes` slot mirroring the existing `chat`
slot.
packages/sdk-storage-sqlocal
- New SqlocalNodesRepository implementing the port. user / position /
deviceMetrics serialized as base64-encoded protobuf bytes (stable
across schema additions). Subpath export at "@meshtastic/sdk-storage-
sqlocal/nodes".
- 6 vitest cases covering upsert + loadAll round-trip, overwrite, proto
round-trip preserves user fields, remove, clear, multi-device isolation.
packages/web
- useConnections opens a SqlocalNodesRepository alongside the chat /
draft repos and passes it to the new MeshDevice constructor.
Test counts: sdk 39 (unchanged — repo round-trip exercised in storage
adapter tests), sdk-storage-sqlocal 24 (+6), web 295 unchanged. Build
clean.
* feat(sdk,web): SDK Node carries hops/mqtt/key-verified; legacy adapter hook
Lays the groundwork for migrating web's 31 nodeDB consumers off the
Zustand `useNodeDB().getNodes/getNode` API onto SDK signals, without a
big-bang rewrite.
packages/sdk
- Node domain entity gains channel, viaMqtt, hopsAway, isKeyManuallyVerified
fields. NodeMapper.fromProto now copies these from the inbound
Protobuf.Mesh.NodeInfo. Required so downstream UIs that show "X hops
away" / "via MQTT" / "encryption verified" can read SDK nodes without
losing fidelity.
packages/web
- New core/hooks/useNodesLegacy.ts: useNodesLegacy() returns
Protobuf.Mesh.NodeInfo[] derived from SDK signals; useNodeLegacy(num)
returns a single NodeInfo. Components migrate one at a time by swapping
useNodeDB().getNodes / getNode call sites for these hooks; templates
stay unchanged because the result shape matches.
No consumer rewrites in this commit — that is per-component follow-up
work to keep diffs reviewable. Web tests (295) still green; production
build clean. SDK 39 / sdk-storage-sqlocal 24 unchanged.
* refactor(web): NodesPage reads node list from SDK signals
First consumer migration off the legacy Zustand nodeDBStore onto
SDK-managed nodes. Pages/Nodes/index.tsx now pulls the full node array
through useNodesLegacy() — which subscribes to the SDK NodesClient
signal underneath — and applies the existing nodeFilter predicate
client-side via useMemo.
Behavior parity:
- Same Protobuf.Mesh.NodeInfo shape rendered in the table (the legacy
adapter ensures channel / viaMqtt / hopsAway / publicKey survive).
- Same debounce semantics — only the underlying source changed.
- hasNodeError + nodeErrors continue to come from the Zustand
nodeDBStore until PKI-error tracking is migrated to the SDK in a
follow-up commit (validation logic still in
packages/web/src/core/stores/nodeDBStore/nodeValidation.ts).
The legacy nodeDBStore still populates from subscriptions.ts, so this
rewrite is reversible and runs alongside the SDK source. Web tests
(295) still green; production Vite build clean.
* refactor(web): migrate 9 nodeDB consumers onto SDK adapter
Sweeps the most-touched UI paths off useNodeDB().getNode/getMyNode/getNodes
and onto the useNodesLegacy / useNodeLegacy / useMyNodeLegacy adapters
introduced earlier. Behaviour parity preserved — the adapter returns the
same Protobuf.Mesh.NodeInfo shape components already render.
Migrated:
- components/Sidebar.tsx — myNode + node count from SDK signals.
- components/CommandPalette/index.tsx — node lookup for connection labels.
- components/UI/Avatar.tsx — single-node lookup.
- components/Dialog/RemoveNodeDialog.tsx — selected node display.
- components/Dialog/PKIBackupDialog.tsx — myNode for download/print headers.
- components/Dialog/LocationResponseDialog.tsx — sender lookup.
- components/Dialog/TracerouteResponseDialog.tsx — endpoint lookups.
- components/Dialog/NodeDetailsDialog.tsx — selected node detail.
- components/PageComponents/Settings/User.tsx — myNode for owner edit.
- components/PageComponents/Settings/Position.tsx — myNode for current position.
- components/PageComponents/Messages/TraceRoute.tsx — hop name lookup.
- components/PageComponents/Messages/MessageItem.tsx — myNode (suspending) +
message author. The polling Suspense fallback now retriggers on the SDK
signal instead of polling the Zustand store directly.
- components/PageComponents/Map/Popups/WaypointDetail.tsx — locked-to node.
- pages/Messages.tsx — sidebar node list + selected peer lookup.
- pages/Map/index.tsx — full filtered list + myNode for fitting. Drops the
now-dead NODEDB_DEBOUNCE_MS constant since the SDK signal layer handles
re-render coalescing internally.
- TraceRoute.test.tsx mocks updated to mock useNodesLegacy instead of
useNodeDB.
NodesLayer.tsx, RemoveNodeDialog (removeNode), ResetNodeDbDialog, and
RefreshKeysDialog still depend on hasNodeError / removeNode /
removeAllNodes on the legacy nodeDB store — those move when PKI-error
tracking and the admin-message paths are migrated to the SDK in the
unread/cleanup follow-up.
Web tests: 295 still green; production Vite build clean. No SDK changes
in this commit.
* refactor(web): rename node legacy adapters to *AsProto
The "Legacy" suffix on the node-adapter hooks reads as if the hook
itself is deprecated, when in fact the hook is the bridge: it converts
SDK Node domain entities into Protobuf.Mesh.NodeInfo so consumer
templates that destructure proto fields keep working during the
migration.
- useNodesLegacy → useNodesAsProto
- useNodeLegacy → useNodeAsProto
- useMyNodeLegacy → useMyNodeAsProto
- File renamed to packages/web/src/core/hooks/useNodesAsProto.ts.
All 16 call sites updated. Test mock in
packages/web/src/components/PageComponents/Messages/TraceRoute.test.tsx
updated to the new module path.
Behaviour unchanged. 295 tests still green; production Vite build clean.
(useChatLegacy follows the same pattern but maps to a hand-written web
type, not a proto — it stays as-is for now and is queued for renaming
once the broader chat-store cleanup lands.)
* refactor(web): useFavoriteNode + useIgnoreNode drive SDK NodesClient
The favorite/ignore admin-message paths now go through the SDK NodesClient
instead of the legacy Zustand sendAdminMessage + manual proto build.
- useFavoriteNode: meshClient.nodes.favorite(nodeNum) /
meshClient.nodes.unfavorite(nodeNum). The SDK already has
FavoriteNodeUseCase + AdminMessageSender behind these APIs.
- useIgnoreNode: meshClient.nodes.ignore / .unignore.
- Both still mirror the optimistic flag flip into the legacy nodeDB store
via updateFavorite / updateIgnore until that store is fully retired —
same TODO as before, "wait for ack before flipping".
Tests rewritten to mock @meshtastic/sdk-react via vi.hoisted (so the
factory captures the spy without hitting the vi.mock hoist trap):
- assert SDK favorite/unfavorite/ignore/unignore calls
- assert legacy store mirror still fires
- assert toast + longName fallback behaviour preserved
- assert no-op when the node isn't in the SDK store yet (parity with
the prior "getNode returned undefined" guard)
Web tests: 295 still green; production Vite build clean.
* refactor(web): ResetNodeDb + RefreshKeys dialogs read SDK; safer adapter
- ResetNodeDbDialog: connection.resetNodes() → meshClient.nodes.reset();
on success it now also calls meshClient.chat.clearAll() instead of the
legacy useMessages().deleteAllMessages(). PKI-error tracking and the
in-memory nodeDB still get cleared via removeAllNodeErrors /
removeAllNodes since those subsystems have not yet migrated. Test
rewritten to mock useActiveClient via vi.hoisted.
- RefreshKeysDialog: drops useNodeDB().getNode in favour of
useNodeAsProto for the missing-key node display. Test wraps render in
a MeshRegistryProvider with an empty registry so the adapter resolves
cleanly with no active client.
Adapter hardening (useNodesAsProto.ts)
- Switched off useNodes() / useMeshDevice() (which both throw outside a
MeshProvider/MeshRegistryProvider with an active client) onto
useActiveClient() + a no-op signal fallback. The hooks now return [] /
undefined when there is no active client instead of throwing, which
fixes RefreshKeysDialog's "no error → render null" path under tests
that don't connect a device.
Web tests: 295 still green; production Vite build clean.
* feat(sdk,sdk-react,web): node PKI / routing-error tracking on the SDK
Moves PKI mismatch / duplicate-key validation and routing-error tracking
out of the legacy Zustand nodeDBStore and into the SDK NodesClient so
every consumer reads the same source of truth. Validates Android's gap
analysis: Meshtastic-Android does not track per-node PKI errors at all,
so the SDK must own this concern client-side.
packages/sdk
- New NodeError + NodeErrorType (Routing_Error | "MISMATCH_PKI" |
"DUPLICATE_PKI"). Mirrors the previous web-only types.
- New nodeValidation infrastructure mapper (pure): byte-equal compare on
publicKey, returns ValidatedNodeInfo { accepted?, error? }. Ports the
detection rules verbatim from
packages/web/src/core/stores/nodeDBStore/nodeValidation.ts.
- NodesClient gains an errors signal + errorFor / hasError / setError /
clearError / clearAllErrors API. handleIncoming runs validation before
upserting; conflicts skip the store write and record an error. A clean
refresh of a previously-flagged node clears the error.
- handleRoutingPacket records PKI_UNKNOWN_PUBKEY / PKI_FAILED /
PKI_SEND_FAIL_PUBLIC_KEY / NO_CHANNEL against packet.from.
- 5 new vitest cases covering MISMATCH_PKI, DUPLICATE_PKI, error-clear-on-
refresh, routing-error capture, clearError / clearAllErrors. SDK total:
44 tests, all green.
packages/sdk-react
- New useNodeErrors / useNodeError(num) / useHasNodeError(num) hooks.
All resolve through useActiveClient() and fall back to empty when no
client is present.
packages/web
- pages/Nodes/index.tsx, pages/Messages.tsx, components/PageComponents/
Map/Layers/NodesLayer.tsx swap useNodeDB().hasNodeError for the SDK
useNodeErrors hook + a memoised Set lookup.
- components/Dialog/RefreshKeysDialog/RefreshKeysDialog.tsx reads the
current error from useNodeError(activeChat); useRefreshKeysDialog.ts
drives meshClient.nodes.clearError + meshClient.nodes.remove instead
of the legacy store. The companion test still passes through the
empty-MeshRegistry render path because useNodeError tolerates a
missing active client.
- core/subscriptions.ts no longer calls nodeDB.setNodeError on PKI /
no-channel routing packets — the SDK records those itself. The dialog
open trigger stays here.
- pages/Nodes/index.tsx drops the now-dead NODEDB_DEBOUNCE_MS constant.
Web tests: 295 still green; production Vite build clean. The legacy
nodeDB still runs its internal validation but its error map is now a
dead end — removal queued in the plan-file follow-up alongside the rest
of the nodeDB cleanup.
* chore(web): remove dead PKI / nodeError paths from legacy nodeDB
Now that the SDK NodesClient owns public-key validation and per-node
error tracking, the legacy Zustand mirrors are dead code.
packages/web/src/core/stores/nodeDBStore/index.ts
- Drops the nodeErrors map + setNodeError / getNodeError / hasNodeError /
clearNodeError / removeAllNodeErrors methods from the NodeDB interface
and factory.
- Drops the validateIncomingNode call inside addNode and inside
setNodeNum's merge path; legacy mirror is now a straight last-write-
wins shallow merge. The SDK runs validation independently against its
own snapshot.
- Drops the nodeErrors entries from the persisted partialize shape.
packages/web/src/core/stores/nodeDBStore/types.ts
- Removes NodeError + NodeErrorType. ProcessPacketParams stays.
packages/web/src/core/stores/nodeDBStore/nodeValidation.ts — deleted
(SDK ports it at packages/sdk/src/features/nodes/infrastructure/
nodeValidation.ts and exposes the verdict via NodesClient).
packages/web/src/core/stores/index.ts — drop the dead NodeErrorType
re-export.
packages/web/src/core/stores/nodeDBStore/nodeDBStore.test.tsx
- Removes tests covering the migrated PKI behaviour (errors map,
MISMATCH, DUPLICATE, "unions nodeErrors") — equivalent coverage now
lives in packages/sdk/src/features/nodes/NodesClient.errors.test.ts.
- Trims the surviving merge-semantics tests to the simpler last-write-
wins shape.
- The "selector re-renders" test swaps the deleted setNodeError mutation
for an updateFavorite call to keep the slice-stability assertion alive.
- The "addNodeDB instance identity" assertion relaxes from .toBe to
content equality — immer's pruneStaleNodes path can reseat the entry,
but the registered DB's id stays stable.
components/Dialog/ResetNodeDbDialog/ResetNodeDbDialog.tsx — calls
meshClient.nodes.clearAllErrors() instead of the legacy
removeAllNodeErrors. Test mocks updated.
components/Dialog/RefreshKeysDialog/* — already migrated to SDK errors
in the previous commit; no further changes here.
Test counts: web 290 (was 295 — 5 PKI-tracking tests retired in
favour of 5 equivalent SDK tests). Production Vite build clean.
* feat(sdk,web): SDK NodesClient owns user/position/lastHeard/snr +
favourite-flag flips; legacy mirror retired
The SDK NodesClient now subscribes to onUserPacket / onPositionPacket /
onMeshPacket so user-record updates, GPS updates, and lastHeard / snr
refreshes flow into the signal-backed store + repository directly. The
favourite / ignored toggles also flip the local flag once the admin
message resolves successfully, so the UI no longer needs to mirror the
state into a parallel Zustand store.
packages/sdk
- NodesClient: new private patch(num, partial) helper that shallow-
merges into the existing entry (or seeds a placeholder Node) and
upserts to the repository in one shot. Used by:
- onUserPacket → patch user
- onPositionPacket → patch position
- onMeshPacket → patch lastHeard / snr (replaces the legacy nodeDB
processPacket flow)
- favorite / unfavorite / ignore / unignore — flag flip on Result.ok
- NodesClient.reset({ keepMyNode? }) — preserves the local node entry
when requested. Mirrors the previous removeAllNodes(true) semantics
the ResetNodeDb dialog relied on.
packages/web
- core/subscriptions.ts: drops the onUserPacket / onPositionPacket /
onNodeInfoPacket / onMeshPacket → legacy nodeDB write paths. The
unused nodeDB parameter is renamed `_nodeDB` for callsite stability;
it will disappear when the store itself is deleted in a follow-up.
- core/hooks/useFavoriteNode + useIgnoreNode: drop the legacy
updateFavorite / updateIgnore mirror — the SDK flips the flag on
success.
- components/Dialog/RemoveNodeDialog: now calls meshClient.nodes.remove
exclusively; no legacy fall-through.
- components/Dialog/ResetNodeDbDialog: calls
meshClient.nodes.reset({ keepMyNode: true }) and meshClient.chat.clearAll().
No legacy nodeDB calls.
- Test mocks for useFavoriteNode / useIgnoreNode / ResetNodeDbDialog
pruned to match.
Test counts: sdk 44 (unchanged), sdk-react 8, sdk-storage-sqlocal 24,
web 290. Production Vite build clean.
Remaining surface on the legacy nodeDB: addNode / addUser / addPosition /
processPacket / setNodeError-equivalent are now unused; the store retains
only updateFavorite / updateIgnore (no callers) and the per-device
plumbing required by the deviceContext hooks. Full deletion of
nodeDBStore queued in the plan-file follow-up.
* chore(web): drop leftover useNodeDB from Position settings page
useMyNodeAsProto already replaces getMyNode here; the import was left
behind during the nodeDB mirror retirement.
* chore(web): delete legacy nodeDBStore — SDK NodesClient is the only source of truth
The Zustand nodeDBStore had no remaining writers (the mirror in
subscriptions.ts was retired in 005d0000) and no remaining readers
outside of bookkeeping (addNodeDB / setNodeNum / removeNodeDB calls
that fed nothing). Drop the whole store along with its persistence
shim and the persistNodeDB feature flag.
- Delete packages/web/src/core/stores/nodeDBStore/.
- Drop the _nodeDB parameter from subscribeAll; it was unused.
- Drop addNodeDB / useNodeDBStore wiring from useConnections; the
meshDeviceId reuse check now keys off the device store instead.
- useNewNodeNum no longer pokes the nodeDB.
- FactoryResetDeviceDialog drops its removeNodeDB call (and the test
drops the matching expectation).
- Strip persistNodeDB / VITE_PERSIST_NODE_DB from featureFlags +
dev-overrides.
- Remove the useNodeDB / useNodeDBStore re-exports + the
bindStoreToDevice wiring from core/stores/index.ts.
* chore(web): retire Zustand messageStore — keep only Message types/enums
The persisted message Zustand store had no remaining consumers — chat
history, drafts, and message state all live on the SDK ChatClient
(SqlocalMessageRepository). The messageStore Zustand surface
(saveMessage, getMessages, setMessageState, getDraft, setDraft,
clearDraft, deleteAllMessages, clearMessageByMessageId, plus the
addMessageStore / removeMessageStore / getMessageStore / setNodeNum
plumbing) is now fully unused.
Collapse messageStore/index.ts to just the MessageState / MessageType
enums + the legacy `Message` shape that the useChatLegacy adapter and a
couple of message components still consume. Delete the Zustand
implementation and its 32-test suite.
Other knock-on cleanups in this commit:
- Drop the _messageStore param from subscribeAll (unused after the
saveMessage-from-subscriptions retirement).
- Drop addMessageStore wiring from useConnections, removeMessageStore
from FactoryResetDeviceDialog, setNodeNum from useNewNodeNum.
- Drop the message branch from the router context (no readers).
- RefreshKeysDialog stops keying off `useMessages().activeChat` (which
was permanently 0 — a dead handle that quietly broke key-refresh
UX). Use the SDK NodesClient's first error directly via
`useNodeErrors()[0]`. The dialog manager already opens the dialog on
PKI_UNKNOWN_PUBKEY, so picking the first error matches the intended
flow.
* chore(web): rename useChatLegacy → useChatAsLegacyMessages
The "legacy" suffix on its own read like the hook itself was deprecated;
the actual purpose is "use SDK chat history but project it into the
legacy Message shape." Rename for clarity. Companion type names follow
suit (UseChatAsLegacyMessages{Broadcast,Direct,Params}).
* feat(sdk-react,web): migrate read-only channel consumers to SDK ChannelsClient
Phase one of the channels-slice migration (PR #8 in plan). Moves the
non-changeRegistry-coupled consumers off the legacy deviceStore.channels
Map onto the SDK signal-backed ChannelsClient.
- sdk-react useChannels: switch from useClient to useActiveClient and
fall back to an empty signal when no client is active. Matches the
no-throw pattern already used by useNodes / useNodeErrors so isolated
component tests and pre-connect renders don't throw.
- Messages.tsx reads channels via useChannels(); filteredChannels is
derived with useMemo, currentChannel via .find(). The SDK Channel
shape (index/role/settings) matches everything this page touches.
- QRDialog reads channels directly via useChannels(); the channels Map
prop is dropped from QRDialogProps + DialogManager.
- getChannelName loosens its parameter type to the SDK-compatible
subset { index, settings?: { name? } } so it accepts both proto
Channel and SDK Channel without conversion.
Channels.tsx, ImportDialog and Settings/index.tsx still read from the
deviceStore — they are coupled to changeRegistry / setChange and will
move with PR #9 (ConfigEditor).
* feat(sdk,sdk-react): scaffold ConfigEditor for the radio/module/channels edit flow
Replaces the (broken) web changeRegistry with a section-grain editor that
lives on the SDK. Per-connection state, signal-backed, exposed via
client.config.editor.
ConfigEditor (domain):
- baseline = what the device most recently sent. Updated automatically
from onConfigPacket / onModuleConfigPacket / onChannelPacket.
- working = UI edits. setRadioSection / setModuleSection / setChannel.
- dirtyRadioSections / dirtyModuleSections / dirtyChannels signals plus
an aggregate isDirty signal.
- Inbound baseline updates do NOT discard pending working changes — if a
section is already dirty, the new baseline is recorded but working stays
put; dirty bookkeeping recomputes against the updated baseline.
- reset() restores working = baseline.
- commit() wraps beginEditSettings → setConfig per dirty radio variant +
setModuleConfig per dirty module variant + setChannel per dirty channel
→ commitEditSettings, then optimistically promotes working to baseline.
- Disconnect clears both baseline and working so a stale working copy can
never leak across reconnects.
Domain types:
- RadioConfig and ModuleConfig are now derived directly from the proto
Config / ModuleConfig payloadVariant union (Extract<{case: V}> shape) so
new variants stay typed without manual list maintenance. This adds
deviceUi (radio) and statusmessage (module) automatically.
sdk-react:
- New useConfigEditor() hook returns the editor for the active client, or
undefined when no client is active. Components subscribe to the editor's
signals via the existing useSignal helper.
Tests:
- 5 new ConfigEditor tests covering: clean start, dirty tracking, multi-
section dirty, reset, mid-edit baseline update preservation, and
disconnect-clears-state. SDK suite 49 passing.
This commit is scaffolding only — no web settings page rewires yet. The
~25 settings pages move to editor.set* / editor.commit() in follow-up
commits, replacing setChange / commitEditSettings call sites and unblocking
deletion of changeRegistry from the device store.
* feat(web): pilot Position / LoRa / MQTT pages on ConfigEditor; Android-aligned layout + labels
First three settings pages migrated off the legacy changeRegistry to the
SDK ConfigEditor. Section structure, field order, and visible strings
are taken from the Meshtastic-Android source of truth so the web and
mobile UIs converge.
Position (radio config):
- Four cards in Android order: Position Packet → Device GPS → Position
Flags → Advanced Device GPS.
- Card 1 fields: positionBroadcastSecs, positionBroadcastSmartEnabled,
broadcastSmartMinimumIntervalSecs (renamed "Smart Interval"),
broadcastSmartMinimumDistance ("Smart Distance").
- Card 2 fields: fixedPosition, lat/lng/altitude (when fixed), gpsMode
("GPS Mode (Physical Hardware)"), gpsUpdateInterval ("GPS Polling
Interval"). gpsMode + gpsUpdateInterval disable when fixedPosition is
on; lat/lng/altitude disable when it's off.
- Card 3 fields: positionFlags multiselect (description from Android).
- Card 4 fields: rxGpio ("GPS Receive GPIO"), txGpio ("GPS Transmit
GPIO"), gpsEnGpio ("GPS EN GPIO").
- onSubmit now calls editor.setRadioSection("position", payload). The
setFixedPosition admin message path is unchanged.
LoRa (radio config):
- Two cards: Options + Advanced (was three: Mesh / Waveform / Radio).
- Options: region, usePreset, modemPreset (when usePreset),
bandwidth/spreadFactor/codingRate (when !usePreset).
- Advanced: ignoreMqtt, configOkToMqtt, txEnabled, overrideDutyCycle,
hopLimit (now "Number of Hops", select 0..7), channelNum,
sx126xRxBoostedGain ("RX Boosted Gain"), overrideFrequency
("Frequency Override"), txPower.
- Drop frequencyOffset (Android does not surface it).
- onSubmit calls editor.setRadioSection("lora", payload).
MQTT (module config):
- Two cards: MQTT Config + Map reporting (new card).
- Card 1: enabled ("MQTT enabled"), address, username, password,
encryptionEnabled, jsonEnabled, tlsEnabled, root ("Root topic"),
proxyToClientEnabled.
- Card 2: mapReportingEnabled, mapReportSettings.shouldReportLocation
(consent gate, "I agree."), positionPrecision (12-15 buckets),
publishIntervalSecs ("Map reporting interval (seconds)").
- positionPrecision + publishIntervalSecs disable until both
mapReportingEnabled and shouldReportLocation are true.
- onSubmit calls editor.setModuleSection("mqtt", payload).
- Validation schema gains shouldReportLocation; address/username/
password limits widened to 63 to match proto, root capped at 31.
Settings/index.tsx handleSave:
- After the legacy changeRegistry flow, runs editor.commit() when the
editor is dirty. Two beginEdit/commitEdit windows are fine — the
device handles them sequentially. Once the rest of the settings pages
migrate, the legacy flow goes away and only editor.commit() remains.
- Save button gating includes editor.isDirty so users can save
ConfigEditor-only changes (e.g. just a LoRa region tweak).
i18n:
- New section labels (config.json position.{positionPacket,deviceGps,
advancedDeviceGps}; lora.{optionsCard,advancedCard}; moduleConfig.json
mqtt.{mqttConfigCard,mapReportingCard}).
- Field labels reworded to match Android strings.xml.
- mqtt.mapReportSettings.shouldReportLocation gains label, description,
consentHeader, consentText (consent text quoted verbatim from
Android).
* feat(web): migrate Bluetooth/Device/Display/Power/Network/Security pages to ConfigEditor
Phase 3a of PR #9. Six more radio-config pages off changeRegistry onto
the SDK ConfigEditor. Section structure + field order + labels taken
from Meshtastic-Android source of truth.
Bluetooth: single "Bluetooth Config" card. Drops the legacy disable-
mode-when-disabled rule; mode and PIN remain editable while bluetooth
is off (matches Android).
Device: four cards (Options / Hardware / Time Zone / GPIO).
- Options: role, rebroadcastMode, nodeInfoBroadcastSecs.
- Hardware: doubleTapAsButtonPress, disableTripleClick,
ledHeartbeatDisabled. Web keeps the proto-aligned (un-inverted) field
names; Android renders them inverted as "Triple Click Ad Hoc Ping" /
"LED Heartbeat" — equivalent semantics, simpler binding.
- Time Zone: tzdef.
- GPIO: buttonGpio, buzzerGpio.
- Drops debug-only "Device Storage & UI" card (debug-only on Android).
- Drops the inline "Use phone time zone" action button (queued for a
follow-up; needs a browser-tz implementation).
Display: two cards (Device Display / Advanced).
- Device Display: compassNorthTop ("Always point north"),
use12hClock, headingBold, units.
- Advanced: screenOnSecs, autoScreenCarouselSecs, wakeOnTapOrMotion,
flipScreen, displaymode, oled, compassOrientation (new — was missing
from web).
- Drops gpsFormat (deprecated in proto; moved to DeviceUIConfig).
Power: single "Power Config" card. Order: isPowerSaving,
onBatteryShutdownAfterSecs, adcMultiplierOverride (web keeps the single
number input; Android splits into a switch + conditional float input —
deferred), waitBluetoothSecs, sdsSecs, minWakeSecs,
deviceBatteryInaAddress. Drops lsSecs (Android does not surface it).
Network: three cards (WiFi Options / Ethernet Options / Advanced).
- WiFi Options: wifiEnabled, wifiSsid, wifiPsk.
- Ethernet Options: ethEnabled.
- Advanced: ntpServer, rsyslogServer, enabledProtocols ("Enabled" /
forward mesh over UDP), addressMode ("IPv4 mode"), then ipv4 ip /
gateway / subnet / dns when STATIC.
- Drops the read-only "current connections" card (no analog state on
web today). IPv4 int↔string conversion is unchanged.
Security: four cards (Direct Message Key / Admin Keys / Logs /
Administration).
- Direct Message Key: privateKey + publicKey (read-only) + Generate +
Backup buttons.
- Admin Keys: three slots, gated on Legacy Admin channel toggle.
- Logs: serialEnabled, debugLogApiEnabled (Android order: serial
first).
- Administration: isManaged, adminChannelEnabled.
- Byte-array conversions and the Pki regenerate / managed-mode dialogs
are unchanged.
i18n: config.json gains card-level keys (bluetoothConfig, options,
hardware, timeZone, gpio, deviceDisplay, advanced, powerConfig,
wifiOptions, ethernetOptionsCard, advancedCard, directMessageKey,
adminKeysCard, logsCard, administration, compassOrientation,
useBrowserTimeZone) and updates field labels to Android strings.xml
values where they differ (e.g. "Bluetooth enabled", "Always point
north", "Use 12h clock format", "Shutdown on power loss", "Wait for
Bluetooth duration", "Battery INA_2XX I2C address", "WiFi enabled",
"Ethernet enabled", "Legacy Admin channel", "Serial console").
* feat(web): migrate 11 module-config pages to ConfigEditor; Android-aligned labels
Phase 3b of PR #9. All remaining module pages off changeRegistry onto
the SDK ConfigEditor. Section structure + field order + labels taken
from Meshtastic-Android source of truth.
Pages migrated (single "<X> Config" card unless noted):
Serial: enabled, echo, rxd ("RX"), txd ("TX"), baud, timeout, mode,
overrideConsoleSerialPort. Drops the per-field disable-when-!enabled
gating (Android keeps fields editable while the module is off).
ExternalNotification: four cards (External Notification Config /
Notifications on message receipt / Notifications on alert/bell receipt
/ Advanced). New card layout matches Android. Schema + page now
include useI2sAsBuzzer. Per-field disable-when-!enabled gating dropped.
Card 1: enabled. Card 2: alertMessage*. Card 3: alertBell*. Card 4:
output, active, outputBuzzer, usePwm, outputVibra, outputMs,
nagTimeout, useI2sAsBuzzer.
StoreForward: adds isServer ("Server"). Removes per-field disable-on-
!enabled. Schema gains isServer.
RangeTest: relabel to Android strings ("Range test enabled", "Sender
message interval (seconds)", "Save .CSV in storage (ESP32 only)").
Removes per-field disable-on-!enabled.
Telemetry: adds deviceTelemetryEnabled ("Send Device Telemetry" — gated
on firmware ≥ v2.7.12 capability flag on Android; web shows
unconditionally for now) and powerScreenEnabled ("Power metrics on-
screen enabled"). Schema gains both. Field labels updated.
CannedMessage: relabels per Android ("Canned message enabled", "GPIO
pin for rotary encoder A/B/Press port", "Generate input event on
Press/CW/CCW", "Up/Down/Select input enabled", "Allow input source",
"Send bell"). The free-form `messages` text field is a separate admin
RPC (setCannedMessages on Android) — queued as a follow-up.
Audio: relabel ("CODEC 2 enabled", "PTT pin", "CODEC2 sample rate",
"I2S word select / data in / data out / clock").
NeighborInfo: adds transmitOverLora toggle. Schema gains it.
AmbientLighting: relabel ("Ambient Lighting Config" card). Same fields.
DetectionSensor: relabel + reorder per Android (enabled,
minimumBroadcastSecs, stateBroadcastSecs, sendBell, name, monitorPin,
detectionTriggerType, usePullup).
Paxcounter: relabel ("Paxcounter enabled", "Update interval", "WiFi
RSSI threshold (defaults to -80)", "BLE RSSI threshold").
i18n: moduleConfig.json gains card-level keys (serialConfig,
externalNotificationConfig, notificationsOnMessage, notificationsOnAlert,
advanced, storeForwardConfig, rangeTestConfig, telemetryConfig,
cannedMessageConfig, audioConfig, neighborInfoConfig,
ambientLightingConfig, detectionSensorConfig, paxcounterConfig) and
new field keys (deviceTelemetryEnabled, powerScreenEnabled,
transmitOverLora, isServer, useI2sAsBuzzer, minimumBroadcastSecs,
stateBroadcastSecs, sendBell, name, monitorPin, detectionTriggerType,
usePullup), with field labels reworked to match Android strings.xml
values.
The User module page is the last consumer of changeRegistry. After it
moves, the deviceStore changeRegistry plumbing + getEffectiveConfig +
setChange / removeChange / getAllConfigChanges / etc. can be deleted.
* feat(sdk,web): migrate User + Channel + ImportDialog off changeRegistry; ConfigEditor gains owner support
Phase 3c-1 of PR #9. The last writers/readers of changeRegistry are
moved to the SDK ConfigEditor. (One sweep commit drops the
changeRegistry plumbing from the deviceStore.)
ConfigEditor (sdk/features/config/domain/ConfigEditor.ts):
- New owner state: baselineOwner / workingOwner signals, isOwnerDirty,
setBaselineOwner(user), setOwner(user). The editor doesn't subscribe
to a SDK signal for the user (owner arrives via NodeInfo, not its own
packet), so the web seeds baseline from useMyNodeAsProto via setter.
- commit() now also runs setOwner (admin message) when isOwnerDirty,
inside the same beginEdit/commitEdit window as radio/module/channels.
- isDirty aggregates owner dirty too. reset() reverts working owner.
- Disconnect clears baseline + working owner.
User page (Settings/User.tsx):
- Aligned to Android: single "User Config" card, fields in order:
Node ID (read-only), Long Name, Short Name, Hardware model
(read-only enum name), Unmessageable, Licensed amateur radio (Ham).
- onSubmit calls editor.setOwner instead of connection.setOwner —
edits queue with the rest of the editor's pending changes and ship
on the global Save.
- Preserves non-edited User fields (id, hwModel, role, publicKey,
macaddr) by spreading the baseline before applying form deltas.
- isUnmessageable now reads from the proto's isUnmessagable instead of
defaulting to false (longstanding bug — the existing value was
ignored).
- shortName min loosened to 1 (was 2) per Android rule.
Channel page (PageComponents/Channels/Channel.tsx):
- Reads working channel from editor.channels via useSignal projection;
drops getChange / setChange / removeChange / deepCompareConfig.
- onSubmit -> editor.setChannel(payload).
Channels page (PageComponents/Channels/Channels.tsx):
- Reads channel list from useChannels() (SDK), maps each into a real
proto Channel via create(ChannelSchema, ...) for the per-tab Channel
component which still expects the proto shape.
- Per-channel dirty indicator now reads editor.dirtyChannels instead
of hasChannelChange.
ImportDialog (Dialog/ImportDialog.tsx):
- Apply path -> editor.setChannel + editor.setRadioSection("lora",...)
instead of setChange. Channel reads via SDK.
i18n: config.json user.* gains userConfig (card label), nodeId,
hardwareModel keys; field labels reworded to match Android (e.g.
"Licensed amateur radio (Ham)", "Unmessageable" with "Unmonitored or
Infrastructure" description). UserValidationSchema gains optional
nodeId / hardwareModel display fields.
* feat(sdk,web): delete changeRegistry; ConfigEditor owns all settings dirty state
Phase 3c-2 of PR #9. With every web settings page already migrated, the
deviceStore changeRegistry plumbing has no remaining writers or readers
and is deleted.
ConfigEditor (sdk):
- New queueAdminMessage(message) for one-off side flows. Queue drains
inside commit() between beginEdit and commitEdit. Used by
Position.tsx for setFixedPosition; future side flows (e.g. SetTime)
reuse the same queue.
- Disconnect / commit success now also reset the admin-message queue.
- isDirty includes a queued admin-message check.
Web Settings/index.tsx:
- handleSave is now a one-liner: editor.commit(). All the legacy
get*Changes / get*ChangeCount / clearAllChanges / connection.setConfig
loops + the post-commit deviceStore mirror writes are gone.
- handleReset calls editor.reset() instead of clearAllChanges().
- Save-button gating reads editor.isDirty + RHF dirty.
- Section change-count badges read directly from editor.dirtyRadioSections /
editor.dirtyModuleSections / editor.dirtyChannels lengths.
Tab dirty-dot indicators (RadioConfig.tsx / DeviceConfig.tsx /
ModuleConfig.tsx): rewired from hasConfigChange/hasModuleConfigChange/
hasChannelChange/hasUserChange to editor signals (dirtyRadioSections,
dirtyModuleSections, dirtyChannels, isOwnerDirty).
Position.tsx: queueAdminMessage call now goes through editor — pending
fixed-position coordinates ride along with the rest of the editor's
dirty state and ship under the same beginEdit/commitEdit window.
deviceStore.ts:
- Drops the entire changeRegistry surface from the Device interface and
factory: setChange / removeChange / hasChange / getChange /
clearAllChanges / hasConfigChange / hasModuleConfigChange /
hasChannelChange / hasUserChange / getConfigChangeCount /
getModuleConfigChangeCount / getChannelChangeCount /
getAdminMessageChangeCount / getAllConfigChanges /
getAllModuleConfigChanges / getAllChannelChanges / queueAdminMessage /
getAllQueuedAdminMessages, plus the changeRegistry field.
- getEffectiveConfig / getEffectiveModuleConfig collapse to plain
device.config[variant] / device.moduleConfig[variant] passthroughs
(kept as a thin compatibility shim for residual callers; the
changeRegistry merge is gone).
- types.ts: ValidConfigType / ValidModuleConfigType derive directly
from LocalConfig / LocalModuleConfig keys (was imported from the
deleted changeRegistry.ts).
- The 252-line changeRegistry.ts file is deleted; ~250 lines also drop
out of the deviceStore factory.
- deviceStore.test.ts loses the change-registry describe block (3
tests). 237 web tests still passing (was 240; -3 dead tests).
Net: -1066 / +136 lines.
* feat(sdk,sdk-storage-sqlocal,web): TelemetryRepository port + SqlocalTelemetryRepository (PR #10)
Telemetry slice gains the same persistence shape as chat / nodes: a
repository port on the SDK side, an in-memory default, an OPFS-backed
SQLite adapter on the storage package side, and lazy hydration into the
in-memory store.
SDK (@meshtastic/sdk):
- New TelemetryRepository port (loadRecent, loadBefore, append,
appendBatch, prune, clearNode, clear) + TelemetryRetentionPolicy
(maxPerNode, olderThanMs).
- New InMemoryTelemetryRepository — default when no adapter is wired.
- TelemetryClient grows TelemetryClientOptions { repository?, retention? }.
Each incoming onTelemetryPacket appends to both the in-memory store
and the repository, then the configured retention policy prunes the
repository.
- latest(nodeNum) and history(nodeNum) lazy-hydrate the in-memory store
from the repository on first subscribe (HYDRATE_LIMIT = 256). loadBefore
passes through to the repository for paged reads.
- clearNode / clear methods exposed on the client.
- MeshClient gains options.telemetry which is passed through to
TelemetryClient.
@meshtastic/sdk-storage-sqlocal:
- New SqlocalTelemetryRepository under ./telemetry subpath. Drizzle-typed
insert/select/delete against the existing telemetry table; payload is
stored as base64 of the proto bytes (per-kind schema lookup) so the
wire shape is the source of truth across schema additions.
- prune({ maxPerNode }) trims with a per-node offset query. prune({
olderThanMs }) deletes by ts cutoff.
- Six new tests cover round-trip, ascending order, deviceId scoping,
per-node retention, age-based prune, and proto payload preservation.
- Re-exports added to mod.ts + ./telemetry subpath in package.json.
web:
- useConnections wires SqlocalTelemetryRepository per connection with
retention { maxPerNode: 500, olderThanMs: 30 days }.
Tests: SDK 57 (was 49 — +8 new), storage 30 (was 24 — +6), web 237.
Build clean.
* feat(sdk,sdk-react,web): unread counts on the SDK ChatClient
ChatClient gains a `chat.unread` namespace mirroring `chat.drafts`:
- byKey: ReadonlySignal<Map<conversation-key-string, number>>
- total: ReadonlySignal<number>
- count(key): ReadonlySignal<number>
- markRead(key): void
Increments happen in the existing onMessagePacket subscriber when
packet.from !== client.myNodeNum (so the outbound echo of our own send
doesn't bump anything). Uses the same ConversationKey shape the rest
of the chat slice already keys by, so direct messages keyed by peer
and broadcasts by channel can never collide.
Counts are in-memory only — persistence will come later if needed
(would require tracking a lastReadAt timestamp per conversation in the
message repository and computing unread on hydrate).
sdk-react: new useTotalUnread / useUnreadCount(key) / useUnreadByKey
hooks. All fall back to safe empty values when no client is active.
Web migration:
- Sidebar reads useTotalUnread instead of summing
deviceStore.unreadCounts.
- MessagesPage: per-channel SidebarButton counts read from
useUnreadByKey()'s `channel:N` keys; per-direct-message counts from
`direct:N` keys. Click handlers call meshClient.chat.unread.markRead
with the typed ConversationKey instead of resetUnread.
- subscriptions.ts: drops onMessagePacket -> incrementUnread mirror
(SDK now owns it). myNodeNum local goes away too — nothing else
consumed it.
- deviceStore: removes unreadCounts field + incrementUnread /
resetUnread / getUnreadCount / getAllUnreadCount methods. The mock
+ test block in deviceStore.test.ts also drop their unread coverage.
- deviceStore.mock.ts: also strips the dead changeRegistry / setChange
/ hasConfigChange / etc. methods that survived from the earlier
changeRegistry deletion.
Tests: SDK 61 -> 65 (+4 ChatClient.unread.test), sdk-react 8, web 236.
Build clean.
* refactor(web): split useConnections into focused modules
useConnections went from 661 lines down to 264 by extracting three
single-responsibility helpers under packages/web/src/core/connections/.
The hook is now pure orchestration; transport / heartbeat / SDK-client
/ status-probe concerns live in their own files.
New modules:
- core/connections/heartbeat.ts (45 LOC): startConfigHeartbeat (5s),
startMaintenanceHeartbeat (5min), stopHeartbeat. Owns the heartbeats
Map; replaces the inline interval bookkeeping. Both helpers stop the
prior heartbeat first so callers don't have to.
- core/connections/sdkClient.ts (61 LOC): buildMeshDevice(connId,
deviceId, transport) opens the OPFS DB, builds the four sqlocal
repositories (chat / draft / nodes / telemetry), and constructs the
MeshDevice with the canonical retention defaults (chat 90d / 1k per
bucket; telemetry 30d / 500 per node). Falls back to in-memory when
sqlocal is unavailable.
- core/connections/transports.ts (236 LOC): per-transport openTransport
factory (HTTP reachability check, BT permission re-acquisition with
optional prompt, Serial port lookup with close-then-reopen),
probeConnection for refreshStatuses, closeTransport for cleanup.
Discriminates over conn.type so useConnections doesn't carry the
switch logic.
useConnections (now 264 LOC):
- Owns the cachedTransports + configSubscriptions maps and the
Zustand selectors.
- teardown(id, conn) consolidates the heartbeat + config-sub +
meshDevice.disconnect + transport-close cleanup that used to be
duplicated across removeConnection / disconnect.
- connect calls openTransport and forwards the resulting transport +
cached BT/Serial handle into setupMeshDevice. The BT
gattserverdisconnected listener is wired here (it needs the connId).
- refreshStatuses simplifies to a filter + Promise.all over
probeConnection.
- syncConnectionStatuses unchanged.
Behavior is unchanged. No new tests — the existing web suite (236)
still passes; build clean.
* chore: move packages/web → apps/web
Web is a deployable SPA, not a library — no @meshtastic scope, no
exports map, no npm/JSR publish target, no other workspace member
depends on it. Conventional pnpm/Turbo/Nx layout puts deployables
under apps/ and libraries under packages/. Doing the move now (after
PR #9 / #10 / unread / useConnections refactor land but before Phase
C ships) so the lib-only packages/* directory remains stable as we
delete packages/core.
Mechanics:
- pnpm-workspace.yaml: add `apps/*` to packages.
- git mv packages/web apps/web (entire directory tree).
- vite.config.ts uses process.cwd(), so no internal path edits needed.
- pnpm filter commands still resolve by package name (`pnpm --filter
meshtastic-web run build`) — no script changes.
External-path consumers updated:
- README.md table row.
- tsconfig.json reference.
- 7 GH workflows (pr.yml, nightly.yml, release-web.yml, the three
crowdin-*.yml, release-packages.yml). The
packages/release-packages.yml `packages/* | grep -v packages/web`
filter is now redundant since web isn't in packages/* anymore — it
collapses to plain `ls -d packages/*`.
Verified: web build clean, web 236 / sdk 65 / sdk-react 8 / storage
30 tests all pass.
* feat: PR #12 Phase C — delete packages/core, retarget transports to @meshtastic/sdk, bump majors
The legacy `@meshtastic/core` package is gone. The six transport-*
packages and the web app no longer depend on it; everything routes
through `@meshtastic/sdk`.
Transport packages (transport-deno, transport-http, transport-node,
transport-node-serial, transport-web-bluetooth, transport-web-serial):
- package.json deps swap `@meshtastic/core: workspace:*` for
`@meshtastic/sdk: workspace:*`.
- src/transport.ts + src/transport.test.ts imports point at
`@meshtastic/sdk` (the `Types` and `Utils` namespaces are still
exported from the SDK so source code is otherwise unchanged).
- README.md examples updated to import from `@meshtastic/sdk`.
apps/web:
- Drops the leftover `@meshtastic/core` workspace dep; nothing in
apps/web/src imports from it.
@meshtastic/sdk:
- README description loses the "Replaces @meshtastic/core" suffix —
there's nothing left to replace.
- Three legacy shim files keep their re-exports but their docstrings
drop the "Phase-A shim, removed in Phase C" framing. The MeshDevice
facade survives because the web app's `connection.factoryResetDevice()`
/ `connection.reboot()` / etc. callsites still go through it; new
consumers should reach into `client.config` / `client.chat` / etc.
- New scripts/rename-dts.mjs is a postbuild step that renames tsdown's
hashed entry-point dts outputs (`mod-<hash>.d.ts` etc.) back to their
canonical names so package.json `types` and downstream dts-bundlers
can find them. Internal chunk dts files (e.g. `Transport-<hash>.d.ts`)
are intentionally NOT renamed because mod.d.ts imports them by path.
- build:npm runs tsdown then the rename script.
Version bumps (signal: now require @meshtastic/sdk):
- @meshtastic/sdk 0.1.0 -> 1.0.0
- @meshtastic/sdk-react 0.1.0 -> 1.0.0
- @meshtastic/sdk-storage-sqlocal 0.1.0 -> 1.0.0
- @meshtastic/transport-http 0.2.5 -> 1.0.0
- @meshtastic/transport-web-serial 0.2.5 -> 1.0.0
- @meshtastic/transport-web-bluetooth 0.1.5 -> 1.0.0
- @meshtastic/transport-deno 0.1.1 -> 1.0.0
- @meshtastic/transport-node 0.0.2 -> 1.0.0
- @meshtastic/transport-node-serial 0.0.2 -> 1.0.0
Workflows: nothing referenced packages/core directly (only the
release-packages.yml glob which already collapsed in the apps/web
move). README packages table loses the legacy `packages/core` row.
Verified: web build clean, all four package suites green
(web 236, sdk 65, sdk-react 8, storage 30).
The transport packages' dist build is currently blocked by a tsdown
cross-chunk dts resolution glitch where the `Types` namespace import
can't follow `mod.d.ts`'s reference to the internal `Transport-<hash>`
chunk. Runtime is fine — only the published-types path is affected,
and transport packages publish via their own release flow. Logged as
follow-up.
* fix(web/connections): probe = "online" not "configured"; flip status to "configuring" before DB open; await transport disconnect
Three reconnect-flow bugs:
1. probeConnection returned "configured" for serial / bluetooth when
the browser had stored permission for the device — but permission
≠ a configured Meshtastic device. The card showed "connected"
and a Disconnect button before the user had ever clicked Connect.
Probe now returns "online" (= "available, click to connect"),
matching the HTTP path. "configured" is reserved for the
onConfigComplete callback.
2. setupMeshDevice flipped status from "connecting" → "configuring"
AFTER awaiting buildMeshDevice, which opens the OPFS DB. If the
DB open stalled (multi-tab contention, slow first-time init), the
card sat at "connecting" indefinitely. Move the status flip ahead
of the persistence await — UI shows "configuring" while
persistence is spinning up.
3. teardown's `device?.connection?.disconnect()` returned a Promise
that was never awaited, so the underlying transport's port.close()
could race the next port.open() on a fast disconnect → reconnect.
Make teardown async, await disconnect, propagate via async
removeConnection / disconnect callers.
Plus: connect() catch block logs the underlying error before turning
it into a status update, so the actual failure shows up in console
even when the toast text is generic.
* feat(web): Position "Use browser location" button + Telemetry firmware capability gate
Two backlog UX nits.
DynamicForm:
- FormGroup gains an optional `footer?: ReactNode` slot that renders
after the field list. Lets pages drop arbitrary JSX (action buttons,
notes, etc.) into a card without subclassing the form.
Position:
- New `UseBrowserLocationButton` component lives inside the Device GPS
card via the new `footer` slot. Calls navigator.geolocation, writes
lat/lng/altitude into the form via `useFormContext` (the
PositionValidation form is wrapped in FormProvider by DynamicForm).
- Truncates lat/lng to 7 decimals to match the proto's max precision.
- Gracefully no-ops when navigator.geolocation is unavailable
(insecure context).
- Failed reads surface as a toast carrying the GeolocationPositionError
message; busy state disables the button + flips the label.
- New i18n keys: position.useBrowserLocation.{label,busy,failed}.
Telemetry:
- `device_telemetry_enabled` is only writable on firmware ≥ v2.7.12
(mirrors Android's `Capabilities.canToggleTelemetryEnabled`). Adds a
small `firmwareAtLeast` semver helper and reads
`device.metadata.get(0)?.firmwareVersion`. The toggle is hidden on
older firmware so we don't push a value the device will silently
drop.
- Unparseable / unknown firmware versions default to "show the toggle"
(rather than hide), so we don't accidentally hide the control on
devices we can't classify.
Build clean, 236 web tests still pass.
* fix(sdk): build clean dts for npm consumers; transports drop Types/Utils namespace
Previously transport-* package dts builds failed with "Missing export" because
rolldown's dts bundler couldn't follow tsdown's cross-chunk re-exports out of
@meshtastic/sdk. Three things land here:
1. mod.ts now re-exports `fromDeviceStream`, `toDeviceStream`, `Queue`, and
`Xmodem` directly. Transport packages were importing these via the legacy
`Utils` namespace; namespace re-exports are exactly what rolldown chokes
on. Transport packages (http, deno, node, node-serial, web-bluetooth,
web-serial) and shared transportContract.ts now use direct imports —
`import { Transport, DeviceOutput, ... } from "@meshtastic/sdk"`.
2. package.json `exports` split: `types` points at `./dist/<entry>.d.ts`
(built dts) so tsdown's downstream rolldown reads a self-contained file;
`default` keeps source paths so vitest + workspace-internal imports still
resolve to .ts source.
3. Postbuild `rename-dts.mjs` now (a) inlines internal chunk dts files
(Transport-<hash>.d.ts) into each entry's dts, rewriting the letter
aliases tsdown produces; (b) strips `type` modifiers from re-exports
so rolldown accepts the bindings as both value- and type-shape;
(c) declares the synthetic `Types`/`Utils` namespaces explicitly,
replacing the broken `<wrapper>_d_exports as Types` aliases tsdown
emits for `export * as` patterns.
vitest.config.ts gains `apps/*` so the workspace move keeps test discovery
working for the apps/web project.
* chore(build): tighten tsdown perf flags across SDK + transport packages
- Drop bogus `dts.isolatedDeclarations` field from SDK (not a real tsdown
option; tsdown was silently ignoring it).
- Make every package explicit about the perf-relevant flags rather than
relying on defaults that drift between tsdown versions: target=esnext
(no syntax downleveling), sourcemap=false, minify=false, treeshake=true,
report=false, splitting=false.
- Modest wall-clock wins: SDK 1020→752ms, transports ~720→~600ms.
`isolatedDeclarations: true` in tsconfig would unlock the bigger oxc-dts
fast path but the codebase isn't ID-clean yet — left as future work.
* fix(web): clear pre-existing typecheck errors (36 → 0)
Sweep covering several unrelated cohorts:
- Delete dead `NewDeviceDialog.tsx` (commented-out in App.tsx, imports point at
non-existent `@components/PageComponents/Connect/*`).
- Add `better-result` to sdk-react deps so `useChat`/`useDirectChat`/
`useFavoriteNode`/`useIgnoreNode` resolve.
- Fix `test-utils.tsx`: route at `routeTree.gen.ts` was never generated;
re-export the existing `routeTree` constant from `routes.tsx` and pass
the missing router context + DeviceWrapper deviceId.
- Pre-existing `noUncheckedIndexedAccess` violations in `pskSchema.test.ts`,
`x25519.ts`, `Table/index.tsx` + test, `useCopyToClipboard` (Timeout vs
number) — non-null asserts where the index is guaranteed by the
surrounding code, plus a defensive `if (!cell) return 0` in the table sort.
- Immer `WritableDraft<T>` mismatches against SDK's `MeshDevice`/`Device`
classes — cast through `Draft<X>` where the inferred recursive draft type
can't represent SDK class internals.
- `deviceStore.mock` updated for the `connectionPhase`/`connectionId` +
setters added when the connection lifecycle was extracted.
- `HeatmapLayer` accepts the `isVisible` prop everyone else's layer accepts.
- `SNRTooltipProps.to` widened to `string | undefined` (single-node hover
has no `to`).
- Zod resolver returns `Record<string, never>` for the error-path values
shape that react-hook-form expects.
- Mock `NodeInfo` in `useFilterNode.test.ts` gains the `isMuted` proto
field that landed upstream.
* fix(web/connections): retry-once + clearer error on Bluetooth GATT connect failure
`NetworkError: Connection attempt failed` from `device.gatt.connect()` is the
most common transient when reconnecting BT — OS stack hiccup, device just
woke from sleep, etc. Adding one retry with a 750ms delay clears most of
those. Persistent failures get a wrapped error message naming the actual
likely causes (out of range, powered off, paired with phone or another
tab) instead of leaving the raw DOMException for the user to interpret.
* refactor(transport-web-bluetooth): own GATT connect-retry semantics + typed error
Per the DDD layering — transport-level concerns belong in the transport
package, not the web app's connection orchestrator. Moved the GATT
`NetworkError: Connection attempt failed` retry-once + the user-facing
error wrapping out of `apps/web/src/core/connections/transports.ts` and
into `TransportWebBluetooth.prepareConnection`.
New `BluetoothConnectError` carries:
- `kind: "transient" | "unavailable" | "missing-service"` so callers can
decide whether to suggest retry vs re-pair vs firmware upgrade.
- `userMessage` — human-readable, actionable string ready for UI.
The web app's `transports.ts` is back to a thin wrapper that just calls
`TransportWebBluetooth.createFromDevice` and surfaces whatever error it
throws. `BluetoothConnectError` is re-exported through the connections
module so the Connections page can `instanceof`-check without depending
on the transport package directly.
* feat(sdk,web): detect newly-flashed device + prompt region setup
Mirrors Meshtastic-Android's `regionUnset` flow. A freshly-flashed device
boots with `Config.LoRa.region == UNSET` and won't transmit at all until
the user picks one. Web now surfaces this:
- `ConfigClient.isRegionUnset: ReadonlySignal<boolean>` — computed from
the radio config signal, false until the first LoRa packet arrives so
consumers don't flash the prompt during the connect handshake.
- `useIsRegionUnset()` hook in sdk-react, re-exported from the package's
public surface.
- `RegionSetupReminder` mounts inside the connected-device branch of
App.tsx. While the SDK reports `isRegionUnset == true`, a persistent
toast offers a "Set region" CTA that deep-links into the LoRa tab
(`/settings/radio`). Toast auto-dismisses the moment a real region is
committed.
Predicate matches Android exactly (single check, no owner/name/setupComplete
heuristics). Lives in the SDK config slice — UI is a thin consumer.
3 new SDK tests; SDK 64 / sdk-react 8 / web 236.
* refactor(transport-web-serial): own port-state hygiene + Result-typed connect errors
Pre-flight close + open-with-backoff lived in apps/web's transport
orchestrator — wrong layer per DDD. Lifted into TransportWebSerial
itself.
Changes:
- `TransportWebSerial.createFromPort` (and `create`) now return
`Result<TransportWebSerial, SerialConnectError>`. No throwing on
expected failures; callers branch on the Result.
- New `preparePort` private static that:
* force-closes the port if `readable` / `writable` are non-null
* opens with up to 4 attempts (250 / 500 / 750 ms backoff) on
`InvalidStateError` — common during USB re-enumeration
* tags persistent failures `kind: "in-use"` (other tab / app
holding the port) vs `"busy"` (transient / unknown) vs
`"unavailable"` (no streams after open)
- `SerialConnectError` carries `kind` + `userMessage` ready for UI.
- `apps/web/src/core/connections/transports.ts` drops its old
conditional `port.close()` + 100ms sleep; just calls
`createFromPort` and unwraps the Result. `SerialConnectError` is
re-exported alongside `BluetoothConnectError` so the Connections
page can pattern-match.
- `AnyTransport` definition simplified — was deriving via
`Awaited<ReturnType<...>>` which broke once `createFromPort`
returned a Result.
- Test FakeSerialPort updated to mirror the real spec: `readable`
/`writable` go null on `close()` and re-create on `open()`.
- 3 new port-hygiene tests cover the close-on-prior-open path,
the backoff-retry success path, and the persistent-`in-use`
Err path. Suite: 5 → 8.
Matches the better-result preference for new application/use-case
code. BT transport stays on the throwing `BluetoothConnectError`
shape for now — separate refactor if we want to converge.
* chore(logging): tslog-gated debug logs across the serial connect path
createLogger now reads `localStorage["mesh-debug"]==="1"` (browser) or
`MESH_DEBUG=1` (node) on each invocation. When set, default minLevel
drops to debug; otherwise stays at info. Existing callers
(MeshClient + co.) are unaffected.
Logs added (all `[name]`-prefixed via tslog) covering the connect
lifecycle the user just hit:
- TransportWebSerial.preparePort: enter, close-needed branch,
close result, each open() attempt, retry decisions, final error.
- TransportWebSerial constructor: pipe wiring, toDevice pipe abort
vs reject path.
- TransportWebSerial read loop: start, done, throw (with
closingByUser flag), reader-lock release.
- TransportWebSerial.disconnect: each cleanup step (abort, pipe
settled, fromDevice cancel, connection.close).
- transports.ts openSerial: cached-port flag, getPorts count,
picker invocation, resolved-port stream state, createFromPort
Result outcome (kind + userMessage on Err).
- useConnections.connect / setupMeshDevice / teardown: phase
transitions, configure() resolve / reject, onConfigComplete fire,
BT gattserverdisconnected, transport.disconnect rejection.
Flip on:
localStorage.setItem("mesh-debug", "1"); location.reload();
* chore(web/storage): logs + 5s timeout around sqlocal DB open
The connect path silently hung at `buildMeshDevice` when sqlocal failed
to open. Adding visibility:
- `getStorageDb` logs creation start, success (with elapsed ms), and
failure (with name + message).
- `buildMeshDevice` races the DB open against a 5s timeout. If sqlocal
hangs (stale Web Lock from a crashed prior tab, OPFS contention,
worker hang), the connect path falls through to the SDK's in-memory
repositories instead of blocking forever — the user gets a working
session and the warn-level log surfaces the underlying cause.
- `buildMeshDevice` logs entry, DB-ready elapsed, repos-opened, and
fall-through decisions.
* feat(sdk,web): live connect-progress overlay (terminal-style log)
Surfaces what the connection handshake is doing in real time. Per DDD,
the predicate + counters live in the SDK; the web overlay is a thin
consumer of the signal.
SDK
- New `MeshClient.progress: ReadonlySignal<ConnectionProgress>` with the
state machine `idle → configuring → configured`. Counters
(config / modules / channels / nodes + boolean myInfo / metadata)
tally inbound packets each `configure()` cycle.
- `configure()` resets to `configuring` with empty counters.
`onConfigComplete` flips to `configured`.
- `ConnectionProgress` + `ConnectionProgressCounters` exported from the
package surface.
- 6 new tests in `MeshClient.progress.test.ts`.
sdk-react
- `useConnectionProgress()` hook reads the active client's signal,
returns `{ phase: "idle" }` when there is no active client so the
caller can render unconditionally.
apps/web
- `ConnectingOverlay` redesigned as a terminal-style streaming log:
- macOS-window-style header (red/yellow/green dots) with a live
`phase` indicator pulse.
- Monospace event lines with `→` (active) / `✓` (done) / `•` (info)
glyphs and a relative-seconds timestamp column.
- Auto-scrolls to the latest entry; blinking caret on the trailing
active line.
- Lines derive from `device.connectionPhase` transitions and per-
counter bumps on `MeshClient.progress`. Resets on each fresh
connect cycle.
- Mounted at the top of the device tree (outside the device-conditional
branch) so it shows during a first-time connect from the Connections
screen as well as reconnects from inside the app.
- i18n strings under `connections.overlay.log.*`.
* refactor(web): redesign ConnectingOverlay as hero card + fix early visibility
Two changes:
Visibility fix — overlay now reads `savedConnections` for any entry
whose status is "connecting" or "configuring". The previous code keyed
off `device.connectionPhase` from the active deviceStore entry, but
that entry doesn't exist until partway through `setupMeshDevice` —
the overlay was hidden during transport-open + storage-open (often
the slowest part of the connect flow).
Visual redo (option C — hero card with radial pings):
- Center: transport-type icon (Globe / Bluetooth / Cable) on a
gradient disc with two concentric ping rings.
- Below: device name + phase label with small spinner.
- 2x2 grid of stat chips (Identity / Metadata / Channels / Nodes)
that flip from gray (dashed circle) to emerald (check or count)
as the SDK reports each piece arriving.
- Slate-to-black gradient panel; non-dismissable while active.
- i18n strings under `connections.overlay.*` updated to match.
* fix(web/connecting-overlay): clear stale in-flight statuses + Cancel escape
Two reasons the overlay could "never disappear":
1. Persisted state from a prior session.
`savedConnections` is Zustand-persisted, so a prior tab that died
mid-connect (page reload, hot reload, force-quit) leaves a saved
connection at status "connecting" / "configuring" forever. On cold
boot the overlay reads that and stays visible. `onRehydrateStorage`
now sweeps any persisted "connecting" / "configuring" /
"disconnecting" entries back to "disconnected" — no live JS code
could complete those, so they're stale by definition.
2. Live attempt that genuinely hangs (firmware in CLI / bootloader,
framing out of sync, `onConfigComplete` never arrives).
After STUCK_THRESHOLD_MS (15s) the overlay surfaces a Cancel button
+ a hint. Cancel calls `useConnections().disconnect(id)` which tears
down the transport and flips status off "configuring". Resets if a
new attempt starts.
i18n adds `connections.overlay.stuckHint` + `cancel`.
* fix(web/connections): close configured-transition race when configCompleteId is buffered
Reproed on serial reconnect: the device kept emitting from a prior
session, so the new MeshClient's `transport.fromDevice → decodePacket`
pump processed the buffered `configCompleteId` synchronously inside
the `buildMeshDevice` await — before `setupMeshDevice` had a chance to
subscribe to `onConfigComplete`. SimpleEventDispatcher doesn't replay
to late subscribers, so the event was lost. The connect overlay (which
keys off the saved-connection status) stayed visible forever even
though the rest of the app saw nodes / messages flowing.
Fix: wire two parallel paths to a shared idempotent `markConfigured`
handler:
- `events.onConfigComplete` (fast path, fires on the next live event).
- `MeshClient.device.status` signal — `decodePacket` also flips the
signal to `DeviceConfigured` on the same packet, and signal
subscribers don't drop the current value if it's already there.
Plus an initial synchronous check in case the status signal had
already settled before either subscribe ran. `configSubscriptions`
unsubscribes both on teardown.
* style(connecting-overlay): drop hardcoded slate/sky for the app's theme tokens
Reuses the same `--color-text-primary`, `--color-text-secondary`,
`--color-background-primary`, and `--color-link` tokens the rest of
the web UI already binds to (light + dark variants resolve via
`[data-theme=...]`), so the overlay now picks up the active theme
instead of fighting it with a hardcoded slate/sky/indigo palette.
- Hero ring + disc → `bg-link` + `bg-link/{20,30}` ping ripples.
Icon uses `text-background-primary` so it stays legible on both
themes (white-on-blue light, dark-on-blue dark).
- Title / phase / hint copy → `text-text-primary` / `text-text-secondary`.
- Stat chips use `green-500` (matches `Button.success`) for the done
state and `text-secondary`-derived neutrals for idle.
- Cancel button reverts to the default `Button` outline variant — was
carrying its own slate overrides, no need.
* fix(sdk/chat): optimistic-append outbound text so it shows up after send
Reproed in MessagesPage on /messages/broadcast/0: typing a message and
pressing Enter cleared the input, but the message never rendered.
Root cause:
- `ChatClient.send` calls `sendText` → `MeshClient.sendPacket(...,
echoResponse=true)`. The echo branch dispatches `onMeshPacket` only.
- `ChatClient` subscribes to the per-portnum `onMessagePacket`, not the
raw `onMeshPacket`. So the outbound message is never appended to its
conversation bucket.
- The Meshtastic firmware does not loop the user's own outbound text
back via `fromradio`, so there's no inbound echo to fall back on.
Fix:
- `ChatClient.send` now optimistically appends the outbound message
(state=Pending) to the matching channel/direct bucket and persists
it via the configured repository as soon as `sendText` resolves Ok.
- The existing `onRoutingPacket` subscriber flips state Pending→Ack /
Failed when the routing ack arrives keyed by packet id — unchanged.
- `ChatStore.hasMessage(key, id)` added; the inbound `onMessagePacket`
subscriber and the `send()` path both consult it so a
belt-and-suspenders firmware echo doesn't double-append.
Tests: ChatClient.send.test.ts — 4 cases (broadcast append, direct
append, echo dedup, routing-ack flips state). Suite 70 → 74 / web
suite untouched at 236.
* fix(sdk/chat): append outbound message before awaiting send (instant render)
Previously the optimistic append happened after `await sendText(...)`,
which itself awaited `queue.wait(id)` — i.e. the firmware ack. On LoRa
that's 1–3 seconds, so the user saw a noticeable delay between hitting
Enter and the bubble appearing.
Move the append before the await. To do that the chat slice needs to
know the packet id synchronously, so:
- `MeshClient.sendPacket` gains an optional `packetId` parameter
(defaults to `generatePacketId()`, behaviour unchanged for callers
that don't pass one).
- `SendTextInput.packetId` plumbs through `SendTextUseCase` to
`sendPacket`.
- `ChatClient.send` generates the id up-front, appends the message
with `state=Pending` immediately, persists it, then awaits
`sendText(..., { packetId })`. On Err the optimistic message stays
visible but flips to `Failed` so the user sees what happened.
Routing-ack subscriber still flips `Pending → Ack` keyed by id —
unchanged.
Tests added (suite 74 → 76):
- "appends the optimistic message before the send promise resolves"
— asserts the bucket contains the message synchronously after the
send call returns its pending promise.
- "flips outbound state to Failed when sendText returns Err"
— exercises the empty-text validation path.
* adding a claude to repo
* handle device reboots
* chore(web): post-rebase fixups — lockfile, dedupe dep, formatting
- Regenerate pnpm-lock.yaml to match the merged package.json set (adds the
@meshtastic/sdk + transport workspace packages from this PR); the rebase
had held the lockfile at main's version via a merge driver.
- Drop a duplicate better-result entry in apps/web/package.json.
- Reformat LoRa.tsx / Display.tsx (oxfmt) after merging main's config fields
into Dan's ConfigEditor field groups.
* test: retire main's nodeDBStore + messageStore tests superseded by SDK migration
Dan's SDK migration removed the Zustand nodeDBStore (node state now lives in
the SDK; useNodesLegacy notes the migration) and the useNodeDB hook. main had
since added nodeDBStore.test.tsx / messageStore.test.ts and kept evolving the
store; the rebase carried those over, so they tested an API this PR removes
(useNodeDB is not a function). Dan's branch contains none of these files.
Remove the dead nodeDBStore store dir and the two orphaned main tests to match
the migrated architecture. The live messageStore (barrel-exported) is kept; only
main's standalone test for it is dropped.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
- **Think First:** Always outline your step-by-step reasoning inside `<thinking>` tags before writing code or shell commands. Claude models perform significantly better on complex TypeScript tasks when they "think out loud" first.
- **Skills:** The `.skills/` directory contains task-specific instruction modules. Load them as needed — only the skill relevant to your current task.
- **Plan Mode:** Use plan mode for architectural changes spanning multiple modules. Write plans to `.agent_plans/` (git-ignored). The Copilot-CLI-specific `/plan`, `/delegate`, `/research`, and `/share` guidance in `AGENTS.md` does not apply to Claude Code — skip the `<copilot_cli_workflow>` section.
| `packages/sdk` | Framework-agnostic TypeScript SDK. Domain-driven feature slices (device, chat, nodes, channels, config, telemetry, position, traceroute, files) built around a `MeshClient` orchestrator with `@preact/signals-core` reactive state. |
- **`packages/core`:** Core functionality for Meshtastic JS.
| `packages/sdk-react` | React hooks + `MeshProvider` on top of `@meshtastic/sdk`. Wraps signals in `useSyncExternalStore` for concurrent-safe renders. |
- **`packages/transport-node`:** TCP Transport for the NodeJS runtime.
| `apps/web` | Reference React web client. Hosted at [client.meshtastic.org](https://client.meshtastic.org). |
- **`packages/transport-node-serial`:** NodeJS Serial Transport for the NodeJS runtime.
- **`packages/transport-deno`:** TCP Transport for the Deno runtime.
| `packages/protobufs` | Generated TypeScript stubs from [`meshtastic/protobufs`](https://github.com/meshtastic/protobufs), produced via `buf generate`. Source of truth for every wire-level type. |
- **`packages/transport-http`:** HTTP Transport.
| `packages/transport-http` | HTTP transport for devices exposing a network interface. |
- **`packages/transport-web-bluetooth`:** Web Bluetooth Transport.
| `packages/transport-web-bluetooth` | Web Bluetooth transport for BLE-capable devices (browsers). |
- **`packages/transport-web-serial`:** Web Serial Transport.
| `packages/transport-web-serial` | Web Serial transport for USB-serial devices (browsers). |
- **`packages/protobufs`:** Git submodule containing Meshtastic’s shared protobuf definitions, used to generate and publish the JSR protobuf package.
| `packages/transport-node` | TCP transport for Node.js. |
| `packages/transport-node-serial` | Serial transport for Node.js. |
| `packages/transport-deno` | TCP transport for Deno. |
| `packages/transport-mock` | In-memory transport for tests. |
All `Meshtastic JS` packages (core and transports) are published both to
All publishable packages ship to both [JSR](https://jsr.io/@meshtastic) and [NPM](https://www.npmjs.com/org/meshtastic).
- **`queue/`**, **`xmodem/`** — packet ack/timeout pipeline and file-transfer protocol.
- **`signals/`** — signal and keyed-collection helpers consumed by every slice.
- **`logging/`** — `tslog` factory used consistently by every class.
- **`identifiers/`**, **`errors/`** — small primitives shared across slices.
The protobuf boundary is strict: wire messages enter through the packet codec,
get mapped into domain entities inside `features/*/infrastructure/*Mapper.ts`,
and signals only ever expose the domain shape.
```
Transport ─▶ Packet codec ─▶ EventBus ─▶ Slice infrastructure
│
▼
Signals (state) ─▶ sdk-react hooks ─▶ UI
▲
│
Slice application (use-cases) ─▶ MeshClient.sendPacket ─▶ Queue ─▶ Transport
```
Expected domain errors are returned as `Result<T, E>` via [`better-result`](https://www.npmjs.com/package/better-result); exceptions are reserved for programmer errors and truly exceptional conditions.
## Getting Started
### Prerequisites
You need [pnpm](https://pnpm.io/) installed. If you plan to regenerate
protobufs, also install the [Buf CLI](https://buf.build/docs/cli/installation/).
### Setup
```bash
git clone https://github.com/meshtastic/web.git
cd web
pnpm install
```
### Run the web client
```bash
pnpm --filter @meshtastic/web dev
```
### Build everything
```bash
pnpm -r build
```
### Run tests
```bash
pnpm -r test
```
### Lint + format
```bash
pnpm check
pnpm check:fix
```
## Developing
### Adding a new feature slice to `@meshtastic/sdk`
1. Create `packages/sdk/src/features/<slice>/` with `domain/`, `application/`, `infrastructure/`, `state/` subdirectories plus an `index.ts` barrel.
2. Implement a signals-backed store in `state/`.
3. Subscribe to the relevant `EventBus` channel(s) inside a `<Slice>Client.ts` class and write mapped domain entities to the store.
4. Wire the new client into `MeshClient` and re-export types from `packages/sdk/mod.ts`.
5. Add vitest coverage: domain invariants, use-cases against `createFakeTransport()`, and round-trip mapper fixtures.
6. If the slice has React callers, add a matching hook under `packages/sdk-react/src/hooks/`.
### Adding a new transport
Implement the `Transport` interface exported from `@meshtastic/sdk/transport`:
```ts
interfaceTransport{
toDevice: WritableStream<Uint8Array>;
fromDevice: ReadableStream<DeviceOutput>;
disconnect():Promise<void>;
}
```
The SDK does the framing and decoding — transports only supply raw bytes.
### Testing
Vitest is wired at the repo root and picks up `packages/*` projects. The SDK
ships `@meshtastic/sdk/testing` with `createFakeTransport()` for wiring tests
without real hardware.
## Publishing
Each publishable package has `build:npm` / `publish:npm` / `prepare:jsr` /
`publish:jsr` scripts. See each package's `package.json` for details.
## Repository activity
## Repository activity
@@ -42,56 +161,11 @@ All `Meshtastic JS` packages (core and transports) are published both to
How this monorepo proves correctness, and where coverage currently sits.
## Levels
Tests live in five tiers. Each PR should add coverage at the **lowest level that catches the regression**, and only climb tiers when that's not possible.
| Tier | Scope | Tooling | Where |
| --- | --- | --- | --- |
| 1. **Unit** | Pure functions, value objects, mappers, single classes with mocked deps | `vitest run` (Node env) | `*.test.ts` colocated with source |
| 2. **Slice integration** | Use-case + store + mapper exercised against in-memory deps; assert outbound bytes and signal state | `vitest` + `createFakeTransport()` | `*.test.ts` in slice dirs |
| 3. **Client integration** | `MeshClient` end-to-end with a fake transport feeding canned `FromRadio` packets | `vitest` + `@meshtastic/sdk/testing` | `packages/sdk/tests/integration/` |
| 4. **Storage integration** | Real Drizzle queries against sql.js in-memory; or against `@vitest/browser` for OPFS | `vitest` (Node + browser) | `packages/sdk-storage-sqlocal/{src,tests}` |
| 6. **E2E / simulator** | Whole stack: SDK → transport → simulator/firmware. Catches protocol drift | `@vitest/browser` for OPFS; `meshtasticd` simulator over TCP for protocol | future `tests/e2e/` |
## Per-package coverage gates
| Package | Required floor | Notes |
| --- | --- | --- |
| `packages/sdk/core` | every primitive (signals, EventBus, Queue, packet-codec, identifiers) has a unit test; lifecycle covered by `MeshClient.test.ts` | adopt `c8` thresholds once stable |
| `packages/sdk/features/*` | each slice ships: 1 domain invariant test, 1 use-case test against fake transport, 1 mapper round-trip (where mappers exist) | Integration covered by `tests/integration/fake-transport.test.ts` |
| `packages/sdk-react` | each public hook has a `renderHook` test that asserts initial render + re-render on signal change | uses jsdom; provider wrapper required |
| `packages/sdk-storage-sqlocal` | every repository method tested against sql.js in-memory; **at least one OPFS-real test per repo** runs in browser mode | sql.js validates SQL correctness; OPFS validates VFS / Worker plumbing |
| `packages/transport-*` | minimum: framing round-trip, disconnect cleans up streams, error path emits status | low-level; ship as is |
| `packages/web` | component tests at `34` baseline; new SDK-driven UI components must add a hook-mock test | currently all green |
## Current state (audit)
| Package | Test files | Tests pass | Gaps |
| --- | --- | --- | --- |
| `packages/sdk` | 7 | 25 ✅ | nodes/channels/config/telemetry/position/traceroute/files slices have **no tests**; no `MeshClient` lifecycle test (only fake-transport integration); no schema migration test |
| `packages/sdk-storage-sqlocal` | 2 | 8 ✅ | sql.js only — **no real OPFS test**, no Worker boot test, no cross-tab BroadcastChannel test (mocked away), no migration v1→v2 test |
| `packages/web` | 34 | 294 ✅ | no `useConnections` test; new `meshRegistry` + `sdkStorage` modules untested; chat persistence end-to-end not exercised |
| `packages/transport-*` | 1 each (5 of 7) | varies | `transport-deno` + `transport-mock` have no tests; transports likely lack disconnect/error coverage |
| `packages/core` | 0 | n/a | legacy, slated for deletion in Phase C; tolerable |
| `packages/ui` | 0 | n/a | pure presentational; visual regression only |
1.**`packages/sdk` slice tests** — one Use-case + one Mapper test per slice (`nodes`, `channels`, `config`, `telemetry`, `position`, `traceroute`). Pattern: build a stub `MeshClient`, dispatch a synthetic event, assert signal value or outbound bytes.
2.**`packages/sdk-react` hook tests** — for every hook listed above, mount under `<MeshProvider>`, drive a signal change, assert `result.current`. One file, ~15 cases.
4.**`packages/sdk-storage-sqlocal` migration test** — bootstrap empty DB, run `MIGRATIONS[]`, assert `_schema.version`. Then add a fake `version: 2` migration and prove it's applied idempotently.
5.**`packages/sdk-storage-sqlocal` browser mode** — add a second `vitest.browser.config.ts` using `@vitest/browser` (Playwright provider) so we exercise real OPFS + Worker. CI runs both modes.
6.**`packages/sdk-storage-sqlocal` BroadcastChannel test** — instantiate two `MultiTabCoordinator` instances in same process; one broadcasts, the other observes. (Node has no `BroadcastChannel` global; use `worker_threads`'s `BroadcastChannel` polyfill or jsdom env.)
7.**`packages/web``meshRegistry` + `sdkStorage` lazy-init test** — assert `getStorageDb()` returns the same promise on repeated calls and only opens the DB once.
8.**`packages/sdk-react` registry test** — mount `<MeshRegistryProvider>` with two clients, switch active, confirm a hook re-renders against the new client.
## E2E / simulator (Tier 6) — scope only
Out of immediate scope; documenting for a follow-up PR.
- Run `meshtasticd` (firmware simulator) in CI Docker via `services:` block.
- Spin up `MeshClient` with `TransportHTTP` pointed at the simulator's HTTP endpoint.
- Drive scripted scenarios: configure → send text → expect ack; channel update; node info exchange; traceroute.
- Use `@vitest/browser` so we also exercise the real OPFS persistence path during E2E.
- Run on `main` only (cost). Smoke subset on PR.
Until that lands, `createFakeTransport()` covers the protocol layer at unit/integration speed.
## Conventions
- Test file colocated with source: `Foo.ts` → `Foo.test.ts`.
- Integration tests under `tests/integration/`.
- Browser-mode tests use the suffix `.browser.test.ts` so they can be filtered.
- Protobuf fixtures live in `__fixtures__/*.fixtures.ts` next to mappers; binary data committed as base64, not raw bytes.
- Each test imports concrete classes from the source path (`./Foo.ts`), not the package barrel — fast type-check, zero re-export drift.
- No mocked SDK from inside SDK tests. Use `createFakeTransport()` and real `MeshClient` instances.
## Running
```sh
pnpm -r test# all packages, Node env
pnpm --filter @meshtastic/sdk test
pnpm --filter @meshtastic/sdk-storage-sqlocal test
"description":"Alerts on incoming bell/alert packets"
},
"advanced":{
"label":"Advanced",
"description":"Pin assignments and timing"
}
}
},
},
"mqtt":{
"mqtt":{
"title":"MQTT Settings",
"title":"MQTT",
"description":"Settings for the MQTT module",
"description":"MQTT module configuration",
"enabled":{
"enabled":{
"label":"Enabled",
"label":"MQTT enabled",
"description":"Enable or disable MQTT"
"description":"Enable or disable MQTT"
},
},
"address":{
"address":{
"label":"MQTT Server Address",
"label":"Address",
"description":"MQTT server address to use for default/custom servers"
"description":"MQTT server address to use for default/custom servers"
},
},
"username":{
"username":{
"label":"MQTT Username",
"label":"Username",
"description":"MQTT username to use for default/custom servers"
"description":"MQTT username to use for default/custom servers"
},
},
"password":{
"password":{
"label":"MQTT Password",
"label":"Password",
"description":"MQTT password to use for default/custom servers"
"description":"MQTT password to use for default/custom servers"
},
},
"encryptionEnabled":{
"encryptionEnabled":{
"label":"Encryption Enabled",
"label":"Encryption enabled",
"description":"Enable or disable MQTT encryption. Note: All messages are sent to the MQTT broker unencrypted if this option is not enabled, even when your uplink channels have encryption keys set. This includes position data."
"description":"Enable or disable MQTT encryption. Note: All messages are sent to the MQTT broker unencrypted if this option is not enabled, even when your uplink channels have encryption keys set. This includes position data."
},
},
"jsonEnabled":{
"jsonEnabled":{
"label":"JSON Enabled",
"label":"JSON output enabled",
"description":"Whether to send/consume JSON packets on MQTT"
"description":"Whether to send/consume JSON packets on MQTT"
},
},
"tlsEnabled":{
"tlsEnabled":{
"label":"TLS Enabled",
"label":"TLS enabled",
"description":"Enable or disable TLS"
"description":"Enable or disable TLS"
},
},
"root":{
"root":{
@@ -253,20 +289,20 @@
"description":"MQTT root topic to use for default/custom servers"
"description":"MQTT root topic to use for default/custom servers"
},
},
"proxyToClientEnabled":{
"proxyToClientEnabled":{
"label":"MQTT Client Proxy Enabled",
"label":"Proxy to client enabled",
"description":"Utilizes the network connection to proxy MQTT messages to the client."
"description":"Utilizes the network connection to proxy MQTT messages to the client."
},
},
"mapReportingEnabled":{
"mapReportingEnabled":{
"label":"Map Reporting Enabled",
"label":"Map reporting",
"description":"Your node will periodically send an unencrypted map report packet to the configured MQTT server, this includes id, short and long name, approximate location, hardware model, role, firmware version, LoRa region, modem preset and primary channel name."
"description":"Your node will periodically send an unencrypted map report packet to the configured MQTT server, this includes id, long and short name, approximate location, hardware model, role, firmware version, LoRa region, modem preset and primary channel name."
},
},
"mapReportSettings":{
"mapReportSettings":{
"publishIntervalSecs":{
"publishIntervalSecs":{
"label":"Map Report Publish Interval (s)",
"label":"Map reporting interval (seconds)",
"description":"Interval in seconds to publish map reports"
"description":"Interval in seconds to publish map reports"
},
},
"positionPrecision":{
"positionPrecision":{
"label":"Approximate Location",
"label":"Approximate location",
"description":"Position shared will be accurate within this distance",
"description":"Position shared will be accurate within this distance",
"options":{
"options":{
"metric_km23":"Within 23 km",
"metric_km23":"Within 23 km",
@@ -290,78 +326,108 @@
"imperial_ft300":"Within 300 feet",
"imperial_ft300":"Within 300 feet",
"imperial_ft150":"Within 150 feet"
"imperial_ft150":"Within 150 feet"
}
}
},
"shouldReportLocation":{
"label":"I agree.",
"description":"I have read and understand the above. I voluntarily consent to the unencrypted transmission of my node data via MQTT.",
"consentHeader":"Consent to Share Unencrypted Node Data via MQTT",
"consentText":"By enabling this feature, you acknowledge and expressly consent to the transmission of your device's real-time geographic location over the MQTT protocol without encryption. This location data may be used for purposes such as live map reporting, device tracking, and related telemetry functions."
}
}
},
"mqttConfigCard":{
"label":"MQTT Config",
"description":"MQTT broker connection"
},
"mapReportingCard":{
"label":"Map reporting",
"description":"Periodic unencrypted map report"
}
}
},
},
"neighborInfo":{
"neighborInfo":{
"title":"Neighbor Info Settings",
"title":"Neighbor Info",
"description":"Settings for the Neighbor Info module",
"description":"Settings for the Neighbor Info module",
"enabled":{
"enabled":{
"label":"Enabled",
"label":"Neighbor Info enabled",
"description":"Enable or disable Neighbor Info Module"
"description":"Enable or disable Neighbor Info Module"
},
},
"updateInterval":{
"updateInterval":{
"label":"Update Interval",
"label":"Update interval (seconds)",
"description":"Interval in seconds of how often we should try to send our Neighbor Info to the mesh"
"description":"Interval in seconds of how often we should try to send our Neighbor Info to the mesh"
},
"neighborInfoConfig":{
"label":"Neighbor Info Config",
"description":"Neighbor Info configuration"
},
"transmitOverLora":{
"label":"Transmit over LoRa",
"description":"Whether NeighborInfo should be transmitted over LoRa. Not available on a channel with default key and name."
}
}
},
},
"paxcounter":{
"paxcounter":{
"title":"Paxcounter Settings",
"title":"Paxcounter",
"description":"Settings for the Paxcounter module",
"description":"Settings for the Paxcounter module",
"enabled":{
"enabled":{
"label":"Module Enabled",
"label":"Paxcounter enabled",
"description":"Enable Paxcounter"
"description":"Enable Paxcounter"
},
},
"paxcounterUpdateInterval":{
"paxcounterUpdateInterval":{
"label":"Update Interval (seconds)",
"label":"Update interval (seconds)",
"description":"How long to wait between sending paxcounter packets"
"description":"How long to wait between sending paxcounter packets"
},
},
"wifiThreshold":{
"wifiThreshold":{
"label":"WiFi RSSI Threshold",
"label":"WiFi RSSI threshold (defaults to -80)",
"description":"At what WiFi RSSI level should the counter increase. Defaults to -80."
"description":"At what WiFi RSSI level should the counter increase. Defaults to -80."
},
},
"bleThreshold":{
"bleThreshold":{
"label":"BLE RSSI Threshold",
"label":"BLE RSSI threshold (defaults to -80)",
"description":"At what BLE RSSI level should the counter increase. Defaults to -80."
"description":"At what BLE RSSI level should the counter increase. Defaults to -80."
},
"paxcounterConfig":{
"label":"Paxcounter Config",
"description":"Paxcounter configuration"
}
}
},
},
"rangeTest":{
"rangeTest":{
"title":"Range Test Settings",
"title":"Range Test",
"description":"Settings for the Range Test module",
"description":"Settings for the Range Test module",
"enabled":{
"enabled":{
"label":"Module Enabled",
"label":"Range test enabled",
"description":"Enable Range Test"
"description":"Enable Range Test"
},
},
"sender":{
"sender":{
"label":"Message Interval",
"label":"Sender message interval (seconds)",
"description":"How long to wait between sending test packets"
"description":"How long to wait between sending test packets"
},
},
"save":{
"save":{
"label":"Save CSV to storage",
"label":"Save .CSV in storage (ESP32 only)",
"description":"ESP32 Only"
"description":"ESP32 Only"
},
"rangeTestConfig":{
"label":"Range Test Config",
"description":"Range Test configuration"
}
}
},
},
"serial":{
"serial":{
"title":"Serial Settings",
"title":"Serial",
"description":"Settings for the Serial module",
"description":"Settings for the Serial module",
"enabled":{
"enabled":{
"label":"Module Enabled",
"label":"Serial enabled",
"description":"Enable Serial output"
"description":"Enable Serial output"
},
},
"echo":{
"echo":{
"label":"Echo",
"label":"Echo enabled",
"description":"Any packets you send will be echoed back to your device"
"description":"Any packets you send will be echoed back to your device"
},
},
"rxd":{
"rxd":{
"label":"Receive Pin",
"label":"RX",
"description":"Set the GPIO pin to the RXD pin you have set up."
"description":"Set the GPIO pin to the RXD pin you have set up."
},
},
"txd":{
"txd":{
"label":"Transmit Pin",
"label":"TX",
"description":"Set the GPIO pin to the TXD pin you have set up."
"description":"Set the GPIO pin to the TXD pin you have set up."
},
},
"baud":{
"baud":{
"label":"Baud Rate",
"label":"Serial baud rate",
"description":"The serial baud rate"
"description":"The serial baud rate"
},
},
"timeout":{
"timeout":{
@@ -369,23 +435,27 @@
"description":"Seconds to wait before we consider your packet as 'done'"
"description":"Seconds to wait before we consider your packet as 'done'"
},
},
"mode":{
"mode":{
"label":"Mode",
"label":"Serial mode",
"description":"Select Mode"
"description":"Select Mode"
},
},
"overrideConsoleSerialPort":{
"overrideConsoleSerialPort":{
"label":"Override Console Serial Port",
"label":"Override console serial port",
"description":"If you have a serial port connected to the console, this will override it."
"description":"If you have a serial port connected to the console, this will override it."
},
"serialConfig":{
"label":"Serial Config",
"description":"Serial module configuration"
}
}
},
},
"storeForward":{
"storeForward":{
"title":"Store & Forward Settings",
"title":"Store & Forward",
"description":"Settings for the Store & Forward module",
"description":"Settings for the Store & Forward module",
"enabled":{
"enabled":{
"label":"Module Enabled",
"label":"Store & Forward enabled",
"description":"Enable Store & Forward"
"description":"Enable Store & Forward"
},
},
"heartbeat":{
"heartbeat":{
"label":"Heartbeat Enabled",
"label":"Heartbeat",
"description":"Enable Store & Forward heartbeat"
"description":"Enable Store & Forward heartbeat"
},
},
"records":{
"records":{
@@ -399,50 +469,66 @@
"historyReturnWindow":{
"historyReturnWindow":{
"label":"History return window",
"label":"History return window",
"description":"Return records from this time window (minutes)"
"description":"Return records from this time window (minutes)"
},
"storeForwardConfig":{
"label":"Store & Forward Config",
"description":"Store & Forward configuration"
},
"isServer":{
"label":"Server",
"description":"Run as a Store & Forward server"
}
}
},
},
"telemetry":{
"telemetry":{
"title":"Telemetry Settings",
"title":"Telemetry",
"description":"Settings for the Telemetry module",
"description":"Settings for the Telemetry module",
"description":"The POSIX timezone string for the device",
"description":"Timezone for dates on the device screen and log.",
"label":"POSIX Timezone"
"label":"Timezone"
},
},
"rebroadcastMode":{
"rebroadcastMode":{
"description":"How to handle rebroadcasting",
"description":"How to handle rebroadcasting",
@@ -52,52 +52,75 @@
},
},
"role":{
"role":{
"description":"What role the device performs on the mesh",
"description":"What role the device performs on the mesh",
"label":"Role"
"label":"Device Role"
},
"options":{
"label":"Options",
"description":"Device role, rebroadcast mode, and node-info broadcast cadence"
},
"hardware":{
"label":"Hardware",
"description":"Hardware-related toggles"
},
"timeZone":{
"label":"Time Zone",
"description":"POSIX time zone for dates on the device screen and log"
},
"gpio":{
"label":"GPIO",
"description":"GPIO pin overrides"
},
"useBrowserTimeZone":{
"label":"Use browser time zone"
}
}
},
},
"bluetooth":{
"bluetooth":{
"title":"Bluetooth Settings",
"title":"Bluetooth",
"description":"Settings for the Bluetooth module",
"description":"Settings for the Bluetooth module",
"note":"Note: Some devices (ESP32) cannot use both Bluetooth and WiFi at the same time.",
"note":"Note: Some devices (ESP32) cannot use both Bluetooth and WiFi at the same time.",
"enabled":{
"enabled":{
"description":"Enable or disable Bluetooth",
"description":"Enable or disable Bluetooth",
"label":"Enabled"
"label":"Bluetooth enabled"
},
},
"pairingMode":{
"pairingMode":{
"description":"Pin selection behaviour.",
"description":"Pin selection behaviour.",
"label":"Pairing mode"
"label":"Pairing mode"
},
},
"pin":{
"pin":{
"description":"Pin to use when pairing",
"description":"PIN to use when pairing in fixed-PIN mode",
"label":"Pin"
"label":"Fixed PIN"
},
"bluetoothConfig":{
"label":"Bluetooth Config",
"description":"Bluetooth configuration"
}
}
},
},
"display":{
"display":{
"description":"Settings for the device display",
"description":"Settings for the device display",
"title":"Display Settings",
"title":"Display",
"headingBold":{
"headingBold":{
"description":"Bolden the heading text",
"description":"Bolden the heading text",
"label":"Bold Heading"
"label":"Bold Heading"
},
},
"carouselDelay":{
"carouselDelay":{
"description":"How fast to cycle through windows",
"description":"How fast to cycle through windows",
"label":"Carousel Delay"
"label":"Carousel interval"
},
},
"compassNorthTop":{
"compassNorthTop":{
"description":"Fix north to the top of compass",
"description":"Fix north to the top of compass",
"label":"Compass North Top"
"label":"Always point north"
},
},
"displayMode":{
"displayMode":{
"description":"Screen layout variant",
"description":"Screen layout variant",
"label":"Display Mode"
"label":"Display mode"
},
},
"displayUnits":{
"displayUnits":{
"description":"Display metric or imperial units",
"description":"Display metric or imperial units",
"label":"Display Units"
"label":"Display units"
},
},
"flipScreen":{
"flipScreen":{
"description":"Flip display 180 degrees",
"description":"Flip display 180 degrees",
"label":"Flip Screen"
"label":"Flip screen"
},
},
"gpsDisplayUnits":{
"gpsDisplayUnits":{
"description":"Coordinate display format",
"description":"Coordinate display format",
@@ -105,35 +128,47 @@
},
},
"oledType":{
"oledType":{
"description":"Type of OLED screen attached to the device",
"description":"Type of OLED screen attached to the device",
"label":"OLED Type"
"label":"OLED type"
},
},
"screenTimeout":{
"screenTimeout":{
"description":"Turn off the display after this long",
"description":"Turn off the display after this long",
"label":"Screen Timeout"
"label":"Screen on for"
},
},
"twelveHourClock":{
"twelveHourClock":{
"description":"Use 12-hour clock format",
"description":"Display time in 12h format",
"label":"12-Hour Clock"
"label":"Use 12h clock format"
},
},
"wakeOnTapOrMotion":{
"wakeOnTapOrMotion":{
"description":"Wake the device on tap or motion",
"description":"Wake the device on tap or motion",
"label":"Wake on Tap or Motion"
"label":"Wake on tap or motion"
},
},
"enableMessageBubbles":{
"enableMessageBubbles":{
"label":"Message Bubbles",
"label":"Message Bubbles",
"description":"Display incoming messages as bubbles on the device screen"
"description":"Display incoming messages as bubbles on the device screen"
},
"deviceDisplay":{
"label":"Device Display",
"description":"Display orientation and clock"
},
"advanced":{
"label":"Advanced",
"description":"Advanced display settings"
},
"compassOrientation":{
"label":"Compass orientation",
"description":"Compass orientation relative to the screen"
}
}
},
},
"lora":{
"lora":{
"title":"Mesh Settings",
"title":"LoRa",
"description":"Settings for the LoRa mesh",
"description":"LoRa radio configuration",
"bandwidth":{
"bandwidth":{
"description":"Channel bandwidth in kHz",
"description":"Channel bandwidth in kHz",
"label":"Bandwidth"
"label":"Bandwidth"
},
},
"boostedRxGain":{
"boostedRxGain":{
"description":"Boosted RX gain",
"description":"Boosted RX gain",
"label":"Boosted RX Gain"
"label":"RX Boosted Gain"
},
},
"codingRate":{
"codingRate":{
"description":"The denominator of the coding rate",
"description":"The denominator of the coding rate",
@@ -144,24 +179,24 @@
"label":"Frequency Offset"
"label":"Frequency Offset"
},
},
"frequencySlot":{
"frequencySlot":{
"description":"LoRa frequency channel number",
"description":"Your node's operating frequency is calculated based on the region, modem preset, and this field. When 0, the slot is automatically calculated based on the primary channel name and will change from the default public slot.",
"label":"Frequency Slot"
"label":"Frequency Slot"
},
},
"hopLimit":{
"hopLimit":{
"description":"Maximum number of hops",
"description":"Sets the maximum number of hops, default is 3. Increasing hops also increases congestion and should be used carefully. 0 hop broadcast messages will not get ACKs.",
"label":"Hop Limit"
"label":"Number of Hops"
},
},
"ignoreMqtt":{
"ignoreMqtt":{
"description":"Don't forward MQTT messages over the mesh",
"description":"Don't forward MQTT messages over the mesh",
"label":"Ignore MQTT"
"label":"Ignore MQTT"
},
},
"modemPreset":{
"modemPreset":{
"description":"Modem preset to use",
"description":"Available modem presets, default is Long Fast.",
"label":"Modem Preset"
"label":"Presets"
},
},
"okToMqtt":{
"okToMqtt":{
"description":"When set to true, this configuration indicates that the user approves the packet to be uploaded to MQTT. If set to false, remote nodes are requested not to forward packets to MQTT",
"description":"When set to true, this configuration indicates that the user approves the packet to be uploaded to MQTT. If set to false, remote nodes are requested not to forward packets to MQTT",
"label":"OK to MQTT"
"label":"Ok to MQTT"
},
},
"overrideDutyCycle":{
"overrideDutyCycle":{
"description":"Override Duty Cycle",
"description":"Override Duty Cycle",
@@ -169,10 +204,10 @@
},
},
"overrideFrequency":{
"overrideFrequency":{
"description":"Override frequency",
"description":"Override frequency",
"label":"Override Frequency"
"label":"Frequency Override"
},
},
"region":{
"region":{
"description":"Sets the region for your node",
"description":"The region where you will be using your radios.",
"label":"Region"
"label":"Region"
},
},
"spreadingFactor":{
"spreadingFactor":{
@@ -210,15 +245,23 @@
"serialHalOnly":{
"serialHalOnly":{
"label":"Serial HAL Only",
"label":"Serial HAL Only",
"description":"Communicate with the radio exclusively over the serial hardware abstraction layer"
"description":"Communicate with the radio exclusively over the serial hardware abstraction layer"
},
"optionsCard":{
"label":"Options",
"description":"LoRa core options"
},
"advancedCard":{
"label":"Advanced",
"description":"Advanced LoRa parameters"
}
}
},
},
"network":{
"network":{
"title":"WiFi Config",
"title":"Network",
"description":"WiFi radio configuration",
"description":"Network configuration",
"note":"Note: Some devices (ESP32) cannot use both Bluetooth and WiFi at the same time.",
"note":"Note: Some devices (ESP32) cannot use both Bluetooth and WiFi at the same time.",
"addressMode":{
"addressMode":{
"description":"Address assignment selection",
"description":"Address assignment selection",
"label":"Address Mode"
"label":"IPv4 mode"
},
},
"dns":{
"dns":{
"description":"DNS Server",
"description":"DNS Server",
@@ -226,7 +269,7 @@
},
},
"ethernetEnabled":{
"ethernetEnabled":{
"description":"Enable or disable the Ethernet port",
"description":"Enable or disable the Ethernet port",
"label":"Enabled"
"label":"Ethernet enabled"
},
},
"gateway":{
"gateway":{
"description":"Default Gateway",
"description":"Default Gateway",
@@ -238,7 +281,7 @@
},
},
"psk":{
"psk":{
"description":"Network password",
"description":"Network password",
"label":"PSK"
"label":"Password"
},
},
"ssid":{
"ssid":{
"description":"Network name",
"description":"Network name",
@@ -250,16 +293,17 @@
},
},
"wifiEnabled":{
"wifiEnabled":{
"description":"Enable or disable the WiFi radio",
"description":"Enable or disable the WiFi radio",
"label":"Enabled"
"label":"WiFi enabled"
},
},
"meshViaUdp":{
"meshViaUdp":{
"label":"Mesh via UDP"
"label":"Enabled",
"description":"Forward mesh packets over UDP"
},
},
"ntpServer":{
"ntpServer":{
"label":"NTP Server"
"label":"NTP server"
},
},
"rsyslogServer":{
"rsyslogServer":{
"label":"Rsyslog Server"
"label":"rsyslog server"
},
},
"ethernetConfigSettings":{
"ethernetConfigSettings":{
"description":"Ethernet port configuration",
"description":"Ethernet port configuration",
@@ -280,18 +324,30 @@
"udpConfigSettings":{
"udpConfigSettings":{
"description":"UDP over Mesh configuration",
"description":"UDP over Mesh configuration",
"label":"UDP Config"
"label":"UDP Config"
},
"wifiOptions":{
"label":"WiFi Options",
"description":"WiFi configuration"
},
"ethernetOptionsCard":{
"label":"Ethernet Options",
"description":"Ethernet configuration"
},
"advancedCard":{
"label":"Advanced",
"description":"NTP, rsyslog, IPv4 mode and address overrides"
}
}
},
},
"position":{
"position":{
"title":"Position Settings",
"title":"Position",
"description":"Settings for the position module",
"description":"Position settings",
"broadcastInterval":{
"broadcastInterval":{
"description":"How often your position is sent out over the mesh",
"description":"The maximum interval that can elapse without a node broadcasting a position.",
"label":"Broadcast Interval"
"label":"Broadcast Interval"
},
},
"enablePin":{
"enablePin":{
"description":"GPS module enable pin override",
"description":"GPS enable GPIO pin override",
"label":"Enable Pin"
"label":"GPS EN GPIO"
},
},
"fixedPosition":{
"fixedPosition":{
"description":"Don't report GPS position, but a manually-specified one",
"description":"Don't report GPS position, but a manually-specified one",
@@ -311,35 +367,35 @@
},
},
"gpsMode":{
"gpsMode":{
"description":"Configure whether device GPS is Enabled, Disabled, or Not Present",
"description":"Configure whether device GPS is Enabled, Disabled, or Not Present",
"label":"GPS Mode"
"label":"GPS Mode (Physical Hardware)"
},
},
"gpsUpdateInterval":{
"gpsUpdateInterval":{
"description":"How often a GPS fix should be acquired",
"description":"How often should we try to get a GPS position (<10sec keeps GPS on).",
"label":"GPS Update Interval"
"label":"GPS Polling Interval"
},
},
"positionFlags":{
"positionFlags":{
"description":"Optional fields to include when assembling position messages. The more fields are selected, the larger the message will be leading to longer airtime usage and a higher risk of packet loss.",
"description":"Optional fields to include when assembling position messages. The more fields are included, the larger the message will be — leading to longer airtime and a higher risk of packet loss.",
"label":"Position Flags"
"label":"Position Flags"
},
},
"receivePin":{
"receivePin":{
"description":"GPS module RX pin override",
"description":"GPS receive GPIO pin override",
"label":"Receive Pin"
"label":"GPS Receive GPIO"
},
},
"smartPositionEnabled":{
"smartPositionEnabled":{
"description":"Only send position when there has been a meaningful change in location",
"description":"Only send position when there has been a meaningful change in location",
"label":"Enable Smart Position"
"label":"Smart Position"
},
},
"smartPositionMinDistance":{
"smartPositionMinDistance":{
"description":"Minimum distance (in meters) that must be traveled before a position update is sent",
"description":"The minimum distance change in meters to be considered for a smart position broadcast.",
"label":"Smart Position Minimum Distance"
"label":"Smart Distance"
},
},
"smartPositionMinInterval":{
"smartPositionMinInterval":{
"description":"Minimum interval (in seconds) that must pass before a position update is sent",
"description":"The fastest that position updates will be sent if the minimum distance has been satisfied.",
"label":"Smart Position Minimum Interval"
"label":"Smart Interval"
},
},
"transmitPin":{
"transmitPin":{
"description":"GPS module TX pin override",
"description":"GPS transmit GPIO pin override",
"label":"Transmit Pin"
"label":"GPS Transmit GPIO"
},
},
"intervalsSettings":{
"intervalsSettings":{
"description":"How often to send position updates",
"description":"How often to send position updates",
@@ -358,16 +414,33 @@
"unset":"Unset",
"unset":"Unset",
"vehicleHeading":"Vehicle heading",
"vehicleHeading":"Vehicle heading",
"vehicleSpeed":"Vehicle speed"
"vehicleSpeed":"Vehicle speed"
},
"positionPacket":{
"label":"Position Packet",
"description":"Position broadcast configuration"
},
"deviceGps":{
"label":"Device GPS",
"description":"Device GPS configuration"
},
"advancedDeviceGps":{
"label":"Advanced Device GPS",
"description":"GPIO pin overrides for the GPS hardware"
},
"useBrowserLocation":{
"label":"Use browser location",
"busy":"Reading location…",
"failed":"Could not read browser location"
}
}
},
},
"power":{
"power":{
"adcMultiplierOverride":{
"adcMultiplierOverride":{
"description":"Used for tweaking battery voltage reading",
"description":"Used for tweaking battery voltage reading",
"label":"ADC Multiplier Override ratio"
"label":"ADC multiplier override ratio"
},
},
"ina219Address":{
"ina219Address":{
"description":"Address of the INA219 battery monitor",
"description":"Address of the INA219 battery monitor",
"label":"INA219 Address"
"label":"Battery INA_2XX I2C address"
},
},
"lightSleepDuration":{
"lightSleepDuration":{
"description":"How long the device will be in light sleep for",
"description":"How long the device will be in light sleep for",
@@ -375,11 +448,11 @@
},
},
"minimumWakeTime":{
"minimumWakeTime":{
"description":"Minimum amount of time the device will stay awake for after receiving a packet",
"description":"Minimum amount of time the device will stay awake for after receiving a packet",
"label":"Minimum Wake Time"
"label":"Minimum wake time"
},
},
"noConnectionBluetoothDisabled":{
"noConnectionBluetoothDisabled":{
"description":"If the device does not receive a Bluetooth connection, the BLE radio will be disabled after this long",
"description":"If the device does not receive a Bluetooth connection, the BLE radio will be disabled after this long",
"label":"No Connection Bluetooth Disabled"
"label":"Wait for Bluetooth duration"
},
},
"powerSavingEnabled":{
"powerSavingEnabled":{
"description":"Select if powered from a low-current source (i.e. solar), to minimize power consumption as much as possible.",
"description":"Select if powered from a low-current source (i.e. solar), to minimize power consumption as much as possible.",
@@ -387,11 +460,11 @@
},
},
"shutdownOnBatteryDelay":{
"shutdownOnBatteryDelay":{
"description":"Automatically shutdown node after this long when on battery, 0 for indefinite",
"description":"Automatically shutdown node after this long when on battery, 0 for indefinite",
"label":"Shutdown on battery delay"
"label":"Shutdown on power loss"
},
},
"superDeepSleepDuration":{
"superDeepSleepDuration":{
"description":"How long the device will be in super deep sleep for",
"description":"How long the device will be in super deep sleep for",
"label":"Super Deep Sleep Duration"
"label":"Super deep sleep duration"
},
},
"powerConfigSettings":{
"powerConfigSettings":{
"description":"Settings for the power module",
"description":"Settings for the power module",
@@ -400,23 +473,27 @@
"sleepSettings":{
"sleepSettings":{
"description":"Sleep settings for the power module",
"description":"Sleep settings for the power module",
"label":"Sleep Settings"
"label":"Sleep Settings"
},
"powerConfig":{
"label":"Power Config",
"description":"Power and sleep configuration"
}
}
},
},
"security":{
"security":{
"description":"Settings for the Security configuration",
"description":"Settings for the Security configuration",
"title":"Security Settings",
"title":"Security",
"button_backupKey":"Backup Key",
"button_backupKey":"Backup Key",
"adminChannelEnabled":{
"adminChannelEnabled":{
"description":"Allow incoming device control over the insecure legacy admin channel",
"description":"Allow incoming device control over the insecure legacy admin channel",
"label":"Allow Legacy Admin"
"label":"Legacy Admin channel"
},
},
"enableDebugLogApi":{
"enableDebugLogApi":{
"description":"Output live debug logging over serial, view and export position-redacted device logs over Bluetooth",
"description":"Output live debug logging over serial, view and export position-redacted device logs over Bluetooth",
"label":"Enable Debug Log API"
"label":"Debug log API enabled"
},
},
"managed":{
"managed":{
"description":"If enabled, device configuration options are only able to be changed remotely by a Remote Admin node via admin messages. Do not enable this option unless at least one suitable Remote Admin node has been setup, and the public key is stored in one of the fields above.",
"description":"If enabled, device configuration options are only able to be changed remotely by a Remote Admin node via admin messages. Do not enable this option unless at least one suitable Remote Admin node has been setup, and the public key is stored in one of the fields above.",
"label":"Managed"
"label":"Managed Mode"
},
},
"privateKey":{
"privateKey":{
"description":"Used to create a shared key with a remote device",
"description":"Used to create a shared key with a remote device",
@@ -436,7 +513,7 @@
},
},
"serialOutputEnabled":{
"serialOutputEnabled":{
"description":"Serial Console over the Stream API",
"description":"Serial Console over the Stream API",
"label":"Serial Output Enabled"
"label":"Serial console"
},
},
"tertiaryAdminKey":{
"tertiaryAdminKey":{
"description":"The tertiary public key authorized to send admin messages to this node",
"description":"The tertiary public key authorized to send admin messages to this node",
"description":"Managed-mode and legacy admin channel"
}
}
},
},
"user":{
"user":{
"title":"User Settings",
"title":"User",
"description":"Configure your device name and identity settings",
"description":"Configure your device name and identity settings",
"longName":{
"longName":{
"label":"Long Name",
"label":"Long Name",
@@ -472,11 +565,23 @@
},
},
"isUnmessageable":{
"isUnmessageable":{
"label":"Unmessageable",
"label":"Unmessageable",
"description":"Used to identify unmonitored or infrastructure nodes so that messaging is not available to nodes that will never respond."
"description":"Unmonitored or Infrastructure"
},
},
"isLicensed":{
"isLicensed":{
"label":"Licensed amateur radio (HAM)",
"label":"Licensed amateur radio (Ham)",
"description":"Enable if you are a licensed amateur radio operator, enabling this option disables encryption and is not compatible with the default Meshtastic network."
"description":"Enabling this option disables encryption and is not compatible with the default Meshtastic network."
},
"userConfig":{
"label":"User Config",
"description":"Identity and licensing"
},
"nodeId":{
"label":"Node ID",
"description":"Read-only — assigned by the device"
},
"hardwareModel":{
"label":"Hardware model",
"description":"Read-only — reported by the device"
"description":"Alerts on incoming bell/alert packets"
},
"advanced":{
"label":"Advanced",
"description":"Pin assignments and timing"
}
}
},
},
"mqtt":{
"mqtt":{
@@ -294,7 +330,21 @@
"imperial_ft300":"Within 300 feet",
"imperial_ft300":"Within 300 feet",
"imperial_ft150":"Within 150 feet"
"imperial_ft150":"Within 150 feet"
}
}
},
"shouldReportLocation":{
"label":"I agree.",
"description":"I have read and understand the above. I voluntarily consent to the unencrypted transmission of my node data via MQTT.",
"consentHeader":"Consent to Share Unencrypted Node Data via MQTT",
"consentText":"By enabling this feature, you acknowledge and expressly consent to the transmission of your device's real-time geographic location over the MQTT protocol without encryption. This location data may be used for purposes such as live map reporting, device tracking, and related telemetry functions."
}
}
},
"mqttConfigCard":{
"label":"MQTT Config",
"description":"MQTT broker connection"
},
"mapReportingCard":{
"label":"Map reporting",
"description":"Periodic unencrypted map report"
}
}
},
},
"neighborInfo":{
"neighborInfo":{
@@ -307,6 +357,14 @@
"updateInterval":{
"updateInterval":{
"label":"Update Interval",
"label":"Update Interval",
"description":"Interval in seconds of how often we should try to send our Neighbor Info to the mesh"
"description":"Interval in seconds of how often we should try to send our Neighbor Info to the mesh"
},
"neighborInfoConfig":{
"label":"Neighbor Info Config",
"description":"Neighbor Info configuration"
},
"transmitOverLora":{
"label":"Transmit over LoRa",
"description":"Whether NeighborInfo should be transmitted over LoRa. Not available on a channel with default key and name."
}
}
},
},
"paxcounter":{
"paxcounter":{
@@ -327,6 +385,10 @@
"bleThreshold":{
"bleThreshold":{
"label":"BLE RSSI Threshold",
"label":"BLE RSSI Threshold",
"description":"At what BLE RSSI level should the counter increase. Defaults to -80."
"description":"At what BLE RSSI level should the counter increase. Defaults to -80."
},
"paxcounterConfig":{
"label":"Paxcounter Config",
"description":"Paxcounter configuration"
}
}
},
},
"rangeTest":{
"rangeTest":{
@@ -343,6 +405,10 @@
"save":{
"save":{
"label":"Save CSV to storage",
"label":"Save CSV to storage",
"description":"ESP32 Only"
"description":"ESP32 Only"
},
"rangeTestConfig":{
"label":"Range Test Config",
"description":"Range Test configuration"
}
}
},
},
"serial":{
"serial":{
@@ -379,6 +445,10 @@
"overrideConsoleSerialPort":{
"overrideConsoleSerialPort":{
"label":"Override Console Serial Port",
"label":"Override Console Serial Port",
"description":"If you have a serial port connected to the console, this will override it."
"description":"If you have a serial port connected to the console, this will override it."
},
"serialConfig":{
"label":"Serial Config",
"description":"Serial module configuration"
}
}
},
},
"storeForward":{
"storeForward":{
@@ -403,6 +473,14 @@
"historyReturnWindow":{
"historyReturnWindow":{
"label":"History return window",
"label":"History return window",
"description":"Return records from this time window (minutes)"
"description":"Return records from this time window (minutes)"
},
"storeForwardConfig":{
"label":"Store & Forward Config",
"description":"Store & Forward configuration"
},
"isServer":{
"label":"Server",
"description":"Run as a Store & Forward server"
}
}
},
},
"telemetry":{
"telemetry":{
@@ -451,6 +529,14 @@
"airQualityScreenEnabled":{
"airQualityScreenEnabled":{
"label":"Air Quality Screen Enabled",
"label":"Air Quality Screen Enabled",
"description":"Show the Air Quality telemetry on the device screen"
"description":"Show the Air Quality telemetry on the device screen"
},
"telemetryConfig":{
"label":"Telemetry Config",
"description":"Telemetry configuration"
},
"deviceTelemetryEnabled":{
"label":"Send Device Telemetry",
"description":"Enable/Disable the device telemetry module to send metrics to the mesh."
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hermes
