Как мы пытались подключить сканер в режиме блютуз к программе: путь проб и ошибок

В рамках разработки приложения для работы с BLE‑сканерами штрих‑кодов мы столкнулись с нетривиальной задачей: нужно было обеспечить прямое подключение сканера к программе и реализовать эмуляцию нажатий клавиш для передачи данных в сторонние приложения. Ниже — подробный рассказ о том, как мы шли к решению, с какими проблемами столкнулись и почему пока не достигли финального результата.

Шаг 1. Постановка задачи

Нам требовалось:

• обнаруживать BLE‑сканеры в радиусе действия;
• подключаться к выбранному устройству;
• получать от сканера данные (штрих‑коды);
• эмулировать нажатия клавиш (например, передавать GS‑символ как F8);
• корректно передавать все символы, включая спецсимволы и Unicode.

Шаг 2. Выбор инструментов

Мы остановились на следующем стеке:

• Python 3.x — основной язык разработки;
• Tkinter — для GUI;
• bleak — библиотека для работы с Bluetooth Low Energy (BLE);
• pyperclip — для копирования в буфер обмена;
• ctypes — для низкоуровневой эмуляции нажатий клавиш через Windows API.

Шаг 3. Реализация базового сценария

1. Сканирование и выбор устройства

• Через BleakScanner.discover() искали доступные BLE‑устройства.
• Выводили список в диалоговом окне Tkinter с колонками: имя, адрес, уровень сигнала (RSSI).
• Пользователь выбирал сканер, и программа запоминала его адрес и имя.

1. Подключение и приём данных

• После выбора устройства мы планировали установить соединение и начать прослушивать характеристики, через которые сканер передаёт данные.
• На этом этапе возникли первые сложности: многие сканеры не объявляют сервисные характеристики явно, а данные приходят в «сыром» виде.

1. Эмуляция нажатий клавиш

• Для режима «клавиатуры» использовали ctypes.windll.user32.keybd_event() для имитации нажатий.
• GS‑символ (0x1D) преобразовывали в F8 (VK_F8 = 0x77).
• Остальные символы передавали «как есть».

1. Режим буфера обмена

• В альтернативном режиме просто копировали штрих‑код в буфер через pyperclip.copy().

Шаг 4. Проблемы, с которыми мы столкнулись

1. Сканеры не отображаются в списке

• При вызове BleakScanner.discover() возвращался пустой список или очень мало устройств.
• Причины:
• сканер работает в режиме HID (эмуляция клавиатуры), а не как BLE‑периферийное устройство;
• сканер не анонсирует сервисы/характеристики, нужные для обнаружения;
• проблемы с правами доступа к Bluetooth на ОС;
• аппаратные ограничения (некоторые сканеры «спят» и не отвечают на запросы сканирования).

1. Не удаётся установить соединение

• Даже если устройство видно, вызов connect() часто завершался ошибкой:
• тайм‑аут соединения;
• отсутствие нужных GATT‑характеристик;
• требования к паролю/сопряжению, которые не обрабатываются в коде.

1. Данные не приходят или приходят «битыми»

• Сканер может передавать данные в нестандартном формате (например, с префиксами/суффиксами, которые нужно декодировать).
• В BLE данные часто разбиваются на фрагменты (MTU), и их нужно собирать вручную.
• Кодировка: не все сканеры передают UTF‑8; возможны проблемы с кириллицей и спецсимволами.

1. Эмуляция клавиш работает нестабильно

• keybd_event() чувствительна к фокусу окна и состоянию клавиатуры.
• Если фокус уходит от целевого приложения, нажатия «теряются».
• Некоторые символы (особенно управляющие) могут интерпретироваться ОС не так, как ожидается.

1. Асинхронность и GUI

• Tkinter работает в основном потоке, а bleak требует asyncio.
• Попытки вызвать await внутри обработчиков кнопок приводили к RuntimeWarning и «зависаниям».
• Решение через asyncio.run_coroutine_threadsafe() помогло, но добавило сложности в отладку.

Шаг 5. Что мы сделали для диагностики

• Проверяли видимость сканера через сторонние приложения (nRF Connect, Bluetooth Scanner) — сканер там тоже не всегда обнаруживался.
• Тестировали разные модели сканеров (бюджетные и промышленные) — результат схожий.
• Изучали документацию сканеров: многие требуют предварительной настройки (режим BLE, сервисы, характеристики).
• Добавляли детальный лог (время, адреса, ошибки) для анализа этапов подключения.
• Пробовали разные версии bleak и Python — без существенного улучшения.

Шаг 6. Почему пока не получилось

1. Аппаратные ограничения сканеров

• Многие сканеры по умолчанию работают в режиме HID (как клавиатура), а не как BLE‑устройство с явными сервисами.
• Для переключения в «режим разработчика» часто нужны специальные штрих‑коды или утилиты от производителя, которых у нас нет.

1. Отсутствие документации по GATT‑сервисам

• Производители редко публикуют UUID характеристик и формат данных. Приходится «гадать» по сырым байтам.

1. Проблемы совместимости

• Разные ОС (Windows/Linux/macOS) по‑разному обрабатывают BLE. Наш код тестировался на Windows, где Bluetooth‑stack иногда нестабилен.
• Драйверы Bluetooth могут не поддерживать нужные профили.

1. Нехватка тестовых устройств

• У нас ограниченный набор сканеров, и ни один из них не гарантирует работу в BLE‑режиме с открытыми сервисами.

Шаг 7. Что дальше

1. Получить документацию от производителя

• Уточнить:
• как перевести сканер в BLE‑режим;
• какие UUID сервисов и характеристик используются;
• формат передачи данных (префиксы, суффиксы, кодировка).

1. Использовать HID‑API вместо BLE

• Если сканер работает как клавиатура, можно перехватывать ввод через:
• keyboard (Python‑библиотека);
• низкоуровневые хуки Windows.
• Минус: потеря гибкости (нельзя читать метаданные устройства).

1. Попробовать другие библиотеки

• pybluez (для низкоуровневого Bluetooth);
• bluepy (альтернатива bleak для Linux).

1. Добавить отладку «сырых» данных

• Выводить шестнадцатеричный дамп полученных байт, чтобы понять структуру пакета.
• Сравнить с примерами из документации сканеров.

1. Тестировать на большем числе устройств

• Попробовать сканеры разных производителей (Zebra, Honeywell, Datalogic) с поддержкой BLE.

Вывод

Мы прошли путь от идеи до рабочей прототипа, но ключевая задача — стабильное подключение и передача данных — пока не решена. Основные причины:

• аппаратные ограничения сканеров;
• нехватка документации по BLE‑сервисам;
• сложности интеграции асинхронного кода с GUI.

Что помогло:

• разделение логики на модули (GUI, BLE, эмуляция);
• использование asyncio и потоков для параллельности;
• детальный логгинг для диагностики.

Следующий шаг — получить доступ к «правильным» сканерам с открытой BLE‑документацией или переключиться на HID‑режим с перехватом ввода.