Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

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

Тема в разделе "Умный дом", создана пользователем nikolz, 28 янв 2018.

  1. nikolz

    nikolz Гуру

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

    kab Авторитетный участник сообщества

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

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

    pvvx Активный участник сообщества

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

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

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

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

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

    pvvx Активный участник сообщества

    Сообщения:
    8.740
    Симпатии:
    1.283
    Давно такое есть у всех чипов. Исключение составляет только ESP8266. У него нет частей с интерфейсами в бинарном виде.
    Линковать итого проще и компактнее с либами или вообще с исходниками. С исходниками намного короче выходит. Ну, а т.к. в ESP вообще ничего кроме мигалки светодиодами не лезет с китай-Espressif подходом, то и заранее подготовленных бинарных либ c интерфейсами у неё нет, кроме варианта web-свалки. У web-свалки основное тело именно в бинарном виде и линкуется с оверлеями. :p
    На RTL (у EMW3080 - RTL серии "B" и для пару других из серии "A") так-же используется основной прошитый заранее блок со всеми интерфейсами и отдельно прошивается модуль пользователя. Основной блок у них назван "kernel" и в нем всё, включая поддержку MQTTS.
    А вы это понимаете?
    Опять у вас всё по своему? :)
    Для написания оверлея к web-свалке категорически не надо трогать его исходников и патчить основной блок находящийся в бинарном виде = файл основной прошивки! - это обозначает, что ничего испортить не выйдет, если не пользоваться WinHex :) :p
    Ваше описание и видение намекает, что вы не ушли далее "AT" команд. Все модули RTL поддерживают "AT" с HTTPS и MQTTS запросами и ответами. Они как раз вписываются в ваше описание как раздельная часть готовых, простых в обращении и полностью рабочих интерфейсов для датчика. :)
    Вы представляете - ещё с DOS (и ранее), и ныне в Windows и Linux все сервисы в виде исполняемых файлов обычно в бинарном виде и ИСПОРТИТЬ их можно только в редакторе типа WinHex :) Но даже ESP-32, в отличии от RTL с индексом "AM" обделен такой возможностью - загрузки пачки исполняемых файлов, даже если туда поставили PSRAM (при чем это сделано специально, чтобы ограничить ваши возможности в выборе). :)
     
    Последнее редактирование: 30 янв 2018
  5. Peter1001

    Peter1001 Новичок

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

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

Поделиться этой страницей