search

slacky1965 / watermeter_zed

Watermeter ZigBee TLSR8258
Apache License 2.0
60 stars 14 forks source link

"оригинальный аглоритм reporting'а был заменен на кастомный" #21

Closed pvvx closed 7 months ago

pvvx commented 7 months ago

Этот алгоритм назначает таймеры. Число таймеров ограничено. При вызове самой процедуры report, если в это время стек занят, SDK сам назначает таймер, чтобы использовать четверть секундную паузу между транзакциями (боится перегрузить роутеры и координатор) и запоминает данные в выделенной для этого памяти. Буферов в памяти хватает не десяток report, а вот таймеры ограничены. В итоге, по описанному "кастомному" алгоритму может быть назначено несколько таймеров на один report и плодится ещё... и у вас включены все сервисы, которые тоже используют таймеры...

И просыпание по таймеру - это лишний расход батареи. Постоянно отрабатывает timerPollRateEvt и можно привязаться к его пробуждению всей системы... Отключается во время потери координатора, во время поиска. Но тогда отрабатывают другие таймеры, но в этот период не вызываются poll процедуры.

slacky1965 commented 7 months ago

Таймеров по умолчанию 24. В Electricity Meter репортингов больше. Там это значение увеличено до 48 и все прекрасно работает.

pvvx commented 7 months ago

Там это значение увеличено до 48 и все прекрасно работает.

c лишним расходом батареи.

slacky1965 commented 7 months ago

Там это значение увеличено до 48 и все прекрасно работает.

c лишним расходом батареи.

А с оригинальным аглоритмом репортингов чип вообще не засыпает более, чем на 1 секунду ...

pvvx commented 7 months ago

По этому я использую другой алгоритм. С учетом того, что стек сам буферизирует выполнение report. Можно в цикле наплодить несколько report, а он потом их передает с необходимыми (если необходимы) паузами в четверть секунды. А у вас просто используется дублирование этой фичи.

В варианте одновременной работы BLE и Zigbee время на Zigbee стек отдается через промежутки передачи BLE рекламы. Выходит, что таймеры Zigbee накапливаются и исполняются пачкой дискретно этому шагу. В итоге общее потребление устройства выходит значительно меньше. Исключаются лишние пробуждения чипа по таймерам Zigbee. Создает это какие-то проблемы у других принимающих Zigbee – не знаю. Но это работает во всех конфигурациях что удалось проверить.

И выходит, что двойное устройство потребляет меньше, чем работающее только в Zigbee :)

slacky1965 commented 7 months ago

По этому я использую другой алгоритм. С учетом того, что стек сам буферизирует выполнение report. Можно в цикле наплодить несколько report, а он потом их передает с необходимыми (если необходимы) паузами в четверть секунды. А у вас просто используется дублирование этой фичи.

В варианте одновременной работы BLE и Zigbee время на Zigbee стек отдается через промежутки передачи BLE рекламы. Выходит, что таймеры Zigbee накапливаются и исполняются пачкой дискретно этому шагу. В итоге общее потребление устройства выходит значительно меньше. Исключаются лишние пробуждения чипа по таймерам Zigbee. Создает это какие-то проблемы у других принимающих Zigbee – не знаю. Но это работает во всех конфигурациях что удалось проверить.

Хорошо, можно где-то поглядеть реализацию того, о чем Вы мне толкуете? Но только для zigbee :))

pvvx commented 7 months ago

https://github.com/pvvx/ZigbeeTLc/blob/master/src/reporting.c Но время для report-ов считается в другой процедуре, когда чип пробуждает кто другой. Так же, чтобы исключить лишний вызов энергоресурсных процедур.

Но только для zigbee :))

Использую это во всех конфигурациях.

Я не претендую на использование других алгоритмов. Просто ищу более глубокие методы оптимизации по потреблению. Есть ещё вопрос – более 3-х endpoint текущий SDK и стороннее ПО не тянет? Мне не хватает endpoint для ретранслятора BLE в Zigbee...

slacky1965 commented 7 months ago

E

Спасибо, проверю. У меня в watermeter'е, с добавлением 2-х датчиков протечки, 5 endpoint'ов. Без проблем.

pvvx commented 7 months ago

Не выходит - ZHA не жрет. Всего 3 шт температуры и влажности... Так же не жрет 2..3 батарейки. Только одну. Но гордо заявляют полную поддержку Zigbee 3.0 :)

C z2m я вообще не связываюсь, т.к. там нет поддержки стандартных устройств Zigbee 3.0. Они объявили об поддержке стандартных устройств Zigbee 3.0 недавно, но дела пока плохи. В Z2M пользователи вынуждены сами писать программу обслуживания любого нового устройства. Это походит на то, что Z2M заставляет пользователей создавать с нуля полную программу работы с координатором Zigbee :)

Хотя это совершенно просто и можно описать даже в js для эксплорера, а Z2M только усложняет задачу для простых пользователей - в Z2M приколисты :) Пример наброска для моих тестов...

Да, и чтобы пользователи вашего Zigbee устройства не жали кнопку для любого действия, необходим период timerPollRateEvt до 4.7 секунд (по стандарту). Среднее общее потребление при таком интервале не выходит больше 10..14 мкА (зависит от уровня RF TX в дБм и естественно с дополнительными оптимизациями ПО).