Files
web/apps/web
Ben Meadors ad692eef74 test(e2e): real-device Playwright messaging suite (#1121)
* 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>
2026-06-20 11:19:50 -04:00
..
2026-06-16 20:30:08 -04:00
2026-06-16 20:30:08 -04:00
2026-06-16 20:30:08 -04:00

Meshtastic Web

CI CLA assistant Fiscal Contributors Vercel

Overview

Official Meshtastic web interface, that can be hosted or served from a node

Hosted version

Stats

Alt

Self-host

The client can be self hosted using the precompiled container images with an OCI compatible runtime such as Docker or Podman. The base image used is Nginx 1.27

# With Docker
docker run -d -p 8080:8080 --restart always --name Meshtastic-Web ghcr.io/meshtastic/web

#With Podman
podman run -d -p 8080:8080 --restart always --name Meshtastic-Web ghcr.io/meshtastic/web

Release Schedule

Our release process follows these guidelines:

  • Versioning: We use Semantic Versioning (Major.Minor.Patch).
  • Stable Releases: Published around the beginning of each month (e.g., v2.6.1).
  • Pre-releases: A pre-release is typically issued mid-month for testing and early adoption.
  • Nightly Builds: An experimental Docker image containing the latest cutting-edge features and fixes is automatically built nightly from the main branch.

Nightly Builds

# With Docker
docker run -d -p 8080:8080 --restart always --name Meshtastic-Web ghcr.io/meshtastic/web:nightly
#With Podman
podman run -d -p 8080:8080 --restart always --name Meshtastic-Web ghcr.io/meshtastic/web:nightly

Warning

  • Nightly builds represent the latest development state and may contain breaking changes
  • These builds undergo automated testing but may be less stable than tagged release versions
  • Not recommended for production environments unless you are actively testing new features
  • No guarantee of backward compatibility between nightly builds

Version Information

Each nightly build is tagged with:

  • The nightly tag for the latest build
  • A specific SHA for build reproducibility

Feedback

If you encounter any issues with nightly builds, please report them in our issues tracker. Your feedback helps improve the stability of future releases

Development & Building

You'll need to download the package manager used with this repo. You can install it by visiting pnpm.io and following the installation instructions listed on the home page.

Development

Install the dependencies.

cd packages/web &&
pnpm install

Start the development server:

pnpm run dev

Building and Packaging

Build the project:

pnpm run build

GZip the output:

pnpm run package

Why pnpm?

Meshtastic Web uses pnpm as its package manager for several compelling reasons:

  • Efficient Storage: pnpm uses content-addressable storage, avoiding duplication of packages across projects and saving significant disk space.
  • Fast Performance: Faster package installation compared to other package managers through symlinks and efficient dependency resolution.
  • Strict Dependency Management: Prevents access to unlisted dependencies, ensuring better project reliability and security.
  • Workspace Support: Excellent monorepo support with workspaces for managing multiple packages efficiently.
  • Reproducible Builds: Lockfile ensures consistent builds across all environments.

Contributing

We welcome contributions! Heres how the deployment flow works for pull requests:

  • Preview Deployments:
    Every pull request automatically generates a preview deployment on Vercel. This allows you and reviewers to easily preview changes before merging.

  • Staging Environment (client-test):
    Once your PR is merged, your changes will be available on our staging site: client-test.meshtastic.org.
    This environment supports rapid feature iteration and testing without impacting the production site.

  • Production Releases:
    At regular intervals, stable and fully tested releases are promoted to our production site: client.meshtastic.org.
    This is the primary interface used by the public to connect with their Meshtastic nodes.

Please review our Contribution Guidelines before submitting a pull request. We appreciate your help in making the project better!