Управление котлом своими руками: инструкция, фото и видео-уроки, цена

12 октября 2009 г.

Версия для печати (PDF)

Большинство производителей котлов продают и продают свои собственные автономные системы управления котлами. Многие из них будут постоянно устанавливать элементы управления в шкафу котла или предоставлять контроллер для настенного монтажа. Чтобы снизить затраты, они обычно делают предположения о том, как вы хотите контролировать свои котлы. Обычно они обеспечивают либо «параллельную», либо «прогрессивную» модуляцию. Немногие предлагают вариант модуляции «Серия». Давайте посмотрим на различия.

1) Параллельная работа является простейшим алгоритмом модуляции. Все котлы будут модулировать из начального положения вместе. Обычно у вас есть возможность отрегулировать «начальную точку» или процент запуска котлов, после чего все котлы будут работать с одинаковой скоростью, от этой начальной точки до 100%. С помощью этой опции разные контроллеры могут управлять разным количеством котлов. Например, HBX CPU-1000 может параллельно работать с пятью котлами. При переходе в режим без нагрузки все котлы переключатся в положение «пуск», затем расчет ПИД-регулятора позволит всем котлам, кроме одного, отключиться на расчетный период времени, чтобы свести к минимуму возможные короткие циклы.

2) Прогрессивная модуляция представляет собой комбинацию последовательной и параллельной модуляции. Ведущий котел запустится и смодулируется до чего-то меньшего, чем 100% (т.е. 80%). Как только ведущий котел достигнет 80%, второй котел загорится до 40%, а ведущий котел уменьшится до 40%. При увеличении нагрузки оба котла увеличатся до 80%. Как только эти два котла достигнут 80%, третий котел запустится и будет модулировать примерно до 55%, а первые два котла будут модулировать примерно до 55%. По мере увеличения нагрузки эти три котла будут совместно модулировать до 100%. При уменьшении нагрузки процесс обратный. См. график ниже.

3) Серийная модуляция обычно не поддерживается многими контроллерами. Это очень простой и простой, но эффективный алгоритм. Ведущий котел запускается и разгоняется до 100% огня. Если потребность в тепле не удовлетворена, то ведущий котел держится на 100%, а второй котел начинает работать, увеличивая мощность до тех пор, пока потребность в тепле не будет удовлетворена. В этом моде ведущий котел может быть на 100%, а второй на 43%. Как только второй котел будет на 100%, он будет поддерживаться на уровне 100% по мере того, как другие котлы подключаются к сети способом, аналогичным второму котлу. Процесс модуляции отключения котлов работает так же, но в обратном порядке. Как и во всех случаях, расчет ПИД-регулятора будет управлять ведущим котлом для минимизации циклов.

Модель ЦП 1000 системы управления HBX предлагает выбор из этих трех вариантов модуляции. Конструкция CPU-1000 также позволяет добавлять модули зон и насосов для легкой адаптации к вашим существующим или будущим потребностям проекта.

Благодарим вас за использование продуктов, продаваемых компанией R. L. Deppmann в Мичигане и Огайо!

Отказ от ответственности: R. L. Deppmann и ее аффилированные лица не несут ответственности за проблемы, вызванные использованием информации на этой странице.

Архив – Щелкните здесь, чтобы просмотреть предыдущие статьи

Управление котлом – взлом дома

Ранее мы обсуждали алгоритмы, которые можно использовать для управления домашней системой отопления, создали простой пользовательский интерфейс для планирования изменений температуры и реверса — спроектировал ранее существовавшее радиочастотное реле для управления котлом. До сих пор веб-служба, обеспечивающая пользовательский интерфейс, была развернута на домашнем ПК, но, поскольку вы, скорее всего, захотите переопределить элементы управления отоплением, когда неожиданно вернетесь домой рано или поздно, нам нужен сайт, который можно было бы добраться откуда угодно.

В этой статье описываются изменения в программном обеспечении, необходимые для достижения этой цели, некоторые обсуждения технических решений и пошаговые инструкции по самостоятельной настройке. Если вы здесь только для того, чтобы получить пошаговое руководство по настройке, перейдите к разделу «Развертывание BoilerIO на AWS».

Как обычно, весь исходный код доступен по лицензии MIT на github.

В предыдущей статье мы предполагали, что хосты, запускающие веб-сервис и выдающие команды управления котлом, находятся в одной сети и, по сути, вероятно, на одном хосте. Чтобы перевести BoilerIO в онлайн (т.е. предоставить доступ к элементам управления из любого места), это предположение больше не соответствует действительности. Хотя вы можете подумать о размещении узла веб-сервера в демилитаризованной зоне (т. е. сделать его доступным для Интернета, сохраняя при этом соединение с вашей сетью), это огромная банка червей безопасности, и это не рекомендуется. Вы можете разместить свой собственный сервер в совершенно отдельной сети, если у вас есть доступ к нескольким общедоступным IP-адресам, но это не является распространенным случаем и поэтому здесь не обсуждается.

Обновлена ​​архитектура BoilerIO

Итак, теперь у нас есть три отдельных приложения:

1. Клиенты : Ваш телефон или ПК, на котором размещено приложение планировщика в веб-браузере, а также доступ и управление элементами управления отоплением, предоставляемыми службой. В настоящее время это веб-приложение JavaScript/HTML (хотя вы можете представить и другие клиентские приложения, такие как приложение для iOS).
2. Служба : предоставляет серверную часть, с которой взаимодействует все остальное: она хранит данные расписания, кэшированные температуры и размещает статические файлы, необходимые для веб-интерфейса. Его можно запустить на нескольких серверах с балансировщиком нагрузки, но для домашней установки достаточно одной маломощной виртуальной машины для размещения всего (бэкэнд-приложения uWSGI, внешнего веб-сервера и базы данных Postgres).
3. Устройства : Это всего лишь частный случай клиента. В настоящее время нет реальной разницы в том, как они получают доступ к сервису, за исключением использования дополнительных конечных точек HTTP для обновления кэшированной температуры на сервере и т. д.  Они выполняют состояние, запрограммированное пользователем через веб-интерфейс, взаимодействуя с локальной инфраструктурой ( например, выдача команд котлу). Это фиксированные «устройства», работающие в локальной сети пользователя, и в настоящее время они аутентифицируются так же, как и клиенты, работающие с пользователем, с использованием общего секрета.

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

В любой онлайн-службе всегда есть риски безопасности и существует возможность неизвестных методов атаки. Одной из будущих работ является написание модели угроз для BoilerIO. Тем временем некоторые ключевые соображения включают:

1. Обеспечение того, чтобы серверная служба требовала аутентификации в качестве пользователя или устройства для любого доступа к API. Подробнее см. ниже: в настоящее время это достигается с помощью базовой аутентификации HTTP (через HTTPS), поддерживаемой nginx.
2. Обеспечение постоянного шифрования связи с серверной службой . Опять же, это реализовано на стороне сервера: конфигурация веб-сервера перенаправляет HTTP-запросы на протокол HTTPS. Код устройства поддерживает, но в настоящее время не требует HTTPS, поскольку это неудобно для локальных развертываний.
3. Обеспечение того, чтобы устройство не допускало непроверенные сертификаты , чтобы снизить вероятность атак типа «человек посередине». Это значение по умолчанию для кода устройства, а для пользовательского интерфейса браузеры должны указать, неисправен ли сертификат.
4. Очистка входных данных , чтобы попытаться отфильтровать все, что может нанести ущерб (деформированные или иным образом вредоносные входные данные).
5. Запуск всех служб с минимальной привилегией . Весь код устройства и сервисный код должен выполняться от имени непривилегированного системного пользователя. Дальнейшие улучшения можно внести, создав для модулей политики SELinux или AppArmour.
6. Не выставлять напоказ ничего лишнего извне , например базу данных или какие-либо службы на самом устройстве. Теперь устройство устанавливает только исходящие подключения и требует только HTTPS-доступа к службе планировщика.
7. Использование надежных паролей , так как вы контролируете все развертывание и можете использовать утилиты в своем браузере для хранения паролей, вы можете иметь отдельные безопасные пароли для каждого пользователя и устройства, которые обращаются к службе.

Внутренняя служба

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

Существует множество способов реализации аутентификации либо через само приложение, либо через веб-сервер, на котором оно размещено. Поскольку BoilerIO сама по себе не поддерживает аутентификацию (например, через OAuth), целесообразным способом достижения разумного уровня безопасности является настройка веб-сервера на требование HTTP-аутентификации. Поскольку я использую nginx, я вынужден придерживаться HTTP Basic Auth, так как их реализация Digest Auth на момент написания статьи не завершена. Очень важно, чтобы аутентификация выполнялась через безопасное (HTTPS) соединение, чтобы предотвратить кражу учетных данных путем захвата трафика аутентификации.

Обратите внимание, что использование базовой аутентификации означает, что если кто-то получит HTTP-запросы в открытом виде, пароль будет доступен злоумышленнику напрямую. Хотя перехват обычно не должен происходить с TLS, вы можете, например, подвергнуться атакам «злоумышленник посередине», если в вашей системе установлены мошеннические сертификаты (так что ваш сайт выглядит законным для браузера, но выдает себя за него). ). Иногда это происходит в корпоративных системах, использующих SSL-прокси.

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

Устройство (устройства)

Планировщик работает в локальной сети пользователя для взаимодействия с датчиками температуры и контроллером котла (любой из которых может работать на одном хосте) и использует веб-службу планировщика получить актуальный график отопления.

Если предположить, что «программное обеспечение устройства» размещено в частной сети и недоступно из Интернета, то основными соображениями безопасности являются:

1. Защита от недопустимых ответов от службы планировщика в случае ее взлома. Код как есть выполняет некоторую проверку ответов и игнорирует ошибочные ответы.
2. Обеспечение достаточной блокировки любых частей локальной конфигурации, таких как брокер MQTT. Это зависит от настройки конечного пользователя.

Amazon Web Services (AWS) предоставляет дешевый и удобный способ получения ресурсов сервера с общедоступным IP-адресом. У вас может быть доступ к альтернативам, включая ваш собственный сервер, и в этом случае части, относящиеся к AWS, можно игнорировать или изменить в соответствии с вашей средой.

BoilerIO в настоящее время использует базу данных Postgres в качестве бэкенда, поэтому удобнее всего настраивать собственные сервисы на виртуальной машине. Elastic Beanstalk может предоставить среду Python, но в любом случае есть база данных, которую нужно разместить, и Amazon взимает плату за базовый экземпляр EC2. Я решил использовать виртуальную машину Lightsail. Lightsail — это, по сути, более простая версия EC2, которая больше похожа на традиционную услугу хостинга виртуальных машин с простой ценой и конфигурацией.

Чтобы все это было полезно, вам необходимо иметь предварительные условия, включая датчик температуры (например, EmonTH) с совместимым интерфейсом (для EmonTH вы можете использовать режим JSON, который я добавил в emonhub) между ним и MQTT, а также способ взаимодействия с вашим котлом (например, радиочастотный интерфейс Danfoss, работающий на JeeLink v3c 433 МГц, если у вас есть совместимый приемник Danfoss).

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

Шаг 1: Создайте свою виртуальную машину

Для этого приложения достаточно самого дешевого экземпляра Ubuntu 16.04.

Вам необходимо зарегистрироваться в AWS. Получив учетную запись AWS, вы можете получить доступ к Lightsail из Консоли управления AWS, чтобы настроить как «экземпляр» (виртуальную машину), так и общедоступный IP-адрес.

В приведенных здесь инструкциях предполагается образ Ubuntu 16.04 LTS. Простого экземпляра 512 МБ/1 VCPU/20 ГБ SSD должно быть достаточно для этого приложения, и в настоящее время его цена составляет 5 долларов США в месяц.

Вам необходимо настроить путь ssh к виртуальной машине. Вы можете либо использовать веб-консоль, либо подключиться, используя либо существующий ключ ssh, либо созданный вами. Я предпочитаю генерировать ключ локально и загружать только часть открытого ключа. В Windows вы можете использовать PuTTY, а в Mac OS вы можете просто использовать openssh прямо из терминала. Все приведенные ниже команды выполняются на сервере, если не указано иное.

Шаг 2: Проверьте код BoilerIO

Код BoilerIO размещен на github; вы можете легко получить копию:

 $ git clone https://github.com/adpeace/boilerio.git 

Шаг 3: Настройка базы данных

Веб-сервер для BoilerIO требует настройки базы данных Postgres:

Во-первых , установите postgres:

 $ sudo apt-get install postgresql 

Затем нам нужно создать пользователя для серверной части. Я бы предложил использовать длинный случайный пароль для этого пользователя, который вы можете сгенерировать с помощью утилита pwgen . Получив пароль, создайте пользователя и базу данных для планировщика:

 $ sudo -u postgres createuser -P scheduler
Введите пароль для новой роли:
Введите его снова:
$ sudo -u postgres createdb scheduler 

Затем создайте таблицы и т. д., используя сценарий в репозитории котлов:

 $ sudo -u postgres psql scheduler 
 Шаг 4: Установка приложения 
 Это простой пример установки пакета Python:
 $ sudo apt-get установить python-setuptools
$ sudo easy_install пункт
$ cd котел
$ sudo -H pip установить. 
 Пакет также зависит от файла конфигурации   /etc/sensors/config  , как описано в README.md в репозитории. Необходимы только параметры конфигурации, относящиеся к веб-приложению, поскольку мы не устанавливаем другие компоненты на сервер. Пример файла конфигурации может выглядеть так:
 [отопление]
scheduler_db_host = локальный хост
scheduler_db_name = планировщик
scheduler_db_user = планировщик
планировщик_дб_пароль = 
 Шаг 5: Настройка uWSGI 
 uWSGI — веб-сервер, который можно использовать для обслуживания приложения BoilerIO flask за nginx. Мы используем его, потому что он более производительный, надежный и безопасный, чем встроенный веб-сервер werkzeug, предоставляемый как часть flask (который предназначен только для использования в разработке). Чтобы установить его, выполните следующее:
 $ sudo apt-get install uwsgi uwsgi-plugin-python 
 Лучше всего запускать приложения uwsgi от имени непривилегированного пользователя, поэтому нам нужно создать пользователя, а затем соответствующим образом установить разрешения для различных местоположений.
 $ sudo adduser --no-create-home --systemoilio 
 Теперь создайте конфигурацию для приложения. Создайте файл  /etc/uwsgi/apps-available/thermostat.ini  :
 [uwsgi].
сокет = /var/www/boilerio/термостат.sock
модуль = бойлерио.schedulerweb:приложение
uid = котел
gid = www-данные
chmod-socket = 664 
 Наконец, создайте каталог для сокета, включите приложение и перезапустите uWSGI:
 $ sudo mkdir -p /var/www/boilerio
$ sudo chown бойлерио: корень /var/www/boilerio
$ sudo ln -s . ./доступные приложения/термостат.ini /etc/uwsgi/приложения включены/
$ sudo systemctl перезапустить uwsgi 
 Вы можете убедиться, что он работает, проверив вывод  ps  :
 $ pgrep -a uwsgi
18503 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/thermostat.ini --daemonize /var/log/uwsgi/app/thermostat .бревно
18511 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/thermostat.ini --daemonize /var/log/uwsgi/app/thermostat .бревно
18512 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/thermostat.ini --daemonize /var/log/uwsgi/app/thermostat .лог 
 Чтобы убедиться, что uWSGI запускается при запуске системы, убедитесь, что для переменной  RUN_AT_STARTUP  установлено значение  yes  в файле  /etc/default/uwsgi .
 Шаг 6: Настройка nginx и HTTPS 
 Чтобы установить nginx, просто запустите:
 $ sudo apt-get install nginx apache2-utils 
 Шаг 6a: Давайте зашифруем! 
 Включение HTTPS через брандмауэр Lightsail
 Чтобы настроить HTTPS, вы можете использовать Let’s Encrypt! Центр сертификации, чтобы получить сертификат для вашего HTTPS-сервера, которому будет доверять большинство браузеров. Давайте шифровать! предоставляет сертификаты с проверкой домена, которые, вероятно, достаточно хороши для ваших нужд. Чтобы получить сертификат, вы должны доказать (с помощью инструмента под названием  certbot  ), что вы контролируете домен. Это дает вам возможность настроить безопасную связь с вашим сайтом, но не доказывает пользователям, что вы являетесь тем, за кого себя выдаете, за исключением того факта, что вы являетесь текущим владельцем домена.
 Чтобы настроить HTTPS с помощью Let’s Encrypt! сертификат, вы можете следовать инструкциям certbot.
 В AWS Lightsail имеется брандмауэр, защищающий вашу виртуальную машину, который необходимо перенастроить, чтобы разрешить входящие подключения HTTPS (порт 443) перед настройкой certbot.
 Шаг 6b: Настройка базовой аутентификации 
 Для использования базовой HTTP-аутентификации необходимо настроить файл htpasswd с именами пользователей и хешированными паролями. Это не должно обслуживаться через HTTP; его можно хранить в  /etc/nginx  подальше от HTTP-сервера. Проще всего его создать с помощью утилиты  htpasswd . Поскольку для этого нет встроенной утилиты nginx, вы можете использовать утилиту из пакета  apache2-utils . Вы можете установить это, а затем создавать пользователей для своего сайта, используя  -c  при первом создании несуществующего файла. Мы используем  sudo  просто для того, чтобы получить разрешение на запись в  /etc/nginx  здесь:
 $ sudo htpasswd -c /etc/nginx/thermostat_htpasswd
$ sudo htpasswd /etc/nginx/термостат_htpasswd
 
 Здесь рекомендуется использовать длинные случайные пароли; вы можете сгенерировать их с помощью  pwgen(1)  , а затем использовать свой браузер, чтобы запомнить пароль. Вам нужно будет включить пароль планировщика в  /etc/sensors/config   файл на хосте, на котором запущен сам планировщик: для получения дополнительной информации см. README.md в репозитории, особенно раздел, посвященный файлу конфигурации.
 Шаг 6c: файл конфигурации nginx 
 Наконец, вам нужно настроить конфигурацию для обслуживания BoilerIO API и статических страниц пользовательского интерфейса. Для этого создайте новый файл конфигурации, который выглядит примерно так:  /etc/nginx/sites-available/boiler , затем свяжите его под  site-enabled   и удалите  по умолчанию   site:
 сервер {
  слушать 80;
слушать [::]:80;
имя сервера ;
вернуть 301 https://$host$request_uri;
}
сервер {
слушать 443 ssl; # под управлением Certbot
    ssl_certificate /etc/letsencrypt/live//fullchain.pem; # под управлением Certbot
    ssl_certificate_key /etc/letsencrypt/live//privkey.pem; # под управлением Certbot
включить /etc/letsencrypt/options-ssl-nginx.conf; # под управлением Certbot
корень /var/www/html;
индекс index.html;
расположение / {
auth_basic 'термостат';
auth_basic_user_file '/etc/nginx/thermostat_htpasswd';
расположение /API {
try_files $uri @boilerio;
}
}
местоположение @boilerio {
включить uwsgi_params;
переписать ^/api/(. *)$ /$1 break;
uwsgi_pass unix:/var/www/boilerio/thermostat.sock;
}
} 
 В приведенном выше файле конфигурации используется структура, отличная от структуры, установленной  certbot , для перенаправления пользователей с сайта HTTP на сайт HTTPS. Версия  certbot   работает, но в приведенном выше примере отсутствует оператор  if  (см. раздел Если это зло) и не включены какие-либо операторы, которые могут привести к доставке какого-либо контента в блок  сервера без SSL , снижение вероятности ошибок при будущих изменениях конфигурационного файла.
 Важно, чтобы  301 Перемещено навсегда   ответ происходит   до  аутентификации. Последовательность для перенаправленного запроса должна быть такой, как показано здесь:
 Вы можете проверить, что поток происходит так, как вы ожидаете, используя такой инструмент, как tcpdump или wireshark. Если вы запустите на сервере команду  tcpdump -w packages -i eth0  или аналогичную, зайдите на сайт из браузера, затем откройте трассировку пакетов, созданную в Wireshark, и отфильтруйте  http , вы должны увидеть следующее — обратите внимание, что нет запросов аутентификации.
No related posts.