Разработка мобильного приложения для вендинговых автоматов
Вендинговый автомат без мобильного приложения — это купюроприёмник и монетоприёмник. С приложением: 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 месяцев. Стоимость рассчитывается индивидуально после анализа моделей автоматов и платёжной инфраструктуры.