Ищу сообщника, надо придумать и сделать WEB интерфейс

[valerivp]

В общем создал я поделие. WEB сервер на ESP8266. Аналог Arduino Mega Server и WEB свалке от pvvx.

Текущий статус 80% от первой беты, сейчас в общий доступ ничего не положу, т.к. товар надо показать лицом, а красивого лица нету
Ищу сообщника который поможет сделать красивый понятный функциональный интерфейс для демонстрации возможностей решения. На данный момент проект предполагается сделать свободным, потому никаких денег не предлагаю. Сообщник получит необходимые исходники и пояснения. Найдутся желающие - велком в ветку и в личку.

Мое решение я создаю как интерфейс для системы управления теплым полом, т.е. это полтора десятка различных датчиков (температуры воды - на 1wire, воздуха - китайские беспроводные от метеостанций, давления, ...) и набор реле (клапаны, насосы, котел, ...). Цель текущего проекта сделать именно интерфейс, без привязки логики к коду системы. Датчики распределены в пространстве. Т.о. есть необходимость связи нескольких систем в одну посредством беспроводных средств. Т.е. датчики будут на одной ESP, а WEB сервер - на другой.

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

Описание существующего функционала и планы, отличия от аналогов:

Я анализировал два решения - они в начале топика.
AMS мне не понравилось структурой и малой функциональностью.
Свалка - да простит меня автор, мое мнение субъективно - она и есть свалка. Ничего не понятно, кроме того что это круто. Необходимо использовать Эклипс, иначе собрать эту свалку не возможно. Да и функционал хромает.

Что сделал я:
Проект разрабатывается в Visual Micro, весь проект - набор нескольких проектов, в которых из одних исходников собирается именно то решение, которое требуется, с учетом нужного функционала. Используются стандартные библиотеки и классы ESP, никаких собственных стеков TCP и пр. - может и есть нестабильности в работе, зато все понятно. При желании, свалив все в один каталог можно скомпилировать в Aduino или в другой среде.
Сейчас параметры кода такие:
Program size: 312 831 bytes (used 30% of a 1 044 464 byte maximum) (12,41 secs)
Minimum Memory Usage: 44488 bytes (54% of a 81920 byte maximum)

Несколько ESP могут объединяться в систему. При этом каждая из ESP может быть как сервером датчиков, так и клиентом, или одновременно (сейчас не реализовано, только идея, а идея - 50% решения). При этом совершенно не важно куда именно подключен конкретный датчик. На каждой ESP из системы будут видны все датчики всех ESP. Датчики адресуются по именам. Соответствие имен датчиков и их ID указывается на той ESP, к которой они физически подключены. Состав показателей датчиков может быть произвольный. Обязательными показателями являются:

• ID - я решил, что все датчики будут иметь 16 битный ID, если физический длиннее - берем CRC16.
• Name,
• Type,
• Source - адрес ESP к которой подключен датчик
• TimeLabel - метка времени получения данных датчиков. Чтобы все хорошо работало, нужно чтобы время было синхронизировано на всех ESP.
• Остальной набор будет зависеть от типа датчика. Но все значения будут int32. Если надо дробные - использовать показатели с фиксированной запятой, например "temperatureX10"

Таким образом добавление и замена датчиков будет делом элементарным. WEB интерфейс и логический контролер адресуют датчик по имени (например "SensorInRoom1") и если датчик сгорит, надо просто назначить этому имени другой ID.
Так же будут виртуальные датчики, значения для которых будут задаваться в файле настроек. Это позволит простым образом унифицировать обращение к датчикам и настройкам на всех ESP в сети.

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

Реализован WEB сервер с минимальным набором встроенных сервисов. Не отключаемых сервисов на данный момент 3:

• Текущее время. Просто транслирует текущее время. Настройки синхронизации пока нет, сервер пока в коде написан. Но сейчас сервер умеет быть как клиентом NTP, так и сервером. Т.е. одна ESP (любая из сети) может смотреть в инет или иметь RTC, и раздавать время остальным.
• Настройки WiFi. Если ESP не настроена для подключения к роутеру, она переходит в режим точки доступа. Присутствует элементарный интерфейс для настройки подключения. Если хочется не элементарный, а с рюшками - надо просто реализовать htm страницу (если включена поддержка файловой системы) с красивой формой. А сервис для применения изменений уже есть. Встроенный интерфейс выглядит так: , а можно загрузить страницу, и будет несколько иначе:
• Встроенная справка по реализованным сервисам. Т.е. встроенная страница 404 содержит описание возможных сервисов с параметрами. Может быть заменена загрузкой страницы 404.htm (если включена поддержка файловой системы).

Все остальное может опционально:

• Поддержка файловой системы SPIFFS.
• Редактор файлов (интернет не требуется, ~100KB на FS). Будет в т.ч. использоваться для редактирования настроек, которые будут в файлах.
• Редактироваться настройки так же могут WEB интерфейсе (не реализовано). Хранение настроек - в файлах.
• Поддержка активного содержимого на стороне сервера. Да-да, сервер уже умеет исполнять скрипты. На данный момент он умеет исполнять их из файлов, файл запускается только из консоли COM. Скрипты могут выполняться в фоне. Запускаться автоматически при старте ESP. Т.о. ESP превращается в простой логический контролер. Скриптовый язык простой, но может расширяться функциями на С. Работа с пинами - в базе, работа с FS присутствует. Редактироваться скрипты могут средствами браузера и ESP.
• Сервер не умеет модифицировать файлы (ну кроме как скриптом), всякие метки, метаблоки и пр. не предусмотрены. Модификация страниц происходит на стороне клиента (AJAX) или скриптом.
• Поддерживаются web-сокеты.
• Поддерживаются датчики 1wire, набор датчиков на одной шине. Адреса в коде указывать не надо.
• Поддерживаюся китайские метеодатчики ( ), набор датчиков на одном приемнике.

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

Вот.
Написал тут много, а показать нечего. Рисовать не умею, дизайнер из меня хреновый. Навыки HTML базовые. С программированием Arduino / ESP знаком полгода (иногда бывает час-два в день или в неделю на это ). Как готовить Git - не знаю.
Я программирую на языке очень далеком от С, и текущий проект - хобби.
Кто хочет сделать интересную штуку - приглашаю к сотрудничеству.

 

[Victor]

Рисовать не умею, дизайнер из меня хреновый.

посмотрите какие интерфейсы для датчиков сделаны в ESPEasy Let's Control It
по дизайну - минимализм вполне удобен или возьмите какую-нибудь готовую админку Яндекс

 

[pvvx]

Наличие вопросов и желания иметь web на WiFi SoC постоянно возрастает, а имеющие реализации на ESP и особенно в Arduino для этого не годятся. На имеющихся WiFi SoC, из-за ограничения ресурсов стандартные методики и библиотеки не подходят. Все “писатели”, использующие стандартные подходы, находятся в режиме “ожидания” контроллеров с большими ресурсами и производительностью. Web-свалка на ESP8266 создавалась для демонстрации, что средней поршивости Web возможен при использовании ресурсов только одного дешевого WiFi SoC и свою миссию выполнила. В её составе нет ни одной стандартной либы от “сообщества” и используется только LwIP. Дальнейшая оптимизация не имеет смысла из-за других ограничений ESP8266 и может принести не более 10% каких-либо доп. плюшек. Применение SPIFFS убьет Web из-за его медлительности уже на среднем размере диска.

В пользовательском устройстве, созданном на Arduino, для создания одной странички “настроек” нет никакого смыслу в использовании Web-сервера. Там достаточно встроенного в C/C++ текста и обработки одного TCP соединения (через TCP socket), что уже откатано в Arduino у других писателей c примитивным парсингом переменных в GET и POST запросах. Более не имеет смысла по причинам не относящимся к web-серверу, а связанных с ограничениями в Arduino других функций и их производительности. Никакие “куки” или “мультидата” или одновременное открытие нескольких файлов и соединений там не требуются. Т.е. не требуется к 80% функциональности HTTP-WEB сервера. Чтобы перевести всю систему на оптимизированные либы потребуется работа не одного человека в течении многих месяцев. И смысла в ней нет – за это время появятся более навороченные WiFi SoC, способные переваривать уже имеющиеся стандартные либы и подходы. В итоге есть смысл оптимизации только того, что получит “окно” на время использования до выхода более крутых микросхем с той-же ценой. С ESP8266 это уже произошло и она является устаревшей – не имеющей смысла в дальнейших разработках. Этого вы не учитываете.
Пока производительность и ресурсы простейших WiFi-SoC дойдут до *nix, c Web уже стоит вопрос реализации совмещения с PHP или другими языками в одном флаконе – т.е. приближение к полноценному web-серверу, в понятиях *nix. На решение этих более перспективных вопросов и ушили все “программеры” и возвращаться к хилому и глючному ESP8266 они не будут. По этому вам остается только одна возможность – привлечение “союзников” за оплату, т.е. платных программистов.

Итог - мой выбор КГ/AM в опроснике

 

[valerivp]

Свой проект я делаю не как депонстрацию, а как универсальную систему, которую можно масштабировать горизонтально. Я не предполагаю использовать ESP как многопользовательский портал. Система строится для автономной работы, ну и доступ в инет - опционален. Я столкнулся с не возможностью иметь в ESP опрос гирлянды 1wire и web. Поэтому решил использовать сеть дешевых устройств для разделения нагрузки. Десяток ESP8266 стоят как одна ESP32.

 

[pvvx]

Свой проект я делаю не как депонстрацию, а как универсальную систему, которую можно масштабировать горизонтально. Я не предполагаю использовать ESP как многопользовательский портал. Система строится для автономной работы, ну и доступ в инет - опционален. Я столкнулся с не возможностью иметь в ESP опрос гирлянды 1wire и web. Поэтому решил использовать сеть дешевых устройств для разделения нагрузки. Десяток ESP8266 стоят как одна ESP32.

“Народное” направление стремиться к использованию языков типа Java. Осваивать CИ/С++ простому обывателю сложно. Тем более ресурсы новоиспеченных дешевых WiFi SoC уже почти готовы для этого. Цена на модуль с WiFi SoC с улучшенными характеристиками для автономной работы и имеющие более 1МБ RAM, плюс штатное подключение микро-SD для файловой системы на Гегобайты всего в 2 раза выше ESP8266 на сегодня.
Почему и указал на SPIFFS – он не является “стандартным и универсальным” решением. Его область применения (мелкие MCU с пару КБ RAM) давно пройдена. Так-же и у самой реализации моей Web-свалки. Она рассчитана и оптимизирована на устройства с объемом RAM в 0.1..1МБ. При больших ресурсах вступает в силу многозадачность – RTOS и там примененные в данном Web алгоритмы не являются оптимальными и следует использовать другой подход с тем-же LwIP. И так везде, со всеми техническими наработками и описанными у вас либами – они всегда устаревают и должны соответствовать аппаратной части.
Вы же ищите кто вам поможет. Но никто из изучающих и интересующихся на дому с каким-то уже имеющимся багажом знаний и бесплатно поддерживающих пользователей не будет брать устаревший WiFi-SoC для новых разработок. Это могут сделать столько те, у кого есть материальная заинтересованность в окучивании пользователей.

иногда бывает час-два в день или в неделю на это ). Как готовить Git - не знаю.
Я программирую на языке очень далеком от С, и текущий проект - хобби.

Вот этого и не хватит для успешной реализации в видимых временных рамках готового проекта по вашему описанию. К тому времени народ уйдет на другие WiFi-SoC, т.к. там будет больше и проще.

 

[valerivp]

Вы же ищите кто вам поможет

Мне не требуется помощь в разработке. Исключительно WEB интерфейс. Это то, что я не способен сделать сам, ну ни как. Ибо хочу красиво, а красиво делать HTML не умею.

Вот этого и не хватит для успешной реализации в видимых временных рамках готового проекта по вашему описанию.

Проект готов на 80%. По большому счету осталось сделать подсистему датчиков. Я знаю в деталях что и как надо сделать. Я оцениваю это часов в 8...10. Плюс остальные плюшки - еще столько же.

Осваивать CИ/С++ простому обывателю сложно.

Точно! Поэтому я решил, что лазить в код прошивки не нужно будет. Ну только если чтобы описать получение данных со своих специфичных датчиков.
Для кастомизации надо будет использовать скрипты (я использую bitlash).

И так везде, со всеми техническими наработками и описанными у вас либами – они всегда устаревают и должны соответствовать аппаратной части

Я использую стандартные библиотеки. Поэтому при появлении другого железа переход будет минимально трудоемок.

 

[pvvx]

Проект готов на 80%. По большому счету осталось сделать подсистему датчиков. Я знаю в деталях что и как надо сделать. Я оцениваю это часов в 8...10. Плюс остальные плюшки - еще столько же.

Значит зайду через неделю-две

Мне нужен web c логгером - записью статистики за годовой цикл и отображением текущих графиков с датчиков на любое устройство с браузером без внешних обращений к глобальной инет сети. Никой привязки к датчикам там нет, как и методов получения от них значений. Есть только общие условия, исходящие из производительности WiFi и ресурсов WiFi-SoC. Это значит, что годовая кольцевая статистика имеет дискрет точки в 1..5 минут, в зависимости от кол-ва датчиков, а текущий интерактивный график должен отображаться со скорость точек менее 0.1 сек. Отсылка данных типа MQTT и связь с внешним глобальным инет решается другими уже готовыми интерфейсами и к web мало относится. Отношение к web тут только одно – он не должен “падать” от внешних запросов и атак.

 

[=AK=]

Мое решение я создаю как интерфейс для системы управления теплым полом, т.е. это полтора десятка различных датчиков (температуры воды - на 1wire, воздуха - китайские беспроводные от метеостанций, давления, ...) и набор реле (клапаны, насосы, котел, ...). Цель текущего проекта сделать именно интерфейс, без привязки логики к коду системы. Датчики распределены в пространстве. Т.о. есть необходимость связи нескольких систем в одну посредством беспроводных средств.

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

 

[pvvx]

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

Позвольте спросить - у вас домашние WiFi роутеры тоже с батарейкой, без проброса кабелей?
"Другие радиоинтерфейсы, которые потребляют на порядок или на два меньше" не позволяют передать необходимый поток. WiFi вступает, когда требуется поток к 100 килобайт в сек, а не как у Arduino на ESP8266. К примеру на RTL8711AM/8195, встроенный ADC уже не вписывается в BT, как и множественные датчики на I2C приходящие с нескольких устройств. Web так-же имеет смысл только при скоростях более 100 килобайт в сек, т.к. переливание страниц с графиками по две точки никого уже не устраивает. Так-же сеть WiFi часто создается для экспериментов, а не для обывательского повседневного использования... прокладывать кабеля в бетонные стены ради снятий замеров с десятка датчиков в недельном эксперименте нет никакого смыслу, если только не желаете выглядеть дятлом с перфоратором для соседей.

 

[=AK=]

Позвольте спросить - у вас домашние WiFi роутеры тоже с батарейкой, без проброса кабелей?
"Другие радиоинтерфейсы, которые потребляют на порядок или на два меньше" не позволяют передать необходимый поток. WiFi вступает, когда требуется поток к 100 килобайт в сек,

Это для управления теплым полом? Смешно. Для этой задачи даже пропускной способности SIGFOX хватит за глаза.

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

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

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

 

[nikolz]

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

 

[Wilder]

Привет всем,

решил немного поучавствовать в дисскусии.

Как не печельно это признавать но, pvvx, прав. Сделать что-то более менее серьезное на esp8266 почти не возможно, в виде огранниченности ресурсов. Я сам загорелся идеей автоматизации купил данный чип и реализовал свой проект, но столкнулся с тем что для нормальной работы нужно постоянно что-то дописывать, выяснять почему не работает тот или иной кусок кода. В итоге я просто прошил свой роутер на прошивку от падавана, и запустил там node.js. Тут тоже есть свои проблемы, но ресурсов пока хватает на все и при этом загрузка не более 5%

Для чего я сейчас хочу использовать ESP8266 ? На сегодняшний момент чип может быть использован только как оконечное устройство, но никак не сервер. И причем использовать его можно предпочтительно для управления какой-любо нагрузкой, так как в качестве датчиков, есть куча рабочих альтернатив на других радиостандартах, я например использую датчики от Xiaomi.

Если кому интересно могут глянуть мою версию wi-fi manager c файловым менеджером здесь. Основное отличие что он умеет редактировать файлы в gzip.

 

[nikolz]

А зачем из велосипеда делать студебекер.
Почему бы не ездить на велосипеде и радоваться, что какой хороший велосипед.
-----------------------------------------
Уж сколько раз твердили миру Ну не для многостраничных серверов ESP8266.
------------------------
ESP8266 очень удобный чип для создания умных датчиков.
--------------------------
Перечисляю что я сделал:
1) спектрометр
2)измеритель влаги в нефти
3) измеритель уровня воды
4) систему мониторинга для разработки неинвазивного измерителя сахара в крови
5) устройство подсчета капель для вискозиметра
6) Не говорю уж об измерителях температуры, влажности,давления расстояния.
Подобные устройства работают от батарейки и от солнечной панельки.
------------------------
Сервер у меня на компе. А на ESP8266 - станция
----------------------
Надо реально смотреть на возможности чипов и все будет ГУД и даже ВЕРИ.

 

[pvvx]

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

Вам ещё для справки: витая пара (100..300 м) стоит к 10 штукам WiFi модулей, обеспечивающим общее (суммарное) расстояние связи в 10 раз более. Не забудьте туда ещё включить штробирование стен, коробочки и свичи c подводкой лепестричества… Бригаде неделю работать ради нескольких замеров или экспериментатору запутаться в раскиданных проводах?
Может у вас есть предложения по промышленному беспроводному интерфейсу с трафиком за 1 МегБайт/сек?

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

Если бы вы умели читать, то автор топика вам уже ответил – у него гирлянды датчиков и один модуль не справляется с ними
Не всем же мигать одним светодиодом, да ещё с пафосом, что вам не дали документации для вашего уровня развития, как это сделать.

Уж сколько раз твердили миру Ну не для многостраничных серверов ESP8266.

А у меня и у других, кто что-то делает и иногда выкладывает всем для возможности повторения, ESP8266 справляется c данной задачей без проблем, пока вы только мечтаете сделать то, что описываете.

PS: И =AK= - вам nikolz подтверждает, что выбор WiFi у него неверен, а для его поделок достаточно простых BT модулей. Ему и пишите, что WiFi совершенно не нужен для его задуманных, но ещё не реализованных поделок.
Устройства с проводным инет да Web на 3..4 пользователя были сделаны и откатаны более 10 лет назад на микруках ещё дешевле, чем ESP8266. Там самая дорогая деталь - разъем изернет. Но тут сайт про WiFi SoC и рамки их применения давно сформировались. И действительно, Arduino + ESP8266 не вписывается в них, а требует другого уровня подхода для реализации задач.
Для "начинающих" изучение эти ограничения не важны - в данном топике чел хочет попробовать разобраться с принципами расширения системы, как он выразился "горизонтально", и ему не нужны ваши кабеля и ваши глупости. Это всего эксперимент для развития, в целях обучения. Релиз они сделают без ваших подсказок - т.е. я и другие всё равно продолжат стремиться к большему, не ограничиваясь вашими не умениями и не желаниями в дальнейшем развитии...

PS2: Вам и тут показали что ваше мнение - есть "старые-пердуны" не воспринимающие современных тенденций.

 

[pvvx]

Написал тут много, а показать нечего. Рисовать не умею, дизайнер из меня хреновый. Навыки HTML базовые. С программированием Arduino / ESP знаком полгода (иногда бывает час-два в день или в неделю на это ).

Я тоже в поисках нормальных javascript, умеющих отображать живой график с нескольких датчиков на разнообразных конечных устройствах с инет-браузером. Статическое отображение графиков и логгов на странице уже освоено и окучено – там всего то нужен протокол по передаче запрашиваемых блоков накопленных данных с устройства с трансфером как раз укладывающихся в полосу WiFi. SPIFFS, в данном случае и является ограничением из-за своей медлительности. Для отображения разнообразных графиков с устройства на страницу, его Web-серверу необходимо передать сам HTML, css, картинки, javascript и данные, общим объемом к 0.3..0.5MB. На SPIFFS и ESP8266 это выливается в ожидание более нескольких секунд до полного отображения, что совершенно не комфортно…
Желающих иметь отображение графиков с множества датчиков в интерактивном режиме всё время увеличивается, достаточно посмотреть любой раздел тем данного форума...
Ожидаю, что вы найдете решение этого вопроса... А на "старых-пердунов" не обращайте внимания - их тут всего пара завелась на данном сайте и как-нибудь окучим.

 

[=AK=]

Вам ещё для справки: витая пара (100..300 м) стоит к 10 штукам WiFi модулей, обеспечивающим общее (суммарное) расстояние связи в 10 раз более. Не забудьте туда ещё включить штробирование стен, коробочки и свичи c подводкой лепестричества… Бригаде неделю работать ради нескольких замеров или экспериментатору запутаться в раскиданных проводах?

Выковырянные из носа аргумены идут в помойку. Нафиг никому не нужно это ваше "суммарное расстояние".

С первого раза до вас не доходит, придется повторять:

• Провода все равно придется прокладывать, чтобы обеспечить питанием прожорливые WiFi модули.
  
• В загородном доме штробить приходится крайне редко. Например, в моем доме это пришлось делать всего 2 раза за 20 с лишним лет, в остальных примерно 100 случаях скрытая проводка прокладывалась гораздо проще, очень быстро, без шума и пыли. Но как это делается - зашоренные жители бетонных хрущоб даже не догадываются.

 

[tretyakov_sa]

Вот.
Написал тут много, а показать нечего. Рисовать не умею, дизайнер из меня хреновый. Навыки HTML базовые. С программированием Arduino / ESP знаком полгода (иногда бывает час-два в день или в неделю на это ). Как готовить Git - не знаю.
Я программирую на языке очень далеком от С, и текущий проект - хобби.
Кто хочет сделать интересную штуку - приглашаю к сотрудничеству.

Смотрите это видео. Может быть подойдет!

Описание здесь:
Home · tretyakovsa/Sonoff_WiFi_switch Wiki · GitHub

 

[Wilder]

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

Не совсем понимаю, в чем проблема. Как раз это относительно не сложно реализовать через WebSocket. Изначально все необходимые файлы(библиотеки) записываются в SPIFFS или PROGMEM. Все эти файлы будут нужны только первый раз. В дальнейшем они кладуться в кэш и уже не тормозят. А объем данных который нужен для оперетивного отображения не превышает сотню байт.

 

[pvvx]

Не совсем понимаю, в чем проблема. Как раз это относительно не сложно реализовать через WebSocket. Изначально все необходимые файлы(библиотеки) записываются в SPIFFS или PROGMEM. Все эти файлы будут нужны только первый раз. В дальнейшем они кладуться в кэш и уже не тормозят. А объем данных который нужен для оперетивного отображения не превышает сотню байт.

Ну это для ESP8266 проектов. Там итог всех проектов в изменении 1 бита в час и WiFi не требуется.

Выковырянные из носа аргумены идут в помойку. Нафиг никому не нужно это ваше "суммарное расстояние".

С первого раза до вас не доходит, придется повторять:

• Провода все равно придется прокладывать, чтобы обеспечить питанием прожорливые WiFi модули.
  
• В загородном доме штробить приходится крайне редко. Например, в моем доме это пришлось делать всего 2 раза за 20 с лишним лет, в остальных примерно 100 случаях скрытая проводка прокладывалась гораздо проще, очень быстро, без шума и пыли. Но как это делается - зашоренные жители бетонных хрущоб даже не догадываются.

Это частный случай и не требует никаких разработок или продумывания каких-то проектов и экспериментов. Датчики ставятся не в поле, и там уже существует проводка питания.
Для вас пример: У меня вот на участке есть парник. До него от ближайшей постройки более 50 метров, и все пересекаются проложенными дорогами для прохода хоть перегруженного камаза (имею в виду что там уже типа стробить и потом чинить эти дорогу придется). Туда кинут броневой кабель в трубах для включения наноса и всяких реле полива. Тянуть ещё один кабель через это всё?
Да, а в городе у меня не хрущеба, а простой "таунхауз" сделанный "Монолитстрой" спб из железобетона с замесом гранита и штробится достаточно сложно, а электропроводка заложена до заливки... Это внешнюю стену проще - там всего кирпич, да типа пеноблок на 0.5 метра...

Смотрите это видео. Может быть подойдет!
Описание здесь:
Home · tretyakovsa/Sonoff_WiFi_switch Wiki · GitHub

Там всего 30 точек через 3 сек - явное рекомендуемое применение BT или устройств 433MГц, а не WiFi. А если надо пусть 100 точек с 5 датчиков в сек?
Для примера - самая дешевая INA219 дает 500 точек 12 бит 2 значения в сек - ток и напряжение...
Никакой "джсон" уже не справиться.
Тогда всё (?) - отказываться от простого WiFi SoC и ставить что-то типа R Pi ?

С одним соединением, через Ajax, ESP ещё как-то справляется на 200 точек в сек, но не в Arduino:

А для большего, без проблем тянет websocket:

Вплоть до 20к точек в сек:

При этом, возникают уже другие проблемы – содержание больших скриптов на web самого устройства и тормознутость javascript на внешнем устройстве где требуется отображение. Стандартные библиотеки javascript уже не подходят, а писать свои нет особого желания. По этому и ведется поиск простых подходящих методов решения совокупности этих вопросов с расчетом на производительность малых WiFi SoC.

У вас то решение не для WiFi, а в пределе для BT и позиционирование WiFi для рабочих проектов выбрано не верно. Только в целях обучения… и то простые WiFi SoC уже доросли до передачи сигналов телеуправления одновременно с видео потоком, а вы застряли на уровне передачи 1 символа в сек…
Простой проект на RTL-ке:

Но топикастер вроде хочет получить что-то рабочее, а не только игрушку в целях изучения (?)

 

[view24]

Универсальный WEB-интерфейс. Звучит очень правильно. Вот реализации: http://view24.org/mks.htm
аналогично, но с некоторыми объяснениями
Chart on-line monitoring fermenter's measurement by free OPC

То, о чем Вы говорите - называется 'панель' или по-буржуйски 'dash-board'.
Еще пример: Группа БиоСофт-24. Автоматизация и визуализация научно-исследовательских и производственных процессов. - BioSoft24.ru
Но эта панель без управления.
Может быть Вы будете первым человеком, кто заинтересуется этой панелью 'view24' со стороны помимо моих заказчиков.