DEX: vending telemetry decoded

What DEX actually is

DEX (Data Exchange) is the vending industry’s standard for pulling audit data out of a machine: sales counts per selection, cash-in-box, coin tube levels, door events, error codes — structured as EVA-DTS records. Originally collected by a technician plugging in a handheld, the modern version is a telemetry device inside the machine reading DEX on a schedule and shipping it upstream — in our case over MQTT to the platform.

From audit file to live platform

• Parse defensively: EVA-DTS implementations vary by manufacturer, firmware, and era — our parser handles a dozen dialects and quarantines what it cannot classify rather than guessing.
• Diff, don’t trust totals: DEX counters are cumulative and reset unpredictably (power loss, board swaps) — sales derive from validated deltas with reset detection, never raw counters.
• Reconcile against cashless: card and UPI transactions arrive in real time; DEX audits arrive on schedule — the reconciliation between them catches theft, faults, and stuck spirals.
• Stock intelligence: per-selection vend counts drive planogram-aware replenishment — the difference between refilling on a route and refilling on demand.

What a legacy protocol teaches

DEX taught my teams more about real-world integration than any modern API: assume dirty data, design for devices that lie, reconcile everything against an independent source, and never let one machine’s malformed record block the fleet’s pipeline. Those instincts transferred directly to OCPP charger fleets — different decade, same physics.

Worked example: raw EVA-DTS to platform event

What actually comes out of the machine, and what the platform turns it into after delta validation:

# Raw DEX/EVA-DTS fragment from the telemetry device
DXS*VENDIMAN*VA*V0/6*1
ID1*VM2041**8850
PA1*10*250          <- selection 10, price 2.50
PA2*1423*355750     <- 1,423 vends, 355,750 cumulative value
CA17*1*250*118      <- coin tube status
EA2*DO*20260811*063212   <- door open event
DXE*1*1

// After parse -> dialect normalization -> counter diff:
{
  "machineId": "VM-2041",
  "type": "sales.delta",
  "window": { "from": "2026-08-10T18:00Z", "to": "2026-08-11T06:00Z" },
  "selections": [
    { "selection": "10", "vends": 7, "value": 17.50 }
  ],
  "counterReset": false,          // validated against previous audit
  "reconciled": { "cashless": 5, "cash": 2, "variance": 0 }
}

The counterReset flag and cashless reconciliation are what separate a telemetry pipeline from a dashboard of phantom sales.