Электросамокаты и электровелосипеды с контроллером — это не просто устройства с BLE-чипом. Типичный стек: контроллер BLDC-мотора (Sabvoton, Kelly, Votol) общается с дисплеем или BMS по протоколу UART/RS485 (часто проприетарный), BLE-модуль (Nordic nRF52840, ESP32) слушает шину и транслирует данные в мобильное приложение. Разработка приложения без понимания этой цепочки заканчивается тем, что приложение «подключилось», но не знает, что делать с потоком байт. Наша команда имеет 5+ лет опыта в этой нише и более 30 успешно запущенных проектов. Мы гарантируем стабильное BLE-соединение и корректную обработку данных с любых контроллеров.
Как мы решаем проблему отсутствия документации на контроллер?
Большинство производителей контроллеров (особенно китайских) не публикуют протоколы. Процесс: снять родной дисплей, подключить USB-UART анализатор (FTDI232, CP2102) параллельно шине и записать трафик в логи. Инструмент — PulseView + декодер UART, либо просто запись в файл через minicom/CoolTerm.
Типичный фрейм протокола Xiaomi M365 (как пример открытого):
[0x55][0xAA][len][addr][cmd][data...][crc_lo][crc_hi]
Фрейм начинается с 0x55 0xAA, затем длина полезной нагрузки, адрес получателя (0x20 — контроллер, 0x21 — BMS, 0x3E — дисплей), команда, данные, CRC16. Для менее популярных брендов CRC считается по-разному — XOR, Modbus CRC, иногда просто сумма байт с маской.
class ScooterFrameParser {
private val buffer = ByteArrayOutputStream()
fun feed(byte: Byte): ScooterFrame? {
buffer.write(byte.toInt())
val bytes = buffer.toByteArray()
// Ищем начало фрейма
val start = findStart(bytes) ?: return null
if (bytes.size - start < 4) return null
val len = bytes[start + 2].toInt() and 0xFF
val totalLen = len + 6 // header(2) + len(1) + addr(1) + cmd(1) + crc(2) - 1
if (bytes.size - start < totalLen) return null
val frame = bytes.copyOfRange(start, start + totalLen)
buffer.reset()
if (start + totalLen < bytes.size) {
buffer.write(bytes, start + totalLen, bytes.size - start - totalLen)
}
return if (verifyCRC(frame)) parseFrame(frame) else null
}
}
Почему стабильность BLE-соединения критична для поездок?
На Android BLE работает через BluetoothGatt. Главная боль — onConnectionStateChange с status = 133 (GATT_ERROR) при подключении, особенно на Android 12+ с включённым Bluetooth Permission. Лечение: retry с задержкой 500-1000 мс, максимум 3 попытки, после — показываем пользователю инструкцию переподключить Bluetooth.
class ScooterBLEManager(private val context: Context) {
private var gatt: BluetoothGatt? = null
private var retryCount = 0
fun connect(device: BluetoothDevice) {
gatt = device.connectGatt(context, false, object : BluetoothGattCallback() {
override fun onConnectionStateChange(g: BluetoothGatt, status: Int, newState: Int) {
when {
newState == BluetoothProfile.STATE_CONNECTED -> {
retryCount = 0
g.discoverServices()
}
status == 133 && retryCount < 3 -> {
retryCount++
g.close()
Handler(Looper.getMainLooper()).postDelayed({ connect(device) }, 800)
}
else -> notifyConnectionFailed()
}
}
override fun onCharacteristicChanged(g: BluetoothGatt,
characteristic: BluetoothGattCharacteristic, value: ByteArray) {
frameParser.feed(value)
}
}, BluetoothDevice.TRANSPORT_LE)
}
}
На iOS CBPeripheral стабильнее, но сессия CoreBluetooth не выживает после перезапуска приложения — сохраняем peripheral.identifier (UUID) в UserDefaults и восстанавливаем через retrievePeripherals(withIdentifiers:). Сравнение платформ показывает, что Android BLE требует больше retry-механизмов, что увеличивает время разработки на 10-15% относительно iOS.
| Характеристика | Android | iOS |
|---|---|---|
| Стабильность подключения | Ниже (status 133) | Высокая |
| Retry-логика | 3 попытки | Не требуется |
| Время разработки BLE-слоя | ~2 недели | ~1 неделя |
| Работа в фоне | Ограничена (Background limits) | Хорошая |
Дашборд: что показываем
Стандартный набор данных с контроллера самоката/велосипеда:
- Скорость (км/ч) — реальная, с датчика колеса или расчётная из RPM + длина окружности
- Заряд батареи (%) — из BMS, реже — расчётный по напряжению
- Напряжение/ток батареи — важно для мониторинга рекуперации
- Температура контроллера и мотора — критично для тяжёлых подъёмов
- Пробег — одометр, суммарный и за поездку
- Режим езды — Eco/Normal/Sport или D1-D5
- Состояние тормозов (если датчики подключены к контроллеру)
Выделим скорость, заряд батареи и температуру как ключевые показатели — их обновление должно быть максимально быстрым. Скоростной график за поездку — обязательный элемент. Renderим через MPAndroidChart (Android) или Swift Charts (iOS 16+). Данные пишем в Room/Core Data каждые 500 мс — поездка на 30 км при таком интервале = ~3600 точек, это не проблема.
Детали протоколов контроллеров
Помимо Xiaomi, встречаются протоколы с фреймом длиной 10-20 байт, где CRC считается как XOR всех байт, или Modbus RTU. Мы разбирали контроллеры Votol (EM-30, EM-100) — там фрейм начинается с 0xAA, команда 0xB1 для данных, CRC16 Modbus. Алгоритм парсинга универсален: ищем преамбулу, читаем длину, проверяем CRC.Управление режимами и настройки контроллера
Ряд контроллеров позволяет перепрограммировать параметры: максимальный ток, ограничение скорости, мощность рекуперации. Отправляем write-команду в Notify Characteristic. Важно: изменения параметров контроллера требуют предупреждения пользователя и подтверждения — неправильный ток может вывести мотор из строя или разрядить батарею за поездку.
Для шеринговых сервисов (флот самокатов) добавляется серверная часть: MQTT или WebSocket, история поездок на бэкенде, геофенсинг, удалённая блокировка. Это отдельный уровень сложности.
Процесс работы
- Анализ протокола контроллера и спецификации BLE-модуля (1-2 недели).
- Прототип подключения: приём и отправка команд, верификация (1 неделя).
- Разработка UI/UX: дашборд, экран поездки, настройки (2-3 недели).
- Реализация BLE-слоя, парсера, записи данных (2 недели).
- Тестирование на реальных поездках (1-2 недели).
- Публикация в App Store и Google Play, прохождение ревью (1 неделя).
Сроки: 6-8 недель на одну платформу, 3-4 месяца на кросс-платформенное решение (Flutter) с поддержкой нескольких протоколов. Стоимость рассчитывается индивидуально после анализа конкретной модели устройства и наличия документации на протокол. Свяжитесь с нами для оценки вашего проекта.
Что входит в работу
После завершения проекта вы получаете:
- Исходный код приложения (native или Flutter) с документацией.
- Инструкцию по сборке и деплою.
- Документацию протокола контроллера (если проводился реверс-инжиниринг).
- Доступ к репозиторию и средствам CI/CD.
- Поддержку при публикации в магазины приложений.
- Обучение администраторов флота (если проект шеринговый).
Мы даём гарантию на стабильную работу BLE-соединения и корректный парсинг данных. Постоянно обновляем приложение под новые версии iOS и Android.
Оцените экономию времени: закажите разработку приложения под ключ и получите готовый продукт, протестированный на реальных устройствах. Пишите — мы поможем.