BLE SoC PHY6202

[pvvx]

В Chrome получить MAC в API невозможно. Только если включить все галки расширений и только в недоделанной специальной функции сканирования, которая ужасающе работает в Windows, но нормально работает в Android с 1M PHY. Это что-то связанное с “безопасностью” Так же исключены некоторые MAC (есть черный список) и чтение некоторых UUID.

Но фиг с ними – может кто из корпорашек пробьет эту стену… к примеру AMD. Процы c BT5.4 продавать надо

@cool2000 - Есть вопрос – зачем в Windows и Linux при соединении, после получения списка сканирования, требуется прием двух (!) рекламных событий? Android обходится одним.
Вы копались в этом, и ситуация не понятна – нафига ждать два события рекламы с интервалом до 10 сек? Чипы BLE соединяют при приеме первого рекламного события и не ждут второго... Это опять Ардуино-программеры покопались?

 

[cool2000]

Вы копались в этом, и ситуация не понятна

На Андроид тоже есть проблемы с этим, точно в режиме Coded PHY. nRF Connect соединяется не с первого раза, хотя сканер регистрирует попытки соединения и принимает и запрос и ответ.
Если соединились, то соединение держит и спокойно переключает PHY, пробовал переключать во все режимы: 1M/2M/Coded_S8.

 

[pvvx]

Надо смотреть не на сканер, а на участников - возможно что сигнал не прошел на их антенны. Всякие коллизии и интервалы...
Думаю что писаки написали так - первый раз принимают для уточнения что такой MAC есть и ждут второго события рекламы с 3-мя рекламами уже для запроса соединения.
Сам адаптер так себя не ведет.

 

[pvvx]

Писакам плевать, что весь мир будет ждать дополнительные до 10 секунд.
А в Linux ещё жаловались, что на это время драйвер блокирован.
Именно по этому там уменьшили интервал почти до 2-х секунд...

 

[pvvx]

Это надо было так умудриться - типа незя открыть несколько файлов одновременно... и блокировать драйвер пока работает один...
Хотя адаптер может работать с несколькими устройствами.

 

[pvvx]

Конкретно написали что драйвер блокируется на время сканирования. Может это была отмазка, но это парадигма Arduino - там учат выполнять всё последовательно и типа таймеров и прочих мультизадачных средств не существует.

 

[pvvx]

В итоге соединение с устройством работающим с "периодической рекламой" не будет работать в Linux или Windows.
Складывая все баги и использование неправильных алгоритмов в реализации Bluetooth в Linux одним блобом AMD не обойдутся для реализации BT5.4 в Linux.
А Bluez, как и kernel дрова необходимо кардинально переписывать с нуля.

 

[pvvx]

А месяц назад накрыли багами Zigbee OTA в ZHA Обновление прошивок в новых версиях Home Assistant простым пользователям теперь недоступно.
Плюс пока ни один вариант шлюза Zigbee в Linux не соответствует стандартной спецификации Zigbee 3.0.
Веселые времена...

 

[cool2000]

А что, есть специальные варианты шлюзов Zigbee для Linux?

 

[pvvx]

Есть всякие программы/либы типа Z2M, Zigpy, ...
Так же есть всякие адаптеры и в них прошивки со своими реализациями Zigbee с разным интерфейсом.
Внешние программы не контролируют всё, что делает адаптер.
И беды и в ПО адаптера и во внешних программах.

 

[pvvx]

Так же в сети Zigbee есть роутеры. В них своё ПО. Как оно реализует стандарт Zigbee 3.0 зависит от их производителя. А это чаще всего писатели под Tuya - помойка из Китая.

 

[pvvx]

В Zigbee можно приколоться с самого начала - соединение с координатором в 90% случаев производится через UART на 115200 Baud.
Несмотря на это фрики сравнивают какой координатор тянет больше одновременно подключенных устройств и роутеров
Типовой (и минимальный) период между пакетами связи у устройства (по стандарту) - четверть секунды. С учетом заголовков и прочей инфы перегрузка шины UART возникает уже при нескольких устройствах...
В итоге сеть Zigbee рассчитана на вялотекущие события и не может использоваться в нормальном IoT для "Вумного дома".
Только для начинающих - играющих в пару устройств.

 

[pvvx]

А далее глядим на такое в логе:
WARNING (MainThread) [zigpy.application] Zigbee channel 25 utilization is 88.70%!
Это уже при сети в 12 устройств, где половина роутеров.

 

[cool2000]

В Zigbee термометре Tuya, похож на TH05 с экраном, 2 батарейки ААА сели меньше чем за полгода!

 

[pvvx]

Для одного приемника реклам - адаптера BLE типично работа с сотней ближайших устройств. Далее RF каналы будут перегружены. Решение только в разносе по положению, что возникает естественным образом.

 

[pvvx]

В Zigbee термометре Tuya, похож на TH05 с экраном, 2 батарейки ААА сели меньше чем за полгода!

Ну это зависит от писателей.
Конечному устройству без проблем выходить на связь раз в сутки
Вот только где такой датчик можно применить, кроме как выключателя света. А сам выключатель в автоматизированной системе не требуется - должен отрабатывать автоматически...

 

[pvvx]

В Zigbee термометре Tuya, похож на TH05 с экраном, 2 батарейки ААА сели меньше чем за полгода!

Там два контроллера "борющихся за независимость" через шину UART на 9600 Бод
Перепрограммированию не подлежит, без устранения лишнего чипа и установки перемычек.

 

[pvvx]

На протокол Matter корпорации переходят для удорожания устройств и обоснования повышения цены. Там тупого MCU недостаточно. Нужен полный стек IP, что требует дополнительных ресурсов у чипа и энергии для его работы. А производственных мощностей для чипов с маложрущими технологиями в пару нанометров не хватает.

 

[pvvx]

А далее глядим на такое в логе:
WARNING (MainThread) [zigpy.application] Zigbee channel 25 utilization is 88.70%!
Это уже при сети в 12 устройств, где половина роутеров.

Для тупейшего анализа возьмем любимый СВЧ диод и осел и поднесем к роутеру:

И это только передача подтверждений у одного данного роутера в сети Zigbee.

А народ дурят, что это "помехи":

"Zigbee channel 15 utilization is 97.04%!" in logs immediately after restart

Hello, I am running a Zigbee network via the ZHA integration and a Skyconnect coordinator. the following error is now appearing in my HA logs after restarting: 2023-04-11 15:19:24.006 WARNING (MainThread) [zigpy.application] Zigbee channel 15 utilization is 97.04%! It only appears...

community.home-assistant.io

Zigbee channel 11 utilization is 92.06%!

I just noticed the following in my logs: Zigbee channel 11 utilization is 92.06%! If you are having problems joining new devices, are missing sensor updates, or have issues keeping devices joined, ensure your coordinator is away from interference sources such as USB 3.0 devices, SSDs, WiFi...

community.home-assistant.io

...

Откуда в лесу помехи на 25-ом канале, когда WiFi на 1 канале?
И почему при увеличении кол-ва устройств в Zigbee сети проценты utilization повышаются?

 

[pvvx]

И похоже, что налепили горбатого в новых версиях. Не уточнял, где это – в прошивках или во внешнем ПО, но теперь устройству принудительно устанавливают период Long Poll Control менее 6 секунд, не взирая на параметр Long Poll Control Min у устройства. Это требует от устройства просыпаться каждый период…
Т.е. и в этом завезлись вредители, жаждущие быстрейшего разряда батареек у конечных устройств.