Розробка мобільного додатку для вендингових автоматів
Вендинговий автомат без мобільного додатку — це прийманик купюр та монет. З додатком: QR-оплата, безготівковий розрахунок, програма лояльності, push-сповіщення про новинки, історія покупок. Для оператора мережі — телеметрія: рівень заповнення, помилки механіки, виручка по точках у реальному часі.
Телеметрія: протокол DEX/UCS та сучасний IoT
Стандарт для вендингових автоматів — протокол DEX/UCS (Data Exchange / Universal Communications Standard). Більшість комерційних автоматів (Crane, Sanden, Azkoyen) мають DEX-порт — RS-232, 9600 бод. Через DEX можна читати лічильники продаж, помилки, залишки товару. Проблема: DEX розроблявся для періодичного зчитування даних при обслуговуванні, не для онлайн-моніторингу.
Сучасне рішення: IoT-контролер (Telemetry Gateway) підключається до DEX-порту та мережі (4G/Wi-Fi). Виробники: Parlance, CPI, Nayax, Coinco. Вони надають REST API для мобільних додатків і дашбордів.
Немає стандартного IoT-модуля? Зробити його на Raspberry Pi Zero + RS-232 адаптер + Python-парсер DEX + MQTT публікація:
import serial, paho.mqtt.client as mqtt
def read_dex_data(port='/dev/ttyUSB0'):
ser = serial.Serial(port, 9600, timeout=5)
# Ініціалізація DEX-сесії
ser.write(b'\x04') # EOT — початок сесії
response = ser.read_until(b'\x04') # читаємо до EOT
return parse_dex_block(response)
def parse_dex_block(data: bytes) -> dict:
# Парсимо блоки VA (Vending Machine Audit)
# VA1 — ідентифікація, VA2 — дані продаж, VA3 — залишки
blocks = data.split(b'\x1c') # FS розділювач
return {block[:3].decode(): block[3:].decode() for block in blocks}
MDB: управління оплатою
MDB (Multi-Drop Bus) — протокол для пристроїв оплати всередину автомата (прийманик купюр, монетоприйманик, картковий ридер). Більшість сучасних касслетів працює через MDB Master — головний контролер автомата керує периферією.
Для безготівкової оплати з телефону: платіжний модуль (Nayax VPOS Touch, PayLink) підключається в MDB-шину автомата як MDB Peripheral. Користувач оплачує в додатку → сервер сигналізує платіжному модулю → модуль емулює монету/купюру в MDB → автомат видає товар.
QR-оплата: механіка сесії
// iOS: генерація QR з session token для автомата
class VendingSessionManager {
func createPaymentSession(machineId: String, amount: Decimal) async throws -> PaymentSession {
let session = try await api.createSession(VendingSessionRequest(
machineId: machineId,
amount: amount,
expiresIn: 120 // 2 хвилини
))
// QR містить session.deepLink — відкриває додаток при скануванні
return session
}
func pollSessionStatus(sessionId: String) -> AsyncStream<SessionStatus> {
AsyncStream { continuation in
Task {
for await _ in Timer.publish(every: 2, on: .main, in: .common).autoconnect().values {
let status = try? await api.getSessionStatus(sessionId)
continuation.yield(status ?? .unknown)
if status == .completed || status == .expired { break }
}
continuation.finish()
}
}
}
}
Polling статусу сесії кожні 2 секунди — простіше WebSocket у цьому випадку. Сесія має TTL 120 секунд: якщо користувач не оплатив, QR застарів, автомат скидає очікування.
Залишки та телеметрія для оператора
Оператор в додатку (або в веб-панелі) бачить по кожному автомату: залишки по ячейкам, виручку за день/тиждень/місяць, помилки (застрявший товар, відмова прийманика купюр, проблема з охолодженням). Маршрут об'їзду — оптимізований список автоматів, які потрібно поповнити сьогодні, з урахуванням залишків та прогнозу продаж.
Інтеграція з системами обліку оператора: 1С, SAP, власні ERP — через REST або файловий обмін (CSV/XLS). Нормалізація даних з різних моделей автоматів — ключова задача бекенду.
Розробка клієнтського додатку (QR-оплата, історія покупок, лояльність) + операторського дашборда для мережі вендингових автоматів: 3–5 місяців. Стоимість розраховується індивідуально після аналізу моделей автоматів та платіжної інфраструктури.