Основные тезисы или о чем эта статья
Тема статьи — визуальное программирование ПЛК ShIoTiny для умного дома, описанного тут: ShIoTiny: малая автоматизация, интернет вещей или «за полгода до отпуска».
Очень кратко рассмотрены такие понятия, как узлы, связи, события, а также особенности загрузки и выполнения визуальной программы на ESP8266, который является основой ПЛК ShIoTiny.
Вступление или пара оргвопросов
В предыдущей статье по поводу своей разработки я сделал краткий обзор возможностей контроллера ShIoTiny.
Как ни странно, общественность проявила довольно сильную заинтересованность и задала мне довольно много вопросов. Некоторые товарищи даже сразу сходу предложили у меня купить контроллер. Нет, я не против того, чтобы немного заработать, но совесть не позволяет мне продавать ещё очень сырую в программном плане вещь.
Поэтому я выложил на GitHub бинарники прошивки и схему устройства: прошивка+инструкция кратчайшая+ схема+примеры.
Теперь каждый может прошить ESP-07 и самолично поиграться с прошивкой. Если кому очень хочется именно такую плату как на фото — то у меня есть их несколько штук. Пишите на почту shiotiny@yandex.ru. Но, как говаривал незабвенный Огурцов: «Я ни за что не отвечаю!».
Итак, перейдём к сути: что такое "узел" (нода) и "событие"? Как выполняется программа?
Как обычно — начнём по порядку: с загрузки программы.
Как загружается программа
Начнем с того, что происходит, когда мы нажимаем кнопочку Upload в редакторе ElDraw и наша схема-программа, состоящая из красивых квадратиков улетает в устройство.
Во-первых, на основе нарисованной нами схемы строится её описание в текстовом виде.
Во-вторых, проверяется — все ли входы узлов соединены с выходами. «Висящих» входов не должно быть. Если такой вход обнаружен — схема в ShIoTiny не загрузится, а редактор выведет соответствующее предупреждение.
Если все прошло успешно, то редактор посылает в ShIoTiny текстовое описание схемы по одному узлу. Разумеется, существующая схема из ShIoTiny предварительно удаляется. Полученное текстовое описание сохраняется во FLASH-память.
Кстати, если вы хотите удалить схему из устройства, то просто загрузите в него пустую схему (не содержащую ни одного элемента-узла).
Как только вся схема-программа загружена в ПЛК ShIoTiny, она начинает «выполняться». Что это значит?
Отметим, что процессы загрузки схемы из FLASH-памяти при включении питания и при приёме схемы из редактора — идентичны.
Сначала идёт создание объектов-узлов на основе их описания.
Затем производится расстановка связей между узлами. То есть генерируются ссылки выходов на входы и входов на выходы.
И только после всего этого запускается основной цикл выполнения программы.
Писал я долго, но весь процесс -от «загрузки» схемы из FLASH-памяти до запуска основного цикла — занимает доли секунды для схемы из 60-80 узлов.
Как работает основной цикл? Очень просто. Сначала он ждёт возникновения события в каком-либо узле, затем обрабатывает это событие. И так без конца. Ну или пока не загрузят в ShIoTiny новую схему.
Уже несколько раз я упоминал такие вещи, как события, узлы и связи. Но что же это такое с программной точки зрения? Об этом и поговорим сегодня.
Узлы, связи и события
Достаточно взглянуть на примеры схем-программ для ShIoTiny, чтобы понять, что состоит схема лишь из двух сущностей — узлов (или элементов) и связей между ними.
Узел, нода или элемент схемы — это виртуальное представление какого-то действия над данными. Это может быть арифметическая операция, логическая операция или вообще какая угодно операция, какая придет нам в голову. Главное, что у узла есть вход и выход.
Вход — это то место, куда узел принимает данные. Изображения входов — это точки, находящиеся всегда с левой стороны узла.
Выход — это то место, откуда извлекается результат работы узла. Изображения выходов — это точки, находящиеся всегда с правой стороны узла.
У некоторых узлов нет входов. Такие узлы генерируют результат внутри себя. Например узел-константа или узел-датчик: им не нужны данные от других узлов, чтобы сообщить результат.
У других узлов, напротив, нет выходов. Это узлы, отображающие, например, исполнительные устройства (реле или еще какие-нибудь подобные). Они принимают данные, но не генерируют результата вычислений, доступного для других узлов.
Кроме того, есть еще уникальный узел-комментарий. Он ничего не делает, не имеет ни входов ни выходов. Его назначение — быть пояснением на схеме.
Что такое «событие»? Событие — это возникновение новых данных в каком-либо узле. Например к событиям относятся: изменение состояния входа (узел Input), приём данных от другого устройства (узлы MQTT и UDP), истечение заданного промежутка времени (узлы Timer и Delay) и так далее.
Для чего нужны события? Да для того, чтобы определить — в каком узле возникли новые данные и состояния каких узлов необходимо изменить в связи с получением новых данных. Событие, как бы «проходит» по цепочке узлов, пока не обойдет все узлы, состояние которых необходимо проверить и изменить.
Все узлы можно подразделить на две категории.
Узлы, которые могут генерировать события назовем «активные узлы».
Узлы, которые не могут генерировать события назовем «пассивные узлы».
Когда узел генерирует событие (то есть у него на выходе появляются новые данные), то изменяется в общем случае состояние всей цепочки узлов, подключенных к выходу узла-генератора события.
Чтобы было понятно, рассмотрим пример на рисунке.
Активные узлы тут — Input1, Input2 и Input3. Остальные узлы — пассивные. Рассмотрим что происходит, когда замыкается тот или иной вход. Результаты для удобства сведены в табличку.
Как видим, при возникновении события, строится цепочка от узла-источника события и до оконечного узла. Состояние тех узлов, которые не попадают в цепочку, не изменяется.
Возникает законный вопрос, а что же будет при возникновении двух или вообще нескольких событий одновременно?
Как любителя творчества Глеба Анфилова, меня так и тянет отправить любопытного вопрошателя к его книге «Бегство от удивлений». Это такая «теория относительности для самых маленьких», в которой хорошо рассказано, что такое «одновременно» и как с этим жить.
Но чисто практически все гораздо проще: при возникновении двух или вообще нескольких событий последовательно строятся и обрабатываются все цепочки от каждого источника события по очереди и никаких чудес.
Следующий вполне законный вопрос любопытного читателя — а что будет, если узлы соединить в кольцо? Или, как это принято говорить среди этих ваших умников — ввести обратную связь. То есть соединить выход одного из узлов со входом предыдущего узла так, чтобы состояние выхода этого узла влияло на состояние его же входа. Напрямую соединить выход узла с его же входом вам не позволит редактор ElDraw. А вот опосредованно, как на рисунке ниже — это сделать можно.
Итак, что же будет в этом случае? Ответ будет очень «определенный»: смотря какие узлы. Рассмотрим пример на рисунке.
Когда контакты входа Input1 разомкнуты на верхнем входе узла А — 0. На выходе узла А, тоже 0. На выходе узла Б — 1. И, наконец, на нижнем входе узла А — 1. Всё ясно. А кому не ясно — посмотрите ниже описание того, как работают узлы «И» и «НЕ».
Теперь замкнем контакты входа Input1, то есть подадим на верхний вход узла А единицу. Те, кто знаком с электроникой, знает, что фактически мы получим классическую схему генератора на логических элементах. И по идее, такая схема должна бесконечно выдавать на выходе элементов А и Б последовательности 1-0-1-0-1-0…. и 0-1-0-1-0-1-…. Ведь событие должно постоянно изменят состояние узлов А и Б, бегая по кругу 2-3-2-3-…!
Но на самом деле этого не происходит. Схема впадет в случайное состояние — или реле останется включенным или отключенным, а может и слегка прожужжать включаясь-отключаясь несколько раз подряд. Все зависит от погоды на южном полюсе Марса. И вот почему так происходит.
Событие с узла Input1 изменяет состояние узла А, потом узла Б и так по кругу несколько раз. Программа определяет «зацикливание» события и принудительно прекращает этот карнавал. После этого изменение состояния узлов А и Б блокируются до возникновения нового события. Момент, в который программа решит — «хватит вертеться по кругу!» — в общем случае зависит от многих факторов и его можно считать случайным.
Будьте осторожны, соединяя узлы в кольцо — эффекты будут не всегда очевидными! Хорошо представляйте что и зачем вы делаете!А можно ли все же построить генератор на доступных нам узлах? Да, можно! Но для этого необходим узел, который сам умеет генерировать события. И такой узел есть — это «линия задержки». Посмотрим как работает генератор с периодом 6 секунд на рисунке ниже.
Ключевым элементом генератора является узел А — линия задержки. Если изменить состояние входа линии задержки с 0 на 1, то 1 на выходе появится не сразу, а только спустя заданное время. В нашем случае это 3 секунды. Точно так же, если изменить состояние входа линии задержки с 1 на 0, то 0 на выходе появится спустя те же 3 секунды. Время задержки задается в десятых долях секунды. То есть значение 30 и означает — 3 сек.
Особенностью линии задержки является то, что она генерирует событие после истечения времени задержки.
Предположим, что изначально на выходе линии задержки был 0. После прохождения узла Б — инвертора — этот 0 превращается в 1 и поступает на вход линии задержки. Сразу ничего не происходит. На выходе линии задержки как был 0 так и останется, но зато включается отсчет времени задержки. Проходит 3 секунды. И тут же линия задержки генерирует событие. На выходе у нее появляется 1. Эта единица после прохождения узла Б — инвертора — превращается в 0 и поступает на вход линии задержки. Проходит ещё 3 секунды… и процесс повторяется. То есть каждые 3 секунды состояние выхода линии задержки меняется с 0 на 1 и затем с 1 на 0. Реле щелкает. Генератор работает. Период импульсов составляет 6 секунд (3 секунды на выходе ноль и 3 секунды — единица).
Но, в реальных схемах, обычно не нужно использовать и этот пример. Существуют специальные узлы-таймеры, которые великолепно и без посторонней помощи генерируют последовательность импульсов с заданным периодом. Длительность «нуля» и «единицы» в этих импульсах равны половине периода.
Для задания периодических действий, используйте узлы-таймеры.Отмечу, что такие цифровые сигналы, где длительность «нуля»и «единицы» равны, называются «меандром».
Надеюсь, я немного прояснил вопрос о том как происходит распространение событий между узлами и чего делать не стоит?
Заключение и ссылки
Статья получилась короткой, но это статья-ответ на возникшие вопросы по узлам и событиям.
По мере развития прошивок и появления новых примеров я буду писать о том, как программировать ShIoTiny небольшие статьи, покуда это будет интересно людям.
Как и ранее, схема, прошивка, примеры, описание узлов и все остальное тут.
Вопросы, пожелания, критика — это сюда: shiotiny@yandex.ru
Комментарии (27)
FForth
12.08.2019 12:20
shiotiny Автор
12.08.2019 12:44Тем, что оно работает прямо на ESP-07 и не требует никакого ПО на ноутбуке, кроме браузера.
То есть всё что нужно для настройки устройства — это ноутбук с WiFi и само устройство ShIoTiny.
Тут я об этом писал habr.com/ru/post/463107iig
12.08.2019 14:06Так то у кого есть ноутбук с wifi — тот может использовать не только браузер, но и любую IDE. Может сценарии в git хранить, например.
shiotiny Автор
12.08.2019 15:52Может. Но мне нравится так:)
Знакомый, например, плату к меня попросил как конструктор для сына.
Спаять, наглядно нарисовать схему без освоения иде и компиляторов. Для пацана 12 лет вообще кайф.
Причем можно и с сотика управлять по mqtt, например.
GarryC
12.08.2019 14:34У меня двойственное отношение к поднятой теме визуального программирования:
1) при проектировании схем для ПЛМ я предпочитаю именно схемотехнические решения и люблю посетовать, что VHDL не дает визуального образа и в нем трудно разбираться, а не схеме все сразу видно,
2) при проектировании программ я категорически не приемлю визуальный стиль, поскольку он, в отличие от хорошо структурированного текста не дает предствления о логике программы.
Интересно, это уже шизофрения, или так и должно быть?shiotiny Автор
12.08.2019 15:57Имхо. Читаемость и нечитаемость программ и чертежей это от автора на 90% зависит.
Ну и от привычки.
Дусюмаю, что вы сами видели кучу непонятных кривых схем и нечитаемых программ.
lingvo
12.08.2019 16:431) ПЛМ сама по себе представляет собой схему из сигналов и железной логики. Линии и сигналы там — это физические линии и сигналы. Поэтому логично, что графическое представление будет лучше отображать суть процессов, происходящих в ней.
2) А с программами для процессоров не все так просто — процессор выполняет последовательно операции, записанные в памяти. Поэтому отобразить это графически не всегда легко. Но в некоторых случаях все-таки возможно. Классика — автомат состояний. На языке программирования это тоже такое себе описание, когда в графике можно нарисовать вот так:
И все понятно, не правда ли?
В данном языке используется попытка описания алгоритма через события/сообщения — т.е. каждое событие создает сообщение, которое, двигаясь от узла к узлу, преобразовывается так, что на выходе появляется какая-то реакция. Это тоже вариант визуального программирования, подходящий для некоторых применений, в особенности, например, всяких сетевых стеков.
FForth
13.08.2019 00:05Начните программировать на Forth (Форт) (и Дракон языке) :)
P.S. ИС Дракон как форт IDE
@ «В каждой шутке есть доля шутки»
shiotiny Автор
12.08.2019 18:01Сам я не за и не против программ или визуального представления.
Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.
Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.
Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.
Вот и всё.
И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.
В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.
Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.
Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.
Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.
И так далее и такое прочее.
Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.lingvo
12.08.2019 18:24Кстати управление освещением по датчику освещенности и движения есть и у меня.
Но тут возникает нюанс, когда не жесткий реал-тайм вдруг превращается в жесткий, а система об этом ни слухом ни духом.
Например, если вдруг "включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре", а нагреватель вдруг взял и не выключился через секунду. И через час не выключился. И полив так и льет весь день.
Мне всегда это мешает спать и я при любом удобном случае перелезу на систему жесткого реалтайма.shiotiny Автор
12.08.2019 19:06То, что вы описали — это отказ, а не «реал-тайм». При исправном устройстве — такое невозможно.
Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.
ИМХО, хороший тон — задавать максимальное время включения.
Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».
Та же история с нагревателем. Или с насосом.
Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.
И еще — аппаратная защита. Скажем полное откубание питания всей системы при переливе бочки, предрхранители опять же.
И можно спать спокойно:) Ну если нервы крепкие:)
Некоторые вон АЭС строят — и ничего, спят сладко:)lingvo
13.08.2019 10:45То, что вы описали — это отказ, а не «реал-тайм». При исправном устройстве — такое невозможно.
Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.Я не договорил. А если нагреватель или полив все-таки выключится, но через день — это считается отказом? Проблема в том, что считать исправной системой, а что неисправной и как определить этот порог нагрузки системы, после которого могут происходить отказы. В системах жесткого реального времени это сделать очень просто — все сигналы опрашиваются каждый цикл времени, время работы алгоритма известно и поэтому определить и, главное, протестировать в каком случае система гарантированно будет работать, а в каком откажет, очень легко. В случае же событийной системы неисправная система может получиться просто за счет того, что все события вдруг наступят одновременно и очередь стека MQTT просто переполнится. Вы это тестировали? При каком количестве сигналов/событий это может произойти?
ИМХО, хороший тон — задавать максимальное время включения.
Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».
Та же история с нагревателем. Или с насосом.Это называется "добавить детерминизм в систему" — то есть вы создаете гарантированные дедлайны времени отклика. А это уже характеристика систем реального времени.
Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.
Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.
Некоторые вон АЭС строят — и ничего, спят сладко:)
Я к таким отношусь и сплю спокойно — как раз примерно для таких применений разрабатываю системы жесткого реального времени, но применить такое же решение в системе Умного Дома я не могу, так как стоят они немало. Поэтому приходится идти на риск и пытаться как-то выкручиваться. :-)
shiotiny Автор
13.08.2019 11:32Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.
Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.
Сеть — лишь задаёт параметры работы алгоритма. Если она даже упадёт — ничего страшного, алгоритм отработает со старыми параметрами. Скажем проработает тот же полив немного больше или меньше — ну и что? Свет позже выключится? Ну и что?
На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.
Ну и аппаратная защита критичных устройств не даст случиться ничему страшному.
Наверное у вас просто некоторое предубеждение в связи с тем, что вы «как раз примерно для таких применений разрабатываете системы жесткого реального времени». Может не надо переносить в быт атомные технологии?:)
Никто же не боится ездить на автомобиле? А ведь у него комп без тройного резервирования:)lingvo
13.08.2019 15:56Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.
Сеть — лишь задаёт параметры работы алгоритма.Но так вы начинаете серьезно себя ограничивать в архитектуре системы. Уже нельзя сделать распределенную систему, где один датчик мог бы давать информацию сразу нескольким системам, или возможность подключать датчики и исполнительные устройства в любых физических точках системы и настраивать их на виртуальные входы/выходы. Также теряется огромное преимущество в том, что имея центральный мощный контроллер, вы можете делать сложные вещи, а не писать все для пукалок типа ESP-8266.
На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.
Конечно, не атомная станция. Только не забывайте напоминать себе, что данное время отклика — это всего лишь вероятностная величина, которая рано или поздно может устремиться в бесконечность. Я себе об этом постоянно напоминаю, что позволяет не забывать про очевидные вещи. Но лучше бы, чтобы напоминать не надо было вообще.
shiotiny Автор
14.08.2019 02:49Так на работе я и пишу все для линукса на мощных контроллерах. Но для управления светом или поливом ничего сложнее пукалок и не надо:)
Требования просто разные. Дома мне надо, чтобы было просто и дешево. Из чего я и исходил.
Кстати, у меня есть возможность задавать с одного датчика данные всем модулям, если их несколько в сети.
Только надо еще время актуальности задавать и смотреть что делать, если параметр устарел.
В общем старая задача — как при ненадежной сети пострить вменяемую систему:)
shiotiny Автор
14.08.2019 06:11Только не забывайте напоминать себе, что данное время отклика — это всего лишь вероятностная величина, которая рано или поздно может устремиться в бесконечность.
Вы, я вижу, опытный спец:) Но если пойти дальше — то вообще всё устройство работает на базе вероятностных величин.
Если так пойти, то:
Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.
Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.
Если с транзистором всё в порядке — отказать может реле.
Если реле не отказало — может оборваться провод или отгореть клемма:))
И так далее. Но это всё теории. Реально, конечно, защиты нужны, но в разумных пределах. ИМХО.lingvo
14.08.2019 11:50Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.
Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.
Если с транзистором всё в порядке — отказать может реле.
Если реле не отказало — может оборваться провод или отгореть клемма:))Это на самом деле не такие уж маленькие вероятности, как вам кажется, и от них есть вполне рабочие защиты. Например в системах, где моторы поднимают платформы с людьми, всегда используется двойной разрыв силовой цепи двумя независимыми контакторами и реле и с контролем срабатывания. А для защиты от залипания, например, у меня все выходы импульсные — т.е. транзистор включается только если на его входе есть импульсы. Если же на выходе будет статический ноль или единица — то транзистор закроется.
Это защиты, которые уже годами отработаны и там все в разумных пределах.
Но я говорю о другом типе вероятности — в случае с событийными системами ваша вероятность будет меняться вместе с нагрузкой системы — пока она маленькая — время реакции прогнозируемо и низкое. Но когда она начнет подниматься и количество сообщений расти — время реакции может неожиданно для вас измениться. А может вы об этом даже и не узнаете сначала. С обрывами выводов и отказами реле все можно легко спрогнозировать, сымитировать и сделать защиту. А вот как быть с событийной системой?
shiotiny Автор
14.08.2019 11:58Но когда она начнет подниматься и количество сообщений расти — время реакции может неожиданно для вас измениться. А может вы об этом даже и не узнаете сначала. С обрывами выводов и отказами реле все можно легко спрогнозировать, сымитировать и сделать защиту. А вот как быть с событийной системой?
Ну так это уже не про мой примитивный контроллер с несколькими событиями в секунду максимум.
Я не спец по высоконагруженным системам с временем отклика в миллисекунды. Совсем не спец.
SolarW
12.08.2019 22:44А можно ли рассмотреть вариант модификации, при котором в прошивке можно было бы настраивать Relays & Inputs на произвольные GPIO?
Чтобы иметь возможность использовать Вашу замечательную программу не только на Вашем же контроллере а и на обычных Sonoff (dual), Electrodragon WiFi Relay, etc?shiotiny Автор
13.08.2019 04:57Рассмотреть можно и я об этом думал. Но сразу возникает куча проблем с настройками и как их сделать удобными, что делать со схемой при изменении функций ноги и так далее. Так что пока думаю.
А WiFi-реле… В ESP-01 c 512К моя прошивка не влезет. Увы. ESP-07 был взят именно потому что там 1Мегабайт памяти.
Может стоит сделать урезанную плату с одним реле и возможностью подключить несколько датчиков? То же самое WiFi-реле, но умнее.
Разница в цене будет не велика, зато помимо дистанционного управления по MQTT можно будет сделать «умный алгоритм». Например, включать освещение не только по команде, но и по датчику освещённости и движения.
Скажем, если в комнате темно и кто-то там есть — включить свет. Или не включать, если поздно (можно на сервере MQTT публиковать и время). В общем — количество степеней свободы растёт многократно.
Кстати, я как раз для тестов своей прошивки микро-проект сделал для освещения — потом выложу.
Входные данные — уровень освещённости (АЦП), время (MQTT), команда (MQTT) и выключатель (INPUT1), датчик движения (INPUT2).
Управляют освещением все три реле.
Первое — «ночник» (включается если в комнате кто-то есть и время обозначено как позднее) текущее время и какое время считать «поздним» — публикуется в MQTT.
Вторая — нормальное (включается если в комнате кто-то есть и время обозначено «вечернее», но в комнате темно).
Третья — полное освещение — (включается если в комнате кто-то есть и время обозначено как «раннее», но в комнате темно).
Выключатель-кнопка меняет по кругу все режимы (отключено-ночник-норма-полное-автомат).
Так же по MQTT можно управлять режимом напрямую.
Будем посмотреть как работает:)
shiotiny Автор
12.08.2019 18:04Сам я не за и не против программ или визуального представления.
Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.
Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.
Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.
Вот и всё.
И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.
В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.
Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.
Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.
Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.
И так далее и такое прочее.
Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.
Так что те, кто хочет — пусть SDK пользуют, кому нравится — JavaScript и Lua. Ну а самые суровые могут и на ассемблере писать:)
Никого не призываю отказаться от убеждений и привязанностей.
poulch
13.08.2019 20:21По мне, так самое неприятное в таком визуальном программировании это видимость параллельного исполнения программы, в то время как реально оно последовательное. Причем как оно последовательно исполняется скрыто под капотом движка. В Labview забавно смотреть в режиме отладки как бегут данные по проводкам, но там есть приличное количество средств для задания порядка выполнения, если нужно. Но большие диаграммы меня в нем всегда угнетали и старался их упростить вызовами CallLibraryFunction или CIN-ами… а так сама по себе задача решена прикольная. Однако в своих модулях для автоматизации я упор делаю на автономность и независимость каждого узла и возможность его автономно настроить(или по-управлять) через веб морду. Чтобы при разваливании сети все отработало свои задачи само. С визуальным программированием это сложновато будет нарисовать…
Ig_B
16.08.2019 09:43Еще бы I2C добавить для расширения функциональности…
shiotiny Автор
16.08.2019 11:05На ESP-07 i2C аппаратный вроде не выведен.
Но после вылова критичных багов (а такие наверняка найдутся) — расширение номенклатуры периферии неизбежно:) Да и надо сделать версию для модулей с 2Мб и более. Но пока надо до ума то, что есть.
lingvo
Принцип работы узлов и событий напоминает Node-RED.
shiotiny Автор
Не отрицаю. Если приближенно, то узел=программная функция, событие — вызов этой функции с параметрами.