Category: it

Category was added automatically. Read all entries about "it".

Оффтоп, накипело.

В чем причина холивара между Си программистами и почти вымершими программистами на ассемблере?

На мой взгляд, причина очевидная.

На ассемблере среднестатистические веб страницы не пишутся.

Также как и не пишутся широко востребованные нативные приложения.
Широко востребованные нативные приложения пишутся чаще всего на Си а то и на СиШарп или даже на Джава.
Но для быстрой разработки приложения на Си, Си программист должен взять огромное количество чужих разработок (это ведь основной плюс? Наличие данных наработок).
Однако, очень часто качество этих сторонних разработок вызывает сомнения, например Си библиотеки Ардуино. Какого-же качества продукт получаем в итоге? А да, ведь количество перерастает в качество? Точно?

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

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

Ассемблер не нужен там, где вы пишете 110-ую версию всем известного приложения, например для опроса датчика температуры. Вы это можете, и можете себя смело называть программистом.

Но ваши труды основаны на трудах тех, кто создает технологии, процессоры и подобное. Тестирует это все в машинных кодах и на ассемблерах. А потом вы берете их труды и называете их недалекими, потому что думаете, что они не способны писать на Си.

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

А я и дальше продолжу создавать решения не зависящие ни от кого.

P.S. Хотите большой и чистой автоматизации без Си и Веб извращений? Постараюсь помочь!

Гидропоника

Допустим, я занялся гидропоникой и хочу использовать свой проект для автоматизации процессов.

Здесь я опишу возмодности проекта и что именно я буду делать на первых шагах.



И так, у меня есть модули для различных датчиков качества воды, типа такого:

Еще есть дозаторы типа (или даже проще, один двигатель, без логики):

Ну и нужен свет.




Казалось бы что проще? Берем ардуино, качаем с сайта производителя https://atlas-scientific.com документацию по протоколу, реализуем его на ардуино (либо даже берем готовую библиотеку, наверное она где-то есть)
И все делаем сами, т.е. сценарии, информирование, удаленный доступ, сбор статистики и прочее, прочее, прочее.

Но я же все эти вопросы уже решил в своем проекте.
Проект представляет из себя три ключевых узла - Java контроллер, сервер, клиент. Также есть различные собственные конечные устройства и различные шлюзы.

Для работы конкретно с вышеописанными устройствами я могу использовать мини компьютер с шиной I2C, либо любой другой компьютер с большим набором UART (например USB-UART устройства).
На этом компьютере будет работать Java контроллер, он будет выполнять все взаимодействие с устройствами, в том числе и выполнять различные сценарии. Данные контроллер будет передавать серверу, а тот их отдавать клиентам и агрегировать.

Мне незачем знать API/протокол EZO устройств, они уже реализованы в проекте (кроме дозатора, об этом позже).

Точно также обстоят дела и с другими устройствами, например управление светом, датчик открытия двери и прочее.
Теоретически я их всех могу подключить к мини компьютеру через GPIO. Но что делать с обычными компьютерами?
Можно прикупить китайских железяк и подключить их по USB к примеру.

Но я пойду другим путем. Жаль, сейчас нет железок под рукой, фото будут позже.
Я возьму решение от Dipex. Мы разработали множество различных модулей.
Среди них есть модули специально для EZO модулей, есть USB шлюз с шиной DipexBus, есть мини компьютер с платой расширения DipexBus, есть специальный модуль для диммирования светодиодных ламп со стабилизацией по току. У нас много железяк, и некоторые специально разрабатывались для данной задачи.

Да, DipexBus проприетарная, но и ее протокол мне не нужен, все в проекте. Мне не за чем работать с DIpex модулями напрямую, так же как и с EZO модулями напрямую.

В итоге, я подключаю USB-DipexBus шлюз в любой компьютер или использую мини компьютер с платой расширения I2C-DipexBus. К нему подключаю EZO Dipex модули (в любом количестве) вставляю в них EZO модули и подключаю датчики. Также на шину подключаю Dipex LED диммер, DIpex IO модули и прочее.

Вот в качестве примера (только здесь другие модули и без корпуса):
photo_2020-05-20_18-30-39.jpg

Таким образом я объединяю DipexBus'ом все свои датчики и исполнительные устройства. Шина реализована на RS485 с поддержкой до 128 устройств.

По поводу дозатора. Мы не стали использовать дозаторы от atlas-scientific, у нас обычные дозаторы (двигатель на 18 вольт) которые управляются отдельным многоканальным модулем Dipex. Библиотеки дозатора atlas-scientific в проекте нет, но его можно добавить при желании.

Теперь программная часть.

Как минимум мне нужен Java контроллер. Он будет выполнять сбор данных, управление и обработку сценариев (логика), передачу данных и событий на сервер для дальнейшей передачи этих данных клиентам, агрегации, информирования, и прочее.

Клиент - отображение показаний, управление устройствами и настройка сценариев и проекта.
Он может работать через сервер или напрямую (если клиент и контроллер находятся в локальной сети)

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

TODO: позже добавлю здесь видео.


Вот теперь мы добрались до API (на тот случай, если полнофункциональный клиент чем-то не угодил). Если мы не хотим использовать сервер и планируем выполнять его задачи сами, то в принципе можно реализовать на базе API свое решение и работать с контроллером напрямую (в точности как это делает клиент).

Либо можем работать через сервер, и здесь варианты:
В данном случае нам нужен итоговый результат. Т.е. показания устройств, статистика, возможность изменять налету проект и сценарии.
Все это можно сделать через аналогичный API (также использует клиент).
Сервер поддерживает несколько подключений, через которые можно использовать API:
- внутренний бинарный протокол (можно предоставить Java библиотеку с его реализацией)
- голый TCP с JSON
- HTTP с JSON
- WebSocket c JSON
Документация будет доступна после написания.

Кроме этого, управлять и собирать показания можно через так называемые точки входа - Telegram, Алиса, email, HTTP и прочее. Методы работы специфичны для каждой точки доступа. Документация также будет доступна после написания.



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

Пока все, буду обновлять по необходимости.

P.S. По поводу пожеланий, я постараюсь найти время и выполнить ваше пожелание (например написать документацию по API). Но при одном условии - Вам действительно нужна эта документация (чтобы я не писал ее в пустую сейчас)

Update 03.01.2021

Я благодарен пользователям, которые оставляют мне комментарии. Благодаря им я вижу о чем забыл сказать или о чем стоило бы повторить.

Ранее я не раз говорил, что мое решение представляет из себя конструктор, т.е. мой конечный клиент либо интегратор, либо самоделкин (DIY любитель).

Клиент, который я предоставляю, является основным инструментом для интегратора. Пользователь тоже может им пользоваться, но для пользователя он будет слишком громоздким и не совсем удобным.
Зачем пользователю такой клиент, если ему нужно просто включать свет в паре комнат?

Конкретно для пользователя я сделал точки входа. Например точку входа Телеграмм или Алиса, где пользователь может управлять устройствами гораздо удобнее. Также были созданы виджеты под Android, которыми я сам пользуюсь очень часто (моя жена пользуется телеграмом и ее вполне это устраивает). Возможно в этом году я стану разработчиком под ios и у нас появится клиент и виджеты под iphone.

Но, в рамках данной задачи (гидропоники), для специалистов я бы создал специальный веб проект, где были бы выведены многочисленные графики, сгруппированы показания, выведены специальные элементы модификации проекта (параметров устройств и сценариев).
API открытое, этим проектом может заняться сторонняя компания, а можно обратиться в Dipex Group - они могут разработать дизайн, WEB портал и разместить его в своем ЦОД'е.

core5277, новая версия

Новая версия 0.2.5

1. Скорректирован драйвер DS1990A
2. Добавлена дополнительная проверка на присутствие датчика в драйвере 1WIRE
3. Восстанавливаем регистр Y в процедуре io/log_bytes.inc
4. Добавлены процедуры чтения и записи байта/блока в EEPROM
5. Добавлен проект для Atmel Studio 7 ./inc/examples/aqua_module/
6. Переименована процедура rom_to_ram_copy8.inc в rom_read_bytes.inc
7. Дополнены файлы микроконтроллеров ./inc/devices/
8. В процессе драйвер mlx90614

Главное - теперь проект можно открыть в Atmel Studio и он даже соберется.
Но все-же, я считаю, тру подход - linux+geany+avra+avrdude

Может быть на выходных запилю небольшую инструкцию для новичков.

http://5277.ru/distr/core5277/core5277.tar.gz

Сценарии на базе 'скриптов'

  Я не раз задумывался о том, как я буду реализовывать скрипты в своем проекте. Речь идет о скриптах для расширения возможностей сценариев, т.е. вместо заполнения параметров формы мы могли бы написать необходимый код. У этой задачи был довольно низкий приоритет, да и проект я позиционирую так, что знание программирования не обязательно.
  Было много разных мыслей, вплоть до написания своего интерпретатора типа Бейсик, разработки встроенного редактора и тому подобное.
Но вот сегодня меня наконец-то озарило, идея в следующем:
  Мне не нужен никакой редактор или интерпретатор, мне нужно сделать ровно тоже самое, что я проделал с кодом отвечающим за функционал устройств, шлюзов и сервисов.
А именно - описать Java интерфейс и на базе его создавать Java библиотеки реализующие необходимую логику.
Тогда, я просто ввожу в клиенте, в сценарии, в блоке условий новый элемент - Java библиотека. В котором задается вендор и сама библиотека и контроллер теперь знает какой код запускать.

При этом данные библиотеки будут разрабатываться кем угодно, также будет некий стандартный набор.

Новый элемент (Java библиотека) будет также в блоках 'Информирование' и 'Управление', что даст практически полную свободу разработчику.

Оффтоп. Современный разработчик

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

И это проявляется во всем. Assert который был заброшен давным давно на Java, оказывается широко применим на C# среди разработчиков не отстающих от моды.
Стоит ли говорить, что это используется для примитивной валидации данных?

Майкрасовтовский WPF популярен, но его контейнер аналогичный hbox/vbox в JavaFX и андроиде реализован так, что остается куча вопросов, хотя все должно быть примитивно. Да и разрабы пошли дальше, они используют сторонюю платную библиотеку, компоненты которой не могут быть даже отображены в инструментарии Microsoft.

А синтаксис. Ради того, чтобы разраб писал одну строчку а не две, был усложнен заметно синтаксис. Зачем? Разве главный трудоемкий процесс у программиста это набивание строк? Я то, наивный, думал, что основное качество кода - его читаемость и однозначность, после конечно вопросов ресурсов.

А Spring - фреймворк для Java? Сейчас в требованиях у почти любой вакансии Java разработчика требуется его знание. Здесь у меня даже нет слов. Мне в крупном проекте не нужен фреймворк, который говорит мне что делать и который хрен поймешь как работает. У меня есть свои наработки моделей и наработки библиотек, которые гораздо лучше фреймворков. Зачем мне их знать? И чем сложность в них разобраться после опыта создания не менее сложных проектов от и до своими руками?

А да, а как вам функциональный метод программирования в C# - в ООП языке? Раньше за это по голове били, теперь это круто и модно.

API проекта автоматизации 5277. Структура данных ответа на запрос выбора локации.

Для коммуникации между собой таких узлов как клиент, контроллер и сервер я использую бинарный протокол.  Моя Java библиотека, с реализацией этого протокола, может преобразовывать его в JSON.  Для удобства чнетия я привожу описание структуры именно на JSON.

  *Это больше ознакомительная часть, чтобы иметь представление как оно работает. Вся детальная информация будет описана в отдельной документации.

  Здесь я опущу заголовочные данные пакета и рассмотрю только тело:


SCB - блок сценариев
LOCATIONS - блок локаций


TIMESTAMP - метка времени(в миллисекундах) последнего изменения сценариев, для определения актуальности данных
SCENARIO_GROUPS - блок  с группами сценариев


ID - идентификатор группы сценариев
LOCATION_ID - идентификатор локации, к которой привязана данная группа
DISABLED - сстояние группы(заблокирована или нет)
NAME - имя группы
SCENARIOS - блок сценариев данной группы


ID - идентификатор сценария
DISABLED - сстояние сценария(заблокирован или нет)
NAME - имя сценария
COMMENT - комментарий к сценарию
PARAMS - блок параметров


ID - идентификатор параметра
TYPE_ID - тип параметра
VALUE - данные параметра(структура и данные зависят от типа параметра)
*детально параметры сценария будут описаны отдельно

Блок SCB рассмотрен, возвращаюсь к верхним элементам.

ID - идентификатор локации
SERIAL - серийный номер контроллера(десятеричная форма), к которому привязана локация
NAME - имя локации
ICON - имя иконки локации
COMMENT - комментарий к локации
INTERROGATE_PERIOD_ID - идентификатор периода опроса устройств
AGGREGATION_PERIOD_ID - идентификатор периода выгрузки данных в БД для статистики
DISABLED - сстояние локации(заблокирован или нет)
IS_LINK - признак локации из другого проекта
PLACES - блок помещений в данной локации
GATEWAYS - блок шлюзов для конечных устройств
DEVICES - блок конечных устройств
GROUPS - группы конечных устройств(для режима вывода наборов показаний, вместо упорядоченного списка устройств с показаниями)
PERMS - блок разрешений, в рамках локации, для пользователей
DATA - блок с данными


ID - идентификатор помещения
NAME - имя помещения
ICON - имя иконки помещения
COMMENT - комментарий к помещению


ID - идентификатор шлюза
TYPE_ID - идентификатор типа шлюза
DEVICE_ID - идентификатор устройства в линейке устройств производителя
VENDOR_ID - идентификатор производителя
PARAMS - параметры устройства(ниже будут описаны на примере конечного устройства)
OWNER_IFACE_ID - идентфикатор физического порта интерфейса к которому подключено данное устройство(входящий).
IFACE - физический порт иннтерфейса который соединен с устройством к которому подключается данное устройство.


ID - идентифкатор интерфейса
IFACE_TYPE_ID - идентификатор типа интерфейса(например UART)
IFACE_NUM - порядковый номер интерфейса(например '0' - UART0)
PARAMS - блок параметров интерфейса


ID - идентификатор параметра
EXT_PARAM_ID - идентфикатор параметра из табличных данных описания набора интерфейсов и параметров каждого типа шлюза(дает гибкость системе, позволяя расширять систему буквально налету)
TYPE_ID - идентификатор типа параметра
SUBTYPE_ID - подтип идентификатора параметра(позволяет описать несколько параметров одного типа)

 Возвращаемся назад.

ID - идентификатор конечного устройства
TYPE_ID - идентификатор типа конечного устройства
NAME - имя конечного устройства
PLACE_ID - идентификатор помещения
COMMENT - комментарий к конечному устройству
INTERROGATE_PERIOD_ID - идентификатор периода опроса конкретного устройства
DISABLED - сстояние устройства(заблокирован или нет)
PARAMS - блок параметров устройства
DEVICE_ID - идентификатор устройства в линейке устройств производителя
VENDOR_ID - идентификатор производителя
GATEWAY_ID - шлюз, к которому подключено данное устройство, null - подключено непосредственно к контроллеру
ICON - имя иконки конечного устройства
AGGREGATION_PERIOD_ID - идентификатор периода выгрузки данных конкретного устройства в БД для статистики
AGGREGATION_EVENT_ID - идентификатор события вне периодической выгрузки данных конкретного устройства в БД для статистики
EXTRASCAN - признак поддержки конкретным устройством функционала экстренного опроса конечных устройств
PERMS - блок разрешений в рамках данного устройства для пользователей(аналогичен PERMS в описании LOCATION)
OWNER_IFACE_ID - идентфикатор физического порта интерфейса к которому подключено данное устройство(входящий).
IFACE - физический порт иннтерфейса который соединен с устройством к которому подключается данное устройство(аналогичен IFACE в GATEWAY).


ID - идентификатор параметра
PARAM_ID  - идентификатор типа параметра
VALUE - значение параметра
SUBTYPE_ID - подтип параметра(например для параметра 'Имя показания' здесь содержится идентификатор типа показания)

Возвращаемся назад.

ID - идентфикатор группы
NAME - имя группы
ICON - имя иконки группы
PLACE_ID - идентификатор помещения
COMMENT - комментарий к группе
*все вышеперечисленные параметры используются аналогично как и в DEVICE
SORT - значение для сорировки групп
ITEMS - блок элементов группы


ID - идентификатор элемента
DEVICE_ID - идентификатор конечного устройства
MEASURE_TYPE_ID - идентфикатор типа показания
NAME - имя показания
SORT - значение для сортировки элементов


ID - идентификатор разрешения
USER_ID - идентификатор пользователя
TYPE_ID - идентификатор типа разрешения


ID - идентфикатор локации
DEVICES - блок данных конечных устройств


ID - идентифкатор конечного устройства
MEASURES - блок показаний конечного устройства


TYPE_ID - идентификатор типа показания устройства
VALUE - значение показания устрйоства


Как сказал ранее, здесь далеко не вся информация, запросов и различных типов ответов большое количество.

Кроме описания структуры и данных таких параметров как значения PARAMS есть еще большое количество табличных данных, в которых описаны практически все данные с которыми работает система.
К примеру, если рассматривать показания, то в таблицах можно найти их типы, иднетификатор текста для словарей, идентификатор единицы измерения, идентификатор типа данных и цвет.
В свою очередь единица измерения содержит идентификатор текста для словарей, идентификатор базовой единицы измерения и множитель. Т.е. система понимает, к примеру, как амперы, так и миллиамперы и может их, при необходимости, преобразовать.

Все это дает некоторую гибкость системе и позволяет ее достаточно легко расширять без участия разработчика.

Сценарии, начало.

  Пожалуй самое сложное в проекте, в вопросе описания использования, это редактирование проекта и сценарии, попытаюсь описать работу с формами сценариев.

  Итак, выбираем в меню 'Настройка сценариев'.


  Мы видим форму групп сценариев, она достаточно проста, здесь можно делать базовые действия с группами: создать, удалить, редактировать, обновить и закрыть. Ничего особенного. Единственное, что необходимо знать - здесь нет механизма блокировки редактирования как в конструкторе(редактор проекта). Описанные операции над группами выполняются сразу же.


Создаем группу.
  Изначальное состояние группы - заблокировано, это означает, что контроллер не будет выполнять сценарии внутри этой группы. Рекомендую снять галку только после описания всех сценариев группы.
Объединение сценариев в группы имеет больше тематический характер, хотя есть и особенность, ведь группу можно включать и отключать(а также можно создать сценарий который будет выполнятся при этих действиях).
Этим можно воспользоваться, к примеру, занести в группу 'Сигнализация' все сценарии отвечающие за контроль дверей и прочее. Ну или скажем создать группу содержащую сценарии имеющие отношение ко временам года(хотя в самих сценариях можно указать периоды работы, например определенные месяцы).
  На этой форме, как и на предыдущей, есть кнопки стандартных действий: добавить, удалить, редактировать, обновить и клонировать. Последняя позволяет быстро сделать копию сценария.
  Также, внизу формы, есть кнопка 'Активировать изменения'. Эта кнопка передает все ваши текущие наработки в данной группе на сервер(или контроллер). До нажатия этой кнопки все изменения хранятся только на данной форме.


  Перед созданием сценария  важно запомнить, что под запуском сценария подразумевается запуск анализа данного сценария контроллером, действия, такие как информирование или управление будут выполнены только при успешном выполнении всех условий данного сценария.

Создаем сценарий.
  Стандартный заголовок, опять же галка 'заблокировать', имя и комментарий(который можно не заполнять).
Далее идут блоки:
1) Причина запуска - описывает причину запуска, т.е. при каких условиях контроллер приступит к анализу данного сценария.
2) Внешние факторы - по сути это дополнительные условия, которые могут влиять на выполнение сценария, например отменить его анализ или заставить контроллер проигнорировать другие условия(например период действия).
3) Период действия - по сути, это фильтр, позволяет указывать когда разрешать дальнейший анализ сценария.
4) Условие - здесь мы можем задать различные условия на базе показаний от устройств, которые также повлияют на дальнейший анализ сценария.
5) Информирование - а это уже исполнительная часть, ее выполнит контроллер только если предыдущие условия это позволили. Здесь мы можем сказать системе что сообщать и куда сообщать.
6) Управление - тоже исполнительная часть, заключительная. Здесь мы можем указать различные действия, например послать команду конечному исполнительному устройству, или запустить другой сценарий на другом контроллере, или выполнить внешний скрипт на машине где запущен контроллер.


  Теперь детально:
Причина запуска:
1) Запуск группы сценариев - будет запущен при снятии галки 'заблокировать' данной группы. Это полезно, если необходимо при включении группы выполнять ряд действий, например послать всем устройствам управления команду 'вкл'.
2) Только системный вызов - означает что данный сценарий может запустить только другой сценарий.
3) В назначенное время - можно указать время(часы и минуты) когда требуется запустить сценарий, при этом можно указать время для повторного запуска. Контроллер будет выполнять повторы, скажем если было задано время запуска 00:00 с повтором каждый час, а текущее время создания данного сценария скажем 13:45. Т.е. запуск будет выполнен в 14:00, 15:00 и .т.д.


4) Обновление показания устройств - анализ сценария будет запущен когда обновятся данные показаний участвующих в анализе(блок 'Условие')
5) Нажатие виртуальной кнопки - в конструкторе(редактор проекта) можно добавить виртуальную кнопку. Здесь можно описать эту кнопку, таким образом можно запускать сценарий нажатием кнопки устройства в клиенте.


6) Написана/произнесена фраза - запуск осуществляется когда с точки управления(Телеграм, Алиса и прочее) поступает фраза. Здесь выполняется ее анализ. Также можно задать фразу которую получит пользователь в ответ.


7) Случайно - запуск сценария осуществляется случайно, проверка раз в минуту, здесь требуется указать вероятность(1/100 - вероятность 1 раз в 100 минут) т.е. для вероятности раз в две минуты нужно указать 50/100 или 1/2.


8) События от устройств - некоторые устройства могут посылать специальные события, по которым контроллер запускает сценарий.


9) Смена состояния контроллера - здесь речь о соединении с сервером, можно запускать сценарий при успешно
установленном соединении или при недоступности сервера. Также можно указать время ожидания.


10) Смена состояния устройства - аналогично предыдущему, но здесь также можно определять перезагрузку для некоторых устройств.


11) Остановка группы сценариев - аналогично первому пункту, но здесь срабатывает сценарий когда мы ставим галку 'заблокировать'

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


  Период действия
1)  В любое время - блок просто игнорируется
2)  В течении периода(простая форма) - здесь все просто указываем период, день часы и минуты начала и день, часы и минуты окончания. В течении этого периода анализ будет продолжен.


3)  В течении периода(расширенная форма) - здесь используется методика планировки задач в crontab. Мы можем указать время, дату и дни недели в течении которых будет продолжен анализ. Используется логическое и. Т.е. если время или дата или день недели не попадает под условие то анализ будет прерван. В полях день, месяц и год можно использовать разделитель ',' и диапазон(через '-'). При наведении на поле появится подсказка.


  Условие
  Пожалуй это самый сложный блок. В нем два элемента 'По показаниям устройств (логическое 'И')' и 'По показаниям устройств (логическое 'ИЛИ')'. Т.е. для успешного анализа, условия правил внутри блока должны быть или все истинны или истинно хотя бы одно соответственно.
  Далее видим кнопки:
  1) Добавить формулу - используется если нам нужно сделать какое-то вычисление на базе показаний в добавленных правилах или констант.
  2) Разрешает повторное выполнение сценария, если мы получили событие от устройства, даже если сам снимок показаний не изменился. Актуально для таких устройств как инфракрасный датчик для ИК пультов. Он может принять одинаковую последовательность данных, что должно быть интерпретировано как еще одна команда.
  3) Разрешает выполнение сценария при первом показании. После запуска контроллера или изменении в проекте существует ситуация, при которой старого значения показания нет, а оно нужно для анализа сценариев. Т.е. анализ выполняется только при изменении показания, отсутствие старого показания не означает, что само показание изменилось. Включенная кнопка означает, что контроллер будет считать, что показание все же изменилось.
  4) Блокировка частого выполнения сценария. Существует внутренний триггер, который после успешного выполнения сценария защелкивается и не позволяет повторное выполнение до тех пор, пока сценарий не пройдет анализ. Таким образом, к примеру,  Вы не будет получать одно и тоже сообщение каждый раз когда контроллер выполнит один и тот же успешный сценарий. Отключение кнопки отключает анализ триггера.
  5) Кнопки + и -  позволяют добавлять правила и удалять выбранное правило.


  Добавим правило.
  Мы увидим дерево устройств, в нем нам нужно выбрать устройство чьи показания мы будем анализировать.


  После выбора появился элемент списка с нашим устройством и внутренним списком условий. Который состоит из номера, названия показания, условия, значения(может иметь разный вид в зависимости от типа показания и условия) и кнопки '+'. Последующие элементы списка имеет кнопку '-', для удаления текущего элемента. Добавление новых элементов осуществляется кнопкой '+' первого элемента(первый элемент удалить нельзя, но можно удалить элемент верхнего уровня).


  Далее. Здесь мы выбираем нужное показание, указываем условие и значение этого условия(можно также указывать диапазоны и пороги).
  Порог нужен для описания работы еще одного триггера - локального триггера для каждого условия. Работает схоже с триггером описанным ранее. Его задача также не допускать повторной отработки сценария.
Принцип следующий. Он срабатывает, когда значение показания достигло указанного условия, т.е. условие истинно только при первом анализе, даже если при повторном значение также достигло указанного условия. Сброс триггера выполняется только тогда, когда показание отклонилось в обратную сторону с учетом дельты в указанный период.
  Т.е. если мы создали условие на температуру больше 20 с порогом в 1, то триггер будет установлен при температуре больше 20 и снят при температуре меньше(20-1).

  Теперь о формулах. Формула также имеет номер , поле для ввода условие и значение для условия. А также кнопку проверки корректности введенной формулы. С помощью меню(правая кнопка мыши) можно подставить показания устройств которые должны быть добавлены заранее. Как и с условиями по показаниям само условие может отсутствовать.


  Таким образом данный функционал позволяет выстраивать цепочки логического 'И' или 'ИЛИ' с любым набором устройств и с любым набором условий для каждого устройства. А также можно добавлять формулы.


Информирование
1)  Никому - блок просто игнорируется
2)  Только мне - информирование будет выполнено только автору сценария
3)  Группе - информирование будет выполнено только для участников группы(пока не реализовано)
4)  Всем - всем в проекте, кто может получать информирование

  Форма для всех типов выглядит одинаково.
  Верхняя часть элементов:
  1)   Метка - в клиенте будет подсвечено красным показания присутствующие в условиях блока 'Условие'
  2)  Сообщение - сообщение будет выведено посредством клиента.
  3)  Телеграм - сообщение получат все пользователи с точкой входа 'Телеграм'
  4)  Эл. почта - аналогично, но для эл. почты.
  5)  СМС - аналогично, но для смс(пока не реализован шлюз, смс стоят денег)
  6)  Звук - на контроллере будет проигран звуковой файл.


  Далее два поля: описание заголовка и основной текст сообщения. Здесь через меню(правая кнопка мыши) можно подставить константы, показания устройства или просто значение показания. Показания выбираются из блока 'Условие'
  Для включенного режима 'Звук' доступны галки повторять(при окончании проигрывания оно будет заново запущено) и 'Останавливать' (проигрывание будет остановлено если при повторном выполнение сценария анализ не был успешно завершен).
  Далее поле для ввода названий файлов, можно перечислять через ',', тогда контроллер будет выбирать файл случайно из указанных. И последнее поле - громкость.

Управление
1) Не управлять - игнорируем данный блок
2)  Управлять устройствами - здесь мы можем добавить несколько устройств, команды которых мы планируем выполнить.
3)  Запуск сценариев - аналогично, здесь мы добавляем сценарии, который планируем выполнить.
4)  Остановка сценариев - аналогично для остановки. На данный момент остановка нужна только для проигрывания звукового файла.
5)  Запуск внешнего скрипта - bash команда или файл выполняется на стороне контроллера
6)  Здесь можно выбрать сценарий, который не принадлежит текущему контроллеру. Т.е. текущий сценарий будет проанализирован скажем на контроллере А, а выполнен сценарий на контроллере Б.



Пример использования
  Это тестовый набор сценариев, обычного термореле(теплый пол). Задача - включать обогрев при температуре меньше или равно 35 градусам и выключать при температуре больше либо равно 36 градусам.

Первый, на включение обогрева.


Второй, на выключение обогрева.



  Заключение
  В общих чертах вроде бы все описал. Конечно есть множество деталей. Но не думаю, что на практике они будут иметь большое значение. Разве только в каких-нибудь очень сложных проектах, однако такой подход я считаю не совсем корректным. Если решение сложное, его должно выполнять специализированное, цельное решение(конечное устройство) а не набор из многих.
  И потом, можно было бы сделать скрипты, которые позволили бы реализовывать более гибкие решения,но на текущем этапе я не сталкивался с задачами, которые нельзя было бы описать здесь без скриптов.

update: добавил картинки