Нет данных через Lora2TCP

[IgorMaevskiy]

Здравствуйте, у нас для тестов на стенде имеется один абонент СИ-13-485 и одна базовая станция БС-2. Из ПО на серверной машине запущен Vega Server и Vega2TCP. Кроме того на другой машине сети развернут Admin Tool, через который добавлены станция и абонент - у станции статус Active, абонент ее видит, лог абонента показывает передаваемую через него информацию на сервер нормально. У Vega2TCP на сервере есть связь с сервером и добавлен абонент, у которого напротив "Доступность" тоже стоит галка. НО при этом по открываемому Lora2TCP порту никакие данные не идут (в логах кроме "Установлено соединение с сервером VEGA" ничего не появляется).
Кроме логов подключаюсь к открытому порту прогой Advanced TCP/IP Data Logger, она подключается, но данных там нет. При подключении в Lora2TCP пояаляется галка напротив "Есть клиент".
Из вопросов:
1) нужно ли каким то "хитрым" способом конфигурировать Lora2TCP (кроме ip сервера и данных авторизации ничего не менял)?
2) как можно увидеть данные от абонента, проходящие через открытый порт?

[IgorMaevskiy]

Проблема была в том, что сервер разворачивался на виртуальной машине. На нормальной системе всё нормально, данные через порт, открытый в Lora2TCP, приходят.
Другой вопрос, поделитесь опытом, если в системе 50 абонентов и открыто, соответственно, 50 портов. Как и чем лучше эти данные оттуда считывать, например, для записи в файл или передачи в скаду?

[petrov_ab]

Про виртуальную машину - странно, у меня читалось нормально. Может быть разрешения какие?
Чем читать - так СКАДой и читайте. В описании устройств в канале указывайте нужный порт.

Я пользуюсь несколько другим методом - Lora2Modbus. Там в зависимости от потребностей "читалки" можно по разному настроить - либо один IP (сервера) и отдельный TCP порт на каждое устройство либо один порт и смещение блока регистров для каждого устройства. У меня и так и так - первый вариант для SCADA, второй для PI (MES система). Причем оба шлюза прекрасно себя чувствуют на одном сервере и работают с одними же и теми модемами. Единственный недостаток - Lora2Modbus работает только на чтение, управлять через него никак.

[svsh1990]

Другой вопрос, поделитесь опытом, если в системе 50 абонентов и открыто, соответственно, 50 портов. Как и чем лучше эти данные оттуда считывать, например, для записи в файл или передачи в скаду?

ИМХО плохой вариант работать с кучей датчиков в прозрачном режиме. Лора для такого не предназначена, особенно если речь идет про онлайн мониторинг показаний.

[IgorMaevskiy]

А в чем проблема работы Лоры с большим количеством абонентов в прозрачном режиме?

[airbit]

А в чем проблема работы Лоры с большим количеством абонентов в прозрачном режиме?

В том сеть LoRaWAN для этого, на наш взгляд, не предназначена.
Прозрачный режим генерирует слишком много пакетов, т.к. обмен в нем, как правило двусторонний (в формате запрос-ответ).
Если опросы производить редко то еще ничего. А если требуется постоянно что-то мониторить и опрашивать - то это уже будет явно нарушение.
Так, например, в диапазоне частот 864-865 МГц устройство после передачи 1 пакета максимального размера 51 байт на SF12 должно "молчать" в течение 2793 секунд, т.е. целых 46 минут. При качественном приеме на SF7 дела обстоят намного лучше - устройство должно "молчать" всего лишь 2 минуты. В диапазоне 866-868 МГц уже по-другому: 279 и 11 секунд соответственно.
Вот и подумайте на сколько растянется при этом опрос устройств...

P.S. ситуацию можно было бы улучшить при условии реализации режима LBT в устройствах, но все равно как мне кажется это все не то. И правильным будет перемещать всю логику с сервера на конечное устройство, которое будет генерировать в сеть только обработанные данные, которые нам нужны.