Skip to main content

How dex-embedded works

The gateway (dex-gateway) is a single program, written in Rust, that runs as a service on the MDVR. It listens to the watches over Bluetooth, resolves who the operator is, stores everything locally and delivers the events to the partner's software.

watch ──BLE──▶ dex-gateway ──▶ local API (gRPC) ──▶ partner software
                    │      └──▶ MQTT (optional)
                    └─────────▶ Dersalis cloud (incidents and telemetry)

Four design decisions​

1. Bluetooth only listens, it never connects​

Every Bluetooth advertisement from the watch already carries everything the gateway needs: journey, incident, status. The gateway only observes these advertisements (passive scan). This avoids the cost and fragility of keeping one connection per device, and requires no pairing.

2. The operator is identified inside the device​

The watch's advertisement carries only a prefix of the employee identifier, which is not enough to resolve them on its own. The gateway downloads the company's list of employees and monitorings from the cloud and keeps it in memory; each event is resolved against that list on the spot, without going to the network.

That is why the device keeps handling operator status even with the connection down: only the refresh of the list depends on the cloud. It is triggered when an operator starts a journey, not all the time.

3. Your software receives already-resolved events​

Your software never sees Bluetooth or internal identifiers. The contract is a local API (gRPC, 127.0.0.1, reachable only from inside the device) with the fields already resolved: the operator's registration number and the monitoring name. The contract is versioned: within version v1 fields are only ever added.

If you do not want to build a gRPC library on the device, use dex-events, which delivers the same events as one JSON line per event. If you prefer a bus, publish over MQTT.

4. Everything is written before it is delivered​

Each event goes into a durable local queue (SQLite) as soon as it is decoded and resolved, with duplicate elimination: the watch repeats the same incident every few seconds while it is active, and that becomes a single record, updated as the incident evolves.

This queue decouples Bluetooth capture from the local API and from cloud sync: a network outage or a partner software that is down loses nothing.

What stays on the device​

  • Gateway journey: the container that incidents, status and attention tests belong to. The partner's software controls it by saying which operator to follow and when the shift ends.
  • Retention: data lives with the journey. After it, the gateway deletes what has already been delivered to the cloud and confirmed by the partner, so the device storage does not grow without limit.
  • Privacy: the operator's name is not stored. The attention test result is health data: it only travels through the local API and, if the partner turns telemetry on, through the cloud, and is never written to a log.

And the cloud?​

The gateway sends incidents (already identified) to the Dersalis cloud in the background, lightly. There is also optional telemetry (vehicle position, gateway and watch state), off by default. The gateway does not depend on the cloud to deliver events to your software.

Next steps​