ESPHome ловит адверты очень редко

[vevsvevs]

Период адверта установлен раз в 5 секунд (пробовал и другие), но успешно ловятся они совершенно бессистемно - от 20-30 секунд до 20 минут и более. При этом в nRF Connect вижу пакеты с довольно редкими выпаданиями, т.е. вполне стабильно. Полагаю, что связано с параметрами interval и window на стороне ESP32, но перебрав великое множество разных вариантов, сколько-нибудь надёжного поведения так и не добился. Нативные датчики разных моделей ловятся нормально, сборка от atc1441 - тоже без проблем, всё совпадает с отчётами nRF Connect. Очень бы хотелось понять причину, и использовать эту прошивку совместно с ESPHome.

[pvvx]

https://esp8266.ru/forum/threads/ochen-chasto-esp32-propuskaet-priem-reklamnyx-paketov.5533/

[vevsvevs]

Спасибо за ответ. Но с окном 125мс, пропуски от стока (возможно, благодаря "пучковым" отправкам), и от ATC (не знаю благодаря чему) идут примерно в отношении 1/100. Здесь же получается 95/100, и это лучший результат. В любом случае, спасибо за попытку разобраться, будем копать дальше, а пока "боевые" просто верну на ATC.

[pvvx]

Test reception of beacons (Advertising) RTL8272DM Realtek AmebaD Arduino.
Original Xiaomi firmware:
delta: 16xx ms, lost: 3, total receive: 100
Custom firmware version 2.4:
delta: 25xx ms, lost: 0, total receive: 150
....
delta: 2524 ms, lost: 1, total receive: 260

/*
   Test Advertisements Scanning
*/
#include "BLEDevice.h"
#if 1
#define AD_PERIOD_MS 2500
BLEAddr inMacAddress = BLEAddr("a4:c1:38:0b:5e:ed"); // The remote data device MAC / custom firware ver 2.4
#else
#define AD_PERIOD_MS 1750
BLEAddr inMacAddress = BLEAddr("a4:c1:38:05:4e:0a"); // The remote data device MAC / original firware Xiaomi
#endif
uint32_t tik_scan, rx_all_count = 0, rx_err_count = 0;
boolean flag_restart = false;
BLEAdvertData foundDevice;

void scanFunction(T_LE_CB_DATA *p_data)
{
  foundDevice.parseScanInfo(p_data);
  if (inMacAddress == foundDevice.getAddr()) {
    uint32_t tt = millis();
    uint32_t delta = tt - tik_scan;
    tik_scan = tt;
    if (rx_all_count++) {
      if (delta > AD_PERIOD_MS + AD_PERIOD_MS / 10) {
        rx_err_count++;
      }
    }
    printf("MAC: %s ------ delta: %d ms, lost: %d, total: %d\n", foundDevice.getAddr().str(), delta, rx_err_count, rx_all_count);
    flag_restart = true;
  }
}

void setup()
{
  Serial.begin(115200);
  BLE.init();
  BLE.configScan()->setScanMode(GAP_SCAN_MODE_PASSIVE); // Active mode requests for scan response packets GAP_SCAN_MODE_PASSIVE
  BLE.configScan()->setScanInterval(420);               // Start a scan every 420ms
  BLE.configScan()->setScanWindow(420);                 // Each scan lasts for 420ms
  BLE.configScan()->updateScanParams();
  BLE.setScanCallback(scanFunction);
  BLE.beginCentral(0);
  tik_scan = millis();
  BLE.configScan()->startScan(420 * 3);
}

void loop() {
  if (flag_restart) {
    flag_restart = false;
    BLE.configScan()->stopScan();
    vTaskDelay((AD_PERIOD_MS / 4) / portTICK_RATE_MS);
  } else if (!BLE.configScan()->scanInProgress()) {
    BLE.configScan()->setScanMode(GAP_SCAN_MODE_PASSIVE); // Passive mode scan response packets
    BLE.configScan()->setScanInterval(2100);               // Start a scan every 2100ms
    BLE.configScan()->setScanWindow(2100);                 // Each scan lasts for 2100ms
    BLE.configScan()->updateScanParams();
    BLE.configScan()->startScan();
    vTaskDelay((AD_PERIOD_MS / 5) / portTICK_RATE_MS);
  } else {
    vTaskDelay(10 / portTICK_RATE_MS);
  }
}

PS: This question should be forwarded to Espressif and ESPHome programmers.

[pvvx]

Но с окном 125мс, пропуски от стока (возможно, благодаря "пучковым" отправкам), и от ATC (не знаю благодаря чему) идут примерно в отношении 1/100. Здесь же получается 95/100, и это лучший результат.

ESP32-WROWER-B, Arduino, sketch:
https://github.com/pvvx/ATC_MiThermometer/blob/master/esp32/BLE_term_lcd/BLE_term_lcd.ino

---

Firmware:
https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer.bin 19 Nov 2020
Time scanning 517 seconds, lost: 36, rx total: 224:

Time since boot: 517. New scan.
  ------ delta: 1900 ms, lost: 36, total: 224
Found service '181a' data len: 17, 10161a18a4c1380b5eed01121f630c1b15
MAC: a4c1380b5eed
Temp: 27.4°, Humidity: 31%, Vbatt: 3099, Battery: 99%, count: 21

---

Firmware v2.4:
https://github.com/pvvx/ATC_MiThermometer/blob/master/ATC_Thermometer24.bin
Time scanning 731 seconds, lost: 41, rx total: 236:

Time since boot: 731. New scan.
  ------ delta: 2500 ms, lost: 41, rx total: 236
Found service '181a' data len: 19, 12161a18ed5e0b38c1a4b90a4a0cf20b5f6004
MAC: a4c1380b5eed
Temp: 27.45°, Humidity: 31.46%, Vbatt: 3058, Battery: 95%, flg: 0x04, count: 96

Где 95/100 ? По времени сканирования процент пропусков сканирования у ESP32 примерно одинаков вне зависимости от прошивок и устройств выдающих рекламу. Возможно все ESP32 имеют небрежно разработанную версию или ошибки в кристалле. Все разработки Espressif кишат глобальными ошибками, несовместимыми с рабочими устройствами. Единственный рынок сбыта чипов Espressif - это DIY, где нет никакой гарантии или ответственности производителя.

Ещё натикало:

Time since boot: 3226. New scan.
 ------ delta: 2512 ms, lost: 182, rx total: 1049

[pvvx]

Оставил в людном месте в городе на 8 часов. От приемников до датчика около 10 метров.
Кол-во сканируемых окружающих устройств BLE колеблется от 50 до 100, кол-во WiFi станций - аналогично.

Последние сообщения в логах:
ESP32: delta: 2520 ms, lost: 1941, rx total: 9884
RTL8722DM: delta: 2510 ms, lost: 853, rx total: 11601

[vevsvevs]

Тоже проверил оба варианта (ATC и PVVX) в нагруженной среде, результаты плачевны, очевидно есть какие-то проблемы в реализации ESPHome. Судя по всему, лучшие результаты ATC были "ошибкой выжившего", т.к. я проверял её только по адвертам с данными, т.е. со значительно бОльшим интервалом выборки.. Предвижу ответ, но всё же спрошу: может всё-таки сочтёте возможным реализовать burst-отправку адвертов с отдельным от маяка интервалом (я почему-то уверен, что это поможет)? Ведь проект ESPHome - очень популярное, гибкое и удобное решение во множестве кейсов в рамках HASS, и очень жаль что его сканер BLE подводит в столь типовом сценарии использования.

[pvvx]

Ещё раз проверил что там показывает тест.
ESP32 перезагрузился - можно считать вышел из строя, хотя у него подключено резервирование питания на АКБ.
RTL8722DM продолжает считать:
delta: 2497 ms, lost: 1764, rx total: 23530
Т.е. в самой неблагоприятной обстановке потери рекламных пакетов от датчика составляют 7.5%.
Это при шуме в эфире от других BLE приблизительно в 3000 пакетов в сек и от 50-ти работающих WiFi AP.
BLE Рекламу гонят всякие телевизоры, какие-то Apple устройства и прочие и каждый гонит с периодом в 10-20 мс...
Магазин у метро, Cанкт-Петербург.

[pvvx]

Ведь проект ESPHome - очень популярное, гибкое и удобное решение во множестве кейсов в рамках HASS, и очень жаль что его сканер BLE подводит в столь типовом сценарии использования.

Я не могу переписать все сторонние программы и исправить все кривые разработки чипов от Espressif и других производителей не вписывающихся в стандарты BLE.
У ESP есть свои фанаты – им и заказывайте приведение в порядок своих разработок.

[pvvx]

К примеру sniffer на TLSR8266 чипе ловит практически все пакеты от всех моих домашних BLE устройств.
У ESP32-WROWER-B (у меня есть и другие ESP32 – различий не заметил), в документации значится:

А у TLSR8266:

По указанным значениям он хуже, но в модуле JDY-10 на внутреннюю антенну ловит лучше.
Как и указанные характеристики в документации на RTL8722DM тоже хуже.
Можно сравнить и с другими чипами BLE от nRF или Ti - они тоже у меня есть. Худшим будет ESP32.
Кому после этого верить?

[vevsvevs]

Безусловно, в первую очередь надо верить личному опыту :) Я с вами полностью согласен, виновный определен, а в последнем сообщении я лишь просил по возможности сделать костыль для одного из самых распространенных и доступных DIY-проектов, т.к. на исполнительном устройстве это выглядит реальнее, чем на изначально забагованном железе ESP32. Ответ я получил, ещё раз спасибо за исчерпывающие ответы и отличный проект!