Хочется устройство на батарейках, в котором будет реал тайм часы, EEPROM 256 bytes, 16 IO (можно наверное и 8),
сериал порт для фирмвар апгрейд или связи с компьютером и самое главное, надо по интернету достучатся до устройства.
Иногда, может пару раз в день, может раз в неделю.
Батарейки желательно 4хАА например, можно неначительно больше.

Все хорошо, но wifi chip потребляет сумасшедшие миллиамперы. Желательно чтоб устройство жило месяц на батарейках, как минимум.
Куда копать? Вроде есть и зигби поменьше едят, но может wifi есть которые спят, мало едят и можно их разбудить.
Думал еще над бриджем от компьютера на инфракрасных лучах, это вроде должно быть малопотребляемым.
Какие есть идеи?

Bluetooth Low Energy. Хватит литиевой "таблетки" на месяцы, может быть даже годы - зависит от периодичности просыпания.

nRF24L01+

ТЗ напрочь отсутствует.
Это устройство где жить будет? Рядом на стенке будет висеть своя базовая станция? Рядом с телефоном пользователя? Или рядом только вайфай (с десятью NAT'ами, но это отдельные проблемы). Или GSM ?

Если нет "своего" устройства на другой стороне радиоканала, выбор совсем небольшой...

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

Интересная статейка про Amazon Dash Button с Wi-Fi и BLE, с помощью которых американских домохозяек приучают туалетную бумагу заказывать:
New Amazon Dash Button Teardown (JK29LP)
Работает от одной AA, но как долго - непонятно...

Рекомендую esp8266.
В данный момент у нас в разработке подобная конструкция. Для тестирования esp.qbit.su
В слипе не более 0.5мА. Данные от устройства отсылаются на сервер, на серваке хранятся уставки и при подключении записываются в устройство. Работают и управляются несколько io, pwm, adc. На adc подключен термодатчик ntc 10k. Если интересно – пишите на email: info собака qbit.su

Так ТС нужно:

а в слипе до esp8266 не достучишься.
Если только не сделать периодические просыпания устройства и пользователь, стучащийся из инета, может ждать очередного пробуждения.

Если девайс в слипе, причём глубоком, и не важно, будь это esp или иной чип, то не достучаться никак до устройства.

Важно, ибо вход/выход в/из слипа nRF24L01+ - это микросекунды, для ESP8266 - это время на порядки больше.
Так что для nRF24L01+ ничего не стоит сделать просыпание раз в несколько секунд на несколько миллисекунд и организовать хендшейк в эти временнЫе окна.
Среднее потребление будет мало отличаться от постоянного слипа, а время доступа - несколько секунд до ближайшего окна просыпания.
Делал такую систему на nRF24L01+ - работает уже 2 года от одной AA.

Шикарно!

Только пара моментов:

Поэтому, выходим из слипа 1мкс или 10мс - это не играет роли, если спим часы!

выход в интернет - однозначно будет чем-либо из Ethernet/ WiFi/ GSM. Разбудить WiFi по этому же самому WiFi невозможно.
Все они ни капли не являются чем-либо, близким к батарейному (4хАА) питанию. Сжирание батареек за 2 дня в самом удачном случае гарантировано.
поэтому. единственный разумный вариант - это мост из "Ethernet/ WiFi/ GSM", висящего наример, на аккумуляторе типа 12v х 9 Ah, непрерывно подзаряжаемого от 220, и собирающего/раздающего по ZigBee/LoWPAN/и т.п. прочей малопотребляющей низкоскоростной линии передачи - данные от устройств с батарейным питанием.

Либо. покупать Qualcomm SDK замногоденег и пилить свою "а-ля мобилу" с питанием от компактного аккума на 4200mAh, но опять-таки, более недели оно без подзаряда не проживёт один фиг, не говорю уже про АА.

Потребление nRF2401+ не сильно отличается от sub-1GHz приемников, а дальность больше. Только опять же какой то центр нужен для отправки сообщений на активацию WiFi. Конечно без детального описания - получается гадание на кофейной гуще.

Нет, нет, дальность то меньше причем при той же мощности излучения как у Tx/Rx sub-1GHz. Физику и энергетику не обманишь. Причем потребление больше, при непрерывном излучении и приемник не такой уж и маложрущий. Бит данных переданный/принятый проигрывает по энергетике субмегагерцовым трансиверам.

ТС не осветил алгоритм доступа к устройству. И что означает это: "Иногда, может пару раз в день, может раз в неделю"?
По какому событию? Кто достукивается? Если не проблема ждать очередного окна связи когда устройство проснётся не секунды, а на порядки дольше - то можно интервал сна соответственно увеличить. Но если ждать так долго нельзя? Если ждать можно не более нескольких секунд (скажем опрос инициирует пользователь, а ему не комфортно ждать даже несколько секунд)?

Да и какие 10мс на просыпание для ESP8266? А регистрация в сети и т.п.? Усыплять ESP8266 я не пробовал, но по-крайней мере холодный старт после сброса у него более 1сек.


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

Опять-же - ТС ничего не сказал о требуемом максимальном времени отклика устройства. Миллисекунды? Секунды? Минуты? Часы? ...

Дальность меньше и еще по другой причине, это более широкая полоса Rx/Tx, что снижает существенно соотношение С/Ш и сокрашает дальность.
Ну и естественно, если мы просыпаемся Rx_ом по временным окнам, потребление меньше на соответствующее соотношение времён. Тут нет причин спорить.

Другой момент связан с мнинимальным временем работы приемника, или его окна. Главным ограничителем оказывается время выбега кварца на стабильную частоту, что может составлять 10мс ...100мс в зависимости от схемы, кварца. Это время плюсуется по любому к временному окну, затем еще синхра, далее минимальный пакет. И если делать все времянки по минимуму, то получаем максимум ненадежности. Из-за причин внешних помех и внутренних ошибок, джиттера и тп. Особенно это ярко замето на границе уверенного приема, когда подходим к порогу. По этому всегда ищется компромис и оптимальное решение для минимального временного окна.

Так что единицы миллисекунд не реально за разумные деньги.

Например, для CC110x время старта опорника - доли ms (точнее, у меня не превышало 200 us), опрос на наличие эфирного запроса - менее 1 ms (при терминировании по отсутствию несущей средствами трансивера) и менее 2 ms при принудительном терминировании "извне". С WiFi такой фокус не пройдет, а для поднятия соединения с ESP8266 секунд пять потребуется, и жрет она при этом как утюг...

У меня есть работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс.

А что про полосу частот вы ничего не написали, про длительность синхры ну и тд.
Затем вы явно эти времена указываете без учета длительность выбега частоты после включения, что составляет 5…10 мс.
Может вы не разобрались или не сами проекты делали. Старт опорника и выбег частоты после включения кв генератора вещи разные.

Господин теоретик, к чему все это, а ? Достаточно того, что решение работает, с указанными времянками. Ну, и "до кучи" - посмотрите типовое время запуска у готовых современных TCXO.

Вы господин радиолюбитель оставляйте право на теоретика за собой. И посмотрите типовое время запуска у чипа о котором говорится nRF24L01+ а не СС110х. Поскольку интересует окно с момента подачи питания. Где в даташите указано ожидание 100мс для указанного чипа,
затем еще плюс время до получения данных в регистрах проца. Поэтому работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс это при постоянном питании.

А работающее десятками тысяч изделие на CC110x - 1...2 ms от подъема опорника из powerdown (с остановленным генератором и субмикроамперным потреблением). С приемом пакета данных (и передача в 1-ms таймслоте с такого же порядка временем пробуждения).

Что до nRF24L01 - у него указано до 1.5 ms max из powerdown, поэтому к чему рассуждение о постоянном питании ? Он тоже меньше 1 uA жрет в этом режиме и ключевать питание необходимости нет.

Господин нерадиолюбитель и нетеоретик, не затруднитесь привести выдержку из даташита на nRF24L01+ откуда Вы взяли эти 100мс?
И посчитать время загрузки стандартного максимального пакета в 32байта на SCLK ==10МГц сами сможете или калькулятором пользоваться научить?
Да и речь вообще-то шла о выходе чипа из сна в режим приёма, для которого никакая загрузка данных не нужна, а нужно лишь чтение слова состояния в конце интервала бодрствования.

Господин нерадиолюбитель и нетеоретик, не затруднитесь прочесть требование ТС? Откуда следует, что устройство нужно выключать а не уводить в слип. И кому кроме вас нужно только чтение слова без подтверждения? Да никому. И покажите работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс

Вы о чём????

Вы сами то поняли что написали? Подтверждение чего? Чтения слова состояния чипа???
Вы вообще в курсе что такое nRF24L01+? Как он работает? Что у него внутри? О чём тут спорите.
Ещё раз - ответьте на вопросы поставленные выше. Откуда Вы берёте этот бред?

Ответьте на вопрос поставленный выше: откуда этот бред про длительность = ~7мс?

Значит так, с интернетом связь будет через комп который недалеко.
Устройство в кварире, но нельзя подключить к сети.
Дальность, ну.. 10 метров до компа. Устройство будет установлено стационарно.
Мне на квартиру ездить чем реже тем лучше.
Да, реал тайм похоже не получается.
Ну можно сделать запрос и ответ СМСом, наверное.
В принципе, 10 секунд окно и опрос думаю допустимо.
То бишь nRF24L01+ или ESP8266.
Спасибо.

Если устройство стационарное, то питание какое? Если батарейка и нужна экономия то nRF24L01+ будет кушать около 1микроампера постоянно и около 13ма в период передачи/подтверждения. Причем к nRF24L01+ нужен проц, например STM8Lxx или аналогичный. И другой комплект около компа. А если хочется в комп по USB подключатся, то желателен проц и поддержкой USB например от тех же STM32F103/107 или аналогичный. Этот старенький трансиверок nRF24L01+ хорош для клав, мышек и тп устройств к компу. Его архитектура и поток данных удобно ориентированы на последующую передачу через USB но нужен проц для обслуги и прога.

ESP8266 этот модуль скорее всего подразумевали, не сам чип. Может и хорош, но проблем с ним поболее, в плане написания софта и получения стабильной долговременной работы. Было выпущено китайцами более 10 ревизий, и тут при покупке желательно не нарваться на старые глючные. Внутри у него есть свой шустрый проц и возможность написать свою прогу по обслуге периферии и выдать через Wi-Fi. Тогда на стороне компа ничего не потребуется, если он поддерживает Wi-Fi. Минус это большое потребление этого модуля. На смену этому модулю выпущены уже модули на чипе ESP32, работают намного стабильнее, лучше их использовать.

Батарейное устройство (СЛЭЙВ) содержит МК(малопотребляющий) + nRF24L01+.
Опрашивающее устройство (МАСТЕР), имеет постоянное питание и постоянное соединение (с сетью или компом). Варианты либо 1 либо 2:
1. Простое устройство, втыкаемое в комп по RS232 или USB. Оно имеет МК+nRF24L01+. На компе - Ваша прога, которая через МАСТЕР опрашивает СЛЭЙВ.
2. (я так делал в своём проекте): Более сложное устройство, содержит МК+nRF24L01+. Также имеет ETHERNET-интерфейс и TCP стек. Втыкается в любой роутер без компа. Опрашивает СЛЭЙВ по командам (в моём случае в МАСТЕР-е я реализовал почтовый клиент SMTP/POP3; можно сделать любой другой способ опроса как удобнее).

Алгоритм опроса в обоих случаях одинаковый - я приводил его выше. В СЛЭЙВе и МК и nRF24L01+ большую часть времени спят.
МАСТЕР, когда ему нужно опросить СЛЭЙВ, периодически передаёт в эфир запрос (у меня период ==3мс), в течение времени не более таймаута (у меня ==1мин).
Когда СЛЭЙВ в очередной раз просыпается (у меня - каждые 20сек) и включает приёмник на время окна приёма (у меня ==7мс) в это окно приёма если сейчас идёт передача от МАСТЕРа гарантированно попадает один из запросов. В конце окна СЛЭЙВ смотрит статус приёма - если принято валидное сообщение - переходит в состояние обмена, если нет - засыпает опять на 20сек.
В состоянии обмена СЛЭЙВ отвечает мастеру ГОТОВ К ОБМЕНУ, увеличивает окно приёма (у меня - до десятков мс (в зависимости от типа запроса МАСТЕРА)) и ждёт очередной команды.
Ну и дальше собственно - работа в режиме запрос-ответ. Если в очередном окне приёма не было получено данных (таймаут обмена) СЛЭЙВ прерывает состояние обмена и уходит в состояние сна на 20 сек.
Примерно так. МК на СЛЭЙВе у меня был - MSP430FR5739.

Если расположение устройства, относительно компа, позволяет связываться по ИК - то можно скомбинировать. ESP8266 спит, а по ИК ожидается импульс пробуждения от компа. ИК вызов пришёл, ESP-шку разбудили, по инету связались. А потом пусть дальше спит, хоть месяцами, и без "окон".

А ИК-приёмник у Вас сколько будет потреблять?

Ну, питание ИК-приемника тоже можно ключевать. Но ТС нужно десять метров, такое оптикой не получится (если только это не спортзал). В квартире и 2.4 гига на таком расстоянии могут споткнуться (тем более что диапазон забит). В особо неблагоприятных случаях даже и 433 MHz не пробивает (с десятком mW).

Интегральный ИК-приёмник, рассчитанный на определённую частоту ИК-импульсов, типа TSOP4ххх - кушает 0.7mA в покое (по даташиту).
Но если не задаваться целью искать несущую ИК-частоту, а просто ожидать 1-2 импульса "побудки", то можно собрать схему из ИК-фотодиода и микропотребляющего усилителя, и вероятно в десяток микроампер уложиться.

Посмотрите реализацию у Ti EZ430 Chronos Watch / datalogger (красивый апнот - наручные часы на CC430XXXX)
Есть радиоинтерфейс и кушают очень мало, - по определению.
Со стороны PC можно использовать аналогичный чип с выходом на USART - COM порт PC - далее кудаугодно.

ИК приемники очень долго просыпаются.

Глянул даташит на TSOP18xx от Vishay - 200 us. Это даже меньше, чем нужно, например, CC110x до начала приема. Но оптика подразумевает либо прямую видимость, или хотя бы достаточно хорошее переотражение от стен. С прямой-то видимостью приемник можно сделать и с нулевым потреблением...