Ищу разработчиков для работы в команде над новым проектом.

[CHERTS]

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

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

 

[aliaksei]

Ну если ума хватает ставить esp на столь ответственную железку и не контролировать размеры принятого, то хай ддосят, не жалко дураков ))

 

[Maxim Zhuravlev]

А зачем JSON? Мне кажется что для домашней автоматизации куда лучше UDP, быстрый, легко реализуемый. Какая разница что будет по вашему запросу генерить CGI скрипт на сервере? При необходимости проконтролировать выполнение, всегда можно реализовать контроль. А по поводу ddosa, wi-fi как раз этим и хорош, что для обеспечения безопасности можно использовать средства стандартные для развертывания сети, которые работают на сетевом оборудовании, а не маленьких экономичных модулях. Выделяешь все модули в отдельный vlan и никто к ним не попадет, особенно, если они за файрволом на роутере.

 

[pvvx]

Ну если ума хватает ставить esp на столь ответственную железку и не контролировать размеры принятого, то хай ддосят, не жалко дураков ))

Как можно DDOS-ить порт Modbus TCP?
А вот пример DDOS Web-сервера на ESP8266 - 228 динамических выданных файлов XML в секунду (4 ms на файл, к сотне одновременно открытых TCP в секунду) и ему всё равно. Ничего не падает и ресурсов ещё море...

Пример: LOGO! 8 – новое поколение логических модулей от Siemens - Встроенный Web сервер поддерживает парольный доступ с обычных и планшетных компьютеров, а также мобильных телефонов с ОС Android.
Но WiFi нет.

А зачем JSON? Мне кажется что для домашней автоматизации куда лучше UDP, быстрый, легко реализуемый.

UDP не катит, т.к. с ним не работает javascript. Это накладывает ограничения в используемом ПО на панели оператора, чем является любое устройство с экраном и WiFi. При TCP и WEB никакого спец ПО ставить на железку не требуется. Всё грузится с самого модуля через стандартный HTTP на время сеанса. Так-же и интерактивное задание малых функций ПЛК для модуля ESP8266 c предварительной компиляцией осуществляется на javascript + swf и т.д. на внешней железке (телефоне с WiFi или планшете). Стандартом передачи данных для этой чехарды является HTTP и XML. И ни каких JSON. Данный проект уже почти реализован, но он имеет атрибуты как "коммерческий", по причине узкой специализации под решение необходимых задач. Т.е. не является открытым, т.к. несет в себе не связанное с ПО и ESP8266, а технологии используемые для управления этой системой спец.пром.установки.
Причина использования именно дешевого модуля в том, что он ставится для настройки/калибровки и диагностики, т.е. не выполняет основных функций установки. Иначе необходимо "сервисникам" таскать для каждого оборудования спец. блоки стыковки с разным ПО и конфигами. А человеческий фактор (забыл, не то взял на объект) тут имеет большое значение и возникает возможность и у эксплуатационщика иметь доступ к неким подстройкам не прибегая к вызову спец. обученных людей со спец.оборудованием. Т.е. выходит дешево и сердито.

 

[Maxim Zhuravlev]

Согласен, в описанном вами сценарии платформо-независимость важный плюс, но если мы говорим про автоматизацию здания, то присутствует несколько неспецефичных для промышленных решений задач и сценариев использования. Если вкратце, то во первых датчики, пользователю как раз не нужен к ним интерфейс, но зато нужна возможность оповестить весь сегмент сети о событии (сработал датчик присутствия, пользователь включил световую сцену, открыто окно ets) в этом случае очень удобно использовать широковещание. Я не специалист по сетям, но на сколько я понимаю средствами tcp это так просто не реализуется, нужно для каждого устройства создавать канал.
Во вторых html достаточно затратен по объёму передаваемой информации, если датаграмма от датчика будет иметь объём 10-20байт максимум, то http на порядок больше.
Ну а бремя общения с пользователем можно переложить на отдельный web-сервер в том числе и на esp, который по запросу будет собирать всю необходимую информацию и отдавать её пользователю, и в оратном направлении тоже.

 

[pvvx]

но если мы говорим про автоматизацию здания,

то WiFi в таких случаях не используют. Исключения если там 1-2 датчика на 500 м2.

 

[Maxim Zhuravlev]

Сейчас да, но по моему мнению это как раз и есть путь для развития.

 

[pvvx]

Сейчас да, но по моему мнению это как раз и есть путь для развития.

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

 

[Maxim Zhuravlev]

А что за проблемы с мощностью? В конце концов, можно сделать отдельную сеть для сенсоров и активаторов. На отдельном канале, и пусть они его делят, скорость им не нужна.