Vega Server

[a.malnev]

Вопрос к разработчикам все еще в силе.

Вопрос к разработчикам.

Возможно ли одновременное подключение к файлу базы данных сервера нескольких приложений?
Есть потребность периодически чистить быстрорастущую базу от старых записей, а сервер останавливать не хочется.
До каких размеров может вырасти файл базы данных без потери производительности сервера?

Добрый день!
1. К SQLite БД конечно подключение может быть только одно.
К MySQL и Postgres могут быть множественные подключения. На практике можно попробовать случай когда каждый из серверов обслуживает свои БС и их зоны видимости не пересекаются. Т.е. базовые станции одного сервера "не видят" устройства других серверов. Иначе будут мешать друг другу вплоть до полного рассинхрона
2. В сервере заложен функционал автоматического слежения за размером очереди данных. Обратите внимание на группу "[database]" в настройках. Сейчас время хранения данных фиксированное - 1 год и каждый день происходит очиста БД от устаревших данных. Возможно есть смысл вынести в настройки максимальное время хранения данных от устройств?

[a.malnev]

Но суть вопроса про ожидаемый ответ не меняется..

Еще раз повторю: связь вообще может быть односторонней БАЗА->СЕРВЕР. Базе, для того чтобы отправить на сервер данные, никакого ответа не требуется.

Хотелось бы почитать что-нибудь от разработчиков относительно протокола сетевого взаимодействия уровня приложения между сервером и базовой станцией. Или это NDA ?

На базах Веги работает свободно распространяемое ПО Semtech UDP Packet Forwarder. Документация и исходники находятся в свободном доступе на github.com

В настройках упомянутого выше Semtech UDP Packet Forwarder указывается только один адрес для передачи данных. Соответственно и данные БС может передавать только на один адрес (на один сервер - если не параллелится поток на принимающей стороне).
Если другой сервер знает адрес БС, то и ему ничего не мешает передавать данный на ту же БС.

[petrov_ab]

Конечно не мешает. Ну а дальше? Адрес сервера не просто так в БС прописан, и данные с "чужого" адреса она просто проигнорирует. Я больше скажу - если БС зарегистрировано на одном сервере, на втором она уже не зарегистрируется. Проверено неоднократно. Иначе все было бы очень плохо с точки зрения нормальной работы сети.

[senswet]

Добрый день. Спасибо за ответ.

Обратите внимание на группу "[database]" в настройках. Сейчас время хранения данных фиксированное - 1 год и каждый день происходит очистка БД от устаревших данных. Возможно есть смысл вынести в настройки максимальное время хранения данных от устройств?

У меня в группе "[database]" есть только два параметра:
taskOptimizationTime=21:00:00
defragPeriod=30.
Первый понятно о чем. Второй - период дефрагментации в днях. Разве он имеет отношение к удалению старых записей? Тем более если вы говорите, что по умолчанию удаляются записи возрастом более года, каким образом в моей базе данных оказались записи всего 2018 года?

В настройках упомянутого выше Semtech UDP Packet Forwarder указывается только один адрес для передачи данных. Соответственно и данные БС может передавать только на один адрес (на один сервер - если не параллелится поток на принимающей стороне).

Речь как раз о дублировании пакетов и шла. То есть база шлет данные не на сервер, а шлюзу, который клонирует пакеты на разные серверы.

[a.malnev]

Добрый день. Спасибо за ответ.

Обратите внимание на группу "[database]" в настройках. Сейчас время хранения данных фиксированное - 1 год и каждый день происходит очистка БД от устаревших данных. Возможно есть смысл вынести в настройки максимальное время хранения данных от устройств?

У меня в группе "[database]" есть только два параметра:
taskOptimizationTime=21:00:00
defragPeriod=30.
Первый понятно о чем. Второй - период дефрагментации в днях. Разве он имеет отношение к удалению старых записей? Тем более если вы говорите, что по умолчанию удаляются записи возрастом более года, каким образом в моей базе данных оказались записи всего 2018 года?

Добрый день! Сегодня еще раз проверим работу данной части.

[Support]

Добрый день!

Вопрос к разработчикам все еще в силе.

Вопрос к разработчикам.

Возможно ли одновременное подключение к файлу базы данных сервера нескольких приложений?
Есть потребность периодически чистить быстрорастущую базу от старых записей, а сервер останавливать не хочется.
До каких размеров может вырасти файл базы данных без потери производительности сервера?

Как писал ранее мой коллега, в сервере был заложен функционал чистки БД от устаревших данных. После проверки мы выяснили, что на данный момент, упомянутая функция не работает. Мы обязательно это исправим в грядущем релизе сервера.

Если Вы используете SQLite, можно расширить возможности работы с БД, перенеся данные в другую СУБД. Достаточно настроить MySQL или PostgreSQL, указать данные в конфигурационном файле сервера. Данные будут перенесены автоматически.

Напоминаю о важности производить резервное копирование БД, перед каким-либо вмешательством в её работу.

[Brokly]

Добрый день !

Отлаживаю только что разработанное устройство с использованием вашей базовой станции БС-1, знаю уже не выпускается, но вопросы будут по серверному софту. Работаю в частотном плане EU868, с планом RU868 ничего не получается даже у оригинальных устройств, грешу на устаревшую станцию.

1. В режиме ОТА устройство нормально дружится со станцией, в ответе JoinAnswer в месте CFList получаю данные, непонятные, всегда разные, длинна соответствует, все остальное непонятно. Что это такое и зачем ?

2. Сильно разочаровало отсутствие поддержки MAC команд DeviceTimeReq/DeviceTimeAns, удобная и нужная функция, кстати легко реализуемая.... Ожидается ли поддержка этой команды вашим софтом ?

3. С MAC командами чехарда какая то. Если я пытаюсь сам использовать эту фичу, загоняю любую команду устройству через сервер, используя API, то первая команда зависает. Шлется постоянно, с каждым пакетом, и последующие команды уже не проходят. Причем в поле Type этот факт отображается, а вот в поле MacData - пусто. Имеется в виду протокол получаемый через API. Как отправить следующую мак команду ? Или это ошибка софта ?

C уважением.

[Brokly]

Классная у вас поддержка ))) Прям моментальная !

[Support]

Добрый день!

Добрый день !

Отлаживаю только что разработанное устройство с использованием вашей базовой станции БС-1, знаю уже не выпускается, но вопросы будут по серверному софту. Работаю в частотном плане EU868, с планом RU868 ничего не получается даже у оригинальных устройств, грешу на устаревшую станцию.

1. В режиме ОТА устройство нормально дружится со станцией, в ответе JoinAnswer в месте CFList получаю данные, непонятные, всегда разные, длинна соответствует, все остальное непонятно. Что это такое и зачем ?

2. Сильно разочаровало отсутствие поддержки MAC команд DeviceTimeReq/DeviceTimeAns, удобная и нужная функция, кстати легко реализуемая.... Ожидается ли поддержка этой команды вашим софтом ?

3. С MAC командами чехарда какая то. Если я пытаюсь сам использовать эту фичу, загоняю любую команду устройству через сервер, используя API, то первая команда зависает. Шлется постоянно, с каждым пакетом, и последующие команды уже не проходят. Причем в поле Type этот факт отображается, а вот в поле MacData - пусто. Имеется в виду протокол получаемый через API. Как отправить следующую мак команду ? Или это ошибка софта ?

C уважением.

1. CFList - список дополнительных частот, сообщаемый сервером, устройству (см. LoRaWAN Specification). Правильно парсить данное поле, помогут таблицы из документа (LoRaWAN Regional Parameters).

2. Данная команда поддержана в тестируемой версии сервера, предполагаем, что в скором времени будет релиз. Для работы с данной командой потребуется:
- Базовая станция с GPS
- Устройство класса А

3. Действительно, была такая ошибка. Она уже исправлена в тестируемой версии сервера.

Классная у вас поддержка ))) Прям моментальная !

Прошу прощения, за столь длительное ожидание ответа. Если Вам потребуется задать срочный вопрос, рекомендую написать на почту support@vega-absolute.ru или позвонить по телефону 8-800-550-41-35.

[Brokly]

Большое спасибо за ответ !

1. CFList - список дополнительных частот, сообщаемый сервером, устройству (см. LoRaWAN Specification). Правильно парсить данное поле, помогут таблицы из документа (LoRaWAN Regional Parameters).

Я в курсе. Я же написал, что содержимое не соответствует документации правообладателя. В частности последний байт CFList должен быть равен 0, только тогда этот список несет содержимое о частотах. У вас этот байт не нулевой, всегда разный. Список частот состоит из некоторого количества частот , каждая из которых занимает по три байта, иными словами это без знаковое число 24 бита, содержащее частоту в герцах деленную на 100. У вас эти данные не имеют никакого отношения к реальности, они всегда разные. Это ошибка ? Или это намеренно передаваемые данные? Если второе, то что это ?