Follow this guide to provision your MNEMOS gateways, install the Vigil Field App on your deployment device, register probes over PDP, and verify your first measurements in the Vigil dashboard.
Gather hardware, prepare your network, and spin up the Vigil backend before physical installation begins.
Issue a bearer token for each gateway, configure MQTT credentials, and perform the PDP JOIN handshake.
Each physical gateway authenticates with a per-device bearer token. The plaintext is shown exactly once at creation — store it immediately in your secrets manager or flash it directly to the firmware before closing this terminal.
The gateway token is bound to the gateway's hardware_id on first JOIN_REQUEST, so pre-provisioning is possible before hardware arrives. Simply omit --hardware-id and the gateway self-registers on its first call.
The Field App runs on any laptop or tablet with Python. Use it on-site to scan device QR codes, review manufacturing data, and push configuration to new nodes — no dashboard access needed from the factory floor.
The Field App is a lightweight local server that exposes a mobile-optimised web interface at http://localhost:7654. Open it on your tablet and scan device QR codes to instantly pull manufacturing data, firmware version, calibration records, and probe-specific tutorial videos.
The Field App requires HTTPS access to the Vigil API server. On-premises deployments should ensure the deployment laptop can reach the API over the local network. For airgapped sites, a read-only snapshot can be pre-loaded before entering the facility.
When a PDP-compatible probe is attached, the gateway reads its TEDS EEPROM and automatically registers each sensing channel with Vigil — binding probes to quantities without any manual configuration.
The Peripheral Detection Protocol (PDP) defines a five-phase handshake between probe and gateway. After physical attachment and mutual authentication, the gateway reads the probe's TEDS EEPROM — 2 KB of identity, calibration, and channel metadata stored in an AT24C16 on the probe PCB.
This EEPROM data is forwarded to the Vigil platform via the probe register endpoint, which automatically creates DeviceBinding records — linking each physical channel to a quantity (temperature, vibration, pressure, etc.) and assigning the correct sample-rate tier.
The gateway then receives a list of binding IDs in the response. These UUIDs are used in every subsequent ingest payload, routing each measurement to the correct database tier and alert rule evaluation queue.
For legacy sensors without TEDS, the Field App provides a manual probe wizard — select probe type, map channels to quantities, and submit. The resulting binding IDs are written to a QR code sticker for future maintenance reference.
Once measurements are flowing, complete device metadata, verify the live chart, and organise into sites and groups within the Vigil dashboard.
Set up alert rules, connect notification channels, define escalation policies, and confirm delivery before declaring the deployment complete.
Once alerts are configured and a test event confirms delivery, your deployment is complete. Document the gateway token IDs and binding IDs in your asset management system for future maintenance.
docker compose logs vigil-api | grep ingest.is_active flag was cleared by an admin. Issue a new token via python manage.py issue_gateway_token and update the gateway firmware config.GET /api/v1/quantities/ and ensure the slug matches exactly (case-sensitive, hyphenated). If the quantity you need is missing, create it via the API or admin interface.PLATFORM_URL in field_app/.env points to the correct host and port. Ensure the deployment laptop and Vigil server are on the same network segment. For HTTPS, confirm the TLS certificate is valid or the CA is trusted by the laptop's OS.device_latest_values table has entries for the binding IDs (run GET /api/v1/devices/{id}/measurements/latest/). If absent, the ingest UPSERT failed silently — check the vigil-api container logs for SQL errors.docker compose ps vigil-worker. Check worker logs for SMTP/webhook errors. Verify the NotificationChannel is_enabled and the alert rule has a RuleNotificationMapping pointing to it. Use the test alert management command to fire a synthetic event: python manage.py test_alerts.