Использование ESP8266 для автономных устройств

[pvvx]

Хотелось бы узнать, какие есть популярные варианты и предложения по использования ESP8266 для автономных устройств с батарейным питанием c применением разных режимов sleep.

Более конкретно:

1) Какие датчики требуется опрашивать и частота их опроса.

2) Каким образом требуется осуществлять передачу данных. Тип протокола и частота соединений с сетью.

3) Каковы объемы накапливаемой и сохраняемой информации локально на самом модуле.

Набор данных с датчика(ов) предполагается с меньшим периодом чем запуск полного SDK для коммутации по WiFi. Это дает возможности по усреднению показаний за период между передачами и т.д. при значительно меньшем общем потреблении модуля. Модуль работает в трех режимах:

1) Полный deep_sleep (мкА)

2) Просыпания с опросами датчика с активным использованием других sleep режимов для задержек опроса (среднее потребление к 5..7 мА с использование быстрой стартовой загрузка до десятков мс)

3) Просыпание с включением WiFi для внешней коммуникации данных (средняя 15..70 мА c пиками до 100 мА но с ограничением на несколько секунд – в самом пределе до десятка).

Накопление информации в самом модуле предполагает циклический буфер в Flash на достаточно большой срок c возможностью использования устройства как “черного ящика” и малой зависимости от не успешных сеансов коммуникаций для передачи данных на внешний накопитель.

Не успешность коммуникации возникает от ограничения потребляемой энергии модулем в режиме активности WiFi. Питание на модуль может поступать от солнечной батареи или другого слабого источника и, к примеру, накапливаться на ионисторе с ограничением длительности цикла передач при активировании WiFi.

Всё это уже проверено и есть куски реализаций с замерами потребления. Штатный китай-SDK для этого категорически не годится (!).

Цель опроса – стоит ли создавать специализированную на данные задачи (и каковы они) открытую версию SDK (с китайскими компонентами сугубо для работы с WiFi).

А заодно объединить данные и информацию по автономному питанию модулей и разных режимов sleep и других методов сокращения потребления...

 

[serrgee]

Мне интересен такой SDK. Несмотря на существующий ассортимент другого железа и интерфейсов, сразу заточенных под низкое потребление, у ESP есть свои преимущества: легкость развертывания, использование готовой инфраструкуты WiFi, дешевизна, простота DIY.

Кроме чистого SDK также надо и про аппаратные решения подумать, чтобы поддержать их в SDK. Первое на очереди это принудительно просыпание от контактного датчика (просто контакты геркона, кнопка включения, тампер, вибрационный датчик (меня потрогали!), резистивный (влажность и всё похожее)).

Конечно, нужно решение для контроля электропитания для источников разных типов (батареи, акки, солнечные панели).

Ещё пока не понимаю, нужны ли внешние часы RTC для контроля пробуждения, или режима LE самой ESP достаточно для работы с длинными отрезками времени.

 

[pvvx]

Ещё пока не понимаю, нужны ли внешние часы RTC для контроля пробуждения, или режима LE самой ESP достаточно для работы с длинными отрезками времени.

Внутренний RTC в ESP не точный и плавает от напряжения питания и температуры... Но это во многих случаях не критично, т.к. возможна синхронизация по SNTP или при передаче данных.
Для начала надо разобраться на нескольких типовых примеров.
Пусть таких:
1) Измерять погоду - температуру и влажность.
2) Контроль какой-то величины на примере разряда аккумулятора в авто с логированием и каким-то оповещением.
Остальные видимые варианты слишком специализированны по своим задачам и аппаратной части - унификации не поддаются.

 

[NutsXXXL]

@pvvx
к погоде еще стоит давление добавить - очень типовая задача.
мониторинг всяких счетчиков расхода похоже людей очень интересует.

из сетевых протоколов всяко narodmon не стоит забывать

 

[sdsm]

Очень интересует! Даже как учебные примеры грамотной работы с flash и питанием.

 

[rybeg]

Да, конечно стоит, потому что сбор данных датчиков погоды это большой процент, что народ делает на данном контроллере, а автономность еще больше подтолкнет перейти от мигания светодиодом дальше.

 

[Shyster]

Цель опроса – стоит ли создавать специализированную на данные задачи (и каковы они) открытую версию SDK (с китайскими компонентами сугубо для работы с WiFi).

Я думал Arduino IDE так и работает. Вобоще задумка суппер. Потребление esp уж очень напрягает.

т.к. возможна синхронизация по SNTP

Это тоже энергия

 

[Димитрий]

На самом деле вопрос с датчиками несколько сложнее чем кажется, некоторым датчикам нужна калибровка и "прогрев" перед замером - это приводит к тому, что период повышенного потребления повышается - часто связано с датчиками газов, например.

Что очень хочется реализовать - это изменение какого-то показателя n% - например у вас есть та же самая погода и влажность, если она в течении длительного периода не меняется, какой смысл её мерить. А хотелось бы как-то реализовать пороговые значения для любого датчика, после которого бы SoC просыпался и делал своё дело, но как это реализовать - я даже в теории не знаю

 

[Shyster]

хотелось бы как-то реализовать пороговые значения для любого датчика, после которого бы SoC просыпался и делал своё дело, но как это реализовать - я даже в теории не знаю

Для аналоговых без проблем через компоратор. А вот цифровые все равно надо опрашивать.

 

[pvvx]

На самом деле вопрос с датчиками несколько сложнее чем кажется, некоторым датчикам нужна калибровка и "прогрев" перед замером - это приводит к тому, что период повышенного потребления повышается - часто связано с датчиками газов, например.

ESP просыпается, включает датчик и засыпает. Время загрузки не китай-SDK, а приложения работающего с датчиком не более десятков мс по типу SDKnoWiFi (те исходники морально устарели и тема примерно про их развитие и у меня уже другие...). Это устаревшие тесты примера из данного SDK по переключениям режимов потребления:

Переключение в режим пониженного потребления, но активного CPU (память не сбрасывается) совсем малое - определяется в основном ожиданием выхода PLL на требуемую частоту. Если приложение не требует CPU на 80/160 MHz, то без проблем используется частота кварца или его двойная. Тогда задержки переключений пониженных режимов потребления с частичной активностью CPU (в основном RAM) вообще нет. В них применим и запуск (продолжение работы) CPU по внешнему сигналу с порта...
Китай SDK потребляет при загрузке по причине включенного WiFi блока и работающего не на своей частоте. Это большая часть потребления, просто так расходуемая на безалаберность. WiFi блок на время загрузки отключается специальным загрузчиком и дает ещё одну серьезную экономию, а время работы загрузчика типа Rapid Loader в десятки раз меньше чем любые другие загрузчики (китайские, используемые во всех обычных системах по типу Ардуин).

Есть и другие варианты ещё более быстрого восстановления после сброса от RTC (по типу в режиме deep-sleep).
Ещё существует вариант перезагрузки по reset со специальной записи в boot-секторе flash, вообще без вывода сообщений rom-bios. Но для этого требуется коммутация при перезагрузке CS на другую flash.

 

[pvvx]

Добрый день,
Вопрос, интересуют примеры задач применения ESP8266 , где нет источников электроэнергии.
Хотелось бы узнать, сталкивался ли кто с такими задачами в реалии.
Т е на сколько актуальна длительная работа от батарейки,
а не от аккумулятора или вообще от сети переменного тока.

Это и есть основной вопрос темы - "интересуют примеры задач применения ESP8266 , где нет источников электроэнергии". А выдумать и иметь "хотелок" можно бесконечное кол-во вариантов.
Пока ничего реального не формируется. Т.е. никакого списка задач, одни узкоспециализированные варианты, которые решаются в частном порядке и под спец.оборудование. По этой причине и закинул развитие SDKnoWiFi и его слияния с стандартным SDK для обслуживания коммуникаций по WiFi в составе "модуля с малым потреблением"...

Просыпание или холодный старт с загрузкой системы для опроса датчика решается за менее 50 мс со средним потреблением за этот период около 60 мА, даже с уже имеющимися решениями.

Это значит, что если к модулю прикрутить электролит на 2200 мкФ прямо в питание 3.3В, зарядить его до 3.3В, то после старта системы (с таймерами, менеджером памяти и прочими сервисами) и первым опросом датчиков получим на электролите порядка 2.1В, что является ещё рабочим напряжением (предел где-то к 70 мс - 1.8 В). Это позволяет определиться с данными от датчика – включать какой-то ещё источник и/или запускать WiFi, и/или уйти на новый deep-sleep. На китайском SDK, без модификаций этого не сделать.

 

[sav-13]

Добрый день,
Вопрос, интересуют примеры задач применения ESP8266 , где нет источников электроэнергии.
Хотелось бы узнать, сталкивался ли кто с такими задачами в реалии.
Т е на сколько актуальна длительная работа от батарейки,
а не от аккумулятора или вообще от сети переменного тока.

Пример задачи.
Имеется цех с оборудованием. В цехе худо ли бедно ли есть WiFi
Задача - мерить температуру и вибрацию на различных местах машины (например, как изменилась работа подшипника вала после ППР)
Тянуть каждый раз провод не удобно. А так прилепил приборчик на магнит в любом месте, датчики подключил куда нужно, можно тоже магнитом и вперед.

 

[sav-13]

Добрый день,
Задача из прошлой жизни, так как занимался вибродиагностикой.
Да, тянуть сеть для передачи данных не надо.
Но и тянуть сеть электропитания тоже не надо.
Cтанок же с электродвигателями, следовательно электропитание уже есть.
Поэтому нет надобности в абсолютно автономном источнике.
Более того, в этой задаче нет надобности и в экономии энергопотребления , т е в режиме сна.
Это не та задача.

Вы немного меня не поняли. Это не станок, а машина. Длиной метров 100. У нее десятки валов и несколько приводов.
И потребность в диагностике возникает в самых различных местах. Производится ППР, затем на контроль ставятся валы №3 и 5, например, как проблемное место. В следующий раз проблемное место совсем другое или комплект ставится на другую машину. А механик, отлаживающий все это, сидит у себя за компом и анализирует значения.

 

[nikolz]

Вы немного меня не поняли. Это не станок, а машина. Длиной метров 100. У нее десятки валов и несколько приводов.
И потребность в диагностике возникает в самых различных местах. Производится ППР, затем на контроль ставятся валы №3 и 5, например, как проблемное место. В следующий раз проблемное место совсем другое или комплект ставится на другую машину. А механик, отлаживающий все это, сидит у себя за компом и анализирует значения.

Понятно,
т е проблема с относительной удаленностью от розетки электропитания.
Тогда вопросы:
1) Максимальное время такого контроля
2) отношение времени паузы к времени измерения.
3) Отношение времени измерения к времени передачи информации по WIFI.
Суть вопросов в том, чтобы выяснить необходимость очень быстрого выхода из сна и необходимости экономии ресурса источника питания.
Пока из постановки задачи не следует надобности бороться за экономию электричества необходимо лишь автономное питание прибора.

 

[sav-13]

Понятно,
т е проблема с относительной удаленностью от розетки электропитания.
Тогда вопросы:
1) Максимальное время такого контроля
2) отношение времени паузы к времени измерения.
3) Отношение времени измерения к времени передачи информации по WIFI.
Суть вопросов в том, чтобы выяснить необходимость очень быстрого выхода из сна и необходимости экономии ресурса источника питания.
Пока из постановки задачи не следует надобности бороться за экономию электричества необходимо лишь автономное питание прибора.

1. Обычно от нескольких дней до месяца. (Когда просят поствить понаблюдать за оборудованием от ППР до ППР, чтобы знать, что делать дальше)
2 Тут сильно зависит от измеряемого параметра, динамики его измерения. Обычно один раз минут в 5 хватает, иногда реже. Если на машине возникают проблемы, то интереснее писать чаще, чтобы потом соотнести время возникновения проблемы с измеряемым параметром.

3. Сразу измерилось, сохранилось на сервер. Это позволят написать простую программку, отслеживающую пороги и сигнализирующую выходи за из значения.

Режим сна мы и не использовали совсем. Раз в два три дня можно сходить, поменять аккумулятор или прибор на зарядку поставить (тем более персонал на машине есть, всегда можно это по телефону решить). Но бывает, что прибор ставится в труднодоступное место, бывает, что для установки нужно остановить машину. Или куда нибудь залезть высоко. Здесь уже автономность была бы не лишней.

 

[nikolz]

1. Обычно от нескольких дней до месяца. (Когда просят поствить понаблюдать за оборудованием от ППР до ППР, чтобы знать, что делать дальше)
2 Тут сильно зависит от измеряемого параметра, динамики его измерения. Обычно один раз минут в 5 хватает, иногда реже. Если на машине возникают проблемы, то интереснее писать чаще, чтобы потом соотнести время возникновения проблемы с измеряемым параметром.

3. Сразу измерилось, сохранилось на сервер. Это позволят написать простую программку, отслеживающую пороги и сигнализирующую выходи за из значения.

Режим сна мы и не использовали совсем. Раз в два три дня можно сходить, поменять аккумулятор или прибор на зарядку поставить (тем более персонал на машине есть, всегда можно это по телефону решить). Но бывает, что прибор ставится в труднодоступное место, бывает, что для установки нужно остановить машину. Или куда нибудь залезть высоко. Здесь уже автономность была бы не лишней.

--------------------------
Благодарю за информацию
Задача понятна.
Резюме:
1) Режим сна вполне можно использовать.
Но проблемы в скорости просыпания нет.
Это обычная задача экономии питания (замеры например 10 секунд в 5 минут позволят продлить работу устройства на порядок , а с учетом того, что ночью не измеряем раз в 30)
с хилым аккумулятором это недели две.
2) Я бы рекомендовал встраивать обработку в ESP, так как процессор мощный , а обработка на лету позволяет сжимать информацию на порядки (иногда в тысячи раз) ,
что не только разгружает сервер ( т е людей от бессмысленного созерцания экрана) ,
но и экономит батарею питания.
3) Задача не та, в том смысле, что нет надобности быстро просыпаться и сильно экономить питание.

 

[serrgee]

Пример применения. датчик протечки для кухни/ванны/подвала

просыпается раз в час/день чтобы сообщить о себе и об уровне заряда аккумулятора
просыпается от датчика влажности (аппаратно)

Климатический датчик для сада/огорода:
просыпается раз в 15 минут, измеряет:
влажность, температуру, (давление) -- параметры воздуха
(освещенность)
температура, влажность -- почва
Если изменения небольшие, то накапливает данные, но нечего не передаёт

Охранный датчик
просыпается аппаратно от изменения состояния одного из входов (геркон, вибродатчик, пропадание внешнего питания (если имеется), пороговый датчик протечки и других)
просыпается от таймера раз в час и сообщает о себе

 

[serrgee]

Как "быстрый" цикл отличается от "обычного" - по времени, по затрачиваемой энергии?

Вот ещё "быстрая" задача: датчик движения транспорта на дороге.

 

[serrgee]

А хотелось бы как-то реализовать пороговые значения для любого датчика,

Для аналоговых сигналов задачу можно решить с АЦП серии ADS1115: он умеет измерять сигнал(ы) и сравнивать с установленными порогами, а при пересечении границ дёргать выход Alert.

 

[serrgee]

Раннее обнаружение пожара в лесу (тайге), в степи.

Откуда WiFi в степи и тайге? Как тревогу передавать?