добрый день
Пытаюсь сделать рассчет и тонкую настройку History для параметров электросчетчика и появилось несколько вопросов.
В какой момент времени начинается точка отсчета для min_interval? заметил, что записи для нескольких контролов в одной и той же группе не синхронизированы по времени.
Внеочередное значение пишется ТОЛЬКО в случае, когда за min_interval ничего не поступило или дополнительно к очередной записи?
при записи внеочередного значения время отсчета для min_interval не меняется? т.е. следующее очередное значение запишется через интервал менее, чем min_interval или оно меняется на текущее и следующая запись произойдет через время не менее min_interval?
За какой промежуток времени или интервалов считается max_burst? когда счетчик обнуляется? т.е. при max_burst=5 запишется 5 внеочередных значений до следующего min_interval или это общее количество внеочередных значений для всех записанных values?
max_burst общий для всех контролов в группе или для кажого контрола считается независимо?
Очень хотелось бы видеть в документации более подробное описание параметров, с графическими примерами на шкале времени
min_interval начинает отсчитывается с последней записи этого контрола в историю.
Внеочередные записи будут записываться сразу по получению, без учёта минимального периода записи.
В процессе работы wb-mqtt-db подсчитывает число записей, если в течение min_interval не было сделано ни одной записи, разрешается сделать одну внеочередную.
Поведение таймера min_interval при внеочередной записи в документации явно не описано. Уточню этот момент у коллег.
Максимальное число внеочередных записей ограничено параметром max_burst. При получении нового сообщения по MQTT, будет сделана внеочередая запись, число доступных записей уменьшится на 1. Так будет происходить пока оно не станет равным нулю. Последующие записи будут делаться согласно настройкам, раз в min_interval, будут записаны минимальное, максимальное и среднее значение за интервал.
max_burst задаётся на уровне группы в конфиге /etc/wb-mqtt-db.conf.
вопрос больше был не про “когда”, а “при каких обстоятельствах”.
т.е. внеочередное значение пишется ТОЛЬКО в случае, когда за min_interval ничего не поступило. Так?
это я читал в документации, не понятно…
вопросы на скрине, файл для редактирования прилагаю
где задается я знаю, вопрос был о другом.
Подсчет совершенных внеочередных записей идет для каждого контрола в группе независимо или он “тратится” при внеочередной записи любого контрола из группы?
Накопление (UpdateBurstRecordsCount) срабатывает только когда !channel.HasUnsavedMessages:
if (!channel.HasUnsavedMessages && group.MaxBurstRecords > 0) {
int newBurstRecords = duration_cast<seconds>(currentTime - channel.LastSaved) / group.ChangedInterval;
channel.BurstRecords = std::max(channel.BurstRecords, newBurstRecords);
}
Итог: тишина → копятся “кредиты” → пришло сообщение → если есть кредит, пишем мгновенно.
max_burst — это параметр группы (лимит), но счётчик BurstRecords — отдельный для каждого контрола.
То есть он задается для всех элементов группы, но считается для каждого индивидуально.
В TLoggingGroup:
int MaxBurstRecords = 0; // ← настройка группы (один лимит для всех)
В TChannel:
int BurstRecords = 0; // ← счётчик каждого контрола независимо
Каждый контрол накапливает и расходует свои кредиты независимо — они не делятся между контролами группы.
есть еще вопрос по вот таким настройкам, как во вложении wb-mqtt-db.conf (5.0 KB)
с ними получается так, что сейчас данные в базе присутствуют только за последний ~1 час.
Контрол пишется только в первую подходящую
группу, в несколько групп сразу значение не дублируется, усреднения по
уровням нет. Все ваши электроканалы попадают в первую
группу «1сек-1час» (min_interval=1, values=3600 → 3600×1с = ровно 1 час),
а группы «1мин-7дн / 1час-3мес / 8час-1год» для них уже не наполняются.
Отсюда и 1 час. Один канал в 4 группы одновременно не попадёт.
Вполне можно, например написать скрипт который будет публиковать в (разные) топики виртуальеного устройства.
Но, обычно проще отдать данные во внешнюю базу для временных рядов, например influx.
Вполне можно, например написать скрипт который будет публиковать в (разные) топики виртуальеного устройства
это костыль, особенно с учетом нашей с вами относительно недавней дискуссии про корректное клонирование устройств/топиков.
Но, обычно проще отдать данные во внешнюю базу для временных рядов, например influx.
это нештатное решение, которое требует отдельного устройства. Если реализовывать на этом же устройстве, то есть риск со временем потерять все это при очередном обновлении. нам это не подходит, к сожалению.
добавьте во future request пжст:
возможность записи и отображения данных в history по нескольким критериям для одного и того же топика.
возможность прямого доступа по ссылке к уже готовому набору для отображения на одном графике нескольких топиков, чтобы не приходилось каждый раз их в интерфейсе выбирать из общего списка. если этих парметров с десяток, то очень неудобно каждый раз их выбирать заново.
