Делюсь опытом Уменьшаем потребление ESP в 10 и более раз!!!

[nikolz]

Добрый день,Всем!!!
мне в личке задали вопрос про протокол ESP-NOW.
В итоге решил рассказать о способах сокращения потребления датчиков и исполнительных устройств, работающих по WiFi ,
к ним относится и ESP8266 ,
в частности Sonoff.
-----------------------------------
Сначала о сути решаемой проблемы.
В классическом решении на WiFi для взаимодействия устройств либо иcпользуется роутер, либо смартфон или устройства включается как точка доступа.
Сама процедура соединения и передачи данных без специальных танцев с бубном составляет от 1 до 4 секунд. При этом ток потребления не менее 70 ма.
При работе от батарейки например датчика температуры используется режим глубокого сна. устройство периодически просыпается , отсылает данные и засыпает.
На основе своего опыта могу сказать, что время активности ESP8266 можно сократить до 0.1-0.13 сек.
Причем существенную часть этого времени составляет время работы загрузчика: от 0.08 сек до 0.1 сек. Но так как в это время еще не включен wifi, то ток потребления составляет в среднем 25 ма.
Использую этот интервал для проверки заряда аккумулятора.
Если заряда недостаточно для связи снова посылаю устройство спать.
Использую это время для проверки показаний датчика и сравнения с заданным коридором значений
Если в коридоре то отправляю устройство снова спать.
Таким образом существенно сокращаются лишние посылки данных.
.------------------------------------
Как правило, в проектах типа "умного дома" , самогонного или пивного агрегата , метеостанция погоды надо измерять температуру и включать и выключать реле лампочку, насос, двигатель.
Для управления такими устройствами и получения данных температуры или давления на смартфон или другое устройство достаточно нескольких байт.
================
Применительно к ESP8266 в интернете известно несколько способов сокращения времени активности таких устройств при передачи данных по WiFi.
-------------------------------------
Вариант 1: использование протокола TCP/IP и фиксированного адреса IP.
Первым его для ESP8266 сделал pvvx.
Недостатки: Применение самопального SDK.
Время активности от 0.54 сек.
-----------------------
Вариант 2: этот способ первым применил я давно, но в инете его не нашел и сегодня.
Использование протокола UDP ,фиксация параметров соединения в RAM RTC ,отключение DHCP.
На форуме я о нем уже рассказывал.
Достоинство : стандартный SDK никаких костылей, длина пакета до 64К.
Время активности от 0.25 сек.
----------------------------
Вариант 3: протокол ESP-NOW .
Недостаток: сложность понимания любителями, необходимость комбинирования с протоколом wifi для обмена данными со смартфоном.
Достоинство : стандартная SDK, никаких костылей, длина пакета до 512 байт.
Время активности: от 0.13 сек(стандартный загрузчик) ; 0.1(специальный загрузчик)
-----------------------------------------
Вариант 4: решение CNLohr на основе самопальной pvvx SDK и использования сырых пакетов.
Отличие от решения ESP-NOW в том, что передаваемый пакет меньше, но используется протокол WiFi.
Недостаток: очень сложно в освоении любителями , не может быть реализована в среде ардуино, требует внесение изменения в софт роутера.
Время активности: как в варианте 3.
----------------------------
Вариант 5: универсальный метод для частных сетей на основе WiFi.
Никаких костылей. Реализуемо легко на ардуино.софт стандартный.
Можно применять не только для ESP.
Не требует роутера.
Недостаток: длина пакета 4 байт
Время активности: как в варианте 3.
===========================
Суть этого метода проста.
В локальной сети мы используем специальные MAC адреса,
1 байт которого, например, 0x36,
2 байт которого указывает номер устройства,
3,4,5,6 байты содержат передаваемую информацию.
в итоге для получения переданной информации требуется лишь выполнить соединение.
время на передачу данных равно нулю, так как данные получаем в момент соединения.
==========================
Вариант реализации этого метода для ардуино можно списать здесь:
HarringayMakerSpace/sonoff-adhoc
----------------------
Таким образом, в вариантах с 3 по 5 работа WiFi блока занимает не более 0.04 сек
именно в это время ток потребления изменяется в пределах от 70 до 300 ма.
В остальное время он может быть сделан не более 25 ма.
в итоге вместо затрат энергии на один сеанс 70 ма*с.
Получаем примерно 3 ма*с.
Желающие могут точнее посчитать экономию для конкретных устройств.
-------------------------------------------
Всем успехов в экономии энергии.

 

[Сергей_Ф]

Вариант реализации этого метода для ардуино можно списать здесь:
HarringayMakerSpace/sonoff-adhoc

Вы, конечно, извините, но никакого варианта реализации, того что предлагаете вы, там нет. Там сделано всё ровно наоборот. ESP работает всегда в режиме softAP и слушает сеть на запросы в сети по Mac-адресу. Никакой экономии это не обеспечит.
Хотя мысль интересная. Может есть более актуальный пример?

 

[nikolz]

Вы, конечно, извините, но никакого варианта реализации, того что предлагаете вы, там нет. Там сделано всё ровно наоборот. ESP работает всегда в режиме softAP и слушает сеть на запросы в сети по Mac-адресу. Никакой экономии это не обеспечит.
Хотя мысль интересная. Может есть более актуальный пример?

это пример применения данного метода передачи информации.
В нем не реализован режим сна.
Поэтому максимальную экономию Вы в этом примере не получите
-----------------
Но экономия есть так как нет импульсов тока в 300 ма для передачи информации
Фактически есть всего один импульс порядка 2-4 мс
---------------------------
Добавьте режим deep-sleep
и будет Вам счастье.
-------------------------------------
"Частое употребление халявы отключает мозг полностью"

 

[Сергей_Ф]

Вы тролите? Какая экономия в режиме softAP? Какой режим deep sleep? В приведённом примере esp приёмник, а не передатчик. Он ничего экономить не может, иначе пропустит команду.

 

[nikolz]

Вы тролите? Какая экономия в режиме softAP? Какой режим deep sleep? В приведённом примере esp приёмник, а не передатчик. Он ничего экономить не может, иначе пропустит команду.

Можете предположить хотя бы на мгновение, что кроме непонятного фейкового слова "троллите" есть нормальные русские слова, например "ошибаетесь"
Если Вы используя слово троллите хотите уличить меня в специальном засорении вашего форума то просто не пишите и я не буду писать свое мнение
Если же Вы действительно хотите узнать мое мнение, которое основано на моем опыте, то видите дискуссию так, что бы было желание вам отвечать
я Вам ничего не должен и не занимаюсь "тролить"

 

[Сергей_Ф]

кроме непонятного фейкового слова "троллите" есть нормальные русские слова, например "ошибаетесь"

Согласен, есть русские слова. В данном случае, имел ввиду "прикалываетесь", "издеваетесь".

то видите дискуссию так, что бы было желание вам отвечать
я Вам ничего не должен и не занимаюсь "тролить"

Если вам нравится придираться к опечаткам, сделанным со смартфона, то дискуссию надо вЕсти, а не вИдеть.

"Частое употребление халявы отключает мозг полностью"

Вы считает, это заявление, граничащее с хамством, хорошее начало для дискуссии на мое первое сообщение?
Вы дали сырую идею, привели неудачный пример. Бывает. Ни кто не идеален, все ошибаются.
Но вы намекнули, что кто-то от вас хочет халявы. Потом вообще уводите тему в сторону и переходите на личность. Это откровенная демагогия. Надеюсь это слово для вас не фейковое.

По поводу приведенного примера, считаю его в том виде как у автора, вредным и более похожем на радиохулиганство. Повторять его никому не советую, если только в частном доме и только ради эксперимента.
Обосную: автор предлагает поднять для каждого esp-выключателя собственную softAP сеть и скрыть их имена. При наличии в доме хотя бы 5 таких выключателей, это практически полностью покроет весь диапазон 2,4ГГц WiFi, что сделает работу домашних WiFi сетей в режиме постоянных коллизий, скорость доступа в интернет снизиться и не только у вас, но и у соседей.
Имеете это ввиду. Там дана только сырая идея, нормальной реализации там нет. Тем более там нет экономии энергии у esp.

 

[pvvx]

По описанию от ТС наблюдается, что ничего не было опробовано на практике. Об этом говорят и ошибки и неточности.

Взять к примеру минимальные и максимальные размеры пакетов (не MTU(!)) передаваемые в физической среде:
Для Ethernet это чаше называют размером фрейма. Посмотреть можно тут:
Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря
Для BT это 1021 байт (2875 мкс) и у BLE это 27 байт (328 мкс) на типичных битрейтах.

Далее у @nikolz имеем путаницу, связанную с изучением имеющихся сред программирования.
В Arduino класс низко-потребляющих устройств отсутствует.
В направлении беспроводной связи Arduino становилась и росло на ESP8266. А данное устройство не приспособлено для автономных устройств. По тому (наверно) и забили на это, но и концепция Arduino не рассчитана для алгоритмов и аппаратных решений у малопотребляющих устройств. Сейчас пытаются вставить костыли, но это только усложнит решения.

DeepSleep не решает проблем малого потребления. Это костыль и аналогичен выключателю питания. Стартовая инициализация WiFi чипа во много раз превышает время самого сеанса связи при обмене несколькими байтами информации. В топку такие решения...

 

[pvvx]

Пока @nikolz дремал с ESP, для малого потребления был создан протокол BLE и выпущена масса SoC специально спроектированных для этого.

На сегодня реализации BLE в сегменте домашних датчиков (передача значений от датчиков раз в пару секунд) достигли показателей менее саморазряда стандартных источников питания.

Для увеличения дальности были созданы и новые стандарты. Тот-же Bluetooth 5.0.

В итоге расстояние связи для современных BLE устройств сравнялось с WiFi. Сегмент этого рынка давно перепрофилировался на них. Arduino в спешке пытается окучить и этот сегмент, но предлагаемые аппаратные решения от этого бренда пока слишком дороги для “народного творчества”. Пример,выпушенный этим летом ARDUINO NANO 33 BLE
Arduino обещают понижение цены в последствии... когда окучат определенное кол-во ардуино-поклонников...
Тем временем массово вышли китайские чипы SoC c BLE не уступающие по параметрам (а иногда и превосходящие) брендовым европейским компашам...

Со стороны пользователя в поддержке связи с BLE уже всё хорошо. Броузеры поддерживают работу с BLE, при этом код на javascript не сложнее чем работа с websocket.

Последним непавшим под BLE (недоразвитым) бытовым сегментом остались роутеры. Там пока срывается прибыль с населения в виде проприетарных шлюзов Xiaomi и других крупных игроков рынка.
Причина в отсутствии (бойкотировании) стандартов для них ради выгоды...

 

[pvvx]

Ну а что с Arduino…

Достичь поддержки стандартов TCP/IP на малых SoC Arduino и её сообщество за более чем 5 лет так и не смогло. Тем временем индустрия родила нового ребенка - BLE. Он более приспособлен для всех встретившихся и обсуждаемых проектов на форуме за последние 5 лет. В итоге WiFi и устаревшие решения и чипы от Espressif уже умерли и никакая подача импульсов питания на лапки не приведет их в чувства

Последние дрыгания связаны с ESP32 – как шлюза BLE. Но устаревшие тех.нормы производства и прочие недочеты проектирования SoC не позволяют собрать на них современное устройство.

Очень мешает невозможность работы одновременно BLE и WiFi, да и никак не поддержать стандарт TCP/IP из-за нехватки RAM… Для игры и изучения элементарщины ESP32 ещё сгодиться именно в такой позе, как шлюз BLE/Mesh <-> IPv4 (UDP only).

 

[pvvx]

@nikolz - Вас чувства не подвели. Но вы не туда приспосабливаете UDP. Это единственный тип пакета связи у ESP чипов со внешним миром – миром IP сетей. Другие (TCP/IP и одноименный стек) он не тянет из-за критической нехватки RAM.
Но для работы по UDP нет никакого внешнего ПО и/или систем...

 

[pvvx]

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

 

[pvvx]

В связи со всем перечисленным, Вам @nikolz, остается только радоваться – стоимость чипов от Espressif переходит в отрицательную область измерения цены.
Остается сегмент “обреченных Arduino”, на которых из ESP остается получать затухающую прибыль.

Скоро вы сможете ‘купить’ ESP8266 со складов за вознаграждение по утилизации. Не упустите момента – далее будут просить за хранение “антиквариата”…

 

[Сергей_Ф]

Несмотря ни на что, попробовал сделать простую библиотеку для АрдуиноИде для реализации передачи данных по принципу из HarringayMakerSpace/sonoff-adhoc

Получилось просто и быстро. Но попытка сделать это ещё быстрее, привела к странной проблеме - не меняется канал передачи данных, всегда передаёт на канале 1. Но быстро - менее 700мкс. На стандартных вызовах 60мс, но на любом канале. Если кто объяснит ошибку, буду благодарен.

Положить папку в библиотеки Ардуино или в пользовательские.
Появятся два примера ESP_AdHoc_Data для передатчика и приёмника.
ESP_AdHoc_Data – Google Диск

P. S. Делал быстро, комментариев минимум. Но там вроде все понятно.

 

[pvvx]

Вопрос переводится в вопрос:
Как связан WiFi.softAP(ssid, password, channel, hidden, max_connection) с запросом ProbeRequest?

 

[pvvx]

Чтобы из ESP на Arduino получить подобие BLE необходимо удалить Loop() и предоставить пользователю управление списком функций событий менеджера управления питанием. Но менеджера управления питанием нет в ESP. Чипы ESP не умеют отключать аппаратные части в любой комбинации и не имеют возможностей быстрого восстановления их прошлого рабочего состояния. Да и такой алгоритм программирования нарушает базовые концепции Arduino...

Выход в эфир WiFi AP с оповещением сопровождается сбоями (коллизиями) текущим работающим WiFi участникам. Пару таких работающих ESP уже не позволят смотреть кино по WiFi. Оставьте WiFi для удовлетворения местных запросов человека с глобальным интернет, а не для датчиков IoT. Эфир WiFi и так уже перенасыщен в городской обстановке и его пропускной способности не хватает.

 

[Сергей_Ф]

Вопрос переводится в вопрос:
Как связан WiFi.softAP(ssid, password, channel, hidden, max_connection) с запросом ProbeRequest?

Дело не в softAP. SoftAP на приёмник, он включён всегда. И приёмник можно сделать на чем угодно, хоть на Малине, хоть на роутере. ESP-передатчик (пример TestSender) может послать запрос ProbeRequest только по одному каналу для определённой сети. Если делаю вызовами из Ардуино, то все работает как описано. Попробовал скопировать код в свою библиотеку, убрав ненужные проверки (в меру своих знаний), запрос шлёт только на канал 1. Хотя канал я выставил.
По поводу помех, вы правы - и сам мешает и данные не всегда доходят. Но в лесу, в деревне может сгодится.

 

[pvvx]

Я не нашел "Хотя канал я выставил" в вашем коде. Нашел вставку канала только в WiFi.softAP(ssid, password, channel, hidden, max_connection), по тому и написал такой вопрос.

 

[Сергей_Ф]

Е ли совсем конкретно, то мне интересно чем запрос

WiFi.scanNetworks( false, true, channel , (uint8*)AdHocName );

отличается от реализации в библиотеке вызова

int8_t fastScanNetworks( uint8 channel, uint8* ssid) {

            WiFi.enableSTA(true);

            int status = wifi_station_get_connect_status();
            if(status != STATION_GOT_IP && status != STATION_IDLE) {
                wifi_station_disconnect();
            }

            struct scan_config config;
            memset(&config, 0, sizeof(config));
            config.ssid = ssid;
            config.channel = channel;
            config.show_hidden = true;
            if( wifi_station_scan(&config, nullptr)) {
                yield();
            }
            return 0;
    }

?

 

[pvvx]

Е ли совсем конкретно, то мне интересно чем запрос
...
отличается от реализации в библиотеке вызова
...
?

Там все концы в закрытую либу от Espressif (которую за 5 лет никто не разбирал и не желает). Выходит, что нет никакого смысла в таких вопросах.
На OpenWRT дрова WiFi уже с исходниками. На китайские BLE PHY62x2 и TLSR8266 предоставлены все варианты приема-передачи raw пакетов на любом канале и любой модуляции (закрыта только реализация либы BLE стека).

 

[Сергей_Ф]

Там все концы в закрытую либу от Espressif (которую за 5 лет никто не разбирал и не желает). Выходит, что нет никакого смысла в таких вопросах.

Спасибо за ответ. Я бы не задавал вопрос, если бы Ардуино вызов тоже бы работал неверно, но он работает правильно. Хотя и намного дольше, поскольку там отрабатывает колбэк. Тут колбэк по сути и не нужен, и я его убрал ( nullptr, пробовал и пустышку подсовывать). Но он же не может влиять на выставление канала в вызове?
Ну и разница 700мкс при укороченном запросе и 60мс Ардуино существенна, имхо. Хотелось бы побороть.

P.S. Добавил в примеры передачу и прием float и char[4], ну что бы совсем не думать.
[off]Когда объяснял своему коллеге, несведущему в программировании, принцип работы, он привел такую аналогию: ESP спит, а потом просыпается и громко орет, что проснулся. И снова спать. При чем в зависимости от передаваемых данных орёт на разный лад. Очень похоже.[/off]