pvvx
commented
1 year ago 10 секунд иногда уже много, для возможности удерживать температуру с гистерезисом в 0.1С, а также для любых PID регуляторов. Обновление экрана не занимает времени и энергии на столько, что стоит заботиться. Это сотые процента от общего потребления. Проблемы только у версии LYWSD03MMC с контролером экрана на UART. Но они более не продаются. А вот полное отключение экрана (контроллера LCD) дает падение потребления в режиме сна чипа более чем в два раза. Типа 6..9 мкА (зависит от чипа) с включенным контроллером LCD и до 2-х мкА при выключенном.
Потребление сильнее зависит от типа датчика. Cтарые - SHTC3 (SHTV3) требуют задать команду пробуждения и измерения и ожидать от 6 мс до выполнения, затем переключать в режим сна. А в данной версии код не оптимизирован по потреблению и всё время ожидания молотит процессором на повышенной частоте, вместо сна, пожирая ток к 5 мА. См. диаграммы...
Так-же необходимо синхронизовать циклы опроса датчика и обновления экрана с таймингом процессов Zigbee. Лишнее "просыпание" SoC кушает в десятки (может и сотни) раз больше, чем отработка обновления LCD с опросом датчика SHT4x. А уж соотношение затрачиваемой энергии на передачу и прием в Zigbee вообще не сравнить с датчиком и обновлением LCD...
Правильной оптимизацией является только один вариант – когда SoC пробуждается исключительно для цикла приема-передачи и во время них делает все остальные дела, т.к. RF работает со своими FIFO-DMA и IRQ.
Сравнение показаний BLE и Zigbee устройств при одинаковом потреблении и дальности связи:
Т.е. нужно дорабатывать версию Zigbee до уровня передачи не менее 1 замера в 10 сек.
Nab0y
I suggest slowing down the internal timer by a factor of six. Personally, it won't make much of a difference for me whether the screen refreshes every 10 seconds or every minute. I don't experience sharp temperature fluctuations, and as a short practice has shown, the sensors don't react that quickly either. The benefits of this approach are much greater: fewer sensor queries, fewer value calculations, screen updates, and, as a result, reduced energy consumption.
I've assembled a test version for myself, and while I only have limited statistics for half a day, the battery consumption graph already looks more optimistic than it did before the changes.
Предлагаю замедлить внутренний таймер в шесть раз. Лично для меня не большая разница будет экран обновляться раз в 10 секунд или раз в минуту, таких резких перепадов температуры у меня нет, да и как показала недолгая практика сами датчики так быстро не реагируют. А пользы от такого решения намного больше, меньше опросов датчиков, меньше расчетов значений, обновлений экрана, как следствие меньше потребление энергии. Я собрал себе тестовую версию, статистики пока мало всего пол суток, но график потребления батареи уже выглядит более оптимистично, чем было до изменений.
My report settings are as follows