Работа с файлами в wb (и взаимодействие с внешним миром через сторонние веб-приложения)

[CyrillU]

Доброго дня,

Возникла потребность писать некоторые данные в отдаваемый наружу файл (например, csv с изменениями, или, в идеале, делать на лету json для внешнего сервиса).

Как следствие, вижу два вопроса:

1. Как можно встроенным http-сервером wb обрабатывать запросы не к штатному веб-интерфейсу, а произвольные? условно, отдавать некие данные на запрос к http://wb_ip/somedata?someheader=somevalue). Либо гире - можно ли на wb сделать отдельное веб-приложение со своим интерфейсом и своей логикой?
2. Если на первый вопрос ответ “да” - а я сильно подозреваю, что как минимум, найти nginx в пакетах удастся, то следующий вопрос - как наладить взаимодействие между внешним миром и данными, которые возникают в процессе исполнения правил? устроит, в принципе, любой вариант - файлы, любая СУБД на борту (mysql, sqlite,…).

Если есть практический опыт - прошу поделиться.

Спасибо!

[BrainRoot]

Добрый день.

@CyrillU

Как можно встроенным http-сервером wb обрабатывать запросы не к штатному веб-интерфейсу, а произвольные?

В контроллере - самый обычной nginx.
Для примера:
Я хочу чтобы при запросе /somerelay/cont?1 реле включалось.
ну и при ?0 выключалось.
Описываю в конфиге сайта так:

    location /somerelay/cont {

        limit_except GET {
            deny all;
        }
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgi-bin/relay.sh;
        fastcgi_param SCRIPT_NAME relay.sh;
        fastcgi_param QUERY_STRING $query_string;
        fastcgi_param REQUEST_METHOD $request_method;
        fastcgi_param CONTENT_TYPE $content_type;
        fastcgi_param CONTENT_LENGTH $content_length;
        fastcgi_param REQUEST_URI $request_uri;
        fastcgi_pass unix:/var/run/fcgiwrap.socket;
        fastcgi_request_buffering off;  # to allow stream-downloading via backend
    }

Скрипт /usr/lib/cgi-bin/relay.sh такой:

#!/bin/bash

send_output() {
    echo "Status: $1"
    echo "Content-type: text/plain"
    echo ""
    echo "$2"
    echo "$3"
}

mqtt_pub_result() {
    mosquitto_pub -d -t "/devices/somedev/somecontrol/on" -m "$1" -r
}


mqtt_pub_result $QUERY_STRING
send_output 200 "result" $QUERY_STRING
exit 0

Результат

wget "http://10.0.0.85:80/somerelay/cont?0" -O -
--2025-01-31 17:50:33--  http://10.0.0.85/somerelay/cont?0
Подключение к 10.0.0.85:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 200 
Длина: нет данных [text/plain]
Сохранение в: «STDOUT»

-                                                     [<=>                                                                                                          ]       0  --.-KB/s               result
0

Ну и соответственно в топик публикуется значение и если вместо топика somedev/somecontrol настоящее значение - реле переключается.

@CyrillU

то следующий вопрос - как наладить взаимодействие между внешним миром и данными, которые возникают в процессе исполнения правил?

Для того чтобы читать исторические данные, например сервис истории имеет RPC метод: GitHub - wirenboard/wb-mqtt-db: Wiren Board database logger
А вообще - размер содержимого топика до 2МБ, можно json прямо в топик публиковать - и по http(s) отдавать. Ну а вообще - довольно общий вопрос, без конкретики нельзя точно ответить.

[BrainRoot]

@CyrillU

устроит, в принципе, любой вариант - файлы, любая СУБД на борту (mysql, sqlite,…).

И да, можно, (конечно!) файлы. Можно и sqlite (сервисами контроллера, тем же wb-mqtt-db используется).
И mysql (mariadb) можно поставить.

[Al-x]

Честно говоря я не уверен, что WB rules стоит использовать при такой задаче. Поскольку движок правил очень тяжёлый, то возможно проще написать приложение на Си или ещё каком языке. В своем время я делал на Си приложение в связке с nginx, даже использовал сокеты с авторизацией и возвратом броузеру в открытом соединении.
Так что в целом нет привязки к ВБ, написать можно на том, что удобнее. Каких-то готовых ВБ методов наверное не подскажу.

[BrainRoot]

@Al-x

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

Реализовывать можно на чем угодно, в общем. Тут дело привычки, скорее. В качестве общей внутренней шины в контроллере MQTT брокер mosquitto, работать с mqtt можно - да из чего угодно.

@Al-x

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

Да, конечно можно. Конфиг “штатного” интерфейса описан в /etc/nginx/sites-available/default. Можно дописать свои ресурсы в него или описать еще один рядом.

[CyrillU]

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

[Al-x]

Стоп, а что мешает использовать mqtt как штатный протокол обмена, а не городить свои приложения и протоколы?

Mqtt много кто поддерживает - от промышленных ПЛК, то китайских модулей с Али. Не у всех конечно, но и не редко.

Правда, если честно, то на ответственное производство я бы WB не поставил, если в команде нет опытного программиста linux систем (ещё лучше реального времени). Не потому что продукт не уважаю, а потому что он всё же под другое заточен, а у меня может рук не хватить сделать заточку профессионально, чтобы гарантированно ничего не зависло и т.п…

[BrainRoot]

@CyrillU

Но параметры техпроцесса надо (хочется) задавать при помощи некоего внешнего приложения / интерфейса,

Для примера: Wi-fi точка доступа плюс клиент - #9 от пользователя sansa26
Но согласен с @Al-x - почему не просто mqtt?

[CyrillU]

@Al-x

Стоп, а что мешает использовать mqtt как штатный протокол обмена, а не городить свои приложения и протоколы?

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

[Al-x]

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

[CyrillU]

@Al-x

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

Я, собственно, и думаю про взаимодействие с правилами через mqtt - но без сторонних костылей, о которых, собственно, исходный пост, этого не реализовать.

[BrainRoot]

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