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

[pvvx]

Для этого термометра выкладывают прошивки на Зигби.
Вместе с прошивками выкладывают команды для редактирования нужных переменных( подстройка показаний, частоты обновления данных, влк.и выкл. каких то параметров)
Это редактирование прошивки осуществляется при помощи Питона.

Это не Питон. Это скрипт для Zigbee2MQTT.

-По этому я узнавал,можно ли производить редактирование при помощи других средств.

Редактирование производится большинством программного обеспечения работающего с Zigbee координатором.
Кроме "Smart Life", "MiHome" и прочих, которые поддерживают только свои устройстсва.

Такие как скорость обновления данных и экрана(так как датчик становится слишком тормознутым).

ZigbeeTLc

Настройки отчета по умолчанию
Конфигурация питания (ClusterID: 0x0001), Напряжение батареи (Attr: 0x0020). Мин. интервал 360 сек., Макс. интервал 3600 сек., Допуск 0.
Конфигурация питания (ClusterID: 0x0001), Оставшийся процент батареи (Attr: 0x0021). Мин. интервал 360 сек., Макс. интервал 3600 сек., Допуск 0.
Измерение температуры (ClusterID: 0x0402), Измеренное значение (Attr: 0x0000). Мин. интервал 30 сек., Макс. интервал 180 сек., Допуск 10 (0,1°).
Измерение относительной влажности (ClusterID: 0x0405), Измеренное значение (Attr: 0x0000). Мин. интервал 30 сек., Макс. интервал 180 сек., Допуск 50 (0,5%).

Обновление экрана (если есть изменения) и замер температуры и влажности происходит каждые 10 секунд.

При уменьшении описанных значений будет сильно расти потребление батареи.

Все эти параметры сторонний софт, управляющий Zigbee координатором, устанавливает свои.
Для Tuya и Xiaomi типичным являются установка минимальных интервалов обновления от 15 минут до часу чтобы не перегружать свои сервера (Cloud).

 

[pvvx]

Для прошивки BLE по умолчанию измерения производятся каждые 10 сек и передаются, и обновляется экран если показания изменились.
Для датчиков с E-Ink (EPD) период увеличен до 20 сек, т.к. потребление таких дисплеев из-за частого обновления больше чем у типичных LCD.
Для BLE в Home Assistant есть две интеграции. Встроенная - "Bluetooth" - "BTHome" обновляет значения и пишет в базу данных со скоростью обновления значений датчиком.
В интеграции "Passive BLE Monitor" на каждое устройство устанавливается период усреднения поступающих значений. Типовой - 30..60 сек.
Но все события всегда отрабатываются и записываются сразу.
Когда у вас будет нормальный "Умный дом" - сотни устройств, то суточный объем записи в базу данных будет составлять около десятка ГегаБайт, при условии что вы исключите запись совсем ненужных...

 

[pvvx]

История и графики в "Smart Life" или "MiHome" не будут обновляться чаще 15 минут, даже если датчик передает значения каждую секунду.
К примеру BLE часы Xiaomi передают температуру и влажность каждую секунду... но толку никакого - шлюз Xiaomi будет пересылать данные (одну точку графика) на Cloud только раз в пол часа.
Аналогично с Tuya хабами и т.д.
Иначе представьте какой будет трафик в сети к этим Cloud. Больше чем у Ютуба

 

[pvvx]

Дошли руки-ноги до оптимизации варианта использования батарейных BLE устройств с экраном, для приема типовых сторонних BLE датчиков имеющих старый стандарт BT4.2… Основная проблема была в начальной синхронизации приема и слежения за периодом передачи BLE advertising стороннего датчика, обычно использующего рандом добавку к периоду передачи…

Примером применения может являться BLE устройство с малой батареей и экраном, производящее прием и показ данных внешнего BLE датчика и синхронно передающего свои данные. При синхронизации с периодом BLE advertising в 5 сек у внешнего датчика, среднее потребление у приемника с экраном (LYWSD03MMC) выходит порядка 20 мкА. Это значительно меньше чем у Zigbee устройства с шагом передачи 5..10 секунд.

Из этого потребление самим LYWSD03MMC с периодом синхронизации в 5 секунд составляет:

• Sleep 6 мкА (сон датчика + 1.8 SoC TLSR8251 + работа LCD)
• Добавка в 6..8 мкА на передачу BLE advertising
• 6..8 мкА на прием BLE advertising от стороннего датчика.

К примеру, это позволяет закинуть внешний датчик на улицу и выводить его показания на панельку с E-Ink дисплеем и питанием от CR2450 в течении более года.

Исходники будут удержаны до появления аналогов у альтернативных реализаций...

 

[pvvx]

GitHub - pvvx/BLETHR: Receiving and displaying data from an external thermometer BTHome on Xiaomi LYWSD03MMC.

Receiving and displaying data from an external thermometer BTHome on Xiaomi LYWSD03MMC. - pvvx/BLETHR

github.com

 

[AGRO]

Коллеги, доброго дня. А нету ли у кого кусочка скетча для Arduino - работы с OTA. Чтобы можно было обновлять прошивку термометра из своего софта, и не приходилось отключать спаривание термометра с esp32 и далее прошивать его через Telink.
Можно, конечно, расковырять TelinkOTA и переписать всё это на Arduino, и впихнуть уже это в esp32, но может есть у кого готовое решение

 

[pvvx]

Уже можно подвести некоторые итоги по системе BLETHR "BLE устройство с малой батареей и экраном, производит прием и показ данных внешнего BLE датчика".

Условия первого измерения:

Дом с 3 жителями (2 подростка).
Источники шума в эфире:
3 смартфона, 2 компа, WiFi роутер, 3 постоянно работающих BLE устройства, BT наушники.

Испытуемые:
BLE устройство LKTMZL02 с LCD в доме принимает уличный термометр ZY-ZTH02 на расстоянии 5 метров от дома. Все используют мощность передачи 0 дБм.

Счетчик ошибок приема у LKTMZL02:

(На выпадения не смотреть - расстояние связи с устройством записи более сотни метров и тут сотня работающих в радиоэфире устройств, прием на BT брелок, работа в обычном формате PHY 1M, уровень приема -101 дБм. При снеге уровень сигнала на приеме ещё ухудшается. Периоды без увеличения счета ошибок - никого нет в доме или спят - выключены WiFi устройства, кроме WiFi роутера)

1463 не принятых маяков за 3-е суток.
В среднем выходит 20 выпадений в час. За час передается 720 маяков. Это 2.7% не принятых маяков.
-----------------------------------------------
Условия второго измерения:

Дом2
Источники шума в эфире:
В окружении (в доме и на улице до 10 метров) более 60 BLE, 40 Zigbee, 20 WiFi вечно активных устройств...

Испытуемые:
BLE устройство ZY-ZTH02Pro с LCD в доме принимает уличный термометр на расстоянии 2 метров от дома.

Счетчик ошибок приема ZY-ZTH02Pro:

Имеет 7818 не принятых маяков за 3-е суток.
В среднем выходит 108 выпадений в час. За час передается 720 маяков. Это 15% не принятых маяков.
Ступень - полная рассинхронизация приема - 5-ть пропусков подряд и новый цикл синхронизации в N непопадений в подстраивающееся окно прима. Причина - работа в 2-х метрах от ZY-ZTH02Pro микроволновки. Сбивает связь не всегда.

 

[pvvx]

Дополнительные причины выпадений - окно приема при окончанию синхронизации всего 10 мс (при потреблении устройством в момент приема 6 мА). Подстраивается с 20 мс до 10 мс по итогам усреднения вычисления периода передачи передатчика. Передатчик имеет шаг передачи 5 секунд. 80% окружающих BLE имеют кратный шаг передачи, но в BLE используется рандом добавка к шагу передачи для расхождения (уменьшения коллизий). В данном случае это от 0 до 6 мс. В окружении у ZY-ZTH02Pro с LCD в 2 метра находится более 15 таких BLE. Они и дают почти постоянный шаг коллизий. Плюс непападения в окно приема из-за ухода счета времени от температуры у RC генератора и рандом добавки периода принимаемого маяка.
Все эти ухищрения с малым окном приема имеют цель уменьшения потребления от батареи принимающим устройством до среднего уровня в 20 мкА с учетом работы LCD индикатора и трансляции собственного маяка (он дублирует данные приема с добавлением счетчика ошибок и напряжения своей батареи).
А так как передача внешнего датчика дублируется 4 раза между измерениями, то даже три подряд выпадения ни на что не влияют.