-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
TLSR8251F512ET24 + E-Inc display + термометр = MHO-C401 Bluetooth термометр
- Автор темы pvvx
- Дата начала
120 сек
pvvx
Активный участник сообщества
Значит иногда не отрабатывает прерывание от пина контроллера E-ink. А чип пробуждается как вы выставили - с периодом 120 сек и завершает работу с E-Ink.
По этому и не было желания делать прошивку на старые тормознутые E-ink и ещё требующие регенерации всех сегментов... На старых MHO-C401 цикл обслуживания CPU дисплея с регенерацией длится более 1.6 секунды... Та ещё помойка... которая со временем ещё и станет серым экраном...
Текущие типы E-Ink (MHO-C401N) не требуют регенерации и их контроллеры отрабатывают обновление экрана в несколько десятков раз быстрее.
По этому и не было желания делать прошивку на старые тормознутые E-ink и ещё требующие регенерации всех сегментов... На старых MHO-C401 цикл обслуживания CPU дисплея с регенерацией длится более 1.6 секунды... Та ещё помойка... которая со временем ещё и станет серым экраном...
Текущие типы E-Ink (MHO-C401N) не требуют регенерации и их контроллеры отрабатывают обновление экрана в несколько десятков раз быстрее.
pvvx
Активный участник сообщества
Во всех прошивках используется такой алгоритм по анализу питания:
С шагом измерения проверяется, что напряжение не ниже 2.0В. Если ниже – переключение в долгий сон на несколько минут с отключением всего, что можно. Чип при этом потребляет менее 0.6 мкА, плюс спящий датчик и контроллер дисплея. Пробудившись опять проверяется на 2.2В и если есть – обычная работа…
Такой алго обеспечивает возможность работы от солнечной панели и супер кондера. При падении напряжения ниже рекомендованного производителем чипа (2.2В) потребление уменьшается до максимально возможного чтобы обеспечить зарядку от слабого источника.
У батареек CRxxx при низких температурах напряжение понижается. Даже у новой при -35..-40С уже будет 2.2В. Когда отогреется напряжение придет в норму. Но если не уменьшить потребление, то батарейка быстро сядет навсегда.
Вот пример конкретно “закинутого” на чердак термометра с CR2032 (где-то там и валяется уже второй год). В начале этого года батарейка у него совсем ослабла и начались отключения:
Когда отогревается, начинает работать
Надо лезть на чердак, искать его там и менять батарейку…
Аналогично и ваш MHO-C401 может отключаться – в начале просадок это происходит чаше и паузы малы... Но на таком тормозном E-Ink вывести сообщение о конце батареи невозможно - не хватит энергии.
С шагом измерения проверяется, что напряжение не ниже 2.0В. Если ниже – переключение в долгий сон на несколько минут с отключением всего, что можно. Чип при этом потребляет менее 0.6 мкА, плюс спящий датчик и контроллер дисплея. Пробудившись опять проверяется на 2.2В и если есть – обычная работа…
Такой алго обеспечивает возможность работы от солнечной панели и супер кондера. При падении напряжения ниже рекомендованного производителем чипа (2.2В) потребление уменьшается до максимально возможного чтобы обеспечить зарядку от слабого источника.
У батареек CRxxx при низких температурах напряжение понижается. Даже у новой при -35..-40С уже будет 2.2В. Когда отогреется напряжение придет в норму. Но если не уменьшить потребление, то батарейка быстро сядет навсегда.
Вот пример конкретно “закинутого” на чердак термометра с CR2032 (где-то там и валяется уже второй год). В начале этого года батарейка у него совсем ослабла и начались отключения:
Когда отогревается, начинает работать
Надо лезть на чердак, искать его там и менять батарейку…Аналогично и ваш MHO-C401 может отключаться – в начале просадок это происходит чаше и паузы малы... Но на таком тормозном E-Ink вывести сообщение о конце батареи невозможно - не хватит энергии.
pvvx
Активный участник сообщества
В Zigbee при потере связи у любого устройства с координатором (или роутером) вызывается процедура поиска сети по всем каналам и если нашлась – ребиндинг, а если нет - новый поиск. А поиск по всем каналам это дичайшее потребление – более 20 мА в течении секунды. CR2032 такое выдерживает только если новая. В прошивке, в отличии от SDK, это дело исправлено - пауза между поисками сети установлена на период в 9 секунд с начала поиска, потом, через 50 секунд переключается на 60 секунд пока не найдет. И всё равно в таком режиме потребление более чем в 50..100 раз больше, чем при нормальной работе (или в BLE).
Потери связи в Zigbee очень часты – единственный канал может быть занят другим устройством (т.к. Zigbee = тормоз) или по WiFi кто-то смотрит видео... В такие моменты все батарейные устройства Zigbee желающие связи хорошо выжирают свои батарейки. А процедура Zigbee OTA на некоторых устройствах – это вообще сразу к четверти емкости батареи…
Zigbee это ужас для батарейных устройств. Т.е. не годится для IoT. Еле подходит только желающим наблюдать измерения раз в час - но это не для автоматики, а только для прикола.
Потери связи в Zigbee очень часты – единственный канал может быть занят другим устройством (т.к. Zigbee = тормоз) или по WiFi кто-то смотрит видео... В такие моменты все батарейные устройства Zigbee желающие связи хорошо выжирают свои батарейки. А процедура Zigbee OTA на некоторых устройствах – это вообще сразу к четверти емкости батареи…
Zigbee это ужас для батарейных устройств. Т.е. не годится для IoT. Еле подходит только желающим наблюдать измерения раз в час - но это не для автоматики, а только для прикола.
pvvx
Активный участник сообщества
К примеру ZHA настраивает время отчета от устройств на 55 минут. Т.е. если у вас отключили электричество, то через 55 минут часть устройств роутеры выкинут из сети навсегда. Будете бегать и жать кнопки для новой случки.
Установка тупого автономного роутера спасет это дело. Когда вырубится координатор все батарейные, после потери связи и нового поиска сети накинутся на этот рoутер.
А координатор отключат все, к примеру перезагружая систему...
Установка тупого автономного роутера спасет это дело. Когда вырубится координатор все батарейные, после потери связи и нового поиска сети накинутся на этот рoутер.
А координатор отключат все, к примеру перезагружая систему...
pvvx
Активный участник сообщества
Т.к. первичная проверка была на нормальной батарейке и сеть у меня всегда с автономными роутерами, у меня таких проявлений не было.
Но всё может быть, т.к. код прошивки менялся для обобщения на все типы поддерживаемых термометров и что-то съехало...
Устанавливать период измерения более 30 секунд не рассчитывается. Т.к. смысла в таком градуснике нет - он будет показывать что-то из прошлого и никакой реакции...
pvvx
Активный участник сообщества
И опция установки периода введена для борьбы с неадекватным поведением ZHA и другого множественного ПО работающего с координаторами.
В стандарте Zigbee 3.0 четко написано - у устройства есть значение минимального и максимального периода LONG_POLL_INTERVAL в кластере POLL_CTRL. И перед установкой необходимо свериться с этими значениями. Но писатели стороннего ПО любят подгадить всем - устанавливают этот период на 6 секунд (к примеру в ZHA) не глядя на указания. Т.е. каждые 6 секунд устройство должно выйти на связь. Писателям ваших батареек не жалко или они хотят чтобы вы их меняли чаще.
Tuya и другие бренды не поддерживают стандарт Zigbee 3.0. У них свой протокол отчетности.
Вообще для адекватной работы в Zigbee 3.0 любое устройство должно выходить на связь каждые 8 секунд. Если период больше - координатор или роутер не будет дожидаться передачи транзкации и выкинет данные для устройства из своего буфера. Но в Z2M и ZHA (и у других) стоит пару повторов для сообщений передавших таймаут...
Установка "периода измерения" в прошивке и является ограничением для минимального LONG_POLL_INTERVAL. При установке координатором значения LONG_POLL_INTERVAL менее этого всё равно будет применен интервал "периода измерения".
В итоге 30 секунд - это предельный максимум, а что там нарисовали или хотят пользователи - это их бред. По умолчанию это значение = 10 сек.
В стандарте Zigbee 3.0 четко написано - у устройства есть значение минимального и максимального периода LONG_POLL_INTERVAL в кластере POLL_CTRL. И перед установкой необходимо свериться с этими значениями. Но писатели стороннего ПО любят подгадить всем - устанавливают этот период на 6 секунд (к примеру в ZHA) не глядя на указания. Т.е. каждые 6 секунд устройство должно выйти на связь. Писателям ваших батареек не жалко или они хотят чтобы вы их меняли чаще.
Tuya и другие бренды не поддерживают стандарт Zigbee 3.0. У них свой протокол отчетности.
Вообще для адекватной работы в Zigbee 3.0 любое устройство должно выходить на связь каждые 8 секунд. Если период больше - координатор или роутер не будет дожидаться передачи транзкации и выкинет данные для устройства из своего буфера. Но в Z2M и ZHA (и у других) стоит пару повторов для сообщений передавших таймаут...
Установка "периода измерения" в прошивке и является ограничением для минимального LONG_POLL_INTERVAL. При установке координатором значения LONG_POLL_INTERVAL менее этого всё равно будет применен интервал "периода измерения".
В итоге 30 секунд - это предельный максимум, а что там нарисовали или хотят пользователи - это их бред. По умолчанию это значение = 10 сек.
pvvx
Активный участник сообщества
Выход на связь по LONG_POLL_INTERVAL - это пробуждение чипа и включение RF на несколько мс, иногда с передачей всякого - т.е. ещё плюс несколько мс и пару просыпаний для передачи транзакций отчетности с интервалами в qt (qt в Zigbee = 0.25 сек). Опрос датчиков занимает значительно менее 1 мс и сильно не влияет общее на потребление.
В MHO-С401 вторым потребителем является экран. А про опрос датчика можно можно вообще забыть на фоне энергии требуемой для обновления и регенерации данного E-Ink.
В MHO-С401 вторым потребителем является экран. А про опрос датчика можно можно вообще забыть на фоне энергии требуемой для обновления и регенерации данного E-Ink.
pvvx
Активный участник сообщества
Период передачи данных в Zigbee 3.0 устанавливается в установках repot, а не путем изменения интервала чтения данных с датчиков и LONG_POLL_INTERVAL!
Изменение LONG_POLL_INTERVAL в прошивке связано только с неадекватным копированием в стороннем ПО дури от кого-то при создании их кода.
Если нужны большие интервалы, чем задано в Zigbee 3.0 - покупайте Tuya датчики... Там как раз некоторые отдают данные раз в пол часа и их Cloud сервер не принимает чаше
Изменение LONG_POLL_INTERVAL в прошивке связано только с неадекватным копированием в стороннем ПО дури от кого-то при создании их кода.
Если нужны большие интервалы, чем задано в Zigbee 3.0 - покупайте Tuya датчики... Там как раз некоторые отдают данные раз в пол часа и их Cloud сервер не принимает чаше
да нет, пару месяцев как менял, GP, обычно держатся 13-14 месяцев (на BT)
Прошил новой версией MHO-C401, проработало буквально несколько секунд-минуту и и завис экран. Проблема такая же как описаная тут - https://github.com/pvvx/ZigbeeTLc/issues/95
Устройство произведено 2024.01 Пробовал разные прошивки, но устройство не смог оживить...В каком направлении двигаться? Есть вероятность что начали использовать совершенно новый контроллер дисплея?
Устройство произведено 2024.01 Пробовал разные прошивки, но устройство не смог оживить...В каком направлении двигаться? Есть вероятность что начали использовать совершенно новый контроллер дисплея?
pvvx
Активный участник сообщества
2024.01 - это явно MHO-C401N, а не MHO-C401. И у них разные прошивки. И по указанной ссылке все давно уже разобрались...
И нет такого символа на экране MHO-C401:
Это не Xiaomi, а скорее всего "Azarton" и прошивка для MHO-C401N.
Ставил именно MHO-C401N
"Azarton" - нигде не написано
pvvx
Активный участник сообщества
Обычно на коробке...
У данного программатора нет обратной связи. Используется только передача данных и вы должны выполнить все условия, а не просто тыкать одним TX USB-COM адаптера в SWS пин чипа термометра...