Запись данных

Точка данных знает только свое текущее значение. Любой, кто хочет узнать, насколько тепло было прошлой ночью или сколько электроэнергии было потреблено за прошлую неделю, нуждается в адаптере, который записывает данные. Существует три таких адаптера, и решение следует принимать заранее, поскольку последующая замена потребует дополнительных усилий.

Не следует путать с двумя внутренними базами данных для объектов и состояний. Они поддерживают текущее состояние системы и обрабатываются с помощью Redis . Это касается истории.

Точка данных знает только свое текущее значение. Любой, кому нужны исторические данные, может активировать запись и выбрать, где именно они должны быть записаны.

Что представляет собой этот курс и чего он не представляет собой.

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

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

Это приводит к четырём вещам, которые регулярно вызывают неожиданности:

• Запись начинается с момента включения устройства. Ретроспективная запись отсутствует, даже за вчерашний день.
• Данные записываются в каждой отдельной точке. Сама система не включается; вместо этого записывается каждое отдельное значение, которое вы хотите просмотреть позже.
• История не хранится во внутренних базах данных. Объекты и состояния представляют текущее состояние; история хранится в другом месте, см. Redis .
• Резервная копия ioBroker не включает это автоматически. Она создает резервные копии объектов, состояний и конфигураций. Записанные значения являются отдельным элементом в BackItUp .

В системных настройках, в разделе «История по умолчанию» , можно увидеть, какой экземпляр предлагается в диалоговом окне или на диаграмме при запросе источника. Это настройка по умолчанию, а не записанная история: источник по-прежнему будет выбираться для каждой точки данных.

Какой адаптер?

Функция истории сохраняет данные в два этапа: сначала значения сохраняются в оперативной памяти, а в файлы записываются только при достижении заданного порогового значения. Это защищает карту, но также означает, что самые последние собранные значения будут потеряны в случае отключения электроэнергии.

Файлы находятся в папке, расположенной ниже./opt/iobroker/iobroker-data без предоставления собственной информации вhistory , а внутри этой папки — по одной подпапке на каждый день. Абсолютный путь, например:/mnt/history Это также возможно, например, на подключенном запоминающем устройстве. Местоположение данных важно для целей резервного копирования; см. ниже.

Для начала, история . Для этого не требуется второй сервис, а переход на InfluxDB возможен позже, см. ниже.

Запись означает перемещение данных на SD-карту, а запись расходует ресурсы SD-карты. Тем, кто регулярно записывает большие объемы данных, следует делать это не на SD-карте, а на SSD-накопителе или в базе данных на другом компьютере.

Включать

Адаптер устанавливается, создаётся экземпляр, а затем для каждой точки данных принимается решение о том, следует ли её записывать. Это делается на вкладке «Объекты» с помощью значка шестеренки в конце строки.

Конфигурация экземпляра содержит настройки по умолчанию, применяемые к каждой вновь активированной точке данных. Эти настройки можно переопределить непосредственно в точке данных.

Запись начинается с момента включения устройства . Ретроспективная запись не предусмотрена.

Пошаговый процесс описан в разделе «Запись значений» .

Важные настройки

Полное описание всех полей можно найти в документации соответствующего адаптера: history , influxdb , sql .

Что следует записывать, а что нет.

Наиболее распространенная причина замедления работы системы через год — не недостаток вычислительной мощности, а то, что кто-то записал все данные, потому что они могут когда-нибудь понадобиться.

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

Переход от адаптера истории к базе данных.

Адаптер истории включает в себя скрипты для этой цели, которые находятся в каталоге./opt/iobroker/node_modules/iobroker.history/converter лежать и сnode быть вызванным. Рекомендуемая процедура:

1. Настройте и запустите новый целевой объект. Сконфигурируйте новый адаптер и включите на нем те же точки данных. Убедитесь, что значения принимаются. В это время данные будут записаны дважды: один раз в историю и один раз на новый целевой объект. Это сделано намеренно, чтобы ничего не было потеряно во время миграции.

2. Анализ существующих данных. Скрипт анализа определяет, какие данные уже существуют в целевой системе, и сохраняет результаты в JSON-файлы. Он вызывается в каталоге конвертера:

cd /opt/iobroker/node_modules/iobroker.history/converter
node analyzeinflux.js influxdb.0 info --deepAnalyze

Соответственно, для базы данных SQL:

node analyzesql.js sql.0 info

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

3. Остановите и преобразуйте адаптер истории.

node history2db.js

Скрипт считывает JSON-файлы из шага 2 и переносит только то, чего еще нет. Затем он продолжает запись файлов, поэтому второй запуск обычно не создает дубликатов. Его также можно вызвать без предварительного анализа; в этом случае необходимо указать начальную дату в качестве параметра, и все данные до этой даты будут преобразованы. Этот процесс может занять много времени.

4. Только после этого следует выполнить очистку. Как только значения в целевом объекте будут заполнены и это подтвердят журналы: удалите данные истории и деактивируйте адаптер.

Перед миграцией создайте резервную копию . Удаляйте старые данные только после того, как новые данные будут достоверно полными, и для проверки этого сверьтесь с графиком, охватывающим длительный период времени.

Полный список параметров для трех скриптов можно найти в документации к адаптеру истории .

Что происходит во время срабатывания предохранителя?

Здесь распространено ошибочное мнение, которое может дорого обойтись: резервная копия ioBroker не содержит записанных значений. Она сохраняет объекты, состояния и файловое хранилище — то есть текущее состояние системы. История хранится в другом месте, и это относится ко всем трем адаптерам.

• В разделе истории файлы действительно находятся ниже...iobroker-data Однако эти файлы не входят в резервную копию ioBroker. При использовании абсолютного пути они в любом случае находятся вне резервной копии.
• В случае с InfluxDB и SQL данные хранятся в отдельной базе данных, зачастую даже на другом компьютере.

Поэтому BackItUp перечисляет их как отдельные типы резервных копий , создаваемые в дополнение к резервной копии ioBroker: History Data , InfluxDB , MySQL , PostgreSQL и SQLite3 . Эти параметры не установлены по умолчанию.

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

Вид

Зарегистрированные значения оцениваются в виде диаграммы, обычно с использованиемecharts Маршрут показан в разделе «Схемы» .