- В этой теме 43 ответа, 6 участников, последнее обновление 4 года, 6 месяцев назад сделано
.
-
Сообщения
-
Наше вам =)
Приятно, что не я один ковыряю вегу с точки зрения стороннего софта.Прошу простить, что статья про лору еще не вышла. Но есть объективные причины в виде большого количества заказов.
На данный момент разработка КП для работы с LoraWan остановлена в связи с изменением концепции итогового решения.
Некоторые вводные: 230 типовых прибором работающих по ModBus.
Задача: раз в интервал, получать значения регистров с каждого прибора, их интерпретировать и визуализировать. При этом должна быть возможность отправлять запрос на изменения некоторых.
Первоначально была идея использовать прозрачный канал обмена через приложение LoraToTCP. Но при увеличении количества объектов, время сеанса связи возросло до неприличия, да и отсутствие гарантии что ответ будет получен, тоже не торт.
А потому стал внимательно смотреть, на то что предоставляет API.После переговоров с Вегой Абсолют, была выпущена специальная прошивка под ModBus устройства, которая позволяет вписать регистры прямо в модем и он (модем) будет их спрашивать с modbus, а потом выдавать в эфир в виде Lora кадром специального формата (так же согласованного с производителем).
Чего я добился: инициатором сеанса связи стал модем. Что значительно сократило время занятия эфира всей сети (ведь раньше БС постоянно отправляла кадры на каждый модем).
На React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora и реализующее логику работы с конечным устройством.Выглядит приложение вот так:
что-то с картинкой не так. Ссылку даю так : https://ibb.co/nksp8jT
На React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora
Красиво выглядит.
То есть приложение получает данные прямо от сервера Веги в браузер?Добрый день, коллеги!
Не настаиваю, но почему бы нет?
У меня так: — сервер под Виндовс, там же в режиме службы шлюз Lora2Modbus. Там несколько «веселые» принципы по обновлению конфигурации, но тут больше наши внутренние политики безопасности мешают. Все это на разных филиалах.
На настоящий момент число устройств больше полсотни и число каналов (они же тэги в другой транскрипции) больше тысячи. Привязаны две системы отображения:
1. RAPID SCADA — вполне приличные отображалки, натренировался на ней. На нашей станции на Урале это сейчас основная система отображения.
2. PI System (PI AF, PI Vision) — понятно что не SCADA но там очень сильная аналитика да и нам она уже стоила крупных денег — грех не попользоваться.Как уже выше написал стык — Modbus TCP. поскольку принципы стыка в RsSCADA и PI — держу два экземпляра шлюзов на сервере (на самом деле больше — например через СИ-13-485 подключено две метеостанции, у которых передача идет в регистрах ModBus (MK26). Пришлось переделывать конфигурационный файл шлюза, а он определяет устройство по имени файла и внутренним ключам — ну никак без еще одного шлюза не обошлось :)). Здесь проблем нет, как то 5 штук было на одном сервере — не мешают друг другу (имена сервисов разумеется разные) и с данными конфликта нет. Поскольку «штатный» шлюз ВЕГА Lora2Modbus не умеет 9пока) передавать данные к устройству пришлось написать на Python програмку — опросник — вот она идет уже на сервер ВЕГА и напрямую ставит пакет в очередь.
Так что если кому интересно — могу рассказать больше. Один момент — у нас жесткие критери на «служебную информацию» поэтому название компании и кто я и где я — не могу сказать без разрешения определенных служб, а они в Италии 🙂
А зачем? У PI свой шлюз — ModBusE, единственное что если для RAPID SCADA надо каждому устройству (желательно, чтобы не плодить множество конфигурационных файлов) давать свой TCP порт, то для PI я делаю один порт со смещением регистра. Тут еще накладывает свои «удобства» то, что для меня не очень удобно что то менять в конфигурации PI — каждый раз идти на поклон к админам PI и выслушивать что мне это не надо и вообще…
В общем работаю на том, что есть :).Оффтоп: Хотелось бы понять, какими данными оперирует PI при построении аналитики? Только измерениями, которые собираются автоматически или что-то, например, ещё вводится оператором дополнительно?
Насколько мне известно любыми. Вообще это система очень сложная. Само собой мы используем далеко не полный функционал. В Инете есть много чего по PI.
Спустя некоторое время возвращаемся в проект по сбору показаний с приборов учета.
И еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.Хотелось бы отметить, что у каждого свое видение и подход, по этому замечание не принимается! ) Нам достаточно получать данные и лезть для этого в структуры базы данных, которая кстати со временем может измениться, нам не нет необходимости, когда есть описанный API. Да и открывать базу хотя бы на чтение для нас не совсем с точки зрения безопасности, так как сервисы стоят на разных машинах и общаются по интернету. Так что в нашем случае API — это оптимальный вариант.
А так я тоже рад, что мы не одни «ковыряемся» с LoRaWan и Вегой. С Вегой разговариваем на тему выпуска прошивки для СИ-13-485, чтобы была возможность отправления определенных команд в канал для опроса каких-либо устройств, чтобы не опрашивать их с сервера. По логике устройство отправляет пакет с адресом устройства в канал, устройства получившее его и имеющее этот адрес отправляет ответ обратно и этот пакет записывается на сервере, мы лишь опрашиваем сервер раз в период. Пока как-то так.
На днях должны доделать обработку событий и карты, постараемся все описать и выложить.
На счет однотипности устройств, у нас пока с этим беда, порядка 10 разных, приходится под каждый прописывать драйвер, а точнее логику чтения пакетов.
Ну вот как раз я и не приветствую таких подходов, как прямой доступ в базу — с этим я с вами согласен (у нас к сожалению в компании определенный бардак, обусловленный в том числе и национальными особенностями :)). Сам я стараюсь строить из «готовых» кирпичиков. Что то получается, что то не очень.
Буду стараться побольше писать сюда.
- Вы должны авторизироваться для ответа в этой теме.