BLE-only locators can't hold the MQTT/TLS connection themselves — a phone
relays their data — so handing the phone a device's permanent client-cert
key would export its identity to every phone it pairs with. Instead the
device signs a server-issued nonce with its permanent key over BLE; once
verified, the backend mints a short-lived session certificate for the
phone's actual MQTT connection, keeping the permanent key on-device always.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Introduces a CA/PKI module so field devices can authenticate to Mosquitto
over TLS (8883) with per-device client certificates (CN = serial number)
instead of a shared password, with matching Devices/MQTT-Certs UI. Adds
live transmitter position tracking alongside logged points, an MQTTS
transport option in the simulator for exercising the real cert-auth path,
and Swagger API docs at /api/docs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Device gains disabledReason (cleared automatically on re-enable). The
devices admin page prompts for a reason when disabling, and shows it
under the device's status once disabled.
New public GET /api/devices/:serial/status lets a field device check
whether it's disabled and why, before any user session exists —
unauthenticated by design, matching the existing serial-based trust
model used for devices/<serial>/log ingestion, and only ever reveals
a boolean plus a short reason string.
The devices/<serial>/log ingest path didn't check isActive at all
(the devices/<mqttUsername>/points path already did) — closed that
gap for both "log" and "status" message types so a disabled device's
data is rejected regardless of which path it arrives on.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds devices/<serial>/log as a job-anchored MQTT ingest path: a locator
identifies itself by serial in the topic (auto-registered on first
sight, org resolved from the job in the payload) rather than by a
pre-provisioned broker credential. Device.serialNumber is now globally
unique so the bare topic segment is enough to resolve identity.
Locator lookup/auto-register logic is shared (LocatorRegistryService)
between this and the existing devices/<mqttUsername>/points path.
New /sim page (own header, outside the main app nav) simulates a
transmitter: pick an open job or create one, set a serial number and
telemetry defaults, and send points one at a time or on an interval
along a simulated walking path. It calls a new authenticated backend
endpoint (POST /orgs/:orgId/sim/publish) that publishes onto the real
broker rather than writing the DB directly, so the simulator exercises
the actual ingest pipeline end-to-end.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the device-events demo with the actual product:
- Prisma + PostGIS data layer (postgis/postgis:17-3.5). Lat/lng decimals
are the source of truth; a generated geometry(Point,4326) column with
a GIST index backs bbox queries. Migrations apply on container boot.
- JWT auth (bcryptjs + httpOnly cookie) with public registration that
creates an org; per-org roles (ORG_ADMIN/MEMBER/VIEWER) enforced by
guards on all /orgs/:orgId routes.
- Scoped API keys (X-API-Key, sha256-hashed, shown once) for
programmatic access, manageable by org admins.
- REST API: jobs/tickets CRUD with filters, points query (time range,
recordedAt cursor, bbox), members, devices, api-keys.
- MQTT ingest: devices publish to devices/{username}/points and /jobs;
unknown tickets auto-create stub jobs (source=DEVICE); every message
is raw-logged to device_events; acks on devices/{username}/jobs/ack.
Broker gets a dedicated backend user; testuser is now a plain device.
- Realtime: plain-WS gateway at /api/ws (socket.io removed) with
cookie auth and per-job channels feeding the map live.
- Next.js frontend: login/register, jobs list with filters, job detail
with live Google map (APWA utility colors, polylines per run) behind
a provider-neutral JobMap abstraction for a future Esri swap, and
settings pages for members/devices/api-keys.
- Seed: Umagul org, admin user, testuser device, demo job with RTK
points. Sample publisher updated to the new topic contract.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The frontend previously connected directly to the MQTT broker via a
CDN-loaded Paho client and a Paho-specific ws proxy. Move that
responsibility into the backend: DeviceDataService persists MQTT
messages to Postgres, and DeviceEventsController exposes them over a
REST endpoint plus a WebSocket gateway that the frontend now consumes
directly. Also adds a pgadmin service for inspecting the database.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>