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 operating in the BTHome v2 format on the display of another BLE thermometer.

Receiving and displaying data from an external thermometer operating in the BTHome v2 format on the display of another BLE thermometer. - 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 раза между измерениями, то даже три подряд выпадения ни на что не влияют.

 

[pvvx]

Очередное бедствие от мелких WiFi SoC.

Не проработала 2 года и видимо сдох БП – высохли кондеры. Это не первый случай, а уже 3-тий, с устройствами WiFi на мелких чипах за 3 года.

И это всего из 3-х работающих на WiFi таких розеток. Остальные, более 20 шт выключателей с измерением потребления на Zigbee работают непрерывно уже более 3-х лет без всяких проблем.

В итоге вся окружающая сеть на 2.4ГГц полегла, включая BLE и Zigbee. Происходило это "стихийно" несколько дней, сначала малыми периодами глушения, видимо когда напряжение в сети слегка падало, потом вышло на постоянное глушение.

Причина обычна.

Когда питание у ESP или других мелких WiFi SoC нестабильно (не хватает тока и/или плавно опускается под нагрузкой) то эти чипы начинают постоянно перезагружаться. При этом некоторые включают активное сканирование AP на всех каналах. Т.е. орут в эфир на каждом канале через несколько мс. Так же у многих по спецификации WiFi положено объявлять при старте о выходе в эфир – это пачка передач из объявлений на всех каналах. У ESP8266 ещё другая беда – если при передаче напряжение питания проваливается, то передатчик остается включенным и это работает как глушилка всего в большом диапазоне (у ESP8266 неисправный BOR и нет связи RF блока с сигналом reset).

А т.к. когда в БП сохнут кондеры, то все эти чудо WiFi чипы постоянно перезапускаются и начинают передавать в эфир, и тут-же сбрасываются и по новому. И так повторяется бесконечно с глушением всех сетей на 2.4ГГц.

Это основная причина по чему необходимо избавляться от мелких WiFi SoC в любом случае.

 

[pvvx]

В аналогичных Zigbee “Умных розетках” установлен такой-же БП. Но разница в потреблении чипом Zigbee от WiFi составляет более 10 раз. У Zigbee розетки самое большой ток потребления имеет реле.

Если над такой WiFi розеткой в пределах 20..30 см установлен термометр, то его показания температуры всегда завышены на 2..3 градуса (может и более). Корпус такой WiFi розетки всегда горячий. У Zigbee – холодный.

В итоге, в среднем, БП или зарядное устройство работающее на WiFi чип дохнет в среднем за период непрерывной работы в 2..3 года. Т.к. все БП имеют КПД не 100% и им необходимо рассеять куда-то потери в закрытом пластиковом корпусе. А размеры корпусов примерно одинаковы и выходит, что для WiFi температура кондеров уже завышена, плюс в 10 раз больший импульсный ток.

 

[sulimoff]

Telink Flasher поломался? Дальше не продвигается

 

[pvvx]

13:56:14: Hardware Revision String: B1.4
13:56:14: Software Revision String: V5.1
13:56:14: Firmware Revision String: github.com/pvvx
13:56:14: Detected custom Firmware
13:56:14: Hardware Version: LYWSD03MMC B1.4, Software Version: 5.1
13:56:14: Custom config HEX string: 55071000064004a931310070
13:56:23: Settings 01 was sent successfully
13:56:24: DevName: [ATC_5B5CA6]
13:56:36: Get Sensor Settings...
13:56:36: Sensor SHTV3(C3) id: 00C30887, I2C address: 0xE0, Kt: 17500, Kh: 10000, Zt: -4500, Zh: 0
13:56:46: Disconnected.

13:57:24: Reconnect to: ATC_5B5CA6
13:57:31: NetworkError: Connection Error: Connection attempt failed.
13:57:31: Reconnect 1 from 5
13:57:36: Hardware Revision String: B1.4
13:57:36: Software Revision String: V5.1
13:57:36: Firmware Revision String: github.com/pvvx
13:57:36: Detected custom Firmware
13:57:36: Hardware Version: LYWSD03MMC B1.4, Software Version: 5.1
13:57:36: Custom config HEX string: 55071000064004a931310070

 

[pvvx]

Telink Flasher поломался? Дальше не продвигается

Скорее всего ваш BT адаптер наелся других вариантов прошивок с данным MAC и не собирается перечитывать новую таблицу UUID.
И он частично прав, т.к. так рекомендовано в стандартах Blouetooth SIG - не стоит тратить энергию знакомого (по MAC) устройства на перечитывание таблицы UUID.
Перезагрузка поможет ему забыть прошлое Сброс возможен и отключением-включением BT в Android. И Chrome тоже любит кэшировать таблицу UUID...

 

[pvvx]

И у Chrome есть разные кнопочки перезагрузки...
И дрова в Linux тоже любят кешировать данную табличку, но там необходимо стереть файлики, поплясав с бубном в диких длинных именах и глубине каталогов...

 

[pvvx]

В данной табличке есть UUID, в котором обозначается какие другие UUID были изменены. Это предусмотрено стандартом, и таковой имеется, но устройство не в состоянии хранить MAC всех входящих, тем более Android-ных со случайными MAC и объявлять им всем что табличка сменилась после OTA Т.е. это всё рассчитано для быстрого с малым потреблением BLE соединения, только если вы не меняете прошивки как перчатки, оставляя при этом тот-же MAC...

 

[pvvx]

В особо тяжких случаях, если пользователь ни бэ ни мэ ни в чем - меняют MAC устройства...

 

[pvvx]

Перечитать таблицу BLE-устройства: инструкция

DeepSeek: Что необходимо сделать чтобы перечиталась таблица BLE устройства?

(Due to technical issues, the search service is temporarily unavailable.)
Чтобы перечитать таблицу атрибутов (Attribute Table) BLE-устройства, нужно выполнить следующие действия:
1. Переподключение к устройству

• Отключитесь от BLE-устройства (disconnect).
• Подключитесь заново (connect).
• При повторном подключении клиент (например, смартфон или ПК) обычно заново запрашивает таблицу атрибутов.

2. Обновление кеша характеристик (если используется)
Некоторые BLE-стэки (например, в Android или iOS) кешируют таблицу атрибутов. Чтобы её перечитать:

• На Android:
  java
  Copy
  BluetoothGatt.refresh() // (через reflection, т.к. метод скрыт в публичном API)
  или перезапустить Bluetooth-адаптер:
  java
  Copy
  BluetoothAdapter bluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
  bluetoothAdapter.disable();
  bluetoothAdapter.enable();
• На iOS:
  Нужно отключиться (CBPeripheral.disconnect) и подключиться заново.

3. Использование GATT-запроса на повторное обнаружение сервисов
После подключения выполните:
java
Copy
bluetoothGatt.discoverServices(); // (Android)
или аналогичный метод на другой платформе.
4. Сброс кеша BLE-стэка (если таблица изменилась)
Если устройство обновило свою таблицу атрибутов (например, после прошивки), но клиент этого "не видит", попробуйте:

• Перезапустить Bluetooth-демон (на Linux/Windows).
• На Android: очистить кеш Bluetooth через "Настройки → Приложения → Bluetooth → Очистить кеш".

5. Использование специализированных утилит

• nRF Connect (Mobile/Desktop) – позволяет принудительно перечитать атрибуты.
• GATT Tool (Linux) – команда primary для повторного сканирования сервисов.

Если устройство поддерживает Service Changed Characteristic (0x2A05), оно само уведомит клиента об изменении таблицы атрибутов, и переподключение не потребуется.
Если проблема сохраняется, проверьте:

• Не изменилась ли прошивка BLE-устройства.
• Корректно ли работает BLE-стэк вашей ОС.
  
  
  
  
  
  

 

[pvvx]

Так что обращайтесь к DeepSeek - оно 90% ответов по BLE и Zigbee (и т.д.) даст правильно (или в нужном направлении - 100%), даже о прошивках TelinkMiFlasher
И напишет любую запрошенную фигню на Arduino, если уточнять... Т.е. по вопросам Arduino форум можно закрывать.

 

[AGRO]

Так что обращайтесь к DeepSeek - оно 90% ответов по BLE и Zigbee (и т.д.) даст правильно (или в нужном направлении - 100%), даже о прошивках TelinkMiFlasher
И напишет любую запрошенную фигню на Arduino, если уточнять... Т.е. по вопросам Arduino форум можно закрывать.

Я как-то попросил его написать скетч на Arduino IDE для кнопки на NRF52 для интеграции в HomeKit. Он написал простой, понятный код. Только использовал в нём несуществующую в природе библиотеку

 

[pvvx]

Я как-то попросил его написать скетч на Arduino IDE для кнопки на NRF52 для интеграции в HomeKit. Он написал простой, понятный код. Только использовал в нём несуществующую в природе библиотеку

Выходит что вы не дали ему правильное задание. Не уточнили что нужно использовать.
И теми более какое дело китайскому ИИ до европейских никчемных чипов c проприетарным ПО?