• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

ESP32 энергосбережение

pvvx

Активный участник сообщества
Нет, просто к такому умному дому нужен слуга, такой же умный, как Вы.
Т е Вы сделали уникальную систему .
И, наверное не ошибусь, для которой не существует документации.
----------------
Полагаю, что умным дом будет тогда, когда к нему не нужно будет приложения в виде еще более умного хозяина.
--------------------
Что касается старых домов, то полагаю Вы ошибаетесь.
Их не сносят, а бросают , либо продолжают в них жить.
Таких по вашему "уникальных" систем наверно к миллиону. Ищите статистику использования в Home-Assistant.
И тут документация. Никто не виноват, что вы столько времени "спали" по данной тематике.

Есть и статистика использования интеграций. Bluetooth ныне используется чаще Zigbee, а где-то далеко ESPHome.
 

pvvx

Активный участник сообщества
И так же напомню – ESP32-C3 имеет хороший приемник BLE и поддерживает уровень ПО где-то до версии Bluetooth 5.2 в ESP-IDF. Прием LE Long Range на уровне до -105 dBm. Но всё это при условии отключенного WiFi. При этом потребление не сверх большое по сравнению с другими вариантами, тип ESP32 и платки не имеют лишних микросхем типа USB-UART, пожирающих питание.
Тестировал тут
 

nikolz

Well-known member
Таких по вашему "уникальных" систем наверно к миллиону. Ищите статистику использования в Home-Assistant.
И тут документация. Никто не виноват, что вы столько времени "спали" по данной тематике.

Есть и статистика использования интеграций. Bluetooth ныне используется чаще Zigbee, а где-то далеко ESPHome.
Мне эта тема не интересна. В инете много разного мусора. Умные дома - это такое название.
Есть например мороженое "48 копеек" Но Вы же не верите, что оно столько стоит. Вот и с умными домами так же.
------------------------
Прочитал Ваши замечания про ZigBee.
Мне этот протокол изначально не нравился по сравнению с BLE.
Наконец-то и Вы об этом сказали.
------------------
 

pvvx

Активный участник сообщества
Прочитал Ваши замечания про ZigBee.
Мне этот протокол изначально не нравился по сравнению с BLE.
Альтернативы всё равно нет.
BLE - это датчики, а Zigbee - исполнительные устройства.
И так будет пока основные системы не станут поддерживать спецификацию Bluetooth 5.4.
В принципе, из-за этого и других тенденций корпорации и решили перейти на Matter. Создать несовместимость и втюхать спец. устройства. Маркетинг и нечего более...
 

pvvx

Активный участник сообщества
Для работы с Zigbee и Matter необходимо иметь специальное устройство типа шлюза. Его необходимо купить. Использовать уже имеющиеся в наличии у пользователя устройства с Matter не выйдет. Это не BLE, поддержка которого есть в любом смартфоне или ноуте и идет опцией для материнских плат.

В итоге никто не напишет общедоступного бесплатного ПО и цена на Matter всегда будет завышена. Безусловно придется затратить часть из стоимости на рекламу по втюхиванию данного стандарта, но это все равно оплатит пользователь.
 

pvvx

Активный участник сообщества
Плюсов для пользователя и в функциональности устройств c Matter пока никаких нет. Бардак в его стандарте уже есть. Требования по производительности и объемам Flash, RAM и т.д. для поддержки Matter к чипам во много раз превышают BLE и Zigbee, WiFi, при этом не увеличивая функциональности, качества и надежности итоговой системы.
Но реклама уже проплачена и множество фриков вещают: Matter - это круто :) Вот только описать в чем оно лучше других стандартов не могут. Т.к. ели туда лезть, то выйдет что всё плохо.
 

pvvx

Активный участник сообщества
По этому сразу пошли ответвления у тех кто входит в ассоциацию Matter и работает на рынке массовых продаж. Типа шлюз Matter, а конечные устройства на Zigbee :p
В тоже самое время рынок, где требуется надежность и множество одновременно управляемых устройств, во всю переходит на устройства BLE с новым стандартом – все ценники с “электронной бумагой”.
 

pvvx

Активный участник сообщества
Вот и выходит, что такие конторы как Apple, создавшие платную ассоциацию Matter пытаются нажиться на обычных пользователях бытовых устройств, по начальной аналогии с Zigbee. Там и требования сертификации и повременной оплаты за использование… Считают пользователей баранами :)
 

pvvx

Активный участник сообщества
Есть например мороженое "48 копеек" Но Вы же не верите, что оно столько стоит. Вот и с умными домами так же.
Это к чему?
К цене?
Ну на сегодня выходит что дешевле и меньшим потреблением чем на BLE 5.4 систему с множеством устройств не сделать.
Это даже внесли в викопедию:
1722670964140.png
 

nikolz

Well-known member

pvvx

Активный участник сообщества
Вот гадаю, как уменьшить потребление при опросе двух датчиков ME18B20.
1722798455207.png
В даташите к ME18B20 нет варианта работы по одному проводу и опрос в таком режиме включения выдает всегда фиксированное значение в регистрах температуры.
Второй бедой у данных датчиков (ME18B20/DS18B20) является то, что при адресном обращении они требуют слишком длинного кода команд. Значительно превышающего весь цикл измерения.
Плюс у ME18B20 - он успешно работает при падении напряжения до 1.8В, не изменяя показания.

Получается, что нет смысла городить адресное обращение к паре датчиков, а проще повесить на разные выводы SoC. И одновременно урезать блок данных при считывании, т.к. новый сброс-presence занимает меньше времени, чем чтение ненужных байт полного фрейма с CRC. Но теряется CRC. И ладно, если применить непрерывный скользящий опрос шины 1-wire на каждом бите, то любые бяки и так будут выловлены. Так и напишем код драйвера...

Т.к. синхронную обработку нескольких датчиков на разных пинах писать сложнее, то для тестового расчета пока подключил одни датчик.
При использовании модуля типа TB-03F (TLSR8250) дополнительных деталей не требуется… Это хорошо.

Измерил что вышло.

Сигнал 1-wire при инициализации датчика MY18B20 - запись регистра конфигурации: ~ 2.5 ms, однократный, происходит при старте питания или сбое на шине 1-wire:
1722798683532.png

Сигнал на шине 1-wire при запросе, ожидании измерения и чтении значений измерения с датчика MY18B20 (~4 мс):
1722798662708.png
Это основная используемая транзакция. Без адресного режима и без CRC.

Далее оцениваем затраты питания. Для это возьмем такой цикл – опрос датчика каждые 10 сек и четыре BLE передачи.
Смотрит на прибавку к каждому 4-ому активному циклу работы SoC:
1722798714010.png
Пробуждение SoC из сна (~1.5 мс), передача BLE advertise по 3-м каналам со сканированием запросов подключения или расширенного ответа (~2.2 мс), запрос и чтение измерения с датчика MY18B20 (~4 мс), хвост питания датчика MY18B20 (~31 мс):

Т.е. раз в 10 секунд имеем добавку в виде (3мА 4.5 мс):
1722798731530.png
А общее среднее потребление - 10.99 мкА.
Все замеры сделаны при питании 3.3В.
 

pvvx

Активный участник сообщества
Расчет добавки:

TLSR825x - опрос MY18B20 без адресного режима и без CRC
Цикл: 10000 мс (10 сек)
Ток при измерении: 3 мА
Время на измерение: 4,5 мс
Потребление при сне: 0 мА (тут не учитываем для сравнения, если добавить доп. чип, т.к. уменьшить имеющееся не выйдет)
Итого, среднее: 0,00135 мА (1,35 мкА)

А если поставить внешний “нановатный” чип для опроса ME18B20?

Под рукой есть PIC12F1571/2. Пусть опрашивает 1-wire и передает в TLSR8250 по Single-Wire до 2-х мегабит. При этом участие TLSR8250 не требуется, т.к. данные будут записаны или считаны прямо из памяти чипа, без участия CPU.
PIC12F1571/2 при 500 кГц и 3.3В кушает:
Активный режим: 200 мкА (PIC12LF1571/2: 135 мкА)
Sleep mode: 0.25 мкА (PIC12LF1571/2: 0.04 мкА)

Но 500 кГц будет маловато, чтобы четко отсчитывать даже 1-Wire. Но типа пущай…

Для 1-Wire в данном случае ещё потребуется припаять резистор к +3.3В. Это будет кушать к 1 мА при работе с шиной. Примем, что общее потребление CPU+резистор подтяжки в активном режиме опроса 1-wire будет 1 мА. Остальное учитывать пока не буду.

Считаем:

PIC12F1571/2 - опрос MY18B20 в адресном режиме и с CRC
Цикл: 10000 мс (10 сек)
Потребление на измерение: 1 мА (ток резистора шины + ток чипа)
Время на измерение: 17 мс
Потребление при сне: 0,0002 мA (200 нА)
Итого, среднее: 0,00189966 мА (1,9 мкА)

PIC12F1571/2 - опрос MY18B20 без адресного режима и без CRC
Цикл: 10000 мс (10 сек)
Потребление на измерение: 1 мА (ток резистора шины + ток чипа)
Время на измерение: 4,5 мс
Потребление при сне: 0,0002 мА (200 нА)
Итого, среднее: 0,00064991 мА (0,65 мкА)

Итог: никакой выгоды от использования внешнего чипа не получаем уже при 2-х синхронных выводах 1-wire у TLSR825x.
 

pvvx

Активный участник сообщества
В расчетах принимали участие:

Все замеры токов при напряжении питания 3.3В.

Ток по линии питания MY18B20, возникающий при запросе, ожидании измерения и чтении значений измерения (первые 4 мс где шум, остальное - его личный хвост):
1722799296436.png

Итоговое потребление по линии 3.3В датчика MY18B20 при опросе раз в 10 сек:
1722799305730.png

Потребление по линии 3.3В датчика MY18B20 между замерами:
1722799312135.png


TB-03F: Возникающий хвост у MY18B20 по линии питания у MY18B20 после чтения измерения :
1722799319582.png

Общее потребление всей системы (модуль TB-03F + датчик MY18B20) во время сна:
1722799326832.png
 

pvvx

Активный участник сообщества
А итог в HA пока такой:
1722800658478.png
2 входа событий - герконов/кнопок, от первого счетчик.
Выход (Power) управляемого выхода
Температура, пока одна
Напряжение батареи.

1722800693164.png
Далее это вырастит в контролирующую систему для внешнего любого инверторного блока кондиционера, включающую обогрев компрессора, поддона с внутренним или внешним алгоритмом управления. Измерение температуры и влажности воздуха тоже будет на другом датчике. Если выйдет, то будет и система определения обмерзания...
Основное назначение - при низких температурах не включать компрессор пока не прогрет и включать прогрев поддона, когда кондей переходит в режим разморозки. Управление кондеем осуществляется другим модулем - он будет ждать сигнала прогрева компрессора. Ну и прочие алгоритмы для уменьшения потребления кондеем, а не как у любителей - вечный прогрев улицы пока холодно...
Питание при имеющемся сетевом напряжении (только тогда коммутируются реле обогревателей). Иначе, без подачи внешнего напряжения, переходит на батарейку типа CR2450 с расчётом работы на 1 год...
 

pvvx

Активный участник сообщества
Как погодную станцию, конструкцию ограждения внешнего блока кондея использовать всё равно не выйдет. Он дует своим и хорошо. Так что рядом температура воздуха зависит от его даже слабой работы :p
1722802812053.png
 

pvvx

Активный участник сообщества
Это всё только для примера, сколько необходимо учесть, чтобы слепить любую систему с автономным режимом и что всегда есть варианты дешево и/или просто изменить схему и/или компоненты для понижения потребления.

На сегодня, ранее описанный датчик, уже обзавелся двумя ME18B20, плюс датчиком температуры и влажности SHT4x.
1723061821112.png
Для уменьшения затрат питания у управляющего SoC оба ME18B20 включены на раздельные GPIO чипа. Т.е. происводится работа с 2-мя шинами 1-wire в параллельном режиме. Плюс удалось ещё уменьшить циклы работы с шиной 1-wire с полным соблюдением параметров указанных к датчикам ME18B20 в даташите.

Чтение измерений сразу по двум 1-wire:
1723061851483.png

Потребление уже 2-мя датчиками ME18B20 по линии питания увеличилось вдвое:

Sensors MY18B20 (x2): Power terminal current (Cycle 4 x 2.5 sec),
Measure:
1723061995502.png

Read & sleep:
1723062028129.png

Попытка прилепить модуль SHT4x с али без паяльника не удалась. Там впаян стабилизатор XC6206P332MR 3.3В c маркировкой “662K”. И если внимательно читать даташит, а не смотреть в нем рекламные надписи (как это любит @nikolz), то эта фигня потребляет не 1 мкА, а до 20 мкА и более, когда входное напряжение падает ниже порога стабилизации. Проверка на Power-Profiler так и показала. Не годится и в качестве малопотребляющего стабилизатора и для Li АКБ. Пришлось выпаять и поставить перемычку…

Sensor SHT4x: Power terminal current (Cycle 4 x 2.5 sec):
Measure:
1723062138449.png
Sleep:
1723062165899.png
И импульс тока на резисторах 10 кОм у I2C в модуле SHT4x (желательно выпаять, и чип преобразования шины 3.3-5В тоже):
1723062181159.png
 

pvvx

Активный участник сообщества
Итоговое потребление всего устройства.
Для анализа выбран режим передаче BLE раз в 5 секунд и опросе датчиков каждые 10 сек.
Полученный средний ток от источника 3.3В составил 8.3 мкА (sleep: 2.5 мкА).

Имеем два активных цикла:
Stage1: BLE передача, измерение питания на ADC, запуск датчиков на измерение, засыпание SoC с активными прерываниями по GPIO, таймера сохранением всей RAM (для TLSR825x это 1.8 мкА).
1723062627473.png
Window: 0.76 мА, 40 ms

Stage2: BLE передача, считывание замеров с датчиков, обновление передаваемых данных, засыпание SoC с активными прерываниями по GPIO и таймера.
1723062632981.png
Window: 0.71 мА, 40 ms

Если в TelinkMiFlasher настроим более 2-х BLE advertise между измерениями, тогда промежуточные циклы активности SoC будут иметь только передачу:

Window: 0.494 мА, 40 ms

Из этого можно рассчитать все варианты возможных комбинаций: длительность паузы между передачами от 100 мс до 10 сек, кол-во таких пауз до измерений от 2-х до 255 (такие параметры задаются в программе настройки - TelinkMiFlasher.html).

По мере тыркания ME18B20, было установлено, что их калибровали!
Расхождения у купленной пачки не более 1 бита младшего разряда. Но только при температуре близкой к +24С - на других не проверял.
1723063053331.png
Светлый график - это SHT4x, а два перекрывающихся на 1 бит - два ME18B20 (разрешение у SHT4x во много раз больше всяких DS/ME18B20).
Все были связаны и кинуты в картонную коробку для исключения конвекции...
 

pvvx

Активный участник сообщества
Не загрузился график:
Если в TelinkMiFlasher настроим более 2-х BLE advertise между измерениями, тогда промежуточные циклы активности SoC будут иметь только передачу:
Intermediate stage:
1723064711746.png
Window: 0.494 мА, 40 ms
 
Сверху Снизу