Комментарии 27
Принцип работы узлов и событий напоминает Node-RED.
То есть всё что нужно для настройки устройства — это ноутбук с WiFi и само устройство ShIoTiny.
Тут я об этом писал habr.com/ru/post/463107
1) при проектировании схем для ПЛМ я предпочитаю именно схемотехнические решения и люблю посетовать, что VHDL не дает визуального образа и в нем трудно разбираться, а не схеме все сразу видно,
2) при проектировании программ я категорически не приемлю визуальный стиль, поскольку он, в отличие от хорошо структурированного текста не дает предствления о логике программы.
Интересно, это уже шизофрения, или так и должно быть?
Имхо. Читаемость и нечитаемость программ и чертежей это от автора на 90% зависит.
Ну и от привычки.
Дусюмаю, что вы сами видели кучу непонятных кривых схем и нечитаемых программ.
1) ПЛМ сама по себе представляет собой схему из сигналов и железной логики. Линии и сигналы там — это физические линии и сигналы. Поэтому логично, что графическое представление будет лучше отображать суть процессов, происходящих в ней.
2) А с программами для процессоров не все так просто — процессор выполняет последовательно операции, записанные в памяти. Поэтому отобразить это графически не всегда легко. Но в некоторых случаях все-таки возможно. Классика — автомат состояний. На языке программирования это тоже такое себе описание, когда в графике можно нарисовать вот так:
И все понятно, не правда ли?
В данном языке используется попытка описания алгоритма через события/сообщения — т.е. каждое событие создает сообщение, которое, двигаясь от узла к узлу, преобразовывается так, что на выходе каждого следующего узла появляется какая-то реакция в виде другого сообщения и так далее, пока сообщение не пройдет через все узлы. Это тоже вариант визуального программирования, подходящий для некоторых применений, в особенности, например, всяких сетевых стеков.
P.S. ИС Дракон как форт IDE
@ «В каждой шутке есть доля шутки»
Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.
Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.
Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.
Вот и всё.
И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.
В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.
Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.
Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.
Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.
И так далее и такое прочее.
Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.
Кстати управление освещением по датчику освещенности и движения есть и у меня.
Но тут возникает нюанс, когда не жесткий реал-тайм вдруг превращается в жесткий, а система об этом ни слухом ни духом.
Например, если вдруг "включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре", а нагреватель вдруг взял и не выключился через секунду. И через час не выключился. И полив так и льет весь день.
Мне всегда это мешает спать и я при любом удобном случае перелезу на систему жесткого реалтайма.
Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.
ИМХО, хороший тон — задавать максимальное время включения.
Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».
Та же история с нагревателем. Или с насосом.
Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.
И еще — аппаратная защита. Скажем полное откубание питания всей системы при переливе бочки, предрхранители опять же.
И можно спать спокойно:) Ну если нервы крепкие:)
Некоторые вон АЭС строят — и ничего, спят сладко:)
То, что вы описали — это отказ, а не «реал-тайм». При исправном устройстве — такое невозможно.
Только если датчик или пускатель из строя выйдет. Ну или программа повиснет. Но на то есть вачдог.
Я не договорил. А если нагреватель или полив все-таки выключится, но через день — это считается отказом? Проблема в том, что считать исправной системой, а что неисправной и как определить этот порог нагрузки системы, после которого могут происходить отказы. В системах жесткого реального времени это сделать очень просто — все сигналы опрашиваются каждый цикл времени, время работы алгоритма известно и поэтому определить и, главное, протестировать в каком случае система гарантированно будет работать, а в каком откажет, очень легко. В случае же событийной системы неисправная система может получиться просто за счет того, что все события вдруг наступят одновременно и очередь стека MQTT просто переполнится. Вы это тестировали? При каком количестве сигналов/событий это может произойти?
ИМХО, хороший тон — задавать максимальное время включения.
Скажем не «включить полив, если датчик замкнут», а «если датчик замкнут включить полив на 20 минут или до размыкания датчика».
Та же история с нагревателем. Или с насосом.
Это называется "добавить детерминизм в систему" — то есть вы создаете гарантированные дедлайны времени отклика. А это уже характеристика систем реального времени.
Ну и второе правило: не управлять по ненадёжной сети. То есть контроеллер не обращается за решением «наверх», а только получает «сверху» парамеры включения устройства, а включает и выключает — сам.
Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.
Некоторые вон АЭС строят — и ничего, спят сладко:)
Я к таким отношусь и сплю спокойно — как раз примерно для таких применений разрабатываю системы жесткого реального времени, но применить такое же решение в системе Умного Дома я не могу, так как стоят они немало. Поэтому приходится идти на риск и пытаться как-то выкручиваться. :-)
Ну часто другой сети нет и не будет. Поэтому надо как-то работать и с этим.
Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.
Сеть — лишь задаёт параметры работы алгоритма. Если она даже упадёт — ничего страшного, алгоритм отработает со старыми параметрами. Скажем проработает тот же полив немного больше или меньше — ну и что? Свет позже выключится? Ну и что?
На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.
Ну и аппаратная защита критичных устройств не даст случиться ничему страшному.
Наверное у вас просто некоторое предубеждение в связи с тем, что вы «как раз примерно для таких применений разрабатываете системы жесткого реального времени». Может не надо переносить в быт атомные технологии?:)
Никто же не боится ездить на автомобиле? А ведь у него комп без тройного резервирования:)
Да фиг с ней с сетью. Я имею ввиду, что сам алгоритм — реализован на контроллере, непосредственно связанным с датчиками и исполнительными устройствами.
Сеть — лишь задаёт параметры работы алгоритма.
Но так вы начинаете серьезно себя ограничивать в архитектуре системы. Уже нельзя сделать распределенную систему, где один датчик мог бы давать информацию сразу нескольким системам, или возможность подключать датчики и исполнительные устройства в любых физических точках системы и настраивать их на виртуальные входы/выходы. Также теряется огромное преимущество в том, что имея центральный мощный контроллер, вы можете делать сложные вещи, а не писать все для пукалок типа ESP-8266.
На самом деле — «умный дом» всё же не атомная станция. Время отклика в секунды — спокойно обеспечивается даже в моём варианте контроллера.
Конечно, не атомная станция. Только не забывайте напоминать себе, что данное время отклика — это всего лишь вероятностная величина, которая рано или поздно может устремиться в бесконечность. Я себе об этом постоянно напоминаю, что позволяет не забывать про очевидные вещи. Но лучше бы, чтобы напоминать не надо было вообще.
Так на работе я и пишу все для линукса на мощных контроллерах. Но для управления светом или поливом ничего сложнее пукалок и не надо:)
Требования просто разные. Дома мне надо, чтобы было просто и дешево. Из чего я и исходил.
Кстати, у меня есть возможность задавать с одного датчика данные всем модулям, если их несколько в сети.
Только надо еще время актуальности задавать и смотреть что делать, если параметр устарел.
В общем старая задача — как при ненадежной сети пострить вменяемую систему:)
Только не забывайте напоминать себе, что данное время отклика — это всего лишь вероятностная величина, которая рано или поздно может устремиться в бесконечность.
Вы, я вижу, опытный спец:) Но если пойти дальше — то вообще всё устройство работает на базе вероятностных величин.
Если так пойти, то:
Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.
Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.
Если с транзистором всё в порядке — отказать может реле.
Если реле не отказало — может оборваться провод или отгореть клемма:))
И так далее. Но это всё теории. Реально, конечно, защиты нужны, но в разумных пределах. ИМХО.
Если ваша программа выдала сигнал, то с ненулевой вероятностью выход контроллера откажет и сигнал не попадёт на базу транзистора.
Если сигнал попадёт на базу транзистора, то с ненулевой вероятностью транзистор оборвётся или пробьётся.
Если с транзистором всё в порядке — отказать может реле.
Если реле не отказало — может оборваться провод или отгореть клемма:))
Это на самом деле не такие уж маленькие вероятности, как вам кажется, и от них есть вполне рабочие защиты. Например в системах, где моторы поднимают платформы с людьми, всегда используется двойной разрыв силовой цепи двумя независимыми контакторами и реле и с контролем срабатывания. А для защиты от залипания, например, у меня все выходы импульсные — т.е. транзистор включается только если на его входе есть импульсы. Если же на выходе будет статический ноль или единица — то транзистор закроется.
Это защиты, которые уже годами отработаны и там все в разумных пределах.
Но я говорю о другом типе вероятности — в случае с событийными системами ваша вероятность будет меняться вместе с нагрузкой системы — пока она маленькая — время реакции прогнозируемо и низкое. Но когда она начнет подниматься и количество сообщений расти — время реакции может неожиданно для вас измениться. А может вы об этом даже и не узнаете сначала. С обрывами выводов и отказами реле все можно легко спрогнозировать, сымитировать и сделать защиту. А вот как быть с событийной системой?
Но когда она начнет подниматься и количество сообщений расти — время реакции может неожиданно для вас измениться. А может вы об этом даже и не узнаете сначала. С обрывами выводов и отказами реле все можно легко спрогнозировать, сымитировать и сделать защиту. А вот как быть с событийной системой?
Ну так это уже не про мой примитивный контроллер с несколькими событиями в секунду максимум.
Я не спец по высоконагруженным системам с временем отклика в миллисекунды. Совсем не спец.
А можно ли рассмотреть вариант модификации, при котором в прошивке можно было бы настраивать Relays & Inputs на произвольные GPIO?
Чтобы иметь возможность использовать Вашу замечательную программу не только на Вашем же контроллере а и на обычных Sonoff (dual), Electrodragon WiFi Relay, etc?
А WiFi-реле… В ESP-01 c 512К моя прошивка не влезет. Увы. ESP-07 был взят именно потому что там 1Мегабайт памяти.
Может стоит сделать урезанную плату с одним реле и возможностью подключить несколько датчиков? То же самое WiFi-реле, но умнее.
Разница в цене будет не велика, зато помимо дистанционного управления по MQTT можно будет сделать «умный алгоритм». Например, включать освещение не только по команде, но и по датчику освещённости и движения.
Скажем, если в комнате темно и кто-то там есть — включить свет. Или не включать, если поздно (можно на сервере MQTT публиковать и время). В общем — количество степеней свободы растёт многократно.
Кстати, я как раз для тестов своей прошивки микро-проект сделал для освещения — потом выложу.
Входные данные — уровень освещённости (АЦП), время (MQTT), команда (MQTT) и выключатель (INPUT1), датчик движения (INPUT2).
Управляют освещением все три реле.
Первое — «ночник» (включается если в комнате кто-то есть и время обозначено как позднее) текущее время и какое время считать «поздним» — публикуется в MQTT.
Вторая — нормальное (включается если в комнате кто-то есть и время обозначено «вечернее», но в комнате темно).
Третья — полное освещение — (включается если в комнате кто-то есть и время обозначено как «раннее», но в комнате темно).
Выключатель-кнопка меняет по кругу все режимы (отключено-ночник-норма-полное-автомат).
Так же по MQTT можно управлять режимом напрямую.
Будем посмотреть как работает:)
Пока ещё не тестировал толком.
Всё зависит от задачи. Я ж не проектировал абстрактный контроллер. Я проектировал вполне конкретный контроллер для задач управления «небыстрыми» процессами.
Почти все эти алгоритмы «умных вещей»: водонасосной станции, из которой родилась идея проекта, управление освещением, вентиляторами, поливами, нагревателями и много-много ещё чем обладают общими свойствами: нет жесткого реал-тайма (задержки реакции могут быть секунды, а то и минуты безо всякого вреда); всё управление — событийное: то есть включение-выключение исполнительных устройств сводится к анализу наступления того или иного события, как то срабатывание датчика, превышение уровня, истечение интервала времени и так далее.
Ну и обязательно нужна та или иная связь с сетью. Я остановился на MQTT для общения через интернет и на UDP-multicast для общения модулей между собой по локальной сети.
Вот и всё.
И опять же — далал всё «just for fun»:) Это уж потом заинтересовались знакомые и начали просить платы. Они же и надоумили меня вытащить всё это в виде статей на хабре.
В предыдущей статье описано, как это всё рождалось. Сокращенно, разумеется.
Что касается «ноутбука с SDK». Да, ноутбук с SDK — это сила. Но ещё в предыдущей статье я писал, что проглядев десятки проектов на ESP8266 я увидел, что по сути все эти SDK применяются для того, что у меня реализуется 5-10 узлами.
Ну, например: включение вентилятора при заданной температуре и включение нагревателя при другой заданной температуре.
Или: управление освещением по MQTT и датчику освещенности. Три уровня света: аварийное, норма, повышенной яркости. Ну и полное отключение.
И так далее и такое прочее.
Я, пожалуй, посвящу следующую статью микро-проектам на ShIoTiny. Именно такого уровня. Заодно и по узлам пройдусь — что кто делает и как.
Так что те, кто хочет — пусть SDK пользуют, кому нравится — JavaScript и Lua. Ну а самые суровые могут и на ассемблере писать:)
Никого не призываю отказаться от убеждений и привязанностей.
ShIoTiny: узлы, связи и события или особенности рисования программ