Имеется контроллер, к которому подключены устройства. Требуется отслеживать изменения на устройствах раз в несколько минут и забирать эти изменения с контроллера для последующей обработки.
Было принято решение собирать данные с контроллера при помощи /etc/wb-mqtt-db.conf из data.db
Если смотреть данные по истории самого контроллера, то отслеживает он их ровно по настройкам /etc/wb-mqtt-db.conf (раз в 2 минуты)
Однако данные внутри самой базы обновляются с неясным интервалом. Вплоть до нескольких часов могут не обновиться. Либо обновятся, но только если перезаписать настройки /etc/wb-mqtt-db.conf.
Требуется решение чтобы данные в БД записывались с установленной периодичностью.
Работа сервиса документирована тут: wb-mqtt-db/README.md at master · wirenboard/wb-mqtt-db · GitHub
Данные в базу записываются по событию изменения значения контрола. Если контрол не меняется (значение остается постоянным) - то записывать его не имеет смысла. То есть фиксируются изменения
У сервиса нет возможности установить желаемый режим, “периодическую” запись.
Логика работы именно событийная. А какую задачу решаете?
Задачу решаем такую: сбор данных сразу с нескольких контроллеров, для последующей обработки и выгрузки в общую базу данных.
Я знаком с документацией и понимаю, что данные записываются по изменению значения.
Проблема в том, что значение на устройстве меняется. История через web-приложение по запросу на нужный канал отображает изменения с установленной в 120с периодичностью.
Однако если я скачаю data.db, в которую заносятся данные, то записи об этих изменениях там отсутствуют. Через N количество времени (обычно это часы) файл data.db обновится и все эти изменения там будут записаны. Но для моей задачи требуется чтобы файл data.db хранил актуальные данные на момент последнего опроса.
Вот тут не понял.
Что значит “скачаю”? То есть файл базы данных, с которым прямо в это время происходит работа, дескрипторы которого открыты - скачивать? Но зачем? Точнее - какой именно результат ожидается?
Файлы любой БД не предназначены для перемещения.
С БД слежует работать именно через ее методы. Если мне, например, нужно получить данные из истории - я использую RPC доступ к ней.
Описан в документации.
Я как-то пропустил ваше сообщение, прощу извинить.
Ноо подход к решению задачи “выкачать файл БД” - работать не будет.
Вы правы, что это плохая практика, но база данных типа SQLite на контроллере вынуждает принимать такие условия в работу. Из-за особенностей SQLite он не допускает подключение к базе удаленно для последующей работы с ним в виде SQL-запросов. А файлы требуется перевести в базу типа PostgresSQL.
Работы через встроенные методы - большой объем работ, требующий парсинга полученных JSON файлов, чтобы собрать значения в новую БД. При условии того что работа идет сразу по множеству контроллеров, которые могут отличаться друг от друга как в незначительных деталях так и очень сильно, то для нас такой парсинг, а так же последующая обработка данных - работа с высоким риском ошибки.
Миграция же с одного типа БД в другой (с SQLite на Postgres) после скачивания не несет таких рисков ошибок и затрат времени.
Поэтому если вариант со скачиванием вы считаете неприемлемым, то поставлю вопрос по иному - как мне тогда получить самые последние актуальные значения в другую удаленную базу данных, не вытаскивая их в виде JSON файлов, которые после надо обрабатывать, а оставляя их в виде .db?
Вариант разбирать методами всю БД, а потом собирать ее заново - практика не лучше, чем копирования файла