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

[sL0n1k]

Разве там rsa?
Мне думалось, что там симметрия, aes, нет?

 

[pvvx]

Это смотря где. В интерфейсе Mijia своё и там несколько ключей. Для процедуры регистрации самого термометра, для прошивки через функции Mijia и для прочих функций. Заходите на сайт Mijia и там всё описано, как и куда обращаться.
А для доп. варианта прошивки OTA разрешено использование функций производителя. Это другой интерфейс и там уже другие ключи. Счас используется только вариант частичной регистрации устройства, чтобы он выдал ключ откытия интерфейса. А OTA от Telink, вообще без ключей, если есть первый простой ключ.
Откройте примеры API от Mijia и там всё есть, кроме самих либ и ключиков, чтобы собрать даже пример.

 

[pvvx]

小米IoT文档与资源中心

iot.mi.com

GitHub - MiEcosystem/mijia_ble_standard

Contribute to MiEcosystem/mijia_ble_standard development by creating an account on GitHub.

github.com

 

[sL0n1k]

понял, спасибо)

 

[sL0n1k]

HA адверт добавил,
longe range в настройках показал
s2=s8 - старшие три флага flg2 =1
none - старшие три флага flg2 =0

кто такой flg2.adv_flags ?

apk - на почте для тестов (если есть возможность потестить), я его переименовал, чтобы про qt в названии ничего не было,
поэтому он станет отдельным приложением, старый можно грохнуть

прошивку с включенным long range на свой девайс пока не шил, если изменений не будет никаких - залью (или есть что-то новое?)

 

[pvvx]

прошивку с включенным long range на свой девайс пока не шил, если изменений не будет никаких - залью (или есть что-то новое?)

Изменений пока нет и временно не будет. Занят разным...
flg2.adv_flags - включает в рекламу стандартный GAP_ADTYPE_FLAGS: Discoverable/BR/EDR. Без них в системной панели WIndows BT и в Bluez устройство не видится. Всем остальным он не нужен - лишние затраты батарейки.
GAP_ADTYPE_FLAGS; // type
/* Flags:
bit0: LE Limited Discoverable Mode
bit1: LE General Discoverable Mode
bit2: BR/EDR Not Supported
bit3: Simultaneous LE and BR/EDR to Same Device Capable (Controller)
bit4: Simultaneous LE and BR/EDR to Same Device Capable (Host)
bit5..7: Reserved
*/

 

[Yakov]

Здравствуйте.
Возможно ли подружить Home Assistant с LYWSD03MMC (в роли экрана) ?
Я бы хотел с Home Assistant посылать на LYWSD03MMC показания другого удаленного датчика температуры.
Заранее благодарен.

 

[sL0n1k]

Long Range firmware short test.

Залил, протестил (пока не долго), работает.
3 девайса лежат рядом, advert period ~ 2.5 сек у всех. Тест через три стены. Много вайфая.

По адресам (последний байт): 49 - китаец, 32 - Texas, B8 - Cypress (legacy - без Long Range)
RSSI у техаса получше, но не существенно. Всех делает кипарис - это он еще без лонга. (К сожалению на этом девайсе не могу включить long range (чип не позволяет))

Коннект - тоже нормально: быстро читает и данные и историю.

Правда, сразу при попытке коннекта - завис жестко, перегрузил, вернул опять long rane - пока коннекты без зависаний .
Ну, это может и не связано с long range, потому как, судя по притухшему экрану, начал сильно жрать батарею, - скорее всего вообще не уходил в слип, видимо в бесконечном цикле.
На адвертах не зависал пока.

В общем, есть еще, что исправить)

Смена режима long range - legacy тоже без проблем - бесшовно.

 

[pvvx]

Возможно ли подружить Home Assistant с LYWSD03MMC (в роли экрана) ?
Я бы хотел с Home Assistant посылать на LYWSD03MMC показания другого удаленного датчика температуры.

Готовых интеграций для этого не видел. ПО термометра это делать позволяет.

 

[pvvx]

Ну, это может и не связано с long range, потому как, судя по притухшему экрану, начал сильно жрать батарею, - скорее всего вообще не уходил в слип, видимо в бесконечном цикле.

Связано - в Coded PHY потребление значительно больше. И если "бросили" соединение, то термометр будет кричать каждый connect interval в течении времени указанного в connect timeout.
Аналогично большой удар на батарейку происходит при начале соединения, когда считываются все UUID. Вызвавший соединение лезет на своих установках connect interval, а переключение (запрос) термометром на изменение параметров соединения происходит позже. В этот момент батарея значительно просаживается, и учитывая что у LYWSD03MMC Xiaomi пожидились с кондерами по питанию, то уже при ~40% батареи соединение рушится.
Термометру тут сделать нечего - не он задает начальные интервалы соединения и интенсивность опроса. Существует только одна возможность - выкинуть все UUID и оставить типа только один. Тогда этот опрос здорово сокращается.
Ещё один провал по питанию происходит при использовании пин-кода и bind. Всё аналогично - запрашивающий заставляет термометр сделать сразу и всё и с принудительной интенсивностью ответов-приветов.
Это недоработка BLE SIG.

 

[pvvx]

В этих случаях даже большой кондер по питанию может не спасти. Он не успеет заряжаться от слабой батареи, а для передачи ответов любому BLE чипу с текущими технологиями нужен ток (от 8 мА) и напряжение (от 1.8В).
А стартовая интенсивность опроса внешним адаптером по стандарту не нормируется и производители плевали, что у датчика слабая батарея.
Некоторые BT адаптеры запоминают прошлый (с последнего соединения) connect interval и повторно лезут уже с его установками... Но это до сброса питания или переинициализации адаптера софтом...
Если у датчика уже подсажена батарея, то по этому повторный coonect чаще бывает удачным...

 

[pvvx]

Для культурных адаптеров есть UUID 2A04 - Peripheral Prefered Connection Parameters, но большинство адаптеров плевали на это. Я пытался и так и сяк это менять, но ничего положительного это не дало. Всё равно адаптеры лезут на соединение с интервалами какими захотят.

 

[pvvx]

Пример, c UUID 2A04 указываем интервал соединения 40..60 ms.
Первое соединение, после сброса адаптера BT CSR A10 (выдергивания и вставки в USB):

Он соблюдает эти указания до команды смены интервалов (где-то на 650 мс).
Теперь второе соединение (адаптер не сбрасывался):

Параметры connect interval уже взяты из прошлого конца соединения.

И это необязательная последовательность - на разных адаптерах всё по разному.

 

[pvvx]

У ESP32 лучше не смотреть вообще - он не успевает ничего обрабатывать, и будут одни перезапросы и полное истощение батареи.
ESP32 тормоз ещё тот - 2 ядра работают не быстрее 16MHz STM32 из-за ужасно громадного C++ кода и пока там восполняется кэш из SPI-Flash с доступом не быстрее 20 мегабайт в сек (т.е. производительность обоих ядер ограничена поступлением кода выполнения для CPUs из SPI-Flash на уровне не более 10 Мкоманд в сек). А дети и Arduino ещё включают лог в UART - это тормоз на уровне 115200 бит вывода отладочных сообщений тормозящих исполнение.
И это даже мелочи - прикручивают MQTT, а это значит что все буфера будут заполнены и CPU не сможет обрабатывать связь с BLE до ответов связи TCP с внешним сервером. И всё это время термометр будет дублировать передачи данных, пока детское чудо и ESP32 не смогут ползти дальше
Кароче, если ESP32 то - гудбай батарейка за пару недель у всех BLE с которыми ESP32 связывается.

 

[sL0n1k]

Опять завис при коннекте, причем теперь экран не притухший. Вряд ли это батарея. Батарейка новая, могу блок питания ему дать, который лабораторный, но не думаю, что надо. Да и батарейка - не повод так зависать. Если я обнаружил, что у меня низкое напряжение питания (прерывание соответствующее , или SDK), то просто перевожу чип в down, можно с соответствующей индикацией в Вашем случае. Да, кстати, про уровень в процентах - насколько я помню характеристика CR2032 аппроксимируется как минимум 3-мя прямыми, если брать прямые, то что у Вас (в %), мягко говоря, далеко от идеала)

Но, как маяк работает без зависаний (пока).

 

[sL0n1k]

Уточнение: зависает в момент установки коннекта, обнаружение сервисов еще не начинается, возможно это поможет найти причину.

 

[sL0n1k]

Кстати, можно указать, что коннект будет происходить только на 1 мбите, в этом случае, при включенном Long Range "маяк пробивает стены", но для того чтобы, например, изменить настройки надо к нему подойти поближе. Так сделано у меня. А еще при коннекте можно снижать мощность передатчика, но так у меня не сделано))

 

[pvvx]

Опять завис при коннекте, причем теперь экран не притухший. Вряд ли это батарея. Батарейка новая, могу блок питания ему дать, который лабораторный, но не думаю, что надо. Да и батарейка - не повод так зависать. Если я обнаружил, что у меня низкое напряжение питания (прерывание соответствующее , или SDK), то просто перевожу чип в down, можно с соответствующей индикацией в Вашем случае. Да, кстати, про уровень в процентах - насколько я помню характеристика CR2032 аппроксимируется как минимум 3-мя прямыми, если брать прямые, то что у Вас (в %), мягко говоря, далеко от идеала)

Но, как маяк работает без зависаний (пока).

Всё это туфта. Если поставить кондер в питание - всё работает. Программно заместить это чип не может.
При импульсе тока TX RF напряжение от CR2032 проваливается слишком резко и любые мозги у любого CPU/MCU поедут. До BOR это не доходит.
Всё это перепроверено много раз - сбивается и RC генератор и нарушаются интервалы..
А в свой вы можете поставить любой кондер. А тут жадность Xiaomi с пустой недопаянной позицией для кондера, чтобы все чаще меняли батарейки

 

[pvvx]

А вторая причина - особенно в Androd connect с интервалом более 1000 мс приводит к сбоям после первой части согласования. Он не откликается более и выходит тайм-аут соединения. Если проскочило - то будет работать, но может ещё раз нарваться. И никакие непрерывные повторы запросов в течении 10 секунд не спасают.

 

[pvvx]

Пример, по току у Xiaomi LYWSD03MMC при connect c Android на не очень свежей CR2032 при con.interval 20 мс latency 124 (125*20=250 мс):

И так ведет себя CR2032 по напряжению:

Один запрос-ответ обслужен после соединения на 4300 мс. Далее, на следующий в 6800 мс, ответа уже нет и термометр дублирует безответные запросы до тайм-аута соединения.
Как это исправить?