ATC_MiThermometer
ATC_MiThermometer copied to clipboard
pvvx
Работа термометров в Home Assistant c Bluetooth LE Long Range.
Предварительное описание решения.
Для примера можно взять: Low-cost Realtek RTL8761 BT adapter
USB ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio
Сurrent version of Linux fw on RTL8761 supports BT5.1:
# hciconfig hci1 version
hci1: Type: Primary Bus: USB
BD Address: 8C:88:2B:00:E1:EA ACL MTU: 1021:6 SCO MTU: 255:12
HCI Version: 5.1 (0xa) Revision: 0x999
LMP Version: 5.1 (0xa) Subversion: 0x646b
Manufacturer: Realtek Semiconductor Corporation (93)
Для работы HA c LE Long Range в интеграции “Bluetooth” желательно установить последнюю версию bluez и добавить в файле /lib/systemd/system/bluetooth.service ExecStart=/usr/local/libexec/bluetooth/bluetoothd --experimental
Из-за неверной инициализации адаптеров BT5.+ в Bluez, перед запуском Home Assistant необходимо переключить BT адаптер на работу в режим Bluetoch 5.0: hcitool -i hci1 cmd 08 31 03 05 05 или во всех режимах PHY 1M/2M/Coded: hcitool -i hci1 cmd 08 31 03 07 07 Номер hciN - свой. Проверить переключение возможно в btmon (log btmon):
@ RAW Open: hcitool (privileged) version 2.22
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3
All PHYs preference: 0x03
No TX PHY preference
No RX PHY preference
TX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
RX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
> HCI Event: Command Complete (0x0e) plen 4
LE Set Default PHY (0x08|0x0031) ncmd 2
Status: Success (0x00)
В итоге, в интеграции "BTHome" получаем успешный прием термометров со стандартной рекламой и работающих в LE Long Range:
Если адаптер будет работать неустойчиво, тогда HA может его переинициализировать и настройка на работу в Coded PHY (Long Range) собьется. Ожидать официальной поддержки в интеграции “Bluetooth” нет никакой возможности. Выбранный автором API “Bleak” не позволяет управлять PHY адаптера и не предвидится никакой поддержки BLUETOOTH SPECIFICATION Version 5.0 от 2016 года.
BLUETOOTH SPECIFICATION Version 5.0 | Vol 1, Part C page 291
Core Specification Change History
9 CHANGES FROM v4.2 TO 5.0
9.1 NEW FEATURES
Several new features are introduced in the Bluetooth Core Specification 5.0
Release. The major areas of improvement are:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY for LE
• LE Long Range
• High Duty Cycle Non-Connectable Advertising
• LE Advertising Extensions
• LE Channel Selection Algorithm #2
Проверить адаптер на совместимость возможно с помощью команд:
# btmgmt phy
Supported phys: BR1M1SLOT BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE1MTX LE1MRX LE2MTX LE2MRX LECODEDTX LECODEDRX
Configurable phys: BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE2MTX LE2MRX LECODEDTX LECODEDRX
Selected phys: BR1M1SLOT BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LECODEDTX LECODEDRX
# hciconfig -a
hci0: Type: Primary Bus: USB
BD Address: 8C:88:2B:20:8B:42 ACL MTU: 1021:6 SCO MTU: 255:12
UP RUNNING
RX bytes:2020 acl:0 sco:0 events:178 errors:0
TX bytes:23965 acl:0 sco:0 commands:178 errors:0
Features: 0xff 0xff 0xff 0xfe 0xdb 0xfd 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'nanopineoplus2'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.1 (0xa) Revision: 0x999
LMP Version: 5.1 (0xa) Subversion: 0x646b
Manufacturer: Realtek Semiconductor Corporation (93)
Установка вариантов PHY в btmgmt работает не совсем корректно (в некоторых вариантах имеются ошибки). Но и с помощью этой программы возможно установить необходимые PHY.
Для этого необходимо:
- Вывести текущие установки PHY:
# btmgmt -i 1 phy
Supported phys: BR1M1SLOT BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE1MTX LE1MRX LE2MTX LE2MRX LECODEDTX LECODEDRX
Configurable phys: BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE2MTX LE2MRX LECODEDTX LECODEDRX
Selected phys: BR1M1SLOT BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE1MTX LE1MRX
- К вариантам 'Selected phys' добавить опции ‘LECODEDTX’ и ‘LECODEDRX’:
# btmgmt -i 1 phy BR1M1SLOT BR1M3SLOT BR1M5SLOT EDR2M1SLOT EDR2M3SLOT EDR2M5SLOT EDR3M1SLOT EDR3M3SLOT EDR3M5SLOT LE1MTX LE1MRX LECODEDTX LECODEDRX
PHY Configuration successfully set
Для установки PHY через API в bluez смотреть /doc/mgmt-api.txt.
Set PHY Configuration Command
=============================
Command Code: 0x0045
Controller Index: <controller id>
Command Parameters: Selected_PHYs (4 Octet)
Return Parameters:
This command is used to set the default PHY to the controller.
This will be stored and used for all the subsequent scanning
and connection initiation.
The list of supported PHYs can be retrieved via the
Get PHY Configuration command. Selecting unsupported or
deselecting default PHYs will result in an Invalid Parameter
error.
This can be called at any point to change the Selected PHYs.
Refer Get PHY Configuration command for PHYs parameter.
This command generates a Command Complete event on success
or a Command Status event on failure.
Possible errors: Invalid Parameters
Invalid Index
Или через hci_send_cmd(). Пример для Python (неполный и не совсем корректный):
import os
import sys
import struct
import bluetooth._bluetooth as _bt
OGF_LE_CTL = 0x08
OCF_SET_DEFAULT_PHY = 0x0031
def set_hci_phy(hci_sock, phy):
# save current filter
old_filter = hci_sock.getsockopt(_bt.SOL_HCI, _bt.HCI_FILTER, 14)
# Setup socket filter to receive only events related to the
# write_inquiry_mode command
flt = _bt.hci_filter_new()
_bt.hci_filter_set_ptype(flt, _bt.HCI_EVENT_PKT)
_bt.hci_filter_set_event(flt, _bt.EVT_CMD_COMPLETE);
_bt.hci_filter_set_opcode(flt, _bt.cmd_opcode_pack(OGF_LE_CTL, OCF_SET_DEFAULT_PHY))
hci_sock.setsockopt( _bt.SOL_HCI, _bt.HCI_FILTER, flt )
#< HCI Command: ogf 0x08, ocf 0x0031, plen 3 [ 03 05 05 ]
_bt.hci_send_cmd(hci_sock, OGF_LE_CTL, OCF_SET_DEFAULT_PHY, phy)
#> HCI Event: 0x0e plen 4 02 31 20 00
pkt = hci_sock.recv(255)
status = struct.unpack("xxxxxxB", pkt)[0]
print(status)
# restore old filter
hci_sock.setsockopt( _bt.SOL_HCI, _bt.HCI_FILTER, old_filter )
return status
if __name__ == "__main__":
dev_id = 1
hci_sock = _bt.hci_open_dev(dev_id)
status = set_hci_phy(hci_sock, struct.pack("<BBB", 3, 5, 5))
_bt.hci_close_dev(dev_id)
НА в докере, не получилось заставить работать с LR по предложенной инструкции. Может быть нужно ещё что то предпринять?
На ходу, когда уже загружен HA, переключение адаптера не работает. Требуется остановить HA. Или выполнить:
hcitool -i hci1 cmd 08 31 03 04 04
hciconfig -a hci1 down
hciconfig -a hci1 up
В Linux, в Bluez, адаптер BT5.0 по старту системы инициализируется неправильно. От этого все проблемы в Linux. Это аналогично тому, что адаптер с USB3.0 принудительно переключается в USB1.1, а API для переключения в USB3.0 нет. В итоге неясно, как Bluez получил какие либо сертификации. Остается одна надежда на ChatGPT и массовые увольнения “программистов”.
Интеграция "bluetooth" работает через прокладку "Bleak". "Bleak" в свою очередь работает через DBUS, Далее следующая "прокладка" - "Bluez", далее kernel. Это упрощенно, т.к. там десятки так называемых API прокладок. Писатели "Bleak" вообще не в курсе что в 2016 году вышел стандарт BT5.0 и есть какие-то переключения PHY у адаптеров. Просто недавно в bluez починили ошибки и в запрос сканирования теперь вставляется значение PHY по умолчанию, которые заданы на низком уровне адаптеру. Но утилиты bluez ещё не умеют создавать connect с разными вариантами PHY описанными в BT5.0. Там ещё не исправлены ошибки.
WEB Bluetooth API нормально не работает в Linux. В Android оно может соединяться с любыми PHY, но меню сканирования у Chrome ещё не умеет работать с BT5.0. В Windows ситуация с WEB Bluetooth API почти аналогична с Linux, но там другие проблемы. Linux тормозят Bluez и Товальдс, подписывая кривые решения.
API Android работает без проблем с Coded PHY и всеми остальными форматами PHY. Примером является nRFConnect и многие другие приложения на Android.
Apple вообще никогда не придерживалось стандартов Bluetooth SIG. И там свои предрассудки.
По идее, в докере, всё должно быть аналогично, если произвести переключение в той части, которая управляет адаптером. Адаптеры BT5.0 умеют сканировать во всех вариантах PHY с 2016 года. Бесшовно принимают рекламные пакеты от Bluetooth и всех вариантов BLE BT5.0, включая не стандартные на 2M PHY, если включить эти опции. Но работать с LE Long Range обычным пользователям не дают писатели софта и корпорации по неизвестным причинам. Возможно это подрывает коммерцию ZigBee...
Интеграция "ble_monitor" в HA включает сканирование только на 1M PHY. Автор ещё не умеет переключать адаптер на работу в BT5.0.
Спасибо за описание. Удалось таки перевести датчики lywsd03mmc на использование BLE LR в HA в докере. Пришлось перейти с ble_monitor на xiaomi_ble и заново их определить. Через btmon проверил подключение действительно в LE Coded. Посмотрю как это будет работать.
Посмотрю как это будет работать.
Потребление от батарейки сильно возрастает в режиме LE Long Range. Более чем в 3 раза из-за увеличения времени передачи в 8 раз на пониженной модуляции. Желательно изменить период трансляции рекламных сообщений на более чем 5 секунд. Включение LE Long Range актуально если термометр расположен на удалении и адаптер его плохо видит. Тестовые проверки при включении LE Long Range в Xiaomi LYWSD03MMC показывают, что связь с ним сохраняется на расстояниях более 500 метров и до 1 км по прямой видимости. В основном это требуется на отдельных частных участках с большими размерами. В городских "человейниках" эта опция бесполезна, т.к. 2.4ГГц плохо распространяется через препятствия в виде железо-бетонных и каменных стен.
Для достижения той же дальности в режиме "Legacy", по сравнению с режимом "LE long Range", требуется увеличение отдачи RF TX с +7 дБм (без учета коррекции ошибок в режиме "LE long Range"). Это недоступно на CR2032 из-за увеличения тока во столько же раз, во сколько требуется увеличение мощности передатчика. По сравнению с Bluetooth 4.0 требуется ещё увеличить мощность передатчика в несколько раз... При переключении на "LE Long Range" время передачи возрастает в 8 раз, но ток от батареи остается прежним (6..7мА при +0 дБм).
Стабильность работы проверена на приеме на дешевый адаптер без доп. антенн (указанный в заголовке темы) от термометра в соседнем доме-бане, находящимся примерно в 100 метрах. При этом уровень приема (RSSI) колеблется на уровне -102..-108 дБм по показаниям данного адаптера. Смартфон при этом спокойно соединяется с термометром в nRFConnect...
Это температура в предбаннике... При протопке печка дает повышение, без печки температура удерживается электронагревателем (мелкая волнистость линии - авто включение/выключение обогревателя)...
# lsusb
Bus 007 Device 002: ID 0a12:0001 USB2.0-BT
# hciconfig -a
hci0: Type: Primary Bus: USB
BD Address: 04:7F:0E:4A:0C:C9 ACL MTU: 1021:9 SCO MTU: 255:4
UP RUNNING INQUIRY
RX bytes:6445 acl:0 sco:0 events:463 errors:0
TX bytes:3579 acl:0 sco:0 commands:347 errors:0
Features: 0xbf 0xee 0xcd 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
Link policy: RSWITCH SNIFF
Link mode: PERIPHERAL ACCEPT
Name: 'BlueZ 5.64'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.1 (0xa) Revision: 0x89
LMP Version: 5.1 (0xa) Subversion: 0x89
Manufacturer: Barrot Technology Limited (2279)
hcitool -i hci0 cmd 08 31 03 05 05
Long Range - ok.
@pvvx
Добрый день! Xiaomi LYWSD03MMC прошит LYWSD03MMC Custom Firmware Version 4.2 на компе веб скрипты (сканер) видит устройство, дает прошить, иногда не может получить температуру влажность, иногда получает :)
19:48:54: Watching advertisements from "ATC_0B27B9"... 19:48:54: Argh! TypeError: device.watchAdvertisements is not a function
НО в HA со свистком Bluetooth 5.0 Realtek один раз добавился через Xiaomi BLE. Потом я недолго поигрался с параметрами через веб конфигуратор, и потом, чтобы я не делал, устройство более не добавляется (не видится)в HA (при этом CGPR1 продолжает нормально работать). Я и прошивал и на оригинальную и на модифицированную и батарею вынимал, и команду DD слал и 56, ничего не помогает.
Термометр в 3 метрах от Bluetooth свистка
на компе веб скрипты (сканер) видит устройство, дает прошить, иногда не может получить температуру влажность, иногда получает :) 19:48:54: Watching advertisements from "ATC_0B27B9"... 19:48:54: Argh! TypeError: device.watchAdvertisements is not a function
На Windows "Advertising.html" практически не работает. Это проблема в Windows c Web bluetooth API.
Работает только на Android.
НО в HA со свистком Bluetooth 5.0 Realtek один раз добавился через Xiaomi BLE.
В HA две интеграции для работы с термометрами - "Bluetooth" и "Bluetooth Low Energy Monitor - Passive BLE monitor".
"Bluetooth Low Energy Monitor" работает со всеми выбранными в TelinkMiFlasher.html форматами.
"Bluetooth" имеет расширения "BTHome" и "Xiaomi BLE". Для них необходимо выбрать в TelinkMiFlasher.html формат BTHome или Mijia. А так-же поставить галочку "AdFlag":
со свистком Bluetooth 5.0 Realtek
Рисунки и названия адаптеров от продавцов ни о чем не говорят. В Windows надо смотреть свойства адаптера в "диспетчере устройств".
По USB VID/PID можно узнать какой чип.
По номерам HCI/LMP - какой версии bluetooth:
@pvvx Может стоит в шапке веб конфигуратора указывать что нужно с мобильного заходить или я не нашел. с телефона конфигуратор заработал. Спасибо Попробовал два формата BTHome, Mijia - не находит. Настройки же сразу применяются, батарею вытаскивать не нужно?
Настройки применяются сразу, но BLE реклама не работает во время соединения. Подключаться для настроек в TelinkMiFlasher.html можно в любой ОС. А вот прием BLE рекламы в Windows зависит многих факторов. И пока в Chrome и других это опция - экспериментальная и предупреждение описано. Если не что-то там не работает - обращайтесь примерно туда: https://github.com/WebBluetoothCG/web-bluetooth https://github.com/WebBluetoothCG/web-bluetooth/blob/main/implementation-status.md
цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком
Google: USB\VID_0BDA&PID_8771 а это и есть 8761B
цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком
А это уже ваши проблемы с версиями ОС на RPI 4 и Home Assistant. Данный адаптер = тормоз. Ловит в 5..10 раз меньше реклам в единицу времени чем другие...
Может отсоединяется по причине посаженной батарейки. Для соединения желательно чтобы было более 40% (+20С). Далее будет работать c HA и до 0%.
батарея 99%. а подключение к chrome на телефоне может мешать подключению к RPI4?
Во время подключения BLE реклама, ту которую принимает HA, не передается. При подключении потребление больше...
спасибо за уделенное время. пока безуспешно. на тлф в браузере все ок на HA - тишина, хотя с таким же конфигом неделю назад термометр соединился, а теперь ни в какую
Отключите соединение с термометром в Android и в других. Закройте эксплорер. В HA термометр появляется с задержкой... Лучше перезапустить всю систему с HA и подождать пару минут.
@pvvx еще маленький вопрос, значок Bluetooth на самом устройстве что обозначает и должен ли он отображаться в момент рекламы (или соединения)?
Значок Bluetooth активен только во время соединения и мигает если нажата впаянная кнопка или геркон с выбором в меню функции геркона/кнопки "соединение" (обычно для Long Range).
@pvvx вместо Xiaomi BLE, установил аддон Passive BLE Monitor
И он нашел оба BLE устройства ¯_(ツ)_/¯ (на том же железе)
hcitool -i hci0 cmd 08 31 03 05 05Long Range - ok.
Hello, I got this dongle and tried to enable long range on my thermometer. Since none of my phones can do 5.0/coded phy and nrfconnect don't see the device I tried this dongle in Ubuntu 22.04 and I have partial success :-)
hcitool switch works and then when using bluetoothctl for scanning like described here https://stackoverflow.com/questions/60318829/bluez-bluetoothctl-scan-vs-hcitool-scan I can see the thermometer - its name and mac address. Then I tried gattool to connect to the mac address but unfortunately it does not work when trying to enumerate services/characteristic and for everything it fails with
Command Failed: Disconnected
So most probably it does not even connect properly. Here is output from btmon advertisement
> HCI Event: LE Meta Event (0x3e) plen 57 #247 [hci0] 1065.463599
LE Extended Advertising Report (0x0d)
Num reports: 1
Entry 0
Event type: 0x0001
Props: 0x0001
Connectable
Data status: Complete
Address type: Public (0x00)
Address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Primary PHY: LE Coded
Secondary PHY: LE Coded
SID: 0x00
TX power: 127 dBm
RSSI: -96 dBm (0xa0)
Periodic advertising interval: 0.00 msec (0x0000)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Data length: 0x1f
12 16 1a 18 1e 52 c9 38 c1 a4 db 09 14 12 c1 0a .....R.8........
4f 0e 04 0b 09 4c 59 57 53 44 30 33 2d 31 45 O....LYWSD03-1E
Service Data (UUID 0x181a): 1e52c938c1a4db091412c10a4f0e04
Name (complete): LYWSD03-1E
and here is connection attempt
< HCI Command: LE Extended Create Connection (0x08|0x0043) plen 42 #250 [hci0] 1065.465694
Filter policy: Accept list is not used (0x00)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Initiating PHYs: 0x05
Entry 0: LE 1M
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
Entry 1: LE Coded
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #251 [hci0] 1065.466611
LE Extended Create Connection (0x08|0x0043) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #252 [hci0] 1069.513740
> HCI Event: Command Complete (0x0e) plen 4 #253 [hci0] 1069.515681
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 31 #254 [hci0] 1069.521684
LE Enhanced Connection Complete (0x0a)
Status: Unknown Connection Identifier (0x02)
Handle: 0
Role: Central (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Local resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Peer resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Connection interval: 0.00 msec (0x0000)
Connection latency: 0 (0x0000)
Supervision timeout: 0 msec (0x0000)
Central clock accuracy: 0x00
somehow it does not handle the connection - gives error " Unknown Connection Identifier (0x02)" what is interesting is that there are those two connection entries Entry 0: LE 1M Entry 1: LE Coded
Is this something that can be changed in the firmware? Maybe it does not make sense to offer LE 1M connection if the advertisement is only over Coded PHY? Maybe with only one "LE Coded" entry gattool would not be confused and would possibly connect?
but when thinking about it maybe those two entries are on PC side(?) so not related to firmware - maybe it says which phy versions the PC supports/can try.
Just tried hcitool -i hci0 cmd 08 31 03 04 04 and indeed, it enables only Coded PHY and there is only 1 entry when connecting and it does not work too, same error.
With this 04 setting bluetoothctl scan shows only thermometer and nothing else, which may be sometimes good.
Oh, is is a bug, and quite old one https://www.spinics.net/lists/linux-bluetooth/msg65444.html
The unknown connection identifier is actually the success case for LE Create Connection Cancel command.
And the cancel is sent becasue of the 4s connection timeout.
Linux does not support the Bluetooth 5.0 specification released back in 2016. All utilities included in Bluez (hciattach hciconfig hcitool hcidump rfcomm sdptool ciptool gatttool in 2017) have long been declared obsolete and cannot be used to work with BLE devices. All other functionality has violations or neglect of the Bluetooth SIG specification There are only small pieces of Bluez and kernel v6.4+ code that work with some adapters.
USB-BT released a couple of years ago on ATS2851, like many others, does not work on Linux, even if all the latest patches to the kernel are applied. Patches in the Kernel are built according to the scheme - we do not understand how the function works or what flags are returned - a patch is put on excluding the use of this function. That is, the implementation of the functioning of BT5.0 and higher by such patches is simply excluded from support (the type of this HCI_xxx_BROKEN) for many BT adapters (selectively by functions). This leads to incomprehensible errors in old utilities as well.
Just tried hcitool -i hci0 cmd 08 31 03 04 04 and indeed, it enables only Coded PHY and there is only 1 entry when connecting and it does not work too, same error. With this 04 setting bluetoothctl scan shows only thermometer and nothing else, which may be sometimes good.
Yes. Because the rest of the functionality is performed by the adapter itself, and the reception of advertising with the reinitialization of the primary and secondary PHY is not patched yet :)
And the cancel is sent becasue of the 4s connection timeout.
Originally, in ancient times, timeouts were set correctly. Then they were fixed so that Linux would not work with BLE, and then fixed by many patch variants. But they never fixed it.
Now the solution is as follows: https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
PS: The only OS in which it is possible to work with BT5+ devices today is Android.
Now the solution is as follows: https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
Thanks! That worked and now it waits much longer however then after those 22 seconds it is cancelled anyway (maybe it does not get any data from thermometer?). Can this be related to some connection parameters like the scan window or max connection interval so that the dongle is not really listening when the data comes?
< HCI Command: LE Extended Create Connection (0x08|0x0043) plen 26 #1336 [hci0] 78319.407277
Filter policy: Accept list is not used (0x00)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Initiating PHYs: 0x04
Entry 0: LE Coded
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #1337 [hci0] 78319.408178
LE Extended Create Connection (0x08|0x0043) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #1338 [hci0] 78341.829151
> HCI Event: Command Complete (0x0e) plen 4 #1339 [hci0] 78341.830377
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
That worked and now it waits much longer however then after those 22 seconds it is cancelled anyway (maybe it does not get any data from thermometer?).
Linux does not support the Bluetooth 5.0 specification released back in 2016. The connection in the "Long Range" mode works very well in Android in a variety of applications using the basic API, including nRFConnect. Similarly, no problems are observed in many SDKs for SoC with BLE. But not on Linux.
I was unable to achieve a connection with BT5.0 devices in Linux on the available adapters. I also used kernel v6.4+ with the latest patches.
Due to the implementation curves in Linux and Windows, the "Web bluetooth API" cannot come to the implementation of BT5.0 scanning. But if:
- Enable the "Legacy" type of advertising on the device (BT 4.2)
- Open the connection program in the Chrome browser
- Start scanning before the device appears in the list of BLE connections
- Switch the device to work in extended advertising with "LE Long Range"
- Click "connect" in Chrome.
In Android, the connection will be successful. As a result, the browser does not yet know how to scan devices with extended and other advertising (BT5.0), but it can connect :) Linux and Windows keep users from accessing new features...
For these reasons, for bad operating systems, thermometers have a button to temporarily switch to the outdated mode for connection.
now it waits much longer however then after those 22 seconds
This is the reason for the use of incorrect algorithms in BT Linux drivers. Earlier it was announced that the implementation of scanning and connecting via the BLE protocol in Linux blocks the driver. This is unacceptable for implementation. It's as if the whole system or program is standing still until the driver figures it out. To connect, it is enough to get one advertising event. But not in Linux - it requires at least two. And if the second one is lost, then a timeout will come out, and 22 seconds will not be enough. Although for other operating systems, 10 seconds is enough, without any blocking.
Ok, then maybe it is worth to try some other bluetooth stack like https://github.com/bluekitchen/btstack and forget about bluez. btstack is opensource and free for non-commercial usage and is supposed to work in linux directly with usb dongles over libusb. BTW, this is the stack which also used in Raspberry Pico W.