Обсуждение унификация софта IoT

[nikolz]

Добрый день,
Выкладываю свою концепцию построения софта IoT.
После ряда экспериментов с ESP и RTL у меня сформировалась универсальная структура программного обеспечения IoT.
Предлагаю высказывать конструктивные предложения.
-----------------------
В общем виде, структура следующая:
Программное обеспечение состоит и трех самостоятельных программно изолированных блоков.
----------------------------
Первый блок отвечает за сбор информации с датчиков.
Этот блок реализуется по типу "bare metal" либо на основе "легких" OCРВ.
У него на входе все датчики и провода, а на выходе энергонезависимая память для хранения первичной информации от датчиков.
Применительно к ESP, этот блок реализуется в boot , а информацию пишет в память RTC.
-------------------------
Второй и третий блоки реализуются на любых OC.
Второй блок отвечает за вторичную обработку информации и передачу этой информации по каналам связи пользователю.
Применительно к ESP у меня этот блок отвечает за передачу информации по WIFI.
----------------------------
Третий блок отвечает за интерфейс с пользователем и накопление информации на удаленных носителях.
==============================
В чем собственно отличие данной концепции от той, которая используется практически всеми в том числе и посетителями данного форума.
отличие в том, что второй и третий блоки являются универсальными и не зависят от набора датчиков.
А первый блок содержит лишь управление датчиками и не требует от его разработчика знать как передавать по WIFI как настраивать соединение.
При этом второй и третий блоки практически не зависят от используемых микроконтроллеров.
======================
Если третий блок сейчас так и реализуется (это андроид или облако), то первый и второй блоки сейчас это винегрет, который стряпает каждый, кто берется делать автоматизацию своего дома.
В данной концепции, выделение второго блока как самостоятельного, позволяет использовать для него коробочное решение и не заниматься изучением протоколов и особенностей соединений по WIFI BLE и т д
--------------------------
В данной концепции, любому желающему надо будет лишь определиться с набором датчиков т е разрабатывать лишь первый блок, а второй блок - взять готовую прошивку (бинарик, а не скетч и либы).
----------------------------------

 

[kab]

Добрый день,
Выкладываю свою концепцию построения софта IoT.

Спойлер

После ряда экспериментов с ESP и RTL у меня сформировалась универсальная структура программного обеспечения IoT.
Предлагаю высказывать конструктивные предложения.
-----------------------
В общем виде, структура следующая:
Программное обеспечение состоит и трех самостоятельных программно изолированных блоков.
----------------------------
Первый блок отвечает за сбор информации с датчиков.
Этот блок реализуется по типу "bare metal" либо на основе "легких" OCРВ.
У него на входе все датчики и провода, а на выходе энергонезависимая память для хранения первичной информации от датчиков.
Применительно к ESP, этот блок реализуется в boot , а информацию пишет в память RTC.
-------------------------
Второй и третий блоки реализуются на любых OC.
Второй блок отвечает за вторичную обработку информации и передачу этой информации по каналам связи пользователю.
Применительно к ESP у меня этот блок отвечает за передачу информации по WIFI.
----------------------------
Третий блок отвечает за интерфейс с пользователем и накопление информации на удаленных носителях.
==============================
В чем собственно отличие данной концепции от той, которая используется практически всеми в том числе и посетителями данного форума.
отличие в том, что второй и третий блоки являются универсальными и не зависят от набора датчиков.
А первый блок содержит лишь управление датчиками и не требует от его разработчика знать как передавать по WIFI как настраивать соединение.
При этом второй и третий блоки практически не зависят от используемых микроконтроллеров.
======================
Если третий блок сейчас так и реализуется (это андроид или облако), то первый и второй блоки сейчас это винегрет, который стряпает каждый, кто берется делать автоматизацию своего дома.
В данной концепции, выделение второго блока как самостоятельного, позволяет использовать для него коробочное решение и не заниматься изучением протоколов и особенностей соединений по WIFI BLE и т д
--------------------------
В данной концепции, любому желающему надо будет лишь определиться с набором датчиков т е разрабатывать лишь первый блок, а второй блок - взять готовую прошивку (бинарик, а не скетч и либы).

----------------------------------

Эти соображения, скорее всего полезны. Но для кого они?

Это уже не для "сделай сам", а для предпринимателя, оценивающего способы возможного завоевания интересующего его рынка...

 

[pvvx]

Приведу пример.
Есть свалка pvvx. В ней работа WIFI переплетена с работой с датчиками.
Чтобы добавить новый датчик Вы должны не испортить все остальное и как-то все это подключить к имеющемуся софту WIFI.
А если надо перенести это на другой контроллер, то появляется такого же размера очередная свалка.

Вы ошиблись в корне. Добавление датчика в Web-свалке не требует переписывания её. Добавляется отдельный программный модуль (оверлей) работы с датчиком, который может грузится хоть по сети или добавляется на web-диск устройства.
При этом на смартфоне или на том, через что производите просмотр показаний ничего не меняется - там работает обычный броузер, а запросы и ответы к оверлею стандартизированы и поддерживаются в web-интерфейсе. При этом оверлей имеет доступ ко всем переменным и функциям основного блока и SDK, чего нет на многих ОС и при этом отсутствуют таблицы стыковки, т.е. память не занята лишними указателями на стандартный ограниченный ряд функций. При этом есть свои "но", но ресурсов у ESP8266 и так мало и без "но" там не обойтись...
Данная концепция покрывает и коммерческие варианты, где оверлей является платным и передается с платного сервиса.
Сама Web-свалка - это всего интерфейс по настройке устройства, содержащий и Help (описание самого устройства в текстовом и графическом формате для пользователя) используя стандартные средства имеющиеся у пользователя с web-браузером. У вас отсутствует данная часть и требуется пляска с бубном и внешние инструкции, что удорожает товар и требует специалиста. Для простых датчиков (BT и т.д.) у всех производителей имеется автоматический интерфейс подключения/включения датчика в систему, существуют и разработаны общие стандарты, и данных вещей и всякой отсебятины на Arduino не требуется.

Основным основанием использования WiFi в IoT является требование от устройства потоков с пропускной способностью превышающей сотню килобайт в сек. Всё остальное реализуется на устройствах c интерфейсом связи типа BT и аналогичных, бурно развивающихся на данном рынке.

Все производители, наполняющие рынок IoT уже выпустили такие устройства в неимоверных кол-вах и рынок заполнен ими. WiFi при этом не используется для включения лампочек или опроса медленных датчиков… Нет никакого смысла в WiFi у таких устройств, что уже доказал рынок. Все имеющиеся на сайте Arduino устройства и проекты на ESP8266 пока ограничены этой областью, т.е. замещены давно готовыми и с лучшими характеристиками.

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

Остается только отдельная сфера – устройства пользователя, где нет своего дисплея и проще использовать дисплей на смартфоне или компе. Простейший пример: лабораторный БП с задаваемыми множественными установками, контролем и мониторингом в реальном времени. Но в связи со своей ненадежность работы ESP8266 не может использоваться и для таких целей.
----
По остальному, что требуется для бытовых устройств, уже было всё разжовано. Каждое устройство должно/обязано обладать автономностью. Об этом гласит вся история всех известных природных объектов По минимуму оно должно иметь внутренний лог использования и прочей статистики за год. Это требуется для производителя и обеспечения гарантий от него. Для примера возьмите холодильник… Пользователю, для контроллера лампочки, так-же надо содержать статистику для определения качеств товара и своевременной замены – сколько раз она включалась и на сколько, и при этом эти данные должны храниться на самом устройстве, т.к. внешняя связь с серверами, через глобальную интернет сеть не обязательна, а для просмотра их не требовалось специальных нестандартных устройств и ПО. Минимальный пример - SMART у винчестера. Данные направления только развиваются и стандартных вариантов доступа к такой информации не имеют, что усложняет ремонт и обслуживание. А это одни из основных показателей у товара в бытовой сфере.

 

[pvvx]

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

Давно такое есть у всех чипов. Исключение составляет только ESP8266. У него нет частей с интерфейсами в бинарном виде.
Линковать итого проще и компактнее с либами или вообще с исходниками. С исходниками намного короче выходит. Ну, а т.к. в ESP вообще ничего кроме мигалки светодиодами не лезет с китай-Espressif подходом, то и заранее подготовленных бинарных либ c интерфейсами у неё нет, кроме варианта web-свалки. У web-свалки основное тело именно в бинарном виде и линкуется с оверлеями.
На RTL (у EMW3080 - RTL серии "B" и для пару других из серии "A") так-же используется основной прошитый заранее блок со всеми интерфейсами и отдельно прошивается модуль пользователя. Основной блок у них назван "kernel" и в нем всё, включая поддержку MQTTS.

Понимаете разницу между ПЕРЕПИСАТЬ и НЕ ИСПОРТИТЬ?

А вы это понимаете?
Опять у вас всё по своему?
Для написания оверлея к web-свалке категорически не надо трогать его исходников и патчить основной блок находящийся в бинарном виде = файл основной прошивки! - это обозначает, что ничего испортить не выйдет, если не пользоваться WinHex
Ваше описание и видение намекает, что вы не ушли далее "AT" команд. Все модули RTL поддерживают "AT" с HTTPS и MQTTS запросами и ответами. Они как раз вписываются в ваше описание как раздельная часть готовых, простых в обращении и полностью рабочих интерфейсов для датчика.
Вы представляете - ещё с DOS (и ранее), и ныне в Windows и Linux все сервисы в виде исполняемых файлов обычно в бинарном виде и ИСПОРТИТЬ их можно только в редакторе типа WinHex Но даже ESP-32, в отличии от RTL с индексом "AM" обделен такой возможностью - загрузки пачки исполняемых файлов, даже если туда поставили PSRAM (при чем это сделано специально, чтобы ограничить ваши возможности в выборе).

 

[Peter1001]

Основным основанием использования WiFi в IoT является требование от устройства потоков с пропускной способностью превышающей сотню килобайт в сек.

Еще дальнобойность. тот же BT просто не пробъёт стену. Z-wave то же так себе, ячеистая сеть только и спасает.
Смотрел коммерческие проекты, везде все пишут, что если главный сервер отказал, то не проблема, датчик сам решит.
Копнул поглубже сплошная дичь, умного нечего не остаётся при выходе сервера. Базовые ф-и конечно работают, если тот же дым он запищит итд.

PS: Я как раз с такой же концепции переполз немного на другую. Но начал с такой же. Концепция автора имеет фундаментальные косяки. Если интересно распишу какая концепция у меня.