Варианты получения данных по ESP-NOW и загрузки их по WiFi на сервер?

[pvvx]

А мощности передатчиков одинаковые?

При одинаковых и выходит от 5 раз.
Только смысл в увеличении мощности к схожей у WiFi, если при в 10 раз меньшей дальность уже больше?
При этом отношение потребление уже от 50 раз.

Доказываете, что модули, которые выпустили через 10-15 лет после, новее, чем те, которые выпустили 10-15 лет назад. Прикольно.

Разница всего в 2 года.

Успехов вам в изучении новых модулей для измерения температуры.

В быту для датчиков ещё есть измерение влажности, давления, освещения, энергии, кнопки, состава/концентраций и всякие Findmy и прочие ключи.
Фото-рамки и ценники для магазинов в большинстве на BLE, так как это практичнее.
У WiFi сфера применения значительно уже.

 

[pvvx]

прикольно читать от Вас рассуждение про качество связи WiFi и BLE.
Вы же хорошо разбираетесь и понимаете, что при одинаrовой мощности излучения и диаграмме направленности антенны и при отсутствии помех( как в вашем случае в деревне в глуши) оба вида связи дадут одинаковую дальность при равенстве бюджета канала. Если бюджет разный , то и дальность разная. Но это не зависит WiFi это или BLE, так как частота одинаковая и вид модуляции одинаковый. У WiFi даже может быть лучше связь так как полоса модуляции шире, а это повышает помехоустойчивость при узкополосных помехах, что хуже у BLE . Причем ESP-Now - это не WiFi так как нет центрального узла.

Тут и сказывается уже сам протокол распределения по времени окон приема-передачи. Да и вообще принцип - у BLE маяка совсем другая концепция.
Про это вы постоянно забываете

Никто не против BLE, поэтому не надо рвать штаны и доказывать, что BLE лучше WiFi.

Есть ещё Zigbee. BLE хорош для датчиков и типа фото-рамок. Остальное - или BLE-MESH или Zigbee. Но никак не WiFi.

Экономьте дальше и измеряйте температуру больше дольше и точнее.

Т.е. вы намекаете на то, что я не выкладываю на Github другие варианты, кроме термометров?
Ну у меня нет времени на поддержку других вариантов.
От вас то вообще никакого толку, кроме как спама и развлекухи в смешных постах...

 

[pvvx]

@nikolz - Заметьте, что ESP-NOW привязан к ESP чипам по причине, что другого варианта противопоставления для более развитых протоколов у них не было.
Ну и вышло что-то кое-какное, т.к чип и блок RF и прочие потроха рассчитаны совсем на другой тайминг работы.
Т.е. это чистое извращение от безысходности - попытка приблизиться к уже имеющимся протоколам на рынке хоть как-то...
Аналог - ногдрыгом выводить VGA сигнал на монитор. Смысл только в игре на раз.

 

[pvvx]

Извращенцы ради хайпа всегда найдутся. На этом строится индустрия заработка в Ютубе и прочих “информационных” сервисах. Это и есть ваше “много написано”.

Но Espressif всё равно идет вынужденным путем – выпускает новые чипы с поддержкой типовых захвативших рынок IoT протоколов – BLE и Zigbee.
Пока это не очень выходит у Espressif – хромает устаревшая технология производства чипов…

Но и такое Г фанаты съедят – китайцы завалят али модулями на 10 рублей дешевле, чем у других производителей по простой причине
– никому из крупных заказчиков-продавцов для серийного выпуска готовых изделий такие чипы не нужны.

 

[pvvx]

Разбирать Вами придуманный пример не вижу смысла.

При этом другие разбираете.
Может все таки разберете и предложите какое решение?
Там суть в том, что нет никакого желания ставить в каждое строение WiFi роутер, да ещё с направленными антеннами. Иначе выходит плохая связь.
И не все строения запитываются от генератора, когда внешняя эл.сеть падает. А падает она часто. И эти проблемы с эл. сетями не только у меня, а в 50% по всей территории России, не считая городов.

Примеры есть в ESP32-idf. У меня проблем нет. модули ESP32C3 есть в продаже и дешевле чем иные. Кроме того в них гораздо больше памяти, что позволяет сохранять данные и передавать их боле большими пакетами.

А нафига нужно передавать более 2-х или 3-х значений от датчика? С индексами и идентификаторами устройства это запросто влезает в 20..60 байт, учитывая и номер IEEE (MAC устройства) и информацию для самого протокола передачи (т.е. все битики RF фрейма).
Приемлемый период передачи от датчиков для IoT (бытовухи) от 2-х до 30 секунд. Остальное - это сигнализации, и то там постоянно необходимо передавать что устройство активно и жизнеспособно.

На передачу фрейма во всех типах протоколов уходит в среднем 1 ms.

Далее идут причуды протокола.
Для уменьшения потерь приема у BLE маяка применяется метод избыточного дублирования передачи и на 3-х каналах.
У остальных - передача на одном канале и прием подтверждения.

Для BLE пусть будет 3 передачи сразу по 3-м каналам - это 9 передач = 9 ms работы передатчика.
Для прочих протоколов: 1 передача, пауза и окно приема. При сбое - дублирование передачи и новое окно приема. Т.е. = от 1 ms передачи и N ms приема при полном успехе и чистоте в эфире по одному каналу.
В итоге, при одинаковой вероятности коллизии в эфире в реальности выходит, что потребление при передаче с подтверждением занимает больше времени и энергии, чем тупое дублирование. Для некоторых протоколов и время ожидания с включенным приемником уже более 9 ms, а работа на одном канале ещё увеличивает вероятность пропуска приема и это актуально с двух сторон.
И BLE маяк гарантировано выигрывает по всем параметрам....

Далее идет время пробуждения чипа и прочие TTX. Для ESP32-C3 они рассмотрены тут: https://esp8266.ru/forum/threads/esp32-c3-light-sleep.6084/

 

[pvvx]

С введением функции "PAwR" в стандарте BLE 5.4 возникла возможность “дуплекса”.
Т.е. устройство передав BLE маяк ожидает прием подтверждения с доп. данными.
Выходит двух стороння приемо-передача и сфера BLE расширяется на сверхмало потребляющие исполнительные устройства.

Отличие у BLE в том, что после конца передачи окно приема значительно меньше чем у WiFi.
В BLE приемник или передатчик включается на любой канал за десятку микросекунд и паузы до приема следующего синхро ограничены в 150 us.
Приемное окно задается во времени получения синхро сигнала начала фрейма, а не целого фрейма. В BLE и скорость АРУ у RF другая.
Получается возможность ограничить окно приема после передачи до пары сотен мкс.
А типичное потребление BLE чипа при включенном приме и активном CPU – 4..10 мА, при уровне приема до -115 дБм.
В итоге уже через пару сотен мкс уже известно, что приема не будет и можно переходить к другим делам или дублированию передачи на следующем интервальном цикле.
Это составляет добавку потребления к маяку в пару сотню мкс при типичных 6 мА.

Пробуйте это выжать в WiFi или ESP-NOW

 

[pvvx]

Механизм скоростного BLE приема после передачи откатан давно. Это реализовано при передаче маяка на каждом канале с возможностью соединения.
Это типовой BLE с начальных стандартов. Но прием ограничен форматом спецификации – принимаются только сообщения в виде запроса соединения или запроса дополнительной информации. Дополнительная информация – это обычно сообщение с именем устройства или другими данными, получаемое при запросе в режиме “активного сканирования”.

Но извращенцев как в Espessif в случае ESP-NOW не нашлось. Никто не использует функцию запроса соединения или инфы в BLE рекламе для передачи других данных на устройство. И не пытаются, а сделали дополнительную функцию “PAwR” в новой версии стандарта с работой на любом дополнительном RF канале.

 

[pvvx]

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

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

 

[nikolz]

Для BLE пусть будет 3 передачи сразу по 3-м каналам - это 9 передач = 9 ms работы передатчика.
Для прочих протоколов: 1 передача, пауза и окно приема. При сбое - дублирование передачи и новое окно приема. Т.е. = от 1 ms передачи и N ms приема при полном успехе и чистоте в эфире по одному каналу.
В итоге, при одинаковой вероятности коллизии в эфире в реальности выходит, что потребление при передаче с подтверждением занимает больше времени и энергии, чем тупое дублирование. Для некоторых протоколов и время ожидания с включенным приемником уже более 9 ms, а работа на одном канале ещё увеличивает вероятность пропуска приема и это актуально с двух сторон.
И BLE маяк гарантировано выигрывает по всем параметрам....

Далее идет время пробуждения чипа и прочие TTX. Для ESP32-C3 они рассмотрены тут: https://esp8266.ru/forum/threads/esp32-c3-light-sleep.6084/

Попробую объяснить, что мне не нравиться в BLE и модулях типа TLSR c BLE.
--------------------------
1) Реклама работает на 3 каналах одновременно. Это значит что фактически все маяки работают на одном канале. Какой же бардак получается в эфире?
----------------------------------
2) Модули с BLE типа TLSR ориентированы именно на работу маяками. У них малый объем памяти и маломощный процессор. т е это очень тупые модули. Поэтому они постоянно что-то шлют в эфир. Но никому не нужны эти данные в реальном времени, так как ничего конкретного сделать в этом реале не получится - нет никаких реальных устройств которым надо этот подток данных.
------------------------------
3) Получается, что существующие модули BLE - это устройства ориентированные на рекламу и простейшие устройства Собственно они так и используются на рынке.
---------------------------------
4) если у нас есть достаточно памяти, то нет надобности постоянно слать в эфир никому не нужные данные в реальном времени. Можно вместо 1000 посылок значения температуры послать один раз эти тысячи значений. Но лучше обработать эту тысячу и послать например выборку параметров значимых спектральных компонент или коэффициентов аппроксимирующих полиномов.
В результате в место 1000 посылок будет раз в сто меньше данных. В конечном итоге не будет забиваться эфир и разряжаться батарейки.
----------------------------
И главное, про время пробуждения ESP32C3...
протестировал... Вы не поверите -время пробуждения 0.65 ms. при токе не более 5 мА.
Т е если обрабатывать данные с датчиков, а не посылать сырые данные в эфир, то затраты энергии будут меньше, чем с модулями типа TLSR c BLE.

 

[nikolz]

и еще ... на ESP32 можно разместить AI или программу распознавания и синтеза голоса либо изображений , что невозможно разместить на других модулях с BLE.
В этом плане альтернатив для ESP32 пока нет.

 

[pvvx]

Попробую объяснить, что мне не нравиться в BLE и модулях типа TLSR c BLE.
--------------------------
1) Реклама работает на 3 каналах одновременно. Это значит что фактически все маяки работают на одном канале. Какой же бардак получается в эфире?

Бардак не большой.
В среднем одно устройство передает ~1 мс на одном канале 1 раз в 5 сек. Т.е. занимает канал передачей не более 0.2 мс в секунду.
Приемник способен принять с одного канала до тысячи фреймов в сек. Но учтя что он ловит и сопровождает три канала, то теоретический максимум составит прием 300 полных рекламных событий в сек.
В итого, чтобы забить все основные каналы, с учетом что вокруг приемника все датчики на одинаковом расстоянии и передают с одинаковым уровнем, потребуется более 1500 устройств. Но расстояния разные и уровни сигналов тоже. Ближний примет, а дальний не создаст ему коллизии...
С учетом того, что даже Home Assitant не справляется с большим потоком точек, то он или усредняет данные на 30 сек или просто тупит 30..60 секунд, то устройств может быть и больше. За 60 секунд пробьется хотя-бы одна передача...

2) Модули с BLE типа TLSR ориентированы именно на работу маяками. У них малый объем памяти и маломощный процессор. т е это очень тупые модули. Поэтому они постоянно что-то шлют в эфир. Но никому не нужны эти данные в реальном времени, так как ничего конкретного сделать в этом реале не получится - нет никаких реальных устройств которым надо этот подток данных.

Этот поток данных больше, чем у 99.999% всех Arduino проектов. И тем более больше чем у Zigbee.
Как-то люди живут с Zigbee и не расстраиваются.
А при соединении типовой BLE дает скорость аналогичную 115200 Бод у UART. Это уже покрывает более 90% всех электронных устройств.

3) Получается, что существующие модули BLE - это устройства ориентированные на рекламу и простейшие устройства Собственно они так и используются на рынке.

Это только вы так считаете. Никто не ограничивает BLE в применении в простейших или сложнейших...

4) если у нас есть достаточно памяти, то нет надобности постоянно слать в эфир никому не нужные данные в реальном времени. Можно вместо 1000 посылок значения температуры послать один раз эти тысячи значений. Но лучше обработать эту тысячу и послать например выборку параметров значимых спектральных компонент или коэффициентов аппроксимирующих полиномов.
В результате в место 1000 посылок будет раз в сто меньше данных. В конечном итоге не будет забиваться эфир и разряжаться батарейки.

Пересчитайте по энергии с учетом всех неурядиц в эфире, а то лепите лапшу на уши....
Для автоматизации и бытовыхи никаких матриц коэффициентов ИИ типа DeepSeek передавать не требуется. Не доросли ещё смарты до возможности загрузки полной текущей модели ИИ в RAM и по скорости обработки не справятся даже для растянутого на часы диалога... В простой ком ещё не лезет... Токо усеченные модельки, которые программы пишут совсем корявые

И главное, про время пробуждения ESP32C3...
протестировал... Вы не поверите -время пробуждения 0.65 ms. при токе не более 5 мА.
Т е если обрабатывать данные с датчиков, а не посылать сырые данные в эфир, то затраты энергии будут меньше, чем с модулями типа TLSR c BLE.

Вы опять что-то там путаете. Он жрет в таком сне больше чем 15 BLE датчиков.
При аналогичном типе сна у любого BLE такой выход равен пару тактам CPU

 

[pvvx]

и еще ... на ESP32 можно разместить AI или программу распознавания и синтеза голоса либо изображений , что невозможно разместить на других модулях с BLE.
В этом плане альтернатив для ESP32 пока нет.

Небоитесь усё есть и давно.
Если вас интересуют нормальные рабочие решения - вперед изучать как пашут E-Ink ценники. Их в некоторых магазинах тысячи... и они всегда online - готовы обновиться и постоянно передают статус батареи, id и т.д. И без всякой MESH...
Уже встроено в Home Assistant...
И там с ESP32 бяда... исправить никак не могут...

 

[pvvx]

И ещё раз – никому не нужны ваши примитивные AI.

Народу нужны тупые панельки с показом тенденции температуры в виде графика и подобные в каждом выключателе света или будильнике. А не включение-выключение чего либо через час по каким-то матрицам спектра анализа...

А для серьезных устройств тем более никто не будет использовать какой-то ESP да ещё с нестандартным протоколом. Даже в пром. мелко-серийке…
Это уровень любителей работающих паяльником на кухне.

 

[pvvx]

Да и цена на модули с BLE/Zigbee уже ниже любых ESP

 

[pvvx]

Попробую объяснить, что мне не нравиться в BLE и модулях типа TLSR c BLE.

Текущая система имеет 68 BLE датчиков и/или устройств передающих состояние для мониторинга.


Это не все BLE участвующие в бардаке моего "Умного дома", а только те, которые может обрабатывать HA. Есть ещё и связанные, работающие друг с другом без HA.

Средний период передачи новых данных у них составляет 10..20 секунд и несколько вариантов передающих события. При передаче событий время от регистрации события до получения в HA составляет 3..7 мс, и далее передача дублируется десяток раз с шагом 50..70 мс.

Если предположить, что выбросим BLE и перестроим имеющуюся систему на ESP c ESP-NOW, тогда:

• Необходимо провести более 600 метров проводов по всем стенам и прочей домашней утвари для питания 68-ми ESP. В том числе и хитро-гибкие на датчики подвижных частей типа дверей.
• Купить партию блоков питания для 68 ESP от сети 230В.
• Напечатать на 3D принтере 68 коробок под все виды данных устройств, да ещё с красивым дизайном.
• Купить несколько десятков экранов для замены готовых в имеющихся на рынке устройствах.
• Написать программы для всех этих видов устройств, поборов все глюки ESP.
• Закупить десятки Li АКБ для датчиков требующих автономную работу.
• Создать координатор данной сети с интеграцией в HA.

Вот нафиг это всё, если эти задачи полностью решаются покупкой готовых устройств с ценой по 200..400 руб?
Комплект батареек на год работы этих 68-ми устройств стоит около 700 руб.
Стоимость электроэнергии при при питании 68 ESP (без учета смены АКБ) составит (2.5Вт*24ч*365дней*68шт) не менее 1500 кВт в год, т.е. по текущему тарифу более 10 т.руб.

 

[pvvx]

@nikolz - Если учесть ещё Zigbee устройcтва, то список удваивается.
Выходит вы предполагаете жизнь в микроволновке из-за пикового излучения всей орды составляющей за сотню WiFi передатчиков

 

[pvvx]

Кроме всего этого наверняка потребуется более мощная системная плата для работы самого Home Assistant. Это ещё доп.потребление при её автономности (текущая имеет автономность в месяц работы). Это связано с тем, что потребуется обработка дополнительных интеграций типа MQTT. А MQTT это тормоз ещё тот и требует энергии. Поток транзакций в ней от датчиков будет не менее 20 шт в секунду (это ещё при условии сверх-оптимизации...). По этой причине координатор типа ESP-NOW не может быть построен на ESP, особенно с передачей по WiFi. Просто не успеет, а других программ-протоколов для шлюзов ESP-NOW и т.д. пока нет.

В итоге и выходит, что ESP-NOW и прочие поделки на ESP (и Arduino)- это участь "экспериментаторов" с одной игрушкой на коленке.

 

[pvvx]

Попробую объяснить, что мне не нравиться в BLE и модулях типа TLSR c BLE.
--------------------------
1) Реклама работает на 3 каналах одновременно. Это значит что фактически все маяки работают на одном канале. Какой же бардак получается в эфире?

@nikolz - Подоспел ответ на ваш вопрос:

TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр

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

esp8266.ru

Т.е. самый шумным является WiFi. От него коллизий в эфире больше всех остальных, при условии работы WiFi роутера на непересекающемся с другими канале.