Уже после написания статьи добавилось несколько z-wave устройств: два реле в подрозетники, датчик открывания окна, датчик движения в гостиной, еще один термостат на радиатор отопления. Осталось написать правила, чтобы закрывать термостат, когда окно открыто.
да, 8 градусов на грани разумного. Штукатурка и приклеенные карнизы при падении ниже 5 градусов могут пострадать. Один раз карниз у меня отвалился в сильный мороз, когда котел не справился и температура опустилась ниже 5 градусов.
Можно и без прогноза, в некоторых случаях котел будет дольше работать, чем нужно. Собственно проблема не в том, что дольше, а в том, что он будет больше включаться-выключаться из-за неравномерности солнечного электричества, сокращая ресурс реле. В любом случае для расчета я беру минимальное из предыдущей ночной температуры и прогнозной.
Посмотрите здесь habr.com/company/sberbank/blog/414219.
Есть солнечное тепло. Собирается солнечными коллекторами. Полностью уходит в дом. Но, появляется не раньше марта.
Есть солнечное электричество, собирается солнечными панелями. Появляется в феврале. Так вот. Допустим мощность первой ступени котла 1.7кВт. Допустим, Солнце светит на 1кВт, тогда от сети 220В я возьму всего 700Вт. Т.е. за 1 час работы котла сэкономлю 1кВт.ч. За счет этой разницы и превентивного прогрева дома я и получаю экономию на поддержании температуры в доме. Прогрев дом до 11 градусов я даю ему 10-12 часов на остывание ночью с выключенным котлом, когда нет солнечного электричества, до 8 градусов, когда включится котел.
Теплоизоляция хорошая. О Солнце я писал вот здесь habr.com/company/sberbank/blog/414219
Больше телпа собирать тоже не получается в межсезонье, особенно ближе к зиме. Если солнечного электричества больше 500Вт — это уже удача. И этого недостаточно даже для 1-й ступени котла.
А солнечное тепло, появляющееся в марте и так все полностью в дом идет.
Так в статье выше я и описал. Зимой и особенно в межсезонье, в режиме охраны в доме поддерживается +8 автоматикой, отдельной от умного дома. Если есть Солнце, то можно прогреть дом превентивно, например до +10, тогда ночью котел дольше будет выключен. Прогноз ночной температуры использую для вычисления целевой температуры, до которой надо прогреть дом, чтобы котел не включался ночью.
Да, на Raspbian кажется даже предустановлен node-red. Но, пока не добрался, чтобы понять подходит мне или нет.
В следующем посте у меня появятся Raspberry и MQTT.
Согласен на 100%. Однако, в одном из правил, ориентированных на использование солнечной энергии у меня используется прогноз ночной температуры. Т.е. не столько для отопления, сколько для экономии.
Т.е. асинхронные правила настолько просты, что нет нужды для них рисовать блок-схемы. Важнее думать об их корректной совместной работе, чтобы результат их действий не был противоположным, иначе в системе возникнут автоколебания.
На скриншоте среды разработки есть правило «Boiler rule».
Там есть строка проверки тока нагрузки
if((LoadCurrent.state as DecimalType) < MaxLoadCurrent — 9) { сделать что-то
LoadCurrent — это как раз и есть item доступный всем правилам.
MaxLoadCuurent — это глобальная переменная (константа), доступная только внутри конкретного файла с правилами. Она как раз равна 25.6 А.
Все параметры в openHAB определяются либо как глобальные переменные внутри файла правил, либо как items. Обратиться к любому item можно из любого правила, вызванного любым событием.
Как это работает. TCP-modbus binding каждые 4 секунды опрашивает modbus-шлюз и считывает параметры электричества. Таким образом они актуализируются. Уже на этапе обновления тока нагрузки можно вызывать правило, которое отключит лишние ступени котла. А можно сделать правило, которое следит за какой-либо температурой и вызывается при ее изменении, а в самом правиле прописать сравнение текущего тока нагрузки, который хранится в соответствующем item с предельно допустимым.
Можно, но надо рисовать. Будет две-три отдельные и очень простые блок-схему. С ходу могу сказать только следующее — правила в основном асинхронные, в том смысле, что управление ТЭНом бойлера и ТЭНами котла — делаются разными правилами и события-триггеры для них могут быть разные. Поэтому единой блок-схемы в любом случае не получится.
Сейчас всех нюансов не помню и сравнения провести без изучения не могу. Выбирал в 2015г. и тогда OH мне показался самым подходящим.
Да, лучше не писать. Но это не мой случай. У меня происходит именно то, что я хотел добиться.
Это сложнее, а не проще. Нет ничего проще, чем написать правило в OH. А гистерезис у котла, естественно есть, штатный.
Однако, на 8 градусах — все нормально.
Есть солнечное тепло. Собирается солнечными коллекторами. Полностью уходит в дом. Но, появляется не раньше марта.
Есть солнечное электричество, собирается солнечными панелями. Появляется в феврале. Так вот. Допустим мощность первой ступени котла 1.7кВт. Допустим, Солнце светит на 1кВт, тогда от сети 220В я возьму всего 700Вт. Т.е. за 1 час работы котла сэкономлю 1кВт.ч. За счет этой разницы и превентивного прогрева дома я и получаю экономию на поддержании температуры в доме. Прогрев дом до 11 градусов я даю ему 10-12 часов на остывание ночью с выключенным котлом, когда нет солнечного электричества, до 8 градусов, когда включится котел.
Больше телпа собирать тоже не получается в межсезонье, особенно ближе к зиме. Если солнечного электричества больше 500Вт — это уже удача. И этого недостаточно даже для 1-й ступени котла.
А солнечное тепло, появляющееся в марте и так все полностью в дом идет.
В следующем посте у меня появятся Raspberry и MQTT.
Спасибо, надо попробовать
Будет интересно узнать о результатах.
Согласен на 100%. Однако, в одном из правил, ориентированных на использование солнечной энергии у меня используется прогноз ночной температуры. Т.е. не столько для отопления, сколько для экономии.
Там есть строка проверки тока нагрузки
if((LoadCurrent.state as DecimalType) < MaxLoadCurrent — 9) { сделать что-то
LoadCurrent — это как раз и есть item доступный всем правилам.
MaxLoadCuurent — это глобальная переменная (константа), доступная только внутри конкретного файла с правилами. Она как раз равна 25.6 А.
Как это работает. TCP-modbus binding каждые 4 секунды опрашивает modbus-шлюз и считывает параметры электричества. Таким образом они актуализируются. Уже на этапе обновления тока нагрузки можно вызывать правило, которое отключит лишние ступени котла. А можно сделать правило, которое следит за какой-либо температурой и вызывается при ее изменении, а в самом правиле прописать сравнение текущего тока нагрузки, который хранится в соответствующем item с предельно допустимым.