Предложения по web-интерфейсу контроллера и WB-MGE

Добрый день! Сформировались некоторые предложения, которые прошу рассмотреть:

  1. По редактору правил:
    1.1. Помимо кнопки “Сохранить” сделать кнопку “Проверить”, по которой осуществлялась бы только проверка кода без его загрузки. Полезно при значительном объеме редактирования для своевременного устранения ошибок без активации добавляемого функционала и перезагрузки правил..
    1.2. В синтаксисе описания правил помимо значения newValue для триггера whenChanged добавить значение oldValue, поскольку оно весьма часто требуется для оценки произошедших изменений. Сейчас же приходится городить внешние переменные. Также удобно было бы в тех же триггерах иметь возможность обработать утерю связи с модулем (неактуальность значения).
    1.3. Кнопка вставки шаблона пустого правила в редакторе правил.
    1.4. 5. На больших файлах сильно не хватает элемента управления, сворачивающего и разворачивающего блоки {} для упрощения навигации, желательно - запоминанием состояния при сохранении.

  2. По системному журналу:
    2.1. Возможность задания фильтров в URL, чтобы можно было открыть в браузере закладку сразу с необходимым набором фильтров.
    2.2. Возможность сохранять последний поисковый запрос, поскольку чаще всего возвращаться приходится к одному и тому же. Можно было бы при повторном открытии устанавливать те же значения фильтров, которые были в “прошлый раз”, а интерфейс дополнить кнопкой сброса фильтров.
    2.2. Кнопка сброса значений фильтров.
    2.3. Возможность выгрузки журнала в файл за период без загрузки его в окно. Порой нужен бывает длинный лог, который устаешь листать до нужного места.

  3. В разделе истории показаний датчиков добавить справочную информацию о формировании значений, интервалах их сбора и, особенно,
    о значениях “дельта”-показателя, графически отображенного заливкой. Сейчас из интерфейса не очевидно, что имеет место некоторое усреднение (группировка) значений.

  4. Управление serial-устройствами:
    4.1. Упрощение переноса устройств между линиями в mqtt-serial, в т.ч. включенными через MODx (снятие блокировки на дублирование SlaveID или автоматизированный перенос между линиями).
    4.2. Подсчет количества настроенных устройств в диалоге поиска serial-устройств.

  5. Хотелось бы, хотя бы в виде отключаемой опции, чтобы в заголовке вкладки web-интерфейса контроллера в браузере в его начале было видно, какой именно раздел открыт. Это актуально при наличии нескольких открытых вкладок, что бывает весьма часто. Кроме того, когда вкладок реально много, то видимая длина ярлыка закладки становится короткой, чтобы вместить условное “Wiren board UI - Устройства”, и нужно сокращать до условного “WBUI - Устройства” или “WBUI - DB - Demo Dashboard” (возможно даже оставлять только последний элемент иерархии).

  6. Виджеты устройств:
    6.1.При настройке элементов в виджетах хотелось бы иметь возможность принудительно указать статус “readonly” для отдельных элементов, например состояние реле у релейного модуля, чтобы показать состояние реле, но защитить его от случайного переключения пользователем.
    6.2. . При добавлении элемента хотелось бы иметь возможность ввести что-то типа “21*8”, чтобы сразу отобразилось “wb-mio-gpio_21:1/Counter 8”. Очень актуально для устройств со значительным количеством элементов, а также для устройств, которым назначены сетевые адреса менее 100 (в поиск по “21” попадают и устройства с адресом 21, и 121, и 213).
    7. WB-MGE: реализовать в web-интерфейсе управление индикторами (вкл/выкл).

Здравствуйте. Благодарю за ожидание..

1.1 - согласен, запишу в книгу пожеланий.
1.2 - а почему не использовать переменные для отслеживания предыдущего значения?
Потерю связи с модулем можно отслеживать простой конструкцией.
1.3 Что значит пустого правила? уточните пожалуйста


2.1 - интересно, добавлю.
2.2 - про кнопку очистки фильтров тоже добавлю
2.3 - сомнительно, но тоже добавлю


3 - вся справочная информация находится в вики.


4.1 не понимаю зачем, если можно физически переставить девайс на другую шину и провести поиск. Все настройки подтянутся из девайса в конфигуратор (пока в testing)
4.2 тоже непонятно зачем. И как понять, что устройство “настроено”? Опишите предполагаемый кейс, пожалуйста.


5 - хорошо, запишу.


6.1 - интересно, тоже запишу.
6.2 - запишу


7 - зачем? опиште свой кейс… обычно, индикаторы на устройстве оотображают тот или иной статус устройства. Если вам нужно отобразить свои статусы - можно использовать сторонние индикаторы..

Цель в том, чтобы, по возможности весь функционал, связанный с изменением / актуализацией значений иметь в одном месте, в одном программном блоке правила. Вариант с использованием “asSoonAs” с “#error” этого не обеспечивает, да и в принципе способен обработать только ошибку, но не восстановление, обработку которого придется не только городить в “onChanged“, но и еще доп.переменную для этого заводить. Предложение же - в том, чтобы иметь возможность обработать все в рамках одного правила. Ведь утрата значения с утратой актуальности его предыдущего значения - это тоже изменение. Вот и хотелось бы при создании правила иметь возможность задать для канала таймаут, по истечении которого при утрате связи будет вызвана функция правила с параметром, отображающим утрату связи. Ну и, соответственно, при восстановлении связи тоже при вызове флаг какой-то выставлять. Потому как базовая же история почти для любой автоматизации - учет предыдущего значения параметра при его смене.(ну, кроме логических) для принятия решения о реакции. А так каждый вынужден городить что-то.

Речь о вставке текст правила в редакторе конструкции вида (типа макроса, что, кстати, и для других типовых конструкций):

defineRule({
whenChanged: ““’,
then: function (newValue, devName, cellName) {
}
});

Вот, аккурат кружочка с буквой “i” и ссылкой на соответствующую страницу wiki и не хватает:-)

Практический смысл такой: исходно устройство подключаем на свободный порт (тестовой шины) RS485, тестируем оборудование, возможно - отлаживаем логику правил. После чего уже перемещаем устройство в целевую локацию. На сегодня его параметры не сохраняются.

Цель: косвенный контроль того, что при поиске все ранее добавленные в систему устройства подключены. Условно: пришли проводить работы, устройств было 17. Что-то переключали, добавляли, заменяли. Чтобы на финише работ убедиться, что отвечающих устройств: 17 минус изъятые плюс добавленные.

Тут все совсем просто: нужна возможность просто отключить световую индикацию, чтобы не мешала.

почему же нет? вот второй блок с else как раз про восстановление связи:

defineRule("onChange", {
  whenChanged: "wb-mr3_48/K1#error",
  then: function (newValue, devName, cellName) {
    if(newValue !== "") {
      Notify.sendSMS("...", "relay is broken");
    } else {
      Notify.sendSMS("...", "relay is OK");
    }
  }
});

На счет предыдущего значения тоже сомнительно, поскольку систем управление сколь угодно много и может появится, например, условие валидности значения - тогда, что угодно записывать в прошлое значение будет неправильным и надо будет строить фильтр перед записью…

Сомнительно, поскольку это конструкция также опциональна. вместо whenChanged может использоваться другой тригер…А может нужно просто виртуальное устройство, без правил…
Тем не менее, я запишу в книгу..

Согласен, хорошо.

В testing уже есть функция считывания параметров девайсов, ожидаем в грядущем stable wb-2602 (со дня на день, надеюсь).

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

согласен, такое встречается, запишу.


Есть еще что-либо добавить?

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

И еще, про управление включением и отключением световой индикации на модулях. По-хорошему, это стоит распространить на все устройства, причем с возможностью управлять этим из правил. Цель: отключать индикацию в темное время суток, в частности. Или в рабочем режиме - отключаем, при отладке - включаем.

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

1 лайк