Добрый день! Прошу ответить про мониторинг Wiren board 7. То что Wiren board является как бы обычным компьютером вызывает слишком много вариантов для передачи данных мониторинга на windows сервер, в том числе и самых тупых, типа логов на wirenboard в smb- шару, поэтому прошу проконсультировать. Можно ли на самом wiren board скриптами повесить действия на изменение параметров оборудования? с применением ШТАТНЫХ средств Wiren board без дополнительной разработки.
на уровне если такой параметр, то слелать то-то.
И есть ли возможность из Windows ШТАТНЫМИ для Windows средствами отследить эти события?
Добрый день.
У меня мало опыта работы с Windows системами.
А какой из стандартных протоколов обычно используете для передачи логов между системами?
Да, конечно можно. Скриптами. Собственно контроллер автоматизации для этого и предназначен. То есть отслеживание входных параметров и управление исполнительными устройствами.
Да, например: Примеры правил — Wiren Board
А какие средства - штатные? Есть где-то описание открытых протоколов?
Вот например: Использование Grafana с контроллером Wiren Board — Wiren Board скрипт который пишет в БД данные. Достаточно вместо вызова записи данных вызвать запись по используемому протоколу.
Довольно абстрактный вопрос, да. В голову приходит такое:
- PowerShell + MQTT — забрать данные с контроллера.
- PowerShell + Write-EventLog — записать событие в журнал Windows.
Нативно для Windows и на контроллер ничего ставить не надо. Про MQTT в контроллере можно почитать у нас в Вики.
Штатные средства - это значит, что не требуется докачивать ПО к имеющемуся в Wiren board и Windows. графона, mqtt.dll, как я понял, могут и не быть в составе ПО.
Необходима обеспеченность инструментарием уровня написания правил типа “если параметр в таком-то диапазоне, то сделай действие”. потому как если сложность разработки будет выше, то это другой уровень решения задачи и привлечения сил.
Насколько я понимаю из ответов, решение в лоб для передачи данных в Windows - это написание правил для Wiren bоard, которые генерят файлы-семафоры в папке, которая расшарены по SMB или ещë как, а уж Windows просканирует папку.
Другие варианты требуют написания гораздо более сложного ПО, пусть и на скриптах. или развëртывания дополнительного ПО типа Syslog коллектора и опять-таки дополнительного анализа.
Конечно, с Забикс на отдельном сервере всë было бы проще, но здесь организационные сложности.
Да это все в общем под windows и на обычном VBS написать можно.
Как пример GitHub - Bsm-B/MQTTBasic: Example VB.net MQTT Client using M2Mqtt library
Ну или питон GitHub - eclipse/paho.mqtt.python: paho.mqtt.python
Просто личшние сущности, такие как “фалы в папке” - надежность понижают.
То есть настраивать VB.net, качать откуда-то питон, непонятно откуда mqtt, создавать проекты, инициализировать структуры, изучать несколько смежных и в корне различных технологий? Не говоря уже о проблеме разрешений в госконторах на средства разработки.
А пользователям надо знать только то ПО, коьорое работает с мониторируемой системой. яи естественно управлять и настраивать только с него.
В то время как “технология” файлов-семафоров вполне себе широко использовалась на т. н “больших” юниксах и, наверное, до сих пор используется судя по некоторым продуктам. простейшие командные файлы живут десятилетиями. Не шучу, есть варианты с прошлого века, там менялись только команды сна ( с досовского be sleep, к нынешнему timeout) да правила реагирования на новые семафоры, которые правятся НЕКВАЛИФИЦИРОВАННЫМ персоналом по шаблону. меняются операционки, платформы серверов ( были и UNIX- папки) . В то время как vbs- скрипты, (были и такие) и программульки на дельфях и т. д. уходили в прошлое при очередной смене платформы. Менялись программы, которые создавали семафоры. но мониторинг вëлся.
Конечно, нативная программа, которая тупо контролирует систему и по триггерам совершает действия или оповещает, немного лучше, но это если непосредственно входит в ПО управления и работает в терминах данной системы.
Wirenboard в первую очередь предназначен для построения систем “умный дом” или похожих систем управления оборудованием. В этой области экосистема Windows встречается крайне редeко. Поэтому найти готовые инструменты которые будут отправлять данные в журнал Windows будет сложно. Это не стандартное применение. Поэтому да, нужно что-то сделать для интеграции в используемую вами экосистему.
1 лайк
Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.