В этом есть и плюсы - кран точно не закиснет.Andrey_B писал(а):Да, согласен. Упустил, что в текущей экспериментальной реализации логика работы с температурными датчиками не такая, как в режиме "термостата".Erik писал(а):Оно же раз в 5 сек срабатывает.Andrey_B писал(а):Не будет работать. И даже не потому, что в Program пока не поддерживаются паузы.
Изначально я планировал, что она будет такая же, как там, но вот теперь в этом уже не уверен.
Но паузы все равно в Program в данный момент не поддерживаются.
И периодичность 5 секунд по-моему слишком мало для управления 3-х ходовым. У меня скрипт на сервере крутит 3-х ходовые с периодичностью в 5 минут.
Кроме того, в связи с довольно резкими колебаниями теплоносителя в системе отопления, значения гистерезиса моего котла штатные +6/-2 градуса, я оцениваю не моментальное значение температуры, а усредненное за 5 минут. Иначе контроллер/сервер без конца бы крутил кран туда-сюда без реальной на то необходимости.
Для того, чтобы не крутить лишнего, нужно следить за динамикой, а не только за текущими значениями (подчиненным правилом,например).
Например, если температура в контуре недостаточная, и кран приоткрылся, нужно в следующий раз смотреть увеличилась ли температура, а не на ее текущее значение. Если увеличилась - можно больше не крутить (или если увеличилась на заданное дельта т градусов, то можно не крутить).
По моему это реально делать силами меги, ресурсов у нее хватает (но для этого нужно многое переделать).
Собственно я понимаю, что очень жалко переделывать, но подумайте, в этом может быть больше перспектив.
Если все правила отвязать от входов, а ресурсы выделить под переменные, то плюсов появится очень много.
- возможно будет на один датчик вешать разные скрипты по разным порогам.
- простой логикой (сложения-вычитания) можно будет делать пропорциональное управление циркуляционным насосом (регулировать скорость/мощность в зависимости от количества включенных петель и их расчетным/настроенным расходам. Через переменную. Которую скрипт включающий/выключающий петлю увеличит/уменьшит пропорционально расходу этой петли в общем потоке ТП, а на эту переменную повесить шим-управление насосом). Без этого при закрытии петли насос распределяет (продавливает) ее поток по остальным петлям. И система перестает себя вести ожидаемо.
- или если при открытии всех петель ТП температура в помещении упала, увеличить порог регулирования трехходового (переменную, которая задает порог). И наоборот, если случается закрытие всех петель - убавить уровень трехходового (уменьшить значение переменной). При реализации этой логики погодозависимость будет нужна только на сравнение заданной температуры ТП (порогом трехходового) с уличной. Если урегулировали до уровня уличной (со смещением или без) - нужно выключить ТП.
- подчиненные правила (из нпримера выше про контроль изменения температуры). Основное правило проверяет отклонение от заданного, подчиненное - отклонение от прошлого замера. Если отклонения от прошлого не было - регулируем. Если было - смотрим в какую сторону. Для одного трехходового крана нужны две пары правил - одна для ситуации, когда текущее больше заданного, вторая - когда меньше заданного. Вторичные в одном случае проверяет, что отклонение от прошлого больше нуля, во втором - что меньше).
Все можно реализовывать без участия сервера, нужны непривязанные правила и область памяти для переменных.
Подумайте. Это интереснее линейной логики вход-выход.