-
Система автоматизации с открытым исходным кодом на базе 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)