Реалізація моніторингу стану автомобіля через мобільний додаток

Реалізація моніторингу стану автомобіля через мобільний додаток

OBD-II порт існує в будь-якому автомобілі, випущеному після 1996 року. Через нього ELM327-сумісний адаптер (Viecar, KONNWEI, Veepeak) по Bluetooth або Wi-Fi відає PID-запити — та додаток отримує обороти двигуна, навантаження, температуру охолоджувальної рідини, швидкість, напругу бортової мережі, коди помилок DTC. Задача звучить просто, але реалізація упирається в кілька нетривіальних моментів.

Протокол ELM327 та типові граблі

Адаптери ELM327 говорять через AT-команди поверх послідовного порту. Підключення через Classic Bluetooth — BluetoothSocket на Android з UUID 00001101-0000-1000-8000-00805F9B34FB (SPP профіль). На iOS Classic Bluetooth для сторонніх додатків закритий; єдиний шлях — BLE ELM327 адаптери (Viecar EA400-P, OBDLink CX) через Core Bluetooth.

Найчастіша помилка при роботі з ELM327 — відправити наступний PID-запит, не дочекавшись > (prompt) у ответі. Адаптер буферизує команди непередбачено, та замість значення RPM додаток отримує ? або NO DATA. Правильний цикл опроса — послідовний, з таймаутом чекання промпта ~200 мс:

class OBDConnection(private val socket: BluetoothSocket) {
    private val input = socket.inputStream.bufferedReader()
    private val output = socket.outputStream

    suspend fun sendCommand(command: String): String = withContext(Dispatchers.IO) {
        output.write("$command\r".toByteArray())
        val sb = StringBuilder()
        var char: Int
        while (input.read().also { char = it } != -1) {
            val c = char.toChar()
            sb.append(c)
            if (c == '>') break
        }
        sb.toString().trim().removeSuffix(">").trim()
    }

    suspend fun readPID(mode: String, pid: String): String {
        return sendCommand("$mode$pid")
    }
}

Ініціалізація адаптера перед опросом обов'язкова: ATZ (сброс), ATE0 (вимкнути еха), ATL0 (без перенесення рядків), ATSP0 (автовибір протоколу). Без ATE0 парсити ответи значно складніше — команда повертається в потоці разом з ответом.

PID-опрос: що реально читається

Стандарт SAE J1979 визначає Mode 01 (поточні дані) та Mode 03 (коди помилок). Не всі PID підтримуються всіма автомобілями — спочатку запитуємо PID 0x00 (supported PIDs 01-20), потім 0x20, 0x40, 0x60, щоб побудувати карту доступних параметрів.

Коди помилок (Mode 03) повертають список DTC у форматі 2 байти на код. Перші два біти визначають систему: 00 — двигун (P), 01 — коробка (P1xxx), 10 — шасі (C), 11 — кузов (B). Декодування кодів у читаємі описи потребує бази даних — відкриті варіанти: CSV з репозиторію hfreire/ecu-can-bus-decoder або платна база від OBD Solutions.

Архітектура додатку

На Android — foreground service з PRIORITY_LOW сповіщенням (інакше Android 8+ убʼє процес за кілька хвилин). Service керує підключенням до адаптера та циклом опроса, UI підписується через StateFlow. На iOS — foreground-only, тому що Core Bluetooth працює в фоні тільки для Heart Rate та кількох інших профілів; опрос поки екран активен.

Частота опроса: RPM та швидкість — кожні 100-200 мс, температура та розхід — кожні 1-2 секунди. Не опитуйте всі PID з однаковою частотою — це перевантажує адаптер та помітно сповільнює CAN-шину.

Додатково: TPMS та камера салону

Датчики тиску шин (TPMS) на більшості автомобілів працюють через окремий радіочастотний протокол (315/433 МГц) та не доступні через OBD-II. Для їх моніторингу потрібні зовнішні BLE-датчики (наприклад, Meneea, Fobo Tire Plus), які прилипають на вентиль та передають тиск та температуру. Інтегруються через стандартний Core Bluetooth / Android BLE API.

Розробка базового мобільного додатку з підключенням до ELM327, моніторингом 10-15 PID та зчитуванням DTC: 3-4 тижні. Повнофункціональний додаток з історією поїздок, геолокацією, розрахунком витрати палива та TPMS: 6-8 тижнів. Вартість розраховується індивідуально після уточнення цільових платформ та списку підтримуваних параметрів.