Arduino.ru

Вопрос в следующем - дайте ссылки на примеры если такое реализуемо.. где покчерпать информации.

Имется ввиду одна ESP и к ней подключаются напрямую без роутера остальные ESP ? Тут будет облом - к одной ESP максиум подключений возможно не более 4, а никак 10.

Если знаний по программированию маловато, то можно воспользоваться готовым проектом https://wifi-iot.com/ , где реализован опрос одной ESP других ESP.

Немного переформулирую. 

Есть ESP8266 и несколько других с датчиками и т.п.

Одна работает как вебсервер и наверное как  AP (на ней микроCD с HTML) и она должна опрашивать другие которые типа модулей (соответственно отвечать)

Будет ли главная подключаться к маршрутизатору например(для вывода в голобульную сеть) незнаю.

Просто какие существуют варианты - нигде нет нормальных описаний... А изучать все библиотеки и т.п. как то многовато.

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

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

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

Теоретически - можно, но есть нюансы:

1. На одной ESP надо поднимать AP;

2. ESP-клиенты должны знать, куда коннектится;

3. Кол-во слотов для коннекта - 4 максимум, надо на клиентах разруливать ситуацию с неудачным коннектом;

То есть алгоритмически всё как бы просто: ESP-клиент коннектится к ESP-серверу, и инициирует обмен инфой. ESP-сервер делает, что надо. Различать, запросили из браузера или с другого ESP - да тупо по виду запроса.

Если же нужна полноценная самонастраивающаяся сеть - это вопрос намного сложнее, но тоже реализуем: сканирование сети, попытка коннекта и обмена информацией, при успешнмо коннекте - поддержание локального пула адресов в сети, при обмене информацией - обмен новыми адресами в сети. P2P, в общем, вполне реализуемо, только секса много.

А если реализовать задачу в обратном направлении: на ESP с датчиками будет поднят АР, а сервер будет подключаться поочередно к каждому и запрашивать данные. Если подключение неудачно, то датчик в ауте. Будут правда большие проблемы с эфиром :), но зато нет ограничения на количество подключений. Так же и на внешний коннект проще будет перейти - просто указал нужный АР и передал данные.

Не рассматривал. Но скажу проще - вайфай так забит что связь с  маршрутизатором не ахти... А если я добавлю кучу сетей...)))

Вот и смотрю все варианты. Уже подумываю одну задачу снять - заменить езенрет шилдом (тоесть что главная будет с шилдом и он уже будет вещать в интернет..)

Тоесть оставить только одну точку и к ней пусть конектятся модули.. А вот как их различать и опрашивать по очереди???

Что значит - как? Вариантов - вагон и тележка. Раз мы решили, что модули сами будут коннектиться к точку доступа, в роли которой также выступает ESP, то:

1. При успешном коннекте модуля к AP он отсылает пакет со своим идентификатором, если идентификатора не выдано - то вместо него строка с нулями, например;

2. AP смотрит - есть идентификатор? Нет - выдаём, запоминаем у себя. Есть - проверяем, есть ли он у нас? Если нет - запоминаем у себя. В обратку клиенту выдаём пакет с ответом, содержащим идентификатор;

3. Клиент сохраняет идентификатор у себя.

Т.е. любой сеанс связи начинается с обмена пакетами идентификаторов. А опрашивать по очереди, если мы говорим в терминах "одна AP - много клиентов" - не совсем правильно: клиенты сами коннектятся к AP, когда надо. И должны сами разруливать невозможность соединения (например, когда все 4 слота AP сейчас заняты).

Или я опять чего не понял в постановке вопроса?

Насчет вагон и тележка -вот и попробуй найти иголку в стоге...

А вот - "Т.е. любой сеанс связи начинается с обмена пакетами идентификаторов. А опрашивать по очереди, если мы говорим в терминах "одна AP - много клиентов" - не совсем правильно: клиенты сами коннектятся к AP, когда надо. И должны сами разруливать невозможность соединения (например, когда все 4 слота AP сейчас заняты)."

Вот это и надо походу!

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

Ещеб найти как езернет к есп прилепить, вообще былоб всё самое то.

Ладно буду разбираться потихоньку.

Ещё вспомнилось, что можно на UDP попробовать построить общение, в принципе ;) Там проще, без подтверждения доставки, броадкастовый адрес в сети есть всегда - туда и срать пакетами ;)

Это однозначно не пойдет - даже не рассматриваю - необходима полноценная двусторонняя связь.

Можно на сервере сделать планировщик подключений и при соединении датчика указывать через какое время ему подключиться в следующий раз. В этом случае будет проще разруливать проблему с 4 соединениями и перегрузкой сервера. При первом подключении сервер разрулит датчики, а дальше уже пойдет штатный режим работы. Интервалы подключений соответственно надо будет подбирать в зависимости от возможностей. Если какой-то датчик вовремя не вышел на связь значит он неисправен - сразу и ловля будет алармов.

не правильная постановка задачи.

1. все есп должны подключаться все к роутеру.

2. если хочешь опросить все еспишки главной то нужно послать броадкаст пакет,

2.1 не зная айпи пакет полчат все есп.

2.2. что бы не засорять эфир одновременными ответами есп нужно в броадкаст пакет посылать имя еспишки которая должна ответить

нечто вроде zal getdata.
2.3 еспишка получив броадкаст пакет по заголовку понимает нужно ли ей отвечать на пакет UDP. имя указывается непосредственно в прошивке.

2.4 еспишка отвечает на запрос - главная еспишка собирает данные.

Чтобы все есп подключить к роутеру надо не любой роутер уже. Вдруг у него будет 100-1000 датчиков. У большинства роутеров тоже есть ограничение на количество одновременных подключений.

все остальное это уже детали.

вариантов тут нет - у любого роутера по любому чип будет лучше

я такую схему реализовывал. только опрашивал я не с еспишки все другие а с телефона - я на телефоне выводил данные с разных espшек на одном экране. все работает очень быстро

Я передал смысл. В любом случае всё плохо.

И есп не годится... тоесть для опросов возможно, но придется идти дальше...

Вебсервер на есп работает даже медленнее чем с w5100 и enc...

Так что пойду разбираться с A10, так как нет ни одной распбери под рукой..

Хочется полноценный миниатюрный многопользовательский сервер (отвечать будет в виде JSON, но данных немало) - и при этом чтобы он был дешевый.

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

Ссылка http://arduino.ru/forum/apparatnye-voprosy/kak-proshit-devboard

Купите роутер TP-LINK и прошейте на него openWRT. На роутере - веб-сервер, бд, все дела, шоколад. А к нему уже - обращайтесь с ESP, гоняя туда/сюда мелкие пакеты данных.

Это как вариант, конечно.

С линуксом не дружу совсем. А про опенврт уже наслышан. (пытался даже поставить на длинк старенький - не пошло чтото, кстати роутер так и лежит без дела)

Я так вот прикинул схему:

Есть одна есп - она как точка доступа к ней цепляется куча других слейвов типа. ну и главная их спокойно неспеша опрашивает и собирает огромные массивы данных (места хватает, не то что в ардуинках).

Отдельный версервер (тему вторую создал - там как раз с линуксом придется разбираться, на нем будет и вебморда и если запрос с приложения то ответ JSON) - ну и этот сервер посредством либо UART либо по радиоканалу опрашивает ту самую точку на есп и забирает огромный массив.

Тоесть все распределено на два блока: Веб сервер и контроллер для опроса еспешек в сети.

Есть ссылки на примеры опроса клиентов вайфай в сети  посмотреть варианты реализаций?

*Писал уже выше что как вебсервер есп медленная до ужаса, ну а как в варианте точки вечером буду пробовать.(если ссылки дадите - сам конечно поищу, но найду ли что нужно!?)

А вот ХЕЗ, честно скажу. Но сам я сделал именно так, как описывал: пока вебморда крутится на ноуте, потом перетащу её на openWRT и роутер, и через n времени опрашивает ESP, которая подключена к контроллеру теплицы. На вебморде по факту хранятся полученный данные, строятся графики, настраивается сам контроллер, короче - удобняк.

В принципе, при таком подходе не надо даже держать промежуточную ESP - достаточно в вебморду вбить адреса всех ESP в сети (ну или сканер какой присобачить), поставить скрипт в cron и дёргать со всех данные, когда надо.

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

и по юарт подключается - есп она маленькая прилепил ее поверх... всё.

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

а опрос и т.п. остается прежний.

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

Кто-нибудь может мне объяснить, как можно поднять и настроить хоть какой-нибудь сервер, в свете вышеотквоченного?

Это скорость чего???

Я так подозреваю Serial - он мне не нужен.

https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80

Иди делай уроки. без тебя забот хватает.

Я вопрос задал и хамить мне не нужно.

Ты первый начал и нажил себе...

Почитай тему про нрф-ки и если не только буквы прочтешь но и смысл поймешь и найдешь истину!!!

(можешь посмотреть другие любые темы - ты один выделился, я бы написал в личку - но таковой нет тут)

Не осталось программы для примера?? Это тоже подошлоб.

В конечном варианте писал как хотел --- и то что там будет приложение андроид (можно выводить например данные с разных еспшек на разных экранах например)

p.masyukov -

вот мое приложение в плей маркете.но это только инструментарий. https://play.google.com/store/apps/details?id=com.embarcadero.PanelControlToolKit

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

если надо сбросить настройки замыкаем рх и тх на старте.... так сделал что бы не выпаявать мк из схемы - ну например ты к rx и tx подключил еще и arduino nano к rx tx . ну и ноги не трогаются другие . удобно.

так мы подготовили к работе

далее

тут есть 2 варианта. 1- как я уже писал просто через броадкаст слать общий пакет конкретному девайсу. тут айпи не нужны. второй варинт - обращаться по ip через протокол http. грубо говоря браузер. но тогда надо в роутере указать что ip никогда не должны меняться. это есть во всех роутерах.

ну далее после  того как определился как тебе лучше.. просто пишем приложение на андройде которое опрашивает. тут тоже очень просто. лично я предпочитаю http. просто много запросов делаю паралельно на разные ip espишек и сразу со всех получаю данных. с броадкастом примерно тоже самое но там надо парсить все ответы как бы в куче.   с браузера http тестить удобно . и через интернет можно обращаться к esp за роутером.

Какая прелесть! Запоминаем.

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

Я прекрасно представляю, что вы можете написать. Можете считать, что даже написали, а я не ответил, если от осознания этого факта вам станет легче.

+++ посмотрю. но все же тут уже не будет вебсервера, придется его рядом строить... 

Обмозгую, надо всю инфу как то переварить.

веб сервер в каждой еспишке. простенькой. подключаем датчик прямо к еспишке если получается. если не получается к еспишке - то еспику соединяем с ардуиной нано через rx и tx . аппаратные порты. лишь они обеспечат должную скорость обмена. при этом после сборки нельзя будет прошить ардуинку нано без разрыва ног.

веб сервер еспишки будет показывать примерно вот так

https://new.vk.com/photo46345751_417650273?rev=1

Не хотите с себя начать?

Я вам совершенно конкретно сказал, что купленые вами модули к NRF24L01 не имеют никакого отношения. Что вас там смутило?

Модули с кляксой вместо чипа не совместимы с оригинальным нордиком и близкими клонами.

Так и надо было писать!!! И не было бы споров.

С датчиками (еспешками) как раз проблем уже меньше всего - на них будут примитивы -- тоесть включить|выключить  реле, светодиод, мосфет и т.п. - ну и кнопок пару напрмиер для смену глоб.переменных, чтобы при опросе они отдавали правильное состояние..

мой вк. https://new.vk.com/ehomesmart

 м.б. кто будет читать эту тему и будет полезно. 

могу оказать определенные услуги....... на эту теу

Так я вам и написал, что это не NRF24L01, а "вольная фантазия дядюшки Ляо на тему "Если бы я был фирмой Nordic Semiconductor".

Что вы мне на это ответили? Вы понесли полную пургу с голословными обвинениями меня в полной некомпетентности. Я что-ли виноват, что вы простое предложение прочитать не можете?