Properties history queue is too long

[Kostosso]

Здравствуйте,
Я только начинаю разбираться в MD по этому не ругайте сильно.
Система установлена несколько дней назад и находится в тестовом режиме. Есть ESP8266 с BMP085/180 и AM2321, а также датчиком движения и одним управляемым реле (тестовая сборка - разобраться, пощёлкать).
Несколько дней всё ок, начал писать первую логику и тут... Перестали отображаться графики на сценах.
В Система/Ошибки системы возникло следующее сообщение "phistory_queue 2 02/05/2019 18:22:49". Если "раскрыть" ошибку -
2019-02-05 18:22:49
Properties history queue is too long (278)
Backtrace:
#0 /var/www/html/scripts/cycle_phistory.php(69): registerError('phistory_queue', 'Properties hist...')
#1 {main}

2019-02-05 02:48:59
Properties history queue is too long (207)
Backtrace:
#0 /var/www/html/scripts/cycle_phistory.php(69): registerError('phistory_queue', 'Properties hist...')
#1 {main}
Пытался выполнить оптимизацию. Определил "переполняющиеся" переменные. ( см файл Hist_1.jpg)
Сделал такие правила оптимизации для этих переменных.
SHumSensors espSensor_humidity02 value 3
STempSensors espSensor_temp05 value 3 avg
Количество накопленных значений резко сократилось ( см файл Hist_2.jpg)
Но графики работать не стали и ошибка не исчезла.

Помогите, пожалуйста, куда копать, и что посмотреть...
на всякий случай прикладываю лог Apache

Доп информация:

• Источник обновлений ядра: Альфа

• Ставил готовый образ от Сергея из "Базовый образ Raspberry Pi3 / Pi2"

• Нештатных завершений работы сервера в этот период не случалось

• Время системное сразу после старта ОС корректное (на главном экране системы)

• В Интернет МДМ выставлен

[fandaymon]

Здравствуйте,
Я только начинаю разбираться в MD по этому не ругайте сильно.
Система установлена несколько дней назад и находится в тестовом режиме. Есть ESP8266 с BMP085/180 и AM2321, а также датчиком движения и одним управляемым реле (тестовая сборка - разобраться, пощёлкать).
Несколько дней всё ок, начал писать первую логику и тут... Перестали отображаться графики на сценах.
2019-02-05 18:22:49
Properties history queue is too long (278)

Это означает что данные поступают с такой скоростью, что система не может их нормально обработать. Сначала данные попадают в очередь, а потом phistory цикл их из очереди обрабатывает. В цикле стоит проверка на размер очереди, по умолчанию 200, и если в очереди больше чем 200 записей, то выдаётся предупреждение. Надо смотреть почему данные поступают с такой интенсивностью, обычно никому не нужны данные о давлении и температуре чаще чем раз в минуту... Ну и если всё-таки данные поступают достаточно редко, тогда надо смотреть почему они так медленно обрабатываются - нет ли каких-нибудь подводных каменей в коде, обрабатывающем данные

[Kostosso]

Согласен, нет никакого смысла получать с такой периодичностью данные о температуре и влажности помещения. В настройках WiFi-IoT изменил интервал обновления датчиков на 2 минуты (ранее было установлено 5 секунд. Как я понял, это значение по умолчанию).
А не подскажите, плиз, как исправить сложившуюся на данный момент ситуацию?
(Интересно, что я только что проверил МД - графики отобразились, но с 14:00 вчера до 4:00 сегодня! а текущих значений на графике опять нет.

[fandaymon]

Согласен, нет никакого смысла получать с такой периодичностью данные о температуре и влажности помещения. В настройках WiFi-IoT изменил интервал обновления датчиков на 2 минуты (ранее было установлено 5 секунд. Как я понял, это значение по умолчанию).
А не подскажите, плиз, как исправить сложившуюся на данный момент ситуацию?
(Интересно, что я только что проверил МД - графики отобразились, но с 14:00 вчера до 4:00 сегодня! а текущих значений на графике опять нет.

Ну я бы радикально поступил - зашел бы в phpmyadmin и удалил бы все записи из таблицы phistory_queue. По идее дальше всё должно работать

[Kostosso]

Здравствуйте,
Я только начинаю разбираться в MD по этому не ругайте сильно.
Система установлена несколько дней назад и находится в тестовом режиме. Есть ESP8266 с BMP085/180 и AM2321, а также датчиком движения и одним управляемым реле (тестовая сборка - разобраться, пощёлкать).
Несколько дней всё ок, начал писать первую логику и тут... Перестали отображаться графики на сценах.
2019-02-05 18:22:49
Properties history queue is too long (278)

Это означает что данные поступают с такой скоростью, что система не может их нормально обработать. Сначала данные попадают в очередь, а потом phistory цикл их из очереди обрабатывает. В цикле стоит проверка на размер очереди, по умолчанию 200, и если в очереди больше чем 200 записей, то выдаётся предупреждение. Надо смотреть почему данные поступают с такой интенсивностью, обычно никому не нужны данные о давлении и температуре чаще чем раз в минуту... Ну и если всё-таки данные поступают достаточно редко, тогда надо смотреть почему они так медленно обрабатываются - нет ли каких-нибудь подводных каменей в коде, обрабатывающем данные

Спасибо, всё удачно разрешилось. Данные начали отображаться. Я уменьшил время опроса датчиков с 5 до 120 секунд (в настройках WiFi-IoT. Как это сделать средствами МД я не нашёл. Подскажите, плиз, кто знает - есть ли такая возможность в МД?).
Остался вопрос, что будет при увеличении количества датчиков. Как определить скорость опроса при увеличении количества с 4 до 50. Есть ли рекомендации по этому поводу? Зависит ли пропускная способность от железа сервера, Стоит ли, в случае увеличения количества датчиков, переходить на нетбук или atom содержащее железо?

[fandaymon]

Остался вопрос, что будет при увеличении количества датчиков. Как определить скорость опроса при увеличении количества с 4 до 50. Есть ли рекомендации по этому поводу? Зависит ли пропускная способность от железа сервера, Стоит ли, в случае увеличения количества датчиков, переходить на нетбук или atom содержащее железо?

Экспериментальным путём - подключить 50 датчиков, поставить опрос раз в минуту, лучше конечно чтобы этот раз в минуту для всех датчиков не случался одновременно... Если будет затыкаться, то увеличить время опроса.
Время обработки естественно напрямую зависит от железа - грубо говоря для каждого значения, поступающего в систему, нужно сделать порядка десятка вызовов sql, отработать связанные с изменением значения методы, а если в этих методах меняются какие-нибудь другие значения, то и методы, связанные с этими значениями. И чем сложнее схема связей, тем больше ресурсов требуется.

[Logrus]

маленько дополню выше на примере сяоми
приходят данные от сенсоров только по изменению, точность два знака
с модуля приходят с точностью в один знак пишутся без сохранения (это для логики, точности в один знак достаточно)
в историю пишется через фильтр если новое не равно записанному с точностью 0.5 (это для графиков, точность 0.5 даже излишняя, можно и целые писать в графике интерполируется)

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