Saltar al contenido principal

Cómo funciona dex-embedded

El gateway (dex-gateway) es un programa único, escrito en Rust, que corre como servicio en el MDVR. Escucha los relojes por Bluetooth, resuelve quién es el operador, guarda todo localmente y entrega los eventos al software del partner.

reloj ──BLE──▶ dex-gateway ──▶ API local (gRPC) ──▶ software del partner
                    │      └──▶ MQTT (opcional)
                    └─────────▶ nube Dersalis (incidentes y telemetría)

Cuatro decisiones de diseño​

1. El Bluetooth solo escucha, nunca conecta​

El reloj ya transmite, en cada anuncio Bluetooth, todo lo que el gateway necesita: jornada, incidente, estado. El gateway solo observa esos anuncios (escaneo pasivo). Eso evita el costo y la fragilidad de mantener una conexión por dispositivo, y no exige ningún emparejamiento.

2. El operador se identifica dentro del equipo​

El anuncio del reloj trae solo un prefijo del identificador del colaborador, que no alcanza para resolverlo por sí solo. El gateway descarga de la nube la lista de colaboradores y monitoreos de la empresa y la mantiene en memoria; cada evento se resuelve contra esa lista en el momento, sin ir a la red.

Por eso el equipo sigue tratando el estado del operador aunque la conexión esté caída: solo la actualización de la lista depende de la nube. Se dispara cuando un operador comienza la jornada, y no todo el tiempo.

3. Su software recibe eventos ya resueltos​

Su software nunca ve Bluetooth ni identificadores internos. El contrato es una API local (gRPC, 127.0.0.1, accesible solo desde dentro del equipo) con los campos ya resueltos: la matrícula del operador y el nombre del monitoreo. El contrato está versionado: dentro de la versión v1 solo se agregan campos.

Quien no quiere compilar una biblioteca gRPC en el equipo usa dex-events, que entrega los mismos eventos como una línea JSON por evento. Quien prefiere un bus publica por MQTT.

4. Todo se graba antes de ser entregado​

Cada evento va a una cola local duradera (SQLite) apenas se decodifica y resuelve, con eliminación de duplicados: el reloj repite el mismo incidente cada pocos segundos mientras está activo, y eso se convierte en un único registro, actualizado a medida que el incidente evoluciona.

Esa cola desacopla la captura Bluetooth de la API local y del envío a la nube: una caída de red o un software del partner fuera de servicio no pierde nada.

Qué queda en el equipo​

  • Jornada del gateway: el contenedor al que pertenecen incidentes, estados y tests de atención. El software del partner la controla indicando qué operador seguir y cuándo termina el turno.
  • Retención: los datos viven con la jornada. Después de ella, el gateway borra lo que ya se entregó a la nube y fue confirmado por el partner, para que el almacenamiento del equipo no crezca sin límite.
  • Privacidad: el nombre del operador no se almacena. El resultado del test de atención es un dato de salud: solo circula por la API local y, si el partner activa la telemetría, por la nube, y nunca se escribe en un log.

¿Y la nube?​

El gateway envía a la nube de Dersalis los incidentes (ya identificados) en segundo plano, de forma liviana. También hay una telemetría opcional (posición del vehículo, estado del gateway y de los relojes), desactivada por defecto. El gateway no depende de la nube para entregar eventos a su software.

Próximos pasos​