Работа термометров в Home Assistant c Bluetooth LE Long Range.

[pvvx]

Предварительное описание решения.

Для примера можно взять:
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.

Для этого необходимо:

1. Вывести текущие установки 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

2. К вариантам '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)

[vartom]

НА в докере, не получилось заставить работать с LR по предложенной инструкции. Может быть нужно ещё что то предпринять?

[pvvx]

На ходу, когда уже загружен 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...

[pvvx]

Интеграция "ble_monitor" в HA включает сканирование только на 1M PHY. Автор ещё не умеет переключать адаптер на работу в BT5.0.

[vartom]

Спасибо за описание. Удалось таки перевести датчики lywsd03mmc на использование BLE LR в HA в докере. Пришлось перейти с ble_monitor на xiaomi_ble и заново их определить.
Через btmon проверил подключение действительно в LE Coded.
Посмотрю как это будет работать.

[pvvx]

Посмотрю как это будет работать.

Потребление от батарейки сильно возрастает в режиме 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...

Это температура в предбаннике... При протопке печка дает повышение, без печки температура удерживается электронагревателем (мелкая волнистость линии - авто включение/выключение обогревателя)...

[pvvx]

aliexpress.com

# 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.

[almirus]

@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 свистка

[pvvx]

на компе веб скрипты (сканер) видит устройство, дает прошить, иногда не может получить температуру влажность, иногда получает :)
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:

[almirus]

@pvvx
Может стоит в шапке веб конфигуратора указывать что нужно с мобильного заходить или я не нашел. с телефона конфигуратор заработал. Спасибо
Попробовал два формата BTHome, Mijia - не находит. Настройки же сразу применяются, батарею вытаскивать не нужно?

[pvvx]

Настройки применяются сразу, но BLE реклама не работает во время соединения.
Подключаться для настроек в TelinkMiFlasher.html можно в любой ОС.
А вот прием BLE рекламы в Windows зависит многих факторов. И пока в Chrome и других это опция - экспериментальная и предупреждение описано.
Если не что-то там не работает - обращайтесь примерно туда:
https://github.com/WebBluetoothCG/web-bluetooth
https://github.com/WebBluetoothCG/web-bluetooth/blob/main/implementation-status.md

[almirus]

По USB VID/PID можно узнать какой чип.

[almirus]

цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком

[pvvx]

Google: USB\VID_0BDA&PID_8771 а это и есть 8761B

цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком

А это уже ваши проблемы с версиями ОС на RPI 4 и Home Assistant.
Данный адаптер = тормоз. Ловит в 5..10 раз меньше реклам в единицу времени чем другие...

[almirus]

то есть просто ждать и выгадать верное время для соединения ?

[pvvx]

Может отсоединяется по причине посаженной батарейки. Для соединения желательно чтобы было более 40% (+20С).
Далее будет работать c HA и до 0%.

[almirus]

батарея 99%. а подключение к chrome на телефоне может мешать подключению к RPI4?

[pvvx]

Во время подключения BLE реклама, ту которую принимает HA, не передается.
При подключении потребление больше...

[almirus]

спасибо за уделенное время. пока безуспешно. на тлф в браузере все ок
на HA - тишина, хотя с таким же конфигом неделю назад термометр соединился, а теперь ни в какую

[pvvx]

Отключите соединение с термометром в Android и в других. Закройте эксплорер.
В HA термометр появляется с задержкой... Лучше перезапустить всю систему с HA и подождать пару минут.

[almirus]

@pvvx еще маленький вопрос, значок Bluetooth на самом устройстве что обозначает и должен ли он отображаться в момент рекламы (или соединения)?

[pvvx]

Значок Bluetooth активен только во время соединения и мигает если нажата впаянная кнопка или геркон с выбором в меню функции геркона/кнопки "соединение" (обычно для Long Range).

[almirus]

@pvvx вместо Xiaomi BLE, установил аддон Passive BLE Monitor

И он нашел оба BLE устройства ¯_(ツ)_/¯ (на том же железе)

[pvvx]

What BLE to MQTT solution (if any)?

I don't use MQTT. I receive BLE in Home Assistant using two simple USB-BT adapters. One works for the near zone, the second for the far zone in the “LE Long Range” mode.
Backup BLE receiving channels are organized on various small SoCs, with my programs.

[fanoush]

NRF has not released USB-BT adapters or software for these options.

I am not talking about (normal HCI) USB-BT adapters. With espruino these dongles can run your stored javascript code, talk to anything over BLE and then write to USB serial any output you need. So the logic is in javascrit code inside the dongle, if the MQTT broker (like EspruinoHub) or the Home Assistant directly can read from serial port it should work.

[pvvx]

No versatility. For each task on NRF you will have to create a new program.

Today there are cheaper chips with full support for BT 5.4 from WCH. Less than 1 dollar.

The CH32V208W is a little more expensive. It has BT5.4, USB, Ethernet,... The SDK contains examples of working with BLE+MQTT+Ethernet...

[fanoush]

No versatility. For each task on NRF you will have to create a new program.

Oh! Well, I think you don't quite get it with the versatility, but never mind. if you have solution that works for you than that's great.

Here is one example of 'no versatility' https://www.espruino.com/Pixl.js+BLE+Ethernet+Bridge - it is NRF device with BLE and ethernet shield connected over SPI. In just few lines of javascript you convert any BLE advertisement seen around into MQTT message and send it to server over ethernet.

You don't need to write that stuff in C like with SDK for CH32V208W . If there would be e.g. micropython for that CH32V208W with working BLE api that can do long range then it would be similar.

[pvvx]

Who cares - I can do it faster in C.

But no one has been able to write a normal BLE gateway on nRF. For years already. And who in the modern world needs chips with libraries in blobs? NRF - proprietary software. - Correction of errors in nRF binary libs has to wait for years.

[lbarjak]

I would like to copy a specific long range solution, put one up, whether c or js. Victor ***@***.***> ezt írta (időpont: 2024. febr. 15., Cs 19:41):

…

Who cares - I can do it faster in C. — Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3B7YMVI7DHMJYNEPPFSO3YTZJFBAVCNFSM6AAAAAAU7QUZZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWHEYTQNBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fanoush]

But no one has been able to write a normal BLE gateway on nRF. For years already.

Not sure what you mean by "normal BLE gateway". If you mean HCI then we already discussed that, it is part of ZephyrOS and works. However due to poor Linux support as you said many times it is not very useful to get long range/coded phy working in Linux.

And who in the modern world needs chips with libraries in blobs? NRF - proprietary software

This was already discussed too. There are several open source production ready certified BLE stacks for nRF5x chips. Hardly any other chip has such wide open source support. There is ZephyrOS which is also current supported official SDK from Nordic (called nRF Connect SDK), there is also Apache NimBLE and there is at least one commercial one with full sources on GitHub which I think needs license for commercial use (forgot its name, maybe it was this one https://github.com/packetcraft-inc/stacks ?). SoftDevices are legacy and you are definitely not forced (or even recommended) to use them if you don't appreciate the advantages (stability, simplicity, clear separation from your code).

[pvvx]

This was already discussed too.

Again, one nRF advertisement, but in reality there are no devices for users or DIY on nRF.

Not sure what you mean by "normal BLE gateway".

I want to enable 'PAWR' on all thermometers, but users have no adapters capable of working with PAwR.
MQTT is just suitable for working with BLE 'PAwR'.
Create a cheap NRF project for working with BLE 'PAwR', and do not write advertising posts ...

[fanoush]

Again, one nRF advertisement, but in reality there are no devices for users or DIY on nRF.

Well I was just disproving your untruths. Would be nice if you could stop so there is no need to correct you over and over again (it is also off topic here).

Sadly you just did it again. There are of course tons of nrf5x based devices directly targeted for DYI both made by companies and also individuals and there is also a lot of hackable cheap nrf52 based stuff on aliexpress (smartwatches, fitness trackers, NFC+BLE keychains). For companies just check sparkfun or adafruit for their own nrf5x boards, adafruit even maintains Arduino and also Circuitpython for nrf52 just check list here https://github.com/adafruit/circuitpython/tree/main/ports/nrf/boards , also Microbit is NRF, the version 2 is 52833 and widely available (version 1 was bad IMO but 2 is nice). The Espruino stuff is mostly nrf52, previously I linked nrf52 boards for doing custom BLE/USB HID keyboards https://github.com/joric/nrfmicro/wiki/Alternatives For some reason they like 52840 based boards for this, not sure why, but they are probably quite popular as they got cloned and sold on aliexpress in quantities (google "ZMK firmware"). The Pinetime watch is nrf52832 - they are using Apache NimBLE there in their firmware. In fact it is one of many cheap hackable OTA updatable DaFit nrf5x based smartwatches which come in many shapes and sizes. One example is the 12 EUR "C17" nrf52840 one a.k.a. Magic 3 you can find on aliexpress now but there are many others. So you must be living in some parallel universe to say that thing I quoted. Or you just like to troll.

I want to enable 'PAWR' on all thermometers, but users have no adapters capable of working with PAwR. MQTT is just suitable for working with BLE 'PAwR'.

Oh, that is actually interesting stuff I did not know yet. Some time ago I tried to sync precise time via advertising but got bitten by that random delay and also wanted to send different scan response based on who is asking (so having bidirectional communication via advertising+scan response), it is nice someone was thinking in same direction and fixing both issues :-) GATT and connections are too heavy for a lot of stuff.

[pvvx]

There are of course tons of nrf5x based devices directly targeted for DYI

Where is the firmware for this thermometer to work in BTHome?

You are describing some toys that are not needed in IoT.
There are many more DIY boards available with other BLE chips. And there are many more of them than with SoС from the NRF

Low cost BLE Advertisements Repeater into Ethernet TCP/IP

@fanoush - How long will you advertise nRF or will you do something? :) :)

So you must be living in some parallel universe to say that thing I quoted.

Or do you need to block access to the repository "from this universe"? :)

[AleXSR700]

I wanted to move from my esp32 to bluetooth on my RPi and found this thread from the docs.
What I am uncleae about is why there is a need for a BLE USB adapter if the RPi already has BLE (5.0) onboard.

Or is this only for people who use their wifi, because yes, then bluetooth does not work properly anymore. But with wifi disabled, should the internal one not be sufficient?

[Nuts-Underline]

предлагаемые что nrf, что wch и esp - новые сущности, для которых нужны будут и драйвера и софт. получается эдакий черный ящик по типу zigbee - мало кто знает как оно вообще работает внутри, просто даем нужные (AT) команды и получаем результат. При этом пока что эта штука будет diy - потребуется некоторые умения, чтобы просто собрать ее и прошить.
А вот если бы заменить весь bluez на другую "прокладку", между уже имеющимся драйвером RTL8761 (из kernel) и HA/BLE passive, которая умела бы только BLE, без тонны ненужного (аудио, obex) и всяких dbus, но знала бы v5.x ...
тем hcitool и hciconfig не нужен обвес, они обеспечивают минимальные операции для ble через socket(AF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC, BTPROTO_HCI);

[pvvx]

А вот если бы заменить весь bluez на другую "прокладку", между уже имеющимся драйвером RTL8761 (из kernel) и HA/BLE passive, которая умела бы только BLE, без тонны ненужного (аудио, obex) и всяких dbus, но знала бы v5.x ... тем hcitool и hciconfig не нужен обвес, они обеспечивают минимальные операции для ble через socket(AF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC, BTPROTO_HCI);

Сокращать или оптимизировать код - это не в духе современных программистов.
По заявлению от Bluez утилиты hcitool и hciconfig являются устаревшими.

Драйвер в Linux kernel не умеет работать с чипами в BT5.0+. И решений не предвидится.
Это аналогично тому, что у вас есть USB2.0 или USB3.0, но Linux может работать только с USB1.1.
Новые стандарты (десятилетней давности) в Linux доступны только с применением индивидуальных патчей.

Ситуация в Linux с WiFi, Zigbee, SSD/NVME, CPU, ... аналогична. Никакой поддержки стандартов вышедших десятилетие назад. Только частичная - выборочная и кривая.
И так, как Linux занимает часть рынка, то это тормозит всех производителей устройств и конечных программных продуктов. К примеру – Chrome Explorer не может включить сканирование BLE устройств в режиме LE Long Range, да и вообще нормально дописать API сканирования BLE устройств для пользователей, т.к. Linux не имеет такой поддержки и функциональности. А производители не могут использовать новые стандарты в реализации своих устройств, тем самым ограничивая пользователей только древним функционалом. Скорее всего такая позиция выгодна кому-то из "разработчиков-держателей" kernel в Linux.

[Nuts-Underline]

Драйвер в Linux kernel не умеет работать с чипами в BT5.0+.

я то думал что низкоуровневый драйвер только транслирует HCI команды через socket. и что для задач HA достаточно послать что то типа cmd 08 31 03 05 05
bluez как бы тоже часть kernel, но к нему прилагается кучка разнородных утилиток типа btgatt-client и btgatt-server которые (глубоко внутри) пишут в socket всякие BT_ATT_OP_READ_BY_TYPE_REQ + PDU, без посредничества dbus. Для десктоптных применений все это действительно не нужно, но для серверного то проще их допилить, наверное (и будут они обновленными :)

[pvvx]

В kernel проблемы с инициализацией USB-BT адаптеров. Куча затычек, отключающих его писателями "непонятные функции" , на которые не смогли разобрать ответ адаптера. Это в основном и есть функционал BT5.0+.
Bleak ссылается на Bluez и Dbus. Bluez ссылается на kernel. Круговая порука...

https://www.bluez.org/profiles/

что для задач HA достаточно послать что то типа cmd 08 31 03 05 05

BLE cоединение в CODED PHY не работает. Так-же не работают все новые варианты ble advertising из новых версий стандартов.
Bluez API не имеет поддержки функционала BT5.0+. Чтобы это исправить необходимо переписать все команды-форматы API с нуля. А это создаст несовместимость с прошлыми версиями. Простыми добавлениями новых затычек это не исправить. Были неправильно выбраны параметры-опции к любым командам BLE и их общая концепция. Исправления путем добавления новых команд приведут к монстру и использованию нескольких команд для выполнения простых действий. В итоге проще ожидать или построить новый API, а про Bluez и Bleak забыть.

[Nuts-Underline]

проще ожидать или построить новый API, а про Bluez и Bleak забыть.

так о том мысль и была. вопрос в том насколько глубоко его отпилить и где все эти затычки и индивидуальные патчи.
в исходниках btrtl.ko и btusb.ko как то больше про загрузку firmware. я так понимаю что само сканирование advertising с прыганием по каналам, да и всего такого находится в firmware, исходников которых realteck никому не дал.
стало интересно как это реализовано в андройде, ядро то там старое, а bluetooth прослойка должна быть вообще своя

[pvvx]

В Andrioid всё нормально. API предоставляет сканирование и подключение устройств во всех вариантах (включая CODED PHY).
В Chrome эксплорерах (Web Bluetooth API) на Andrioid сканирование не дописано из-за Linux, но если при сканировании в режиме PHY 1M был захвачен MAC (устройство появилось в списке подключений), то дальнейшее переключение устройства в CODED PHY не влияет на подключение - всё подключится. И это так же говорит о том, что API полное и полностью поддерживает CODED PHY. В Windows и такое не работает - там всё запутано сложнее.
А в Linux - вообще никак не подключиться к устройству работающему в CODED PHY. И мелкие патчи не помогут.

само сканирование advertising с прыганием по каналам, да и всего такого находится в firmware

Все функции находятся в firmware адаптера. И если адаптер имеет спецификацию BT5.+, то соблюдает её.
Но в Linux, при инициализации, производится опрос всех имеющихся функций у адаптера. При непонятном ответе часть из функций просто блокируют, ограничивая доступ. См. "kernel bluetooth quirk" - HCI_QUIRK.. примеры

[Nuts-Underline]

спасибо, теперь увидел и суслика и подводную часть айсберга (в исходниках kernel). В кишочках android я наверное уже не буду копаться - перетаскивать низкий уровень из ядра в ядро слишком кучеряво будет.

[pvvx]

К примеру, если в НА запускается интеграция “https://github.com/custom-components/ble_monitor”, то она через “Bleak” включает адаптер на работу только с PHY 1M. Если переключить PHY после старта интеграции, то если в интеграции возникнут какие ошибки или недочеты, то она опять переключит адаптер на работу только с PHY 1M. Это проблема находится в “Bleak”. А “Bleak” там используется только для переинициализации адаптера при старте и ошибках. Остальное на "Bluez".
Интеграция “Bluetooth” работает через “Bluez” (и DBUS) и (пока) не использует функции установки режимов PHY у адаптера (первичных и вторичных). Только за счет этого возможно перевести адаптер в разные режимы PHY на ходу, подав описанные в теме низкоуровневые команды самому адаптеру. Это дает возможность использовать сканирование в PHY Coded, но не более. Всё остальное работать с Coded PHY не будет.

В “Bluez” у функций нет параметров задания первичного и вторичного PHY, что требуется для поддержки BT5.0+. Есть только спец функция глобальной установки типов PHY, которую (пока) никто не использует. Т.е. необходимо переписывать все BLE функции в "Bluez", на что никто никогда не пойдет.
Большинство установок по умолчанию в "Bluez" заданы не в соответствии со стандартами Bluetooth. По этому работа эксплорера и прочих API с BLE устройствами невозможна без коррекции конфигурационных файлов "Bluez".

[Nuts-Underline]

секунду. Bleak я вижу только один раз в custom_components/ble_monitor/ble_parser/get_beacon_key.py и это отдельный вызываемый скрипт. в других местах используется https://github.com/ukBaz/python-btsocket (BlueZ Bluetooth Management API)внутри которой пути ведут в сокеты libc_socket(PF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI). это тоже типа часть bluez https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt где я так понял и есть упоминаемая функция установки режимов PHY включая 13 LE Coded
dbus уже вообще лишняя прокладка выходит.
то есть надо что то делать с кодом в ядре, в папке /linux-6.11/net/bluetooth/... где много всяких quirk?
даже если сделать свою каcтомную сборку ядра (мантейнеров kernel кстати стали банить по географическому признаку) то там, я так понял, много допиливать требуется, хотя там есть упоминания BT5.2

[pvvx]

dbus уже вообще лишняя прокладка выходит.

У большинства HA работает в контейнере.

Про "Bleak"

BTHome

Да и много где писалось, не только мной. Но воз и ныне там...
А хотелось бы реализацию “PAwR” и стандартной шифрации BLE рекламы из BT5.4.
Тогда Zigbee более никому не нужен.

то есть надо что то делать с кодом в ядре

Вместо копания в Linux и Windows проще сделать свой адаптер. Благо большинство чипов на рынке полностью поддерживают BT5.0+, а реализации BT5.4 – это чисто программные дополнения. В SDK большинства чипов уже давно примеры BT5.3. Даже ESP32-C3 поддерживает всё необходимое.
По просьбе Ircama я накидал программы приемника BLE реклам, а он оформил проект https://github.com/pvvx/ADV_BLE2UART. Аналогично возможно и дальше развить...

[Nuts-Underline]

У большинства HA работает в контейнере.

ну вот и тут засада.... я как раз наоборот - накачал ядер в том числе андройда, посмотреть, что и как менялось в net/bluetooth и насколько я вижу - в ядре 6.6 уже есть всякие adv_sec_phy и BT5.3 так что надежда есть

[pvvx]

так что надежда есть

Эта надежда теплится уже десяток лет :)
И десть лет назад, код был правильный для версий Bloetooth того времени и были правильные установки по умолчанию всяких интервалов, пока туда не залезли кенты из Intel и специально внесли искажения. Затем эти поправки много лет исправляли и так, на сегодня, и не исправили.

Последние пару лет хотя-бы работает сканирование в LE LR с командой адаптеру, а если начнут исправлять - большая вероятность что вообще ничего работать не будет.

Проблемы находятся в использованных алгоритмах и подходах. Мелкими патчами и дополнениями это не исправить.
Пример: В Android при подключении к BLE устройству достаточно одного приема события BLE рекламы (маяка). Т.к. адаптер и вообще все команды в чипе исполняются путем аппаратных (или полу-аппаратных) функций состоящих в запуске транзакции RX-TX или TX-RX. Сразу после приема маяка передается RF фрейм соединения и происходит соединение. А в Windows и Linux требуется прием двух событий BLE рекламы. Если период между приемами больше 10 секунд (стандарт BLE), то Linux и Windows выйдут по таймауту. А это возникает очень часто, т.к. бывают выпадения приема из-за помех в эфире. В итоге в Linux надо ставить тайм-аут более 20 сек и всем пользователям всегда ждать дополнительное время, равное интервалу BLE рекламы у устройства для соединения.
Android этого лишен.
Аналогично с приводимыми отговорками, что нельзя ставить большие интервалы, т.к. на время сканирования драйвер якобы блокируется. Чего нет ни у кого другого.
Т.е. мультизадачность в Linux не работает и не видно её решения, к примеру в одновременном соединении с разными устройствами с разными PHY, одновременное сканирование и трансляция маяка. Все современные мелкие чипы BLE это умеют.

И у “модных” мини-компьютерных плат типа “ Raspberry Pi” есть аппаратные приколы. Соединение с чипом BLE на UART c 115200 Baud :) В этот низкоскоростной интерфейс связи входят и заголовки HCI интерфейса, плюс нет контрольной суммы и у всех пользователей периодически проскакивают ошибки. Linux не является real-time системой и еле-еле обрабатывает UART в 115200, и то, только за счет FIFO в UART.
А для HCI уже недостаточно USB2.0FS.

Да и Линус Торвальдс закрыл доступ разработчикам из России. Я вот думаю тоже удалить все свои репозитории с BLE с github.com и переехать на что-то типа GitVerse... Тем более что более-менее чипы BLE ныне все китайские и у китайцев всё более лучше в перспективе с BLE, как и в области API для новых стандартов, так и в SDK к чипам…

[Nuts-Underline]

примечательно что kernel в android практически тот же самый, включая работу с несколькими видами hci, верхушка только совсем другая. и как то работает.
свой адаптер тоже надо каким то интерфейсом подключить, мне собственно и такое сойдет, но надо будет такой адаптер подарить хотя бы автору интеграции passive ble, а так же создать свой протокол вместо hci.. плюс там свои приколы наверняка... но это все уж за рамки этой темы про термометры

[AleXSR700]

Interesting conversation, although i need to translate everytime.
Please don't move to gitverse.

[evadim]

pvvx

Да и Линус Торвальдс закрыл доступ разработчикам из России. Я вот думаю тоже удалить все свои репозитории с BLE с github.com и переехать на что-то типа GitVerse

Интересная мысль, которую я сначала не заметил, из-за правки. Похоже что волны вокруг Линуса вскрыли причины, по которым русских людей или продукты так или иначе выпиливают из публичных проектов. А я так понимаю через полтора месяца будет интересно.

AleXSR700

Please don't move to gitverse.

Is there any issue to keep read interesting conversation on some random git hosting? Is Gitverse any different to Gitlab, Codeberg etc?

But the real issue is what after this Linux kernel drop some maintainers because unknown reason can lead to sudden removal of pvvx's repositories from Github - why not? While Linux Fondation have unclear relations to sanctons and complience, Microsoft owned Github clearly have them.

[AleXSR700]

The problem is the lack of usage of gitverse and the higher likeliness that the language will shift from the international language English to Russian.
I mean no disrespect, but I would not be in favor of switching to a primarily German git either, despite it being my native tongue. I think English will remain the language for international collaboration.

[Nuts-Underline]

можно вообще исключить bluez используя отдельный [bt стэк]https://github.com/bluekitchen/btstack/tree/master/port/libusb(url) который умеет обращаться к usb адаптерам включая RTL8761 через libusb, умеет extended advertising and scanning и знает про LE Coded

[pvvx]

можно вообще исключить bluez

В итоге проще ожидать или построить новый API, а про Bluez и Bleak забыть.