Ingesta MQTT
Broker
| Entorno | URL |
|---|---|
| Staging | mqtts://mqtt.linter-iot-stg.icent.digital:8883 |
| Local | mqtts://localhost:8883 |
La conexión usa TLS mutuo: CA propia + certificado X.509 por equipo. Linter dispone del bundle de conexión (CA, certificado y clave de cliente, más un script Python de ejemplo).
Topic
telemetry/<partNumber>/<deviceId>partNumber— serial del modelo (catálogo de tipos). Si no está dado de alta en el catálogo, las lecturas se almacenan pero no se pueden mostrar tipadas.deviceId— MAC en minúsculas sin separadores.
Canal descendente reservado (comandos, fase posterior): commands/<deviceId>.
Payload
JSON plano con las métricas del equipo; los campos son libres por tipo:
{ "level_pct": 62, "consumption_l": 12.4 }Cada mensaje se persiste en telemetry_raw con receivedAt y dispara dos
procesos:
- Motor de alertas — evalúa las reglas de umbral del tipo
(definidas por ROOT en el catálogo). Incumplir crea una alerta
ACTIVE; volver al rango la resuelve sola. - Notificaciones — si hay reglas de email para
alert.raised, se encolan y envían.
Alternativa HTTP
Para equipos sin capacidad MQTT (p. ej. integraciones puntuales o pruebas), el servicio de ingesta acepta la misma lectura por HTTP:
curl -X POST https://ingest.linter-iot-stg.icent.digital/v1/telemetry/<partNumber>/<deviceId> \ -H "Content-Type: application/json" \ -d '{ "pressure": 5.2, "hours": 1420 }'Devuelve 202 y persiste la lectura igual que la vía MQTT. El canal
recomendado para equipos en campo sigue siendo MQTT sobre TLS mutuo.
Conectar un equipo nuevo
- ROOT da de alta el modelo en el catálogo (part number → tipo) si no existe.
- El equipo publica en su topic con su certificado.
- Las lecturas aparecen en Telemetría (ROOT) al momento; el equipo queda operativo de cara al cliente al completarse la vinculación.