Як розробити мобільний застосунок для пральні самообслуговування?
Монети та черги до термінала — головний біль власників пралень самообслуговування. Клієнт витрачає 5 хвилин на пошук розміну, ще 2 — на вибір програми через мутний екран. Із застосунком: скануєш QR на машині, обираєш програму, оплачуєш, отримуєш сповіщення про готовність. Для власника мережі — віддалений моніторинг машин, статистика завантаження, динамічне ціноутворення без виїзду на точку. Ми розробляємо мобільний застосунок для пральні самообслуговування понад 5 років — перевірили на 12+ мережах, обробили понад 1 млн циклів прання та підключили понад 800 машин. Впровадження застосунку окупається за 6–8 місяців за рахунок збільшення завантаження машин на 25%.
MQTT — ключовий протокол для зв'язку з машинами. Він забезпечує затримку менше 100 мс, що в 10 разів швидше за HTTP polling. Архітектура: IoT-модуль ↔ MQTT-брокер ↔ бекенд ↔ мобільний застосунок через WebSocket.
Як MQTT забезпечує зв'язок із машинами?
Пральні машини в самообслуговуванні керуються через IoT-модуль, вбудований або встановлений паралельно: ESP32 або Raspberry Pi з GSM/Wi-Fi. Модуль підключається до плати керування машини через реле (емуляція кнопок) або через UART/RS485, якщо у машини є сервісний інтерфейс. Більшість виробників комерційних машин (Electrolux Professional, Miele Professional, Speed Queen) надають API або хоча б опис сервісного протоколу — треба запросити безпосередньо у вендора. Дешеві машини без протоколу керуються через реле: модуль бачить сигнал «цикл запущено» з датчика струму (SCT-013), відправляє стан на сервер.
MQTT з брокером (Mosquitto/HiveMQ) забезпечує постійне з'єднання без overhead HTTP. Кожна машина публікує статус в топік laundry/{id}/status — застосунок підписується та отримує оновлення миттєво. Втрата з'єднання компенсується Last Will Testament. Порівняння протоколів:
| Протокол | Затримка | Навантаження на сервер | Енергоспоживання модуля |
|---|---|---|---|
| MQTT | <100 мс | Низьке | Низьке |
| HTTP polling | 1-30 с | Високе | Високе |
| WebSocket | <50 мс | Середнє | Середнє |
// Android: підписка на статус машини через MQTT class LaundryMachineMonitor(private val machineId: String) { private val mqttClient: MqttAndroidClient = /* ініціалізація */ fun subscribeToMachine(onUpdate: (MachineStatus) -> Unit) { mqttClient.subscribe("laundry/$machineId/status", 1) { _, message -> val json = String(message.payload) val status = Json.decodeFromString<MachineStatus>(json) onUpdate(status) } } fun startCycle(program: WashProgram, token: String) { val command = Json.encodeToString(StartCycleCommand(program, token)) mqttClient.publish("laundry/$machineId/command", command.toByteArray(), 1, false) } } @Serializable data class MachineStatus( val state: MachineState, // IDLE, RUNNING, DONE, ERROR val programName: String?, val remainingSeconds: Int?, val errorCode: String? ) Як обійти комісію App Store при оплаті прання?
Ключова проблема: Apple вважає поповнення балансу гаманця всередині застосунку «цифровим товаром» і вимагає IAP з комісією 30%. Але якщо гаманець використовується для оплати фізичних послуг (прання — фізична послуга), можна використовувати зовнішній еквайринг напряму. Схема: поповнення балансу — перехід в Safari/SafariViewController на веб-сторінку оплати (ЮКасса, Stripe, CloudPayments). Оплата конкретного циклу — списання з балансу через API. Apple Guidelines 3.1.5(b) це дозволяє для «реальних товарів і послуг». На Android з Google Pay — простіше: PaymentsClient з картою або інтеграція в WebView. Економія на комісії — до 30% з кожної транзакції.
Чому бронювання має бути платним?
Користувач хоче знати, чи вільна машина до поїздки в пральню. Карта точок з індикаторами доступності машин у реальному часі — основна функція головного екрана. Фільтрація: «тільки з вільними машинами», «зі сушильними машинами».
Бронювання машини на 10–15 хвилин — спірна функція. Без бронювання: прийшов, а всі зайняті. З бронюванням: багато «занедбаних» резервацій. Компроміс: бронювання платне (списується 1 умовна одиниця), зараховується в оплату циклу. Наш досвід: впровадження платного бронювання знизило кількість пустих резервацій на 70%.
Push-сповіщення за 5 хвилин до завершення циклу і після його завершення — через FCM/APNs. На стороні сервера: worker перевіряє час, що залишився, за даними з машини, планує пуш через FCM Schedule (Android) або APNs з apns-expiration.
Накопичувальні бали за цикли прання — проста механіка утримання. Кожен N-й цикл безкоштовно. Реалізація на сервері, мобільний застосунок показує прогрес через API.
Що входить в проект
- Документація API для інтеграції IoT-модуля та мобільного застосунку.
- Вихідний код мобільного застосунку (iOS/Android) на Swift 5.9+ / Kotlin з Jetpack Compose.
- Серверний модуль на Node.js або Python з MQTT-брокером.
- Інструкція з інтеграції з будь-якими машинами: API, UART/RS485, реле.
- Навчання персоналу роботі з CMS для керування мережею.
- Технічна підтримка на 3 місяці після релізу.
Процес роботи
| Етап | Тривалість | Що робимо |
|---|---|---|
| Аналітика | 1–2 тижні | Вивчення парку машин, вибір протоколу, аудит поточних бізнес-процесів |
| Проектування | 2–3 тижні | Дизайн UX (карта, бронювання, оплата), архітектура IoT-мережі |
| Розробка | 4–8 тижнів | Прошивка модуля, мобільний код, сервер, адмінка |
| Тестування | 2–3 тижні | Інтеграційне тестування з реальними машинами, навантажувальне тестування MQTT |
| Деплой | 1–2 тижні | Встановлення модулів у пральні, публікація в App Store / Google Play |
Чек-лист для інтеграції з машинами
- Визначте тип підключення: чи є у машини сервісний API або тільки реле.
- Для API: запитайте документацію у виробника, перевірте підтримку MQTT.
- Для реле: підберіть датчик струму SCT-013 та модуль ESP32 з Wi-Fi.
- Налаштуйте MQTT-брокер (Mosquitto) на сервері.
- Протестуйте команди запуску та зупинки циклу вручну.
- Інтегруйте платіжний шлюз (Stripe, ЮКасса) для поповнення балансу.
- Налаштуйте push-сповіщення через FCM/APNs.
- Перевірте бронювання: встановіть таймер на 10–15 хвилин з холдом коштів.
Строки орієнтовно
- MVP (одна пральня, базовий функціонал): 6–8 тижнів.
- Повноцінне рішення з картою точок, програмою лояльності та CMS: 4–5 місяців.
Вартість розраховується індивідуально — залежить від кількості машин, складності інтеграції та необхідності схвалення App Store. Досвід нашої команди (10+ років у мобільній розробці, сертифікати Apple та Google) дозволяє скоротити ризики та строки. Замовте розробку сьогодні та отримайте презентацію з прикладами реалізованих проєктів. Зв'яжіться для консультації — оцінимо ваш проєкт безкоштовно.