MajorDoMo

Всем привет,

Хочу посоветываться. При сохранении данных в свойста, у которых выставлен признак хранения истории, происходит автоматическа оптимизация. Она работает следующим образом -- если новое значение совпадает с двумя предыдущими, то вместо трёх показаний в истории остаётся только два -- первый и последний из повторяющейся последовательности. Средний как бы выбрасывается, как ни на что не влияющий. Всё бы ничего, но вскрылась проблема -- в некоторых случаях надо считать сумму показаний за период, где имеет значение каждый экземпляр показаний. В итоге мы пришли к вариантам -- либо отключать оптимизацию на этапе сохранения истории, либо оставлять всё как есть и думать как обрабатывать исключительный случай вот таких вот показаний (добавлять галочку "не оптимизировать на этапе сохранения истории" -- вариант, но чем меньше галочек, тем лучше). Отключение оптимизации плохо только тем, что при неоптимальной организации кода или сбора данных может очень быстро расти база из-за повторяющихся одинаковых значений. Последнее лечится установкой и настройкой модуля Оптимизатора, но тоже так себе вариант, потому что не все сообразят, что нужно делать, а система к тому времени уже будет неповоротливой.

Короче, делитесь соображениям

Проблема вскрылась у меня с датчиком осадков. Он раз в минуту присылает количество срабатываний (потом умножается на коэффициент и получаем мм осадков).
Как решу проблема опишу данный датчик в топике MySensors

В итоге хотелось получать историю за период. 1 час, 12 часов, 24 часа - мм осадков. Но оптимизатор по сохранению данных оптимизирует значения.

Чтобы не было разногласий: Большая база против верные данные предлагаю сделать настройку типа оптимизации в свойстве объекта, рядом с пунктом "Хранить историю (дней):"
По сути можно вынести правила оптимизатора в этот пункт.

• Показательные (как сейчас). Добавляет если 2 последних неравны (Если равны меняет дату изменения у последнего). При оптимизации заменяет период на среднее
• Без оптимизации. Добавляет всю историю. Не оптимизирует оптимизатором
• Нарастающий. Если равен последнему изменяет дату, если не равен добавляет новый. Оптимизирует за период - максимальным значением
• Вес. Добавляет в историю всегда. Оптимизирует - сумма значений

Новый флаг немного будет пугать новых пользователей. Зато будет не портить и держать оптимизированными истории свойств.

Я этот кусок кода по сохранению истории значений постоянно правлю (есть мысли анализировать скорость изменения некоторых параметров,
для этого в течении последних нескольких часов нужны все показания, например по температуре/влажности - четко видно, когда открыли окно).
Поддерживаю предложение Ивана - эти варианты настроек закроют большинство потребностей.

cabat писал(а):Я этот кусок кода по сохранению истории значений постоянно правлю (есть мысли анализировать скорость изменения некоторых параметров,
для этого в течении последних нескольких часов нужны все показания, например по температуре/влажности - четко видно, когда открыли окно).
Поддерживаю предложение Ивана - эти варианты настроек закроют большинство потребностей.

Поделитесь алгоритмом

Изложу здесь в более сжатом виде то о чем писал в группе скайпа.

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

Сделать как описано выше и дополнительно предрасчетные таблицы остатков и оборотов (аля 1с). В интерфейсе рядом с числовым свойством добавить две галочки: Обороты, Остатки.
У оборотов есть понятие периодичность, например день/неделя/месяц. Соответственно должно быть некое задание, которое бы периодически вызывалось и подсчитывало агрегатные функции для текущего периода: Сумма, Макс, Мин, Сред... А дальше на диаграмме выбираем Объект - Эл.Счетчик, Свойство - Значение, ВидАгрегата - Оборот, Период - День, Функция - Сумма. Диаграмма получает данные уже из предварительно посчитанной таблицы. Таким образом показания верные, быстро выводится, хранится более-менее компактно, для конечного пользователя без программирования.
У остатков суть та же, только подсчитываются соответственно остатки на окончания определенных периодов - день, неделя, месяц. Если вывести в диаграмму - покажет какие были показания на каждый конкретный день (или месяц). Я думаю не очень актуально, но вдруг...

sergejey писал(а):добавлять галочку "не оптимизировать на этапе сохранения истории"

Единственный приемлемый вариант.
Описанная задача (каждое показание важно) очень редка. В большинстве случаев решается инкрементным счетчиком, который накапливает в себя периодические значения.
Замечу, что желательно что бы МОДУЛЬ оптимизатора тоже смотрел на галку.

По поводу количества галок. Настройку системы можно делать только 2-я способами: формулы или галки. В первом случае меняются сами формулы (скрипты) во втором - коэффициенты, условия в IF. Чем ближе система к "коробочному варианту" , тем больше мест с галками и меньше формул. Можно думать над местом расположения той или иной галки, но сама суть настройки остается.

Пользуясь случаем: в системе много контекстной помощи, но вся она ведет на заглушки и пустышки. Это очень усложняет работу, освоение нового. Думаю, что Сергей просто не предает значения отсутствию helpa, так как ему он не нужен. Подсказки нужны. Они ОЧЕНЬ облегчают вход в проект. И подсказка должна вести на статическую страницу в ВиКи, и только от туда на форум.

NightRider писал(а): дополнительно предрасчетные таблицы остатков и оборотов (аля 1с). В интерфейсе рядом с числовым свойством добавить две галочки: Обороты, Остатки.
У оборотов есть понятие периодичность, например день/неделя/месяц. Соответственно должно быть некое задание, которое бы периодически вызывалось и подсчитывало агрегатные функции для текущего периода: Сумма, Макс, Мин, Сред...

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

ErmolenkoM писал(а):Пользуясь случаем: в системе много контекстной помощи, но вся она ведет на заглушки и пустышки. Это очень усложняет работу, освоение нового. Думаю, что Сергей просто не предает значения отсутствию helpa, так как ему он не нужен. Подсказки нужны. Они ОЧЕНЬ облегчают вход в проект. И подсказка должна вести на статическую страницу в ВиКи, и только от туда на форум.

Пользуясь случаем, отмечу, что любой участник форума может изменить текст подсказки в wiki -- нужно просто нажать на редактирование страницы и войти в wiki, используя логин/пароль от форума. Очень надеюсь на помощь в заполнении подсказок

Ivan писал(а):..Поделитесь алгоритмом

Алгоритмов пока никаких нет, так мысли..
Пришлось вспоминать школьный курс математики - расчет производных и т.п.
Хочется вычислять направление изменения показателя и скорость изменения - тогда можно это как то использовать при управлении..
Но это так - мысли на будущее, времени мало, дело движется медленно, пока только несколько датчиков и один модуль индикации на дисплее 1602..

В последнем обновлении добавили флаг HISTORY_NO_OPTIMIZE
Чтобы отключить оптимизацию в config.php нужно добавить строку
*** Сообщение запрещено. Сообщение похоже на спам. ***