TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр

pvvx

pvvx

Активный участник сообщества
И безусловно Espressif Systems всегда указывает завышенные характеристики (типа с пропусками 70% приема может когда и будет, если всё вокруг чипа идеально и супер антенна тоже, т.е. только при крайних лабораторных условиях):
ESP32C3 Series, Bluetooth LE 125 Kbps
Sensitivity @30.8% PER –105 dBm
RF transmit power Max^ 18.00 dBm
 
N

nikolz

Well-known member
pvvx написал(а):
nRF52840: -103 dBm sensitivity in 125 kbps, +8 dBm TX power.
BL702: -104 dBm sensitivity in 125/250 kbps, +14 dBm TX power.
CH583: Receiving sensitivity для 125 kbps не указано, +7dBm transmission power. Но указано: The communication distance is about 1000 meters at the transmission power of 7dBm and 125Kbps
PHY6252: Sensitivity:-105dBm@BLE 125Kbps data rate, TX Power -20 to +10dBm
....
Нажмите для раскрытия...
Угу, Вы еще бы телегу с авто сравнили по расходу бензина.
---------------
Вы наверное не забыли, если знали, что сравнивать надо при равенстве всех прочих параметров.
-------------
Сравнивать надо равные скорости передачи и объемы передачи данных.
что же относительно увеличения дальности у различных протоколов, то там увеличивается дальность путем создания избыточности а это расход времени и понижение скорости передачи полезной информации
--------------
Дальность связи - это бюджет радиомодуля.
А это лишь приемник +антенна и передатчик
Протоколы не имеют никакого значения, если нет помех.
-----------------------
А если есть помехи, дальность определяется уже другим методом
================
поэтому не надо ля-ля. Вы практически какую дальность на BLE получили? На сколько больше чем на ESP?
Вот то-то.
 
pvvx

pvvx

Активный участник сообщества
nikolz написал(а):
Угу, Вы еще бы телегу с авто сравнили по расходу бензина.
---------------
Вы наверное не забыли, если знали, что сравнивать надо при равенстве всех прочих параметров.
-------------
Сравнивать надо равные скорости передачи и объемы передачи данных.
что же относительно увеличения дальности у различных протоколов, то там увеличивается дальность путем создания избыточности а это расход времени и понижение скорости передачи полезной информации
--------------
Дальность связи - это бюджет радиомодуля.
А это лишь приемник +антенна и передатчик
Протоколы не имеют никакого значения, если нет помех.
-----------------------
А если есть помехи, дальность определяется уже другим методом
================
поэтому не надо ля-ля. Вы практически какую дальность на BLE получили? На сколько больше чем на ESP?
Вот то-то.
Нажмите для раскрытия...
Как и писано - на BLE LongRange к километру на даче.
На Wifi - пол километра и всего на 2.4ГГц + падение скорости. Пришлось через каждые не более 100 метров ставить репитеры.
 
pvvx

pvvx

Активный участник сообщества
Очередной "треш" термометр TH-05 от китайцев, под вид Xiaomi LYWSD03MMC, но для Tuya (палаточных изготовителей).
Датчик влажности заклеен (наклейка используется для монтажа, чтобы ничего не попало) :)
Minimum chipset power consumption (sleep mode, datacheet):
PHY6222QC-W04I - 13uA @ Sleep Mode with 32KHz RTC and all SRAM retention
BL55028 - 9 uA
Sensor? - 1 uA?
Total: above 23 uA
Это много для CR2032. На пол-года при успехе покупки хороших CR2032 и эксплуатации в отапливаемом помещении...
 
Slacky

Slacky

Member
Виктор, извините, немного не по теме. Вы же следите за BTHome? Вышла новая версия 2.0 и она уже доступна в HA 2022.12. Я обновил HA до этой версии. И два счетчика появились и отрабатывают. Но V2.0 BTHome сильно поменяли формат сообщений. Придется немного переписать код.

А вопрос у меня такой - если зашифровать сообщение, согласно методу, описанному в BTHome - https://bthome.io/encryption/, то по получению такого сообщения как HA его будет декодировать?

И второй - есть где-нибудь пример шифрования на Си?

Спасибо.
 
pvvx

pvvx

Активный участник сообщества
Slacky написал(а):
Вы же следите за BTHome?
Нажмите для раскрытия...
Да, и комментировал...
Вышла новая версия 2.0 и она уже доступна в HA 2022.12.
Нажмите для раскрытия...
Мне не нравится "новая версия 2.0". Для приема любого сообщения на масеньком MCU она требует всю кросс-таблицу всех известных идентификаторов и длины каждой переменной.
Т.е. если добавится что-то, то по минимуму будет необходима перепрошивка с обновлением. Такой выдумали формат. Обещают исправить ситуацию в версии 3.0 :)
И есть беды в HA с Bluez. и за этим всё тянется, включая BTHome. Пока не исправят, использовать интеграцию "bluetooth" можно только в ознакомительных целях.
А вопрос у меня такой - если зашифровать сообщение, согласно методу, описанному в BTHome - https://bthome.io/encryption/, то по получению такого сообщения как HA его будет декодировать?
Нажмите для раскрытия...
По введенному в конфигурации к устройству типовому коду, как от MiHome - bindkey, типа такого '43CA100B38FB9E7299DDE3538ED45D68'.
И второй - есть где-нибудь пример шифрования на Си?
Нажмите для раскрытия...
Для каждого MCU и вариантов SDK/либ возможны сильные отличия в описании и названии функций.
Но алгоритм примитивный - AES CCM, аналогичен прошлому от Mijia (MiHome), но не делает cipher.update(b"\x11") и наверняка Ernst Klamer описал на Питоне...
Есть в прошивке термометра, есть где-то и в ESPHome (надо только убрать аналог cipher.update(b"\x11") и скормить правильно куски)

Есть ещё беды, которые не предусмотрены во всех интеграциях HA основанных на "bluetooth" и если встрою в термометры BTHome v2.0, то придется им и ещё кое что лечить... :)
По этому не всё сразу.... почуток, а то не справляются :)
 
pvvx

pvvx

Активный участник сообщества
AES CCM - стандартная для BLE и есть во всех реализациях. По тому и выбрана. Но как и какие вызовы - это мучить конкретный SDK.
 
pvvx

pvvx

Активный участник сообщества
Slacky написал(а):
У меня не получилось. Перекомпилил пакет, согласно версии 2, и HA кроме уровня сигнала ничего не показывает ...
Нажмите для раскрытия...
Что "не получилось"?
Это - из-за неоднозначностей в Bluez, в начале рекламного пакета должны быть флаги. Иначе Bluez не работает с экспериментальной опцией "пассивное сканирование".
А в обычном режиме у Bluez только активное сканирование, которое посадит вам все автономные устройства BLE и затрет SD/SSD за пару месяцев непрерывной записью :p
И смешно - Экспериментальное спустя десятки лет наличия BLE... :)
 
pvvx

pvvx

Активный участник сообщества
pvvx

pvvx

Активный участник сообщества
Та и вооще, только год назад начали исправлять ошибки и кривые алгоритмы введенные всякими аборигенами в основном из Intel и подписанные в продакшн Линус Торвальдсом с BT/BLE в Linux.
"кривые алгоритмы" так и не исправили. Пусть все мучаются.
Ещё хорошо что они не залезли в Android. :)
 
pvvx

pvvx

Активный участник сообщества
Самое глобальное – они сделали из многозадачной системы работы с BT адаптером однозадачную, аля Arduino. Хотя адаптеры имеют распределение процессов по времени и переключение прием/передача и прыжки по каналам у BLE адаптера = пару мкс.
А у них – процесс приема рекламы останавливает все другие процессы и блокирует драйвер.
Это как если система пишет или читает какой-то файл, то другие процессы должны ждать закрытия файла - завершения работы с ним первого процесса. Дитя Arduino.
 
N

nikolz

Well-known member
pvvx написал(а):
Как и писано - на BLE LongRange к километру на даче.
На Wifi - пол километра и всего на 2.4ГГц + падение скорости. Пришлось через каждые не более 100 метров ставить репитеры.
Нажмите для раскрытия...
опять не верно сравнение.
в BLE у вас соединение точка-точка а в WiFi как?
если уж сравнивать, то надо брать два ESP в режиме ESP-NOW или на Wifi режим point to point.
и тогда будет тоже с натяжкой
в BLE дальность увеличивается за счет сужения полосы т е пропускной способности канала. это азы.
Да это даст эквивалент повышения мощности передатчика, но лишь при наличии помех.
Еще 5 лет назад ti делали эксперимент у них дальность BLE составила 10 км.
 
pvvx

pvvx

Активный участник сообщества
nikolz написал(а):
опять не верно сравнение.
в BLE у вас соединение точка-точка а в WiFi как?
если уж сравнивать, то надо брать два ESP в режиме ESP-NOW или на Wifi режим point to point.
и тогда будет тоже с натяжкой
в BLE дальность увеличивается за счет сужения полосы т е пропускной способности канала. это азы.
Да это даст эквивалент повышения мощности передатчика, но лишь при наличии помех.
Еще 5 лет назад ti делали эксперимент у них дальность BLE составила 10 км.
Нажмите для раскрытия...
Хватит бубнить. сказано что в 10 раз будет при LongRange (Coded PHY) дык и работает.
 
pvvx

pvvx

Активный участник сообщества
pvvx

pvvx

Активный участник сообщества
Мне проще было вставить ccm.c/ccm.h - там всё совпадает с типовыми примерами.
Для новой версии надо убрать байт add, указав длину 0
C: 
//     uint8_t add = 0x11; не нужен в новой версии шифра
    aes_ccm_encrypt_and_tag((const unsigned char *)&bindkey, // указатель на ключ, аналог от MiHome
                       (uint8_t*)&nonce, sizeof(nonce), // MAC и всякие ID устройства
//                       &add, sizeof(add),
                       0, 0, //
                       pdata_in, data_size, // указатель на шифруемые данные
                       pdata_out,  // указатель куда писать результат
                       pmic, 4); // указатель на 32-х битный счетчик
 
pvvx

pvvx

Активный участник сообщества
Обшибся:
Код: 
    aes_ccm_encrypt_and_tag((const unsigned char *)&bindkey, // указатель на ключ, аналог от MiHome
                       (uint8_t*)&nonce, sizeof(nonce), // MAC и всякие ID устройства, 32-х битный счетчик
                       0, 0, // add  не нужен
                       pdata_in, data_size, // указатель на шифруемые данные
                       pdata_out,  // указатель куда писать результат
                       pmic, 4); // указатель куда писать типа подпись-"контрольную сумму" шифра
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу