• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

BLE SoC PHY6202

pvvx

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

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

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

cool2000

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

pvvx

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

pvvx

Активный участник сообщества
Писакам плевать, что весь мир будет ждать дополнительные до 10 секунд.
А в Linux ещё жаловались, что на это время драйвер блокирован. :eek:
Именно по этому там уменьшили интервал почти до 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.
Веселые времена...
 

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

Member
В 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 устройств, где половина роутеров.
Для тупейшего анализа возьмем любимый СВЧ диод и осел и поднесем к роутеру:
1713743458473.png
И это только передача подтверждений у одного данного роутера в сети Zigbee.

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

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

pvvx

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