На данный момент для уменьшения задержек при работе датчика движения приходится устанавливать частоту обновления Current motion побольше, например каждые 200ms (сижу на testing, поэтому “новый” планировщик), что создает дополнительную нагрузку на правила: постоянно идет пересылка сообщений об изменениях по MQTT и их обработка движком. Также без движения постоянно прилетают изменения Current Motion в пределах 19-24. Из-за него перечисленного пришлось в том числе отключить историю по этим параметрам.
Мне кажется, что нагрузку можно уменьшить следующим образом:
Добавить RW регистр “Пороговое значение”
Добавить RO регистр “Более порогового значения”, в который датчик будет записывать true, когда больше и false, когда меньше.
Таким образом можно опрашивать часто “Более порогового значения”, и реагировать на изменения. И иметь такой параметр у каждого датчик было бы неплохо.
В идеале - еще бы иметь возможность по запросу через MQTT принудительно обновлять данные (публикуем в топик “update” и топик улетает в приоритетный запрос в очереди).
Можно еще подумать про изменение настроек wb-mqtt-serial через MQTT, т.к. мне кажется, что было бы правильнее обновлять параметры настроек только частично, чем перезагружать конфиг и заново инициализировать все устройства.
Для более быстрой реакции на события как раз и был сделан новый планировщик с указанием желаемого времени опроса каналов.
В вашем варианте придется также часто по Modbus опрашивать регистр “Более порогового значения", а вот правила будут вызываться реже, да. Думаю, такой регистр может быть полезен для быстро изменяющихся параметров (движение, звук). Но обычно задержки 300-500 мс вполне допустимы.
При опросе датчика по Modbus не известно, изменились ли его показания, поэтому приходится делать периодический опрос для обновления данных, опрос настраивается по желанию. Но разработчики работают над оптимизацией протокола обмена, чтобы устройство само могло инициировать отправку данных при изменении.
В настройках истории есть параметр для задания минимального интервала данных, попробуйте увеличить его:
Планировщик поэтому новый и тестирую, чтобы понимать нюансы.
А как оптимизировать? Там либо ждать, что датчик может что-то прислать, и это правильно пойти по пути с Modbus → CAN (либо вообще отказаться от шины RS485 (уже все везде по ethernet) и уйти просто в MQTT, и на каждом устройстве иметь по два порта, либо выпускать коммутатор), а не вот это все. Либо датчик при получении запроса по Modbus присылает в ответ не только то, что просили, но и срочное изменение. И для оперативной связи надо иметь хотя бы один параметр. От этого может поехать планирование, т.к. линия будет занята дольше, чем планировалось.
Задержки - допустимы, но как обычно хочется уменьшить, чтобы на все реагировать быстрее. Мозг реагирует на разницу, а не конкретную задержку, а разница между разными датчиками - существенна.
С историей все понятно, что можно просто реже писать, это не исправит того момента, что запись о превышении порога - только виртуальным устройством, с текущим значением, также можно и правило задать по тому, что писать, поэтому проще было сразу отключить и писать только виртуальное.