ShIoTiny: узлы, связи и события или особенности рисования программ



    Основные тезисы или о чем эта статья


    Тема статьи — визуальное программирование ПЛК ShIoTiny для умного дома, описанного тут: ShIoTiny: малая автоматизация, интернет вещей или «за полгода до отпуска».

    Очень кратко рассмотрены такие понятия, как узлы, связи, события, а также особенности загрузки и выполнения визуальной программы на ESP8266, который является основой ПЛК ShIoTiny.

    Сайт проекта 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
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 27

      0

      Принцип работы узлов и событий напоминает Node-RED.

        0
        Не отрицаю. Если приближенно, то узел=программная функция, событие — вызов этой функции с параметрами.
        0
        Чем Ваше решение выигрывает по сравнению, например, с FlProg и HiAsm?
          0
          Тем, что оно работает прямо на ESP-07 и не требует никакого ПО на ноутбуке, кроме браузера.
          То есть всё что нужно для настройки устройства — это ноутбук с WiFi и само устройство ShIoTiny.

          Тут я об этом писал habr.com/ru/post/463107
            0

            Так то у кого есть ноутбук с wifi — тот может использовать не только браузер, но и любую IDE. Может сценарии в git хранить, например.

              0

              Может. Но мне нравится так:)
              Знакомый, например, плату к меня попросил как конструктор для сына.
              Спаять, наглядно нарисовать схему без освоения иде и компиляторов. Для пацана 12 лет вообще кайф.
              Причем можно и с сотика управлять по mqtt, например.

          0
          У меня двойственное отношение к поднятой теме визуального программирования:
          1) при проектировании схем для ПЛМ я предпочитаю именно схемотехнические решения и люблю посетовать, что VHDL не дает визуального образа и в нем трудно разбираться, а не схеме все сразу видно,
          2) при проектировании программ я категорически не приемлю визуальный стиль, поскольку он, в отличие от хорошо структурированного текста не дает предствления о логике программы.
          Интересно, это уже шизофрения, или так и должно быть?
            0

            Имхо. Читаемость и нечитаемость программ и чертежей это от автора на 90% зависит.
            Ну и от привычки.
            Дусюмаю, что вы сами видели кучу непонятных кривых схем и нечитаемых программ.

              0

              1) ПЛМ сама по себе представляет собой схему из сигналов и железной логики. Линии и сигналы там — это физические линии и сигналы. Поэтому логично, что графическое представление будет лучше отображать суть процессов, происходящих в ней.
              2) А с программами для процессоров не все так просто — процессор выполняет последовательно операции, записанные в памяти. Поэтому отобразить это графически не всегда легко. Но в некоторых случаях все-таки возможно. Классика — автомат состояний. На языке программирования это тоже такое себе описание, когда в графике можно нарисовать вот так:
              image
              И все понятно, не правда ли?


              В данном языке используется попытка описания алгоритма через события/сообщения — т.е. каждое событие создает сообщение, которое, двигаясь от узла к узлу, преобразовывается так, что на выходе каждого следующего узла появляется какая-то реакция в виде другого сообщения и так далее, пока сообщение не пройдет через все узлы. Это тоже вариант визуального программирования, подходящий для некоторых применений, в особенности, например, всяких сетевых стеков.

                0
                Начните программировать на Forth (Форт) (и Дракон языке) :)
                image

                P.S. ИС Дракон как форт IDE
                @ «В каждой шутке есть доля шутки»
                0
                Сам я не за и не против программ или визуального представления.

                Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.

                Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.

                Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.

                Вот и всё.

                И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.

                В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.

                Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.

                Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.

                Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.

                И так далее и такое прочее.

                Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.
                  0

                  Кстати управление освещением по датчику освещенности и движения есть и у меня.


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

                    0
                    То, что вы описали — это отказ, а не «реал-тайм». При исправном устройстве — такое невозможно.
                    Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.

                    ИМХО, хороший тон — задавать максимальное время включения.

                    Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».

                    Та же история с нагревателем. Или с насосом.

                    Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.

                    И еще — аппаратная защита. Скажем полное откубание питания всей системы при переливе бочки, предрхранители опять же.

                    И можно спать спокойно:) Ну если нервы крепкие:)

                    Некоторые вон АЭС строят — и ничего, спят сладко:)
                      0
                      То, что вы описали — это отказ, а не «реал-тайм». При исправном устройстве — такое невозможно.
                      Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.

                      Я не договорил. А если нагреватель или полив все-таки выключится, но через день — это считается отказом? Проблема в том, что считать исправной системой, а что неисправной и как определить этот порог нагрузки системы, после которого могут происходить отказы. В системах жесткого реального времени это сделать очень просто — все сигналы опрашиваются каждый цикл времени, время работы алгоритма известно и поэтому определить и, главное, протестировать в каком случае система гарантированно будет работать, а в каком откажет, очень легко. В случае же событийной системы неисправная система может получиться просто за счет того, что все события вдруг наступят одновременно и очередь стека MQTT просто переполнится. Вы это тестировали? При каком количестве сигналов/событий это может произойти?


                      ИМХО, хороший тон — задавать максимальное время включения.
                      Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».
                      Та же история с нагревателем. Или с насосом.

                      Это называется "добавить детерминизм в систему" — то есть вы создаете гарантированные дедлайны времени отклика. А это уже характеристика систем реального времени.


                      Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.

                      Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.


                      Некоторые вон АЭС строят — и ничего, спят сладко:)

                      Я к таким отношусь и сплю спокойно — как раз примерно для таких применений разрабатываю системы жесткого реального времени, но применить такое же решение в системе Умного Дома я не могу, так как стоят они немало. Поэтому приходится идти на риск и пытаться как-то выкручиваться. :-)

                        0
                        Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.


                        Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.

                        Сеть — лишь задаёт параметры работы алгоритма. Если она даже упадёт — ничего страшного, алгоритм отработает со старыми параметрами. Скажем проработает тот же полив немного больше или меньше — ну и что? Свет позже выключится? Ну и что?

                        На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.

                        Ну и аппаратная защита критичных устройств не даст случиться ничему страшному.

                        Наверное у вас просто некоторое предубеждение в связи с тем, что вы «как раз примерно для таких применений разрабатываете системы жесткого реального времени». Может не надо переносить в быт атомные технологии?:)

                        Никто же не боится ездить на автомобиле? А ведь у него комп без тройного резервирования:)
                          0
                          Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.
                          Сеть — лишь задаёт параметры работы алгоритма.

                          Но так вы начинаете серьезно себя ограничивать в архитектуре системы. Уже нельзя сделать распределенную систему, где один датчик мог бы давать информацию сразу нескольким системам, или возможность подключать датчики и исполнительные устройства в любых физических точках системы и настраивать их на виртуальные входы/выходы. Также теряется огромное преимущество в том, что имея центральный мощный контроллер, вы можете делать сложные вещи, а не писать все для пукалок типа ESP-8266.


                          На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.

                          Конечно, не атомная станция. Только не забывайте напоминать себе, что данное время отклика — это всего лишь вероятностная величина, которая рано или поздно может устремиться в бесконечность. Я себе об этом постоянно напоминаю, что позволяет не забывать про очевидные вещи. Но лучше бы, чтобы напоминать не надо было вообще.

                            0

                            Так на работе я и пишу все для линукса на мощных контроллерах. Но для управления светом или поливом ничего сложнее пукалок и не надо:)


                            Требования просто разные. Дома мне надо, чтобы было просто и дешево. Из чего я и исходил.


                            Кстати, у меня есть возможность задавать с одного датчика данные всем модулям, если их несколько в сети.


                            Только надо еще время актуальности задавать и смотреть что делать, если параметр устарел.


                            В общем старая задача — как при ненадежной сети пострить вменяемую систему:)

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


                              Вы, я вижу, опытный спец:) Но если пойти дальше — то вообще всё устройство работает на базе вероятностных величин.

                              Если так пойти, то:

                              Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.

                              Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.

                              Если с транзистором всё в порядке — отказать может реле.

                              Если реле не отказало — может оборваться провод или отгореть клемма:))

                              И так далее. Но это всё теории. Реально, конечно, защиты нужны, но в разумных пределах. ИМХО.
                                0
                                Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.
                                Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.
                                Если с транзистором всё в порядке — отказать может реле.
                                Если реле не отказало — может оборваться провод или отгореть клемма:))

                                Это на самом деле не такие уж маленькие вероятности, как вам кажется, и от них есть вполне рабочие защиты. Например в системах, где моторы поднимают платформы с людьми, всегда используется двойной разрыв силовой цепи двумя независимыми контакторами и реле и с контролем срабатывания. А для защиты от залипания, например, у меня все выходы импульсные — т.е. транзистор включается только если на его входе есть импульсы. Если же на выходе будет статический ноль или единица — то транзистор закроется.
                                Это защиты, которые уже годами отработаны и там все в разумных пределах.


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

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


                                  Ну так это уже не про мой примитивный контроллер с несколькими событиями в секунду максимум.

                                  Я не спец по высоконагруженным системам с временем отклика в миллисекунды. Совсем не спец.
                      0

                      А можно ли рассмотреть вариант модификации, при котором в прошивке можно было бы настраивать Relays & Inputs на произвольные GPIO?
                      Чтобы иметь возможность использовать Вашу замечательную программу не только на Вашем же контроллере а и на обычных Sonoff (dual), Electrodragon WiFi Relay, etc?

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

                        А WiFi-реле… В ESP-01 c 512К моя прошивка не влезет. Увы. ESP-07 был взят именно потому что там 1Мегабайт памяти.

                        Может стоит сделать урезанную плату с одним реле и возможностью подключить несколько датчиков? То же самое WiFi-реле, но умнее.

                        Разница в цене будет не велика, зато помимо дистанционного управления по MQTT можно будет сделать «умный алгоритм». Например, включать освещение не только по команде, но и по датчику освещённости и движения.

                        Скажем, если в комнате темно и кто-то там есть — включить свет. Или не включать, если поздно (можно на сервере MQTT публиковать и время). В общем — количество степеней свободы растёт многократно.

                        Кстати, я как раз для тестов своей прошивки микро-проект сделал для освещения — потом выложу.

                        Входные данные — уровень освещённости (АЦП), время (MQTT), команда (MQTT) и выключатель (INPUT1), датчик движения (INPUT2).

                        Управляют освещением все три реле.

                        Первое — «ночник» (включается если в комнате кто-то есть и время обозначено как позднее) текущее время и какое время считать «поздним» — публикуется в MQTT.

                        Вторая — нормальное (включается если в комнате кто-то есть и время обозначено «вечернее», но в комнате темно).

                        Третья — полное освещение — (включается если в комнате кто-то есть и время обозначено как «раннее», но в комнате темно).

                        Выключатель-кнопка меняет по кругу все режимы (отключено-ночник-норма-полное-автомат).

                        Так же по MQTT можно управлять режимом напрямую.

                        Будем посмотреть как работает:)
                          0
                          Вот черновик управления светом.

                          Пока ещё не тестировал толком.
                        0
                        Сам я не за и не против программ или визуального представления.

                        Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.

                        Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.

                        Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.

                        Вот и всё.

                        И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.

                        В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.

                        Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.

                        Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.

                        Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.

                        И так далее и такое прочее.

                        Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.

                        Так что те, кто хочет — пусть SDK пользуют, кому нравится — JavaScript и Lua. Ну а самые суровые могут и на ассемблере писать:)

                        Никого не призываю отказаться от убеждений и привязанностей.
                          0
                          По мне, так самое неприятное в таком визуальном программировании это видимость параллельного исполнения программы, в то время как реально оно последовательное. Причем как оно последовательно исполняется скрыто под капотом движка. В Labview забавно смотреть в режиме отладки как бегут данные по проводкам, но там есть приличное количество средств для задания порядка выполнения, если нужно. Но большие диаграммы меня в нем всегда угнетали и старался их упростить вызовами CallLibraryFunction или CIN-ами… а так сама по себе задача решена прикольная. Однако в своих модулях для автоматизации я упор делаю на автономность и независимость каждого узла и возможность его автономно настроить(или по-управлять) через веб морду. Чтобы при разваливании сети все отработало свои задачи само. С визуальным программированием это сложновато будет нарисовать…
                            0
                            Еще бы İ2C добавить для расширения функциональности…
                              0
                              На ESP-07 i2C аппаратный вроде не выведен.
                              Но после вылова критичных багов (а такие наверняка найдутся) — расширение номенклатуры периферии неизбежно:) Да и надо сделать версию для модулей с 2Мб и более. Но пока надо до ума то, что есть.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое