Кнопку сохранения скрипта прошу вывести за пределы поля написания скрипта, так чтобы не приходилось каждый раз переходить на верх, чтобы сохранить скрипт.
Тоже самое с кнопкой reboot, надо вывести его из девайсов, бывает частенько приходится ей пользоваться при написании скриптов. А при наличии большого количества устройств или девайсов приходится долго ждать пока они все загрузятся и успокоятся.
Как написал выше устройства (девайсес) очень долго грузятся даже по локальной сети. Надо что то с этим поделать. Или не открывать их все, а только нужные, или что то со скоростью загрузки порешать. Речь идет об устройствах когда их много. Возможно удобнее всего просто свернуть те устройства которые не нужны для отладки.
Надо вывести информацию о свободном месте на диске, чтобы постоянно было видно. Чтобы понимать почему завис контроллер чего ему не хватает. Хорошо бы также вывести размер лог файла чтобы понимать что привело к отсутствию возможности сохранения скрипта и .т.д.
Надо придумать кнопку, которая высвобождает память от ненужного мусора. Рядом количество свободного места, чтобы понимать когда стоит нажать.
Хорошо бы видеть список установленных программ (без участия командной строки, мне например это не удобно).
Надо придумать способ оптимизации запросов по шине с целью повышения быстродействия обмена информацией между устройствами и контроллером. Количество устройств известно, также известны используемые регистры (можно лишние исключить автоматически). Также автоматически (может после нажатия какой то кнопки) оптимизировать временные интервалы запросов, задержек и т.д. с целью повышения быстродействия. Иметь каждый раз возможность переоптимизации, при необходимости, после добавления используемых регистров и устройств.
Надо иметь возможность быстрого вызова хелпа (справочной информации) по командам используемого языка написания скриптов прямо с окна написания скриптов. Хелпы, которые есть в различных местах сайта требуют хорошей доработки для быстрого восприятия.
Иметь возможность изменения высоты окна отладки (внизу экрана в разделах написания скриптов и девайсес).
Как я раньше предлагал, было бы очень удобно в окне отладки иметь возможность вмешиваться в работу переменных и т.д. Например их подправлять в реальном времени, чтобы быстрее прийти к результату и т.д. Это из практики работы с другим контроллером, как показывает опыт очень удобно.
Например, при настройке json файлов на сторонние устройства. Чтобы изменения вступили в силу приходится перезагружать контроллер.
Я отталкиваюсь от практической точки зрения. Например, раньше я мог писать лог файл размером 35Мбт и после этого уже не получалось сохранить изменения в скриптах. Как понимаю из за отсутствия места. Удаляем лог файл, обязательно перезагружаем контроллер (снова ребут) и только после этого продолжаем писать скрипты. Так вот если раньше размер лог файла мог быть 35Мбт, то теперь12Мбт. По моему мнению где то какой то мусор накапливается и нужно от этого избавиться, чтобы высвободить место.
Вы не ответили на все мои вопросы, только выборочно.
Я предлагал вам сделать кнопку обновления, нажав на который пользователь мог понять что есть обновление либо нет. Еще лучше вывести сообщение с предложением обновиться через вэб интерфейс, не сложно же написать такой скрипт. Я например не слежу за новостями на вашем сайте и захожу только при возникновении проблем.
Снова возвращаясь к предложениям по совершенствованию WB, которые сейчас обсудили:
Оповещение об обновлении прошивок в вэб интерфейсе.
Вывод информации о состоянии памяти. Список установленных программ, занимаемое им место, свободное место в памяти…
Вывод кнопок Reboot и Save(скриптов) в левый столбик вэб страницы, так чтобы не приходилось каждый раз искать эти кнопки.
Лог-файл, на какой раздел? Скоько на нем места, сколько свободно, чем занято?
Зачем перегружать? Я знаю только одно событие, которое требует перезагрузки: обновление ядра.
Пишется скриптом совершенно без проблем, по расписанию вызывается apt update &&apt list --upgradable |wc -l и результат выводится.
Обновление “прошивки” - это совершенно ненужный способ. Применим только в случае когда полностю меняется версия ОС. Обычный мезанизм обновления пакетами - он намного удобней.
Список пакетов:
dpkg -l
“Занимаемое место” - это интересно… Для того ж mosquitto, например, как считать: с зависимостями, только бинарник, или все вместе с базой данных?
Свободное место в памяти - именно avaliable или плюс отданное сейчас под буфер?
Вот “Save” - согласен на 100%
Кнопка “Reboot” - не нужна совсем… перезагружать для применения настроек - нонсенс…
Да, это добавим.
А в “другом” контроллере программа выполняется без связи с реальнымиокружающими устройстами? Вот отстановил я программу, какое-то событие на которое должна быть реакция произошло - и было пропущено. Зачем? А посмотреть и поменять переменные - можно просто выведя их в интерфейс, например, если лога мало.
У нас подход к взаимодействию с контроллером подразумевает что человек - главный и ему решать что и как контроллеру делать.
Вы ориентируете WB на любителей копаться в линуксе или на широкий круг людей которые готовы строить умные дома на WB? Не нужно заставлять помнить все эти команды, если этого нет на экране. Работаем с экраном не более того.
Удобство вывода на экран информации об обновлении куда удобнее предложенных вами команд.
Нет контроллера рядом подцепиться и точно ответить. Скрипт на сохранить пока не удалить лог и не перезагрузить. Почему не могу ответить вам виднее.
Имелось ввиду обновление контроллера и не плохо бы знать о выходе обновлений прямо в разделе девайсес на каждом устройстве
Ну зачем все это знать если нет этого на экране? Или в хелпе, который можно вызвать нажав вопросительный знак. Кто в линуксе копается каждый день возможно он помнит все команды. А те кто строит умные дома заостряют свою память на совершенно других вещах. У вас хороший получился контроллер только нужно немного допилить для тех кто не любитель линукса)
Все устройства работают в контроллером в реальном времени. Переменные меняются и сохраняются до тех пор пока их не перепишет скрипт. Можно поменять температуру на термостате, а как сделано чтобы не возвращалось на текущее не могу объяснить. Есть какие то правила вмешательства подобного рода для удобства отладки.
Например, скрипт ждет пока наполнится бак с водой. А вода льется медленно. Чтобы этого долго не ждать в отладке меняем значение на полный бак. И так далее. Вот в чем удобство отладки событий которые еще не наступили, но которые можно ускорить в режиме отладки. Я скоро буду переписывать скрипт обратноосмотической установки под WB вот там этот режим отладки очень нужен и смогу ли я обойтись отладкой с помощью логов и подробнее указать на недостатки отладки WB смогу по ходу действий. Смогу сообщить чуть позднее.
это мне совершенно непонятно. В линуксе нет как такового понятия “занимаемое программой место”, это невозможно отследить.
История про невозможность сохранения скриптов, про 12 мегабайт логов - она совершенно ненормальная. Помогите нам пожалуйста с ней разобраться, коллега выше задавал несколько вопросов.
Если включена отладка то вполне нормально может быть большой лог. Смотря что и сколько записывать в лог. Сейчас отлаживаю ПИД регулятор и важно накопить логи хотя бы за пару дней, чтобы потом проанализировать.
Я как понимаю старые логи архивируются и хорошо бы системе понимать что заканчивается место и как то об этом предупредить. Так получается что контроллер продолжает работать хотя писать логи уже некуда и это определяется только после очередной правки скрипта, который не сохраняется.
есть предложение сделать диагностический задатчик импульсов и замыкания контактов, с выставление периода
может быть включить этот функционал в модули входов
я столкнулся с ситуацией когда у меня импульсы считали скорость вращения (4 импульса в минуту) при этом скорость была разная на разных однотипных устройствах, на одних график был более мене, на других были периодические “прыжки”, на третьих вообще прыгал страшно
я думал что этот на устройствах так крутится по разному, но оказалось что это не скорость прыгает (устройства были в трудно доступном месте, не сразу разобрался), скорость оказалась у всех одинаковая
это заббикс агент с mosquitto_sub не в силах был обслужить данное количество узлов равномерно и получалось скорость на графиках прыгала
после того, как я перешел на zabbix 5.2 и стал пользоваться mqtt.get, то графики выровнялись
и сейчас когда есть скачки (очень редко, но бывает), я знаю что это задержки в приеме данных
и по этим графикам в т.ч. видно - все ли в порядке с обработкой данных
мое предложение:
на модулях подсчета импульсов сделать “метроном”, функционал генерирующий импульсы с регулируемой частотой, для диагностики возможностей системы обработки данных, т.е. для определения - за какой промежуток времени, при заданной частоте, система может корретно подсчитывать скорость импульсов
так проще, но это будет инструмент на контроллере
я предлагаю сделать на модуле, он может быть удален от контроллера
мы в этом случае проверяем и линию от модуля к контроллеру и сам модуль
настраиваемая скважность может показать за какой промежуток времени система адекватно может считать скорость по импульсам - начались скачки, значит это предел
Для проверки линии и времени на запрос проще использовать:
export DEV_PORT=/dev/ttyRS485-2
export DEV_ADDR=55
time for i in {1..100}; do modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x03 -r128; done
и разделив на 100 результа - получим время одного запроса.
Ну и планировать скорость реакции исходя из полученного.
