Вопрос Один хост и три ведомых устройства, получающие данные с него

[Maka]

Пишу в раздел для новичков, потому что запутался совсем. Прежде чем задавать вопрос читал усердно, но вопросов только больше становится.
Есть такая задача: нужно с главной esp8266 (хост), получающей данные от устройства по протоколу DMX512 передать данные на три esp8266 (ведомые). На каждую из трех свои. С DMX я вроде разобрался, а с топологией сервер - клиент вошел в ступор.
Должен ли хост быть точкой доступа или ведомые должны быть тремя разными AP? Должен ли хост быть сервером, или как то по другому? Как в общих чертах должна выглядеть иерархия? Причем нужно еще иметь возможность зайти на хост с устройства с браузером для настройки. Помогите пожалуйста пока с общей идеологией.

 

[Maka]

Мне видится так - хост является AР и сервером с четырьмя страницами (это я могу), одна для настройки с мобильника/планшета/ноутбука, а три остальных для трех слейвов, получающих с них (как то?) то что им причитается. Задайте направление пожалуйста.
В arduino IDE пишу, если что.

 

[nikolz]

Мне видится так - хост является AР и сервером с четырьмя страницами (это я могу), одна для настройки с мобильника/планшета/ноутбука, а три остальных для трех слейвов, получающих с них (как то?) то что им причитается. Задайте направление пожалуйста.
В arduino IDE пишу, если что.

Ваши вопросы относятся к общеобразовательным вопросом по организации беспроводных сетей
Поэтому надо читать в инете про сети а не форум по ESP.
посмотрите в интете ответы на вопросы
1) что такое сервер
2) что такое клиент
3) что такое точка доступа (AP)
4) что такое WiFi
5) основы организации сетей
6) основы организации беспроводных сетей
потом задайте вопрос о том, что конкретно вам не ясно по ESP.

 

[Maka]

Ваши вопросы относятся к общеобразовательным вопросом по организации беспроводных сетей
Поэтому надо читать в инете про сети а не форум по ESP.
посмотрите в интете ответы на вопросы
1) что такое сервер
2) что такое клиент
3) что такое точка доступа (AP)
4) что такое WiFi
5) основы организации сетей
6) основы организации беспроводных сетей
потом задайте вопрос о том, что конкретно вам не ясно по ESP.

Спасибо за мегасодержательный ответ. На arduino.ru для дураков есть раздел с основными функциями, общей схемотехникой и т.д. На этом сайте есть такое? Я с налёту не нашёл. В ИДЕ примеров много, но комментировано очень мало. Блин, я за 2 месяца на ардуине начал писать, до этого о си ничего не зная. А тут... Ну не понятно мне чем в примерах WIFIserwer отличается от WEBserwer когда нужен первый, а когда второй. Похоже придется на nrf24l01 все организовать, так проще.

 

[Юрий Ботов]

Для начала поймите главное: сервер это тот кто посылает данные ТОЛЬКО по запросу клиента. Он не может послать данные просто когда ему захочется (ну данные на нем обновились), сначала он должен получить запрос от клиента. Исходя из этого и выбирается топология. Если есть "хост" и на нем часто меняются данные, и на эти изменения нужно немедленно реагировать - делайте его клиентом и расслылайте данные на сервера. Если быстрая реакция не требуется - делайте "хоста" сервером, и организуйте у клиентов периодический запрос данных с сервера, только не переусердствуйте с частотой опроса - esp не справится с тремя одновременными запросами - это вам не компьютер

 

[Maka]

Для начала поймите главное: сервер это тот кто посылает данные ТОЛЬКО по запросу клиента. Он не может послать данные просто когда ему захочется (ну данные на нем обновились), сначала он должен получить запрос от клиента. Исходя из этого и выбирается топология. Если есть "хост" и на нем часто меняются данные, и на эти изменения нужно немедленно реагировать - делайте его клиентом и расслылайте данные на сервера. Если быстрая реакция не требуется - делайте "хоста" сервером, и организуйте у клиентов периодический запрос данных с сервера, только не переусердствуйте с частотой опроса - esp не справится с тремя одновременными запросами - это вам не компьютер

Спасибо вам за ответ!
Ага! Реагировать нужно немедленно. Значит хост должен быть АР, на нем клиент, отсылающий запросы на три сервера если данные изменились, а те по запросу забирают данные. Как то так?

 

[Юрий Ботов]

почти: хост AP и на нем клиент, и три подключающихся к AP сервера. Как только на хосте изменились данные, клиент на хосте по очереди рассылает данные на три сервера (разумеется надо контролировать подключены ли сервера к AP).

 

[Maka]

почти: хост AP и на нем клиент, и три подключающихся к AP сервера. Как только на хосте изменились данные, клиент на хосте по очереди рассылает данные на три сервера (разумеется надо контролировать подключены ли сервера к AP).

Может туманно сформулирую вопрос... Насколько я понял, общение сервер-клиент можно реализовать по tcp и по http (могу ошибаться), http это для браузера и картинок, а по tcp можно слать сырые данные, любого типа. Что предпочтительней для моего случая, если мне нужно передать int? Если я буду использовать tcp протокол, смогу ли я на "хосте" организовать еще страничку настроек для доступа с мобильника/планшета/ноутбука. Не будет ли конфликта между веб-клиентом и tcp-клиентом? Библиотеки то разные и клиенты разного типа.
Я может ересь пишу, но от гугла уже устал, тем более, чтобы правильно задать вопрос нужно знать большую часть ответа.

 

[Сергей_Ф]

@Maka а ещё есть udp
И можно слать сразу всем в сети, а не по очереди.
Конфликта не будет, если все сделать правильно.

 

[Maka]

@Maka а ещё есть udp
И можно слать сразу всем в сети, а не по очереди.
Конфликта не будет, если все сделать правильно.

А правильно это при включении запускать веб-клиента ,скажем на минуту, если никто не открыл страницу настроек используем данные из еепром и переходим в режим tcp? Нет, плохо, нужно ждать минуту даже если хочешь начать работу на старых настройках. Значит нужна кнопка, нажав на которую переводим "хост" в режим настройки. Или проще и круче можно?

 

[Юрий Ботов]

А правильно это при включении запускать веб-клиента ,скажем на минуту, если никто не открыл страницу настроек используем данные из еепром и переходим в режим tcp? Нет, плохо, нужно ждать минуту даже если хочешь начать работу на старых настройках. Значит нужна кнопка, нажав на которую переводим "хост" в режим настройки. Или проще и круче можно?

Извини - бред.
Сервер (настройки) - сам по себе, клиент - сам по себе. Блокировка при записи только на время записи в EEPROM, а если по уму то никто не мешает держать кэш в памяти... И - да HTTP - это просто разновидность TCP. (ну если быть совсем точным, то HTTP работает "поверх" TCP).

 

[Maka]

Извини - бред.
Сервер (настройки) - сам по себе, клиент - сам по себе. Блокировка при записи только на время записи в EEPROM, а если по уму то никто не мешает держать кэш в памяти... И - да HTTP - это просто разновидность TCP. (ну если быть совсем точным, то HTTP работает "поверх" TCP).

Тут другое, я плохо описал... Настройки сети, я думаю, в этом проекте менять не понадобится (защита от дурака), я имел в виду адрес "хоста" в сети DMX, в интервале 1 - 512. Эту возможность предоставить пользователю необходимо. По уму нужен dip переключатель для задания адреса , как всегда и делается в такого рода устройствах, но это девять пинов коту под хвост, есть ли столько на esp8266.

 

[Юрий Ботов]

Если позарез нужен именно DIP switch - я бы прицепил к свичу копеечный stm8s103f3p66 и написал бы на нем слэйв i2c (это 20 строчек). И по i2c подвесил бы это к esp. Но можно и просто поднять на esp конфигурационный web сервер (никто не запрещает поднять два сервера на разных портах на одной esp), и позволить пользователю менять в нем адрес dmx...

 

[valerivp]

не стоит смешивать в кучу топологию WiFi сети (станции- STA и точки доступа AP) и TCP (клиент / сервер).

По задаче:

Простая схема - ведомые это сервера. Ведущий - клиент. Когда надо - клиент посылает данные.
Особенность клиента - он должен знать адрес, куда посылать данные. Лично мне эта схема не нравится.

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

Таким образом, я бы сделал:
вариант 1:
Ведомые - это клиенты. Общение с сервером по Websocket (это очень просто). Клиент знает адрес сервера, открывает канал, сервер шлет данные когда надо.

Вариант 2:
Ведомые - это подписчики MQTT-UDP. Эта модификация протокола удобна тем, что ориентирована на широковещательную рассылку, настроек не надо, если все в одной подсети.

Настройка ведомых:
В любом случае необходим web интерфейс для указания параметров wifi.
Таким образом адрес DMX так же можно в web-интерфейсе.
Лично я делаю включение режима AP по нажатию кнопки на девайсе - потом можно подключаться и все настраивать. После настройки - рестарт и точка доступа выключается, чтоб глаза не мозолить.

 

[Maka]

Ну вот как все закрутилось... Наверно нужно полностью озвучить тз. "Хост" подключен к пульту DMX и должен иметь возможность настройки на свой DMX адрес от 1 до 512. При включении должен сразу начать работу на первом адресе (если не настроен) или прочитать из памяти прошлую настройку DMX. По видимому нужно настройку DMX проводить по веб-интерфейсу. Предположим, у "хоста" DMX-адрес 10, значит ведомый №1 получает данные канала 10, №2 - 11, №3 - 12. Нумерация ведомых постоянна, первый ведомый должен получать всегда данные самого младшего канала, и дальше по возрастанию. Настроек сети не должно быть вообще, все прописано жестко и без прошивки не изменяемо.

Простая схема - ведомые это сервера. Ведущий - клиент. Когда надо - клиент посылает данные.
Особенность клиента - он должен знать адрес, куда посылать данные. Лично мне эта схема не нравится.

А мне так вполне нравится. Адрес это идентификатор ведомых, это необходимо.

вариант 1:
Ведомые - это клиенты. Общение с сервером по Websocket (это очень просто). Клиент знает адрес сервера, открывает канал, сервер шлет данные когда надо.

И это тоже подходит вроде.

 

[Maka]

Я тут почему флужу так долго, железа нет пока, есть только одна есп для опытов. Когда наступит час Х я должен знать что и как, или вообще на ардуине и нрф все делать. С ними понятно все, проблема в интерфейсе "хоста" - нужен экран, кнопки, энкодер. Вот и думай - либо просто но много пайки (ардуино) или сложно (для меня) и красиво на одной плате ESP.

 

[valerivp]

"Хост" подключен к пульту DMX и должен иметь возможность настройки на свой DMX адрес ...

ничего не понял

Замечание - "мне схема НЕ нравится" = "крайне НЕ рекомендую"

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

 

[Maka]

ничего не понял

Смотрите: в протоколе DMX512 каждому устройству на проводе должен быть присвоен свой адрес. Он выставляется на самом приборе. Пульт просто транслирует в сеть пакет с данными о всех 512 каналах. Устройство (диммер, динамический прибор, дыммашина) сидит и слушает только свой канал. И реагирует на изменения. У устройства может быть диапазон адресов, у сложных приборов 30 и больше. У моего "прибора" три канала. По этому на приборе устанавливается стартовый адрес, и он ловит изменения только своих каналов, в моем случае - стартовый адрес + 2. Я не передаю в эфир весь поток, я отлавливаю "свои" каналы и шлю "ведомым".

 

[valerivp]

Смотрите: в протоколе DMX512 каждому устройству на проводе должен быть присвоен свой адрес. Он выставляется на самом приборе. Пульт просто транслирует в сеть пакет с данными о всех 512 каналах. Устройство (диммер, динамический прибор, дыммашина) сидит и слушает только свой канал. И реагирует на изменения. У устройства может быть диапазон адресов, у сложных приборов 30 и больше. У моего "прибора" три канала. По этому на приборе устанавливается стартовый адрес, и он ловит изменения только своих каналов, в моем случае - стартовый адрес + 2.

тогда еще проще
надо забыть про диапазоны.
ESP цепляется к девайсу, считывает все его адреса. Другим концом цепляется к WiFi и для каждого адреса DMX ставит подписку на топик MQTT-UDP (вида ESP_ID_123456/DMX_78).
Ведущий пуляет в эфир данные, все ведомые их ловят и реагируют. Сколько ведомых и сколько на каждом из них адресов - становится не важно.

 

[Maka]

Другим концом цепляется к WiFi

А может как то без сторонней точки доступа? Сам "хост" может быть АР? Нужно минимизировать этап настроек. Типа подключил и работает, только на"хосте" при желании поменять старт-адрес. Пользователи разного уровня бывают, да и время инсталляции немаловажно.