Smart Vending Telemetry.

Project Overview

Puts every vending machine online — reporting stock, sales and faults in real time so you restock the right machines, never miss a sale, and fix breakdowns fast.

A vending machine is a shop that runs itself in a location no one visits — which is exactly why it is so often failing quietly: sold out of its best line for a week, jammed and taking money for nothing, or being restocked on a fixed schedule that wastes trips to full machines and misses empty ones. The reason is that the operator is blind between visits. This project fixes that by putting the machine online: a telemetry unit reports stock, sales and faults in real time, so the operator always knows the true state of every machine and can act on it.

The unit monitors what matters commercially and operationally. It tracks stock levels per slot (from vend events, and optionally sensors) so the operator knows what is running low where; it records sales (what sold, when, for how much) for revenue visibility and demand insight; and it detects faults — a jam, a payment failure, a temperature problem in a chilled machine, a door left open — and alerts immediately. All of this streams over cellular (vending machines rarely have Wi-Fi) to a central platform.

The value is turning a fleet of blind machines into a managed, data-driven operation: route restocking to the machines that actually need it (and skip the ones that don't), never miss sales to unnoticed sell-outs, fix breakdowns fast instead of after a customer complains, and understand demand to stock each machine to its location. It is honest that integrating with real vending hardware (via MDB/DEX or sensors) varies by machine, and that payment/cash handling is a regulated, security-sensitive domain to be treated carefully. But as a real-time stock/sales/fault telemetry unit, it gives vending operators the one thing an unattended machine never has: continuous visibility.

What this project does

• Reports per-slot stock levels in real time
• Records sales (item, time, price) for revenue/demand insight
• Detects and alerts faults (jam, payment, temperature, door)
• Streams telemetry over cellular to a central platform
• Routes restocking to the machines that need it
• Catches sell-outs and breakdowns immediately
• Turns a blind fleet into a managed operation

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Per-slot stock tracking (vend events / sensors)
• Sales recording and demand analytics
• Fault detection + immediate alerts
• Cellular telemetry to a fleet platform
• Restock-routing and sell-out prevention
• Machine health (temperature, door, payment)
• Honest about vending-hardware integration and payment security

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Vending integration (MDB/DEX or sensor-based) for vend/sale events
• Per-slot stock and sales tracking
• Fault detection (jam/payment/temperature/door)
• Cellular telemetry to a platform
• Fleet analytics: restock routing, demand

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹4,115, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 2181.5 mA. With a 1.5× design margin the supply should deliver at least 3300 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Interface the machine for vend/sale events (MDB/DEX where available, or vend-detect sensors) — integration varies by machine.
• Add health sensors: temperature for chilled machines, a door reed, and jam/payment status where accessible.
• Stream telemetry over cellular; vending sites rarely have Wi-Fi.
• Power from the machine via a regulator; keep the unit isolated from payment/cash systems.
• Do not interfere with payment/cash handling — monitor, and treat that domain as security-sensitive.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

A vending machine's whole business model is being unattended — a shop in a place no one staffs — and that is precisely what makes it fail expensively. Between an operator's visits the machine can sell out of its best product and keep taking custom for lines nobody wants, jam and refuse to vend while still accepting payment, or (if chilled) drift out of safe temperature — and the operator learns none of it until the next scheduled visit, which itself may be a wasted trip to a machine that is still full. Every one of these losses is a visibility problem, and telemetry solves it by making the unattended machine continuously report its own state.

The telemetry tracks the three things that actually determine a vending operation's success. Stock per slot tells the operator what is running low and in which machine, so a sell-out is anticipated rather than discovered — tracked from vend events (each vend decrements a slot) and optionally sensors. Sales — what sold, when, at what price — give real-time revenue visibility and, aggregated, reveal demand: which products move at which locations, so each machine can be stocked to its site instead of a generic planogram. Faults — a jam, a payment failure, an over-temperature in a chiller, a door left open — are detected and alerted immediately, because a broken machine earns nothing and annoys customers for every hour it stays broken unknown.

The transport reality shapes the design: vending machines sit in lobbies, corridors and streets that rarely offer Wi-Fi, so telemetry streams over cellular to a central platform. There the individual machines become a managed fleet. The operational payoffs are direct and measurable: restocking is routed to the machines that need it (and full machines are skipped), turning fixed, wasteful schedules into demand-driven routes; sell-outs are prevented, so the machine is always selling its best lines; breakdowns are fixed fast, maximising uptime and revenue; and demand data informs what to stock where. This is the same shift every telemetry system delivers — from reacting late to acting on live data — applied to a fleet whose defining feature is that no one is watching it.

The design is honest about two real constraints. First, integration varies: some machines expose sales/stock through standard interfaces (MDB between the controller and peripherals, DEX for audit data), while others need vend-detection sensors retrofitted — so the telemetry unit meets the machine where it is. Second, and importantly, payment and cash handling is a regulated, security-sensitive domain: the telemetry unit is a monitor, and it must not interfere with payment/cash systems or handle payment data casually — anything touching payments carries compliance and security obligations that must be respected. Within those honest bounds, the unit delivers exactly what an unattended machine has always lacked and most needs: continuous, real-time visibility of its stock, its sales and its faults, so the operator can run a fleet on data instead of guesswork.

The maths behind it

Stock tracking from vends

Each slot starts at capacity; every vend decrements it:

  stock[slot] -= 1   on a vend event
  low if stock[slot] ≤ SLOT_MIN → restock this slot/machine

Optionally corrected by sensors / restock re-tare.

Fault detection

jam       : vend commanded but not dispensed
payment   : repeated payment failures
temp      : chiller temp > T_max for > t
door      : open beyond a service window

→ immediate alert (a broken machine earns nothing).

Fleet value

route restock → only machines with low stock (skip full)
prevent sell-outs → always selling best lines
fix faults fast → maximise uptime × revenue
demand → stock each machine to its location.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Interface the machine for vend/sale events

   Tap vend/sale events via MDB/DEX where available, or fit vend-detection sensors, and add health sensors (temperature, door, jam/payment status).

2. Track stock/sales and detect faults

   Decrement slot stock on vends, record sales, and detect jams, payment failures, temperature and door faults.

3. Stream over cellular and manage the fleet

   Stream telemetry to a platform over cellular, alert on faults/low stock, and drive restock routing and demand analytics.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Record sales, track stock and flag faults

   On each vend, record the sale and decrement the slot; independently check for faults (jam, payment, temperature, door) and flag low stock.

   cppvending.ino Copy Download

   int stock[SLOTS];                 // per-slot remaining
   const int SLOT_MIN = 2;
   const float T_MAX = 8.0;          // chiller degC
   
   // A completed vend: record the sale and decrement the slot.
   void onVend(int slot, int price_cents){
     if (stock[slot] > 0) stock[slot]--;
     recordSale(slot, price_cents, now());          // revenue + demand
     if (stock[slot] <= SLOT_MIN)
       alert("low_stock", slot);                    // restock THIS slot/machine
   }
   
   // Independent health/fault checks.
   const char* checkFaults(bool vendFailed, int payFails, float temp, bool doorOpen){
     if (vendFailed)          return "jam";          // commanded, not dispensed
     if (payFails >= 3)       return "payment_fault";
     if (temp > T_MAX)        return "over_temperature";
     if (doorOpen)            return "door_open";
     return nullptr;
   }

   if (stock[slot] > 0) stock[slot]--;Each vend decrements that slot's stock, so the operator always knows what is running low and where.

   recordSale(slot, price_cents, now()); // revenue + demandSales are recorded with time and price for real-time revenue visibility and demand analysis.

   if (stock[slot] <= SLOT_MIN) alert("low_stock", slot); // restock THIS slot/machineA low slot flags for restock before it sells out, and names the exact slot and machine for routing.

   if (vendFailed) return "jam"; // commanded, not dispensedA jam is inferred when a vend is commanded but nothing dispenses — a fault that otherwise takes money for nothing until noticed.

2. Stream telemetry and alert immediately

   Stream stock/sales/health to the platform over cellular, and alert immediately on faults and low stock so machines are fixed and restocked fast.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Smart Vending Telemetry — ESP32 + cellular

   Reports per-slot STOCK, SALES and FAULTS in real time to a fleet
   platform over cellular, so operators route restocking, prevent
   sell-outs, and fix breakdowns fast. Monitors only — never interferes
   with payment/cash (a regulated, security-sensitive domain).
   ══════════════════════════════════════════════════════════════════ */

#include <ArduinoJson.h>

#define SLOTS 24
int   stock[SLOTS];
const int   SLOT_MIN = 2;
const float T_MAX = 8.0;
const char* MACHINE = "VM-207";

void stream(const char* topic, JsonDocument& d){
  char buf[256]; serializeJson(d, buf);
  cellularPublish(topic, buf);                   // over cellular
}

void onVend(int slot, int price){                // completed sale
  if (stock[slot] > 0) stock[slot]--;
  StaticJsonDocument<128> s;
  s["machine"]=MACHINE; s["slot"]=slot; s["price"]=price; s["stock"]=stock[slot];
  stream("vending/sale", s);                     // sales + demand
  if (stock[slot] <= SLOT_MIN){
    StaticJsonDocument<96> a;
    a["machine"]=MACHINE; a["slot"]=slot; a["alert"]="low_stock";
    stream("vending/alert", a);                  // route restock here
  }
}

void reportHealth(bool vendFailed, int payFails, float temp, bool door){
  const char* fault = nullptr;
  if (vendFailed) fault="jam";
  else if (payFails>=3) fault="payment_fault";
  else if (temp>T_MAX) fault="over_temperature";
  else if (door) fault="door_open";

  StaticJsonDocument<160> h;
  h["machine"]=MACHINE; h["temp"]=temp; h["door"]=door;
  h["fault"]=fault?fault:"none";
  stream("vending/health", h);
  if (fault) stream("vending/fault", h);         // immediate fault alert
}

void setup(){ cellularInit(); loadStock(stock); }

void loop(){
  int slot, price;
  if (pollVendEvent(&slot, &price)) onVend(slot, price);   // MDB/DEX/sensor
  reportHealth(vendFailed(), paymentFailures(), chillerTemp(), doorOpen());
  delay(5000);
}

Configuration & Calibration

Configuration steps

• Configure the vending interface (MDB/DEX or sensors) and per-slot capacities.
• Configure low-stock thresholds, fault checks and chiller temperature limit.
• Configure cellular telemetry and the fleet platform link.
• Configure isolation from payment/cash systems (monitor only).

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Vend/stock accuracy

   Verify vends decrement the right slot and that stock matches a manual count; re-set on restock.

2. Fault detection

   Confirm jams, payment failures, over-temperature and door-open are detected and alerted.

3. Connectivity

   Verify cellular telemetry across the machine's locations.

Network Architecture & Connectivity

Communication protocol

Machines stream stock, sales and health/faults; the platform turns them into restock routes, revenue views and service alerts.

Message contract between the device and the broker.

Cloud platform configuration

A fleet platform provides live stock/sales/health, restock routing, revenue/demand analytics, and fault dispatch.

Dashboard setup

A fleet view of each machine's stock, sales, health and faults, with a prioritised restock route.

Mobile app integration

Fault alerts and low-stock alerts with the machine/slot to service.

Security considerations

• Authenticate machines; secure telemetry.
• Monitor only — never interfere with payment/cash; treat payments as regulated/secure.
• Isolate the telemetry unit from payment systems.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

Real-time stock, sales and fault telemetry per machine, driving restock routing and fast fault response.

{
  "machine": "VM-207",
  "slot": 6,
  "sale_price": 150,
  "stock": 2,
  "temp": 5.4,
  "fault": "none",
  "alert": "low_stock"
}

Machine VM-207 just sold slot 6 down to 2 units and flagged low stock — restock is routed to this machine and slot specifically, while a full machine nearby is skipped.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Track stock per slot from reliable vend detection; reset on restock.
• Alert on faults immediately — fault latency is lost revenue.
• Stream over cellular; buffer/retry where coverage is patchy.
• Drive restock routing and demand stocking from the data.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• Monitor only — never interfere with payment/cash handling, a regulated and security-sensitive domain.
• Isolate the telemetry unit from payment systems; handle any payment-adjacent data securely.
• For chilled machines, treat over-temperature as a food-safety alert.
• Install safely inside the machine, powered via a proper regulator.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• Never power an RF module without its antenna fitted — the reflected power destroys the output stage. Check your local licence-free band and duty-cycle limits before transmitting.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Reset slot stock on each restock; verify vend detection accuracy.
• Check fault detection (jam/payment/temp/door) periodically.
• Verify cellular coverage and telemetry delivery.
• Review demand data to keep each machine stocked to its location.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add predictive restock (from sale-rate trends).
• Add cashless/telemetry integration where compliant and secure.
• Add dynamic pricing/promotions from demand.
• Add energy monitoring and remote diagnostics.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Vending machineReference
2. Vending telemetry / MDBReference
3. DEX (data exchange)Reference
4. TelemetryReference
5. Fleet / route optimisationReference