SCN-ENERGY-005: Управление нагрузкой (отключение неприоритетных потребителей при пиковой мощности)
Концепция управления нагрузкой (Load Shedding)
Управление нагрузкой, или Load Shedding, — это один из ключевых сценариев энергоэффективности как для частных, так и для коммерческих объектов. Его основная задача — автоматически отключать неприоритетных потребителей электроэнергии в моменты, когда общее потребление приближается к критическому или нежелательному порогу. Этот процесс позволяет избежать негативных последствий, как технических, так и финансовых.
> 💡 Подсказка: Для коммерческих объектов, таких как небольшие производства, гостиницы или офисные центры, управление пиковой мощностью может снизить ежемесячные счета на 15-30% за счет исключения штрафов за превышение заявленной мощности, которая прописывается в договоре с энергосбытовой компанией.
Что такое пиковая мощность?
Пиковая мощность (Peak Power) — это максимальное мгновенное значение мощности, потребляемой всеми электроприборами на объекте в определенный момент времени. Важно понимать, что электросеть, включая вводной кабель, автоматические выключатели и внутреннюю проводку, проектируется именно под пиковую, а не среднюю нагрузку.Превышение этого пикового значения может привести к двум основным проблемам:
Концепция приоритезации нагрузок
В основе сценария управления нагрузкой лежит простое, но эффективное правило: не все потребители электроэнергии одинаково важны в каждый момент времени. Систему можно научить "жертвовать" менее важными нагрузками для сохранения работоспособности более важных. Для этого все потребители на объекте разделяются на группы по приоритетам.
📋 Ключевые понятия:
- Критически важные нагрузки (Приоритет 1): Потребители, отключение которых недопустимо. К ним относятся циркуляционные насосы системы отопления, серверное оборудование, системы безопасности и связи, аварийное освещение.
- Приоритетные нагрузки (Приоритет 2): Потребители, отключение которых крайне нежелательно, но возможно на очень короткий срок. Например, основное освещение, компьютеры на рабочих местах.
- Неприоритетные нагрузки (Приоритет 3): Инерционные системы, временное отключение которых не приведет к немедленному дискомфорту. Классические примеры: электрический бойлер, системы вентиляции, кондиционеры.
- Отключаемые нагрузки (Приоритет 4): Потребители с наименьшим приоритетом, отключение которых практически не влияет на комфорт или производственные процессы в краткосрочной перспективе. Сюда входят теплые полы, зарядные станции для электромобилей, подогрев уличных дорожек.
Общий алгоритм работы сценария выглядит следующим образом:
Этот умный механизм позволяет максимально эффективно использовать выделенную электрическую мощность, не жертвуя работой ключевых систем.
---
Архитектура и компоненты системы
Для реализации надежного сценария управления нагрузкой требуется правильно подобранная аппаратная база, где контроллер HI выступает в роли "мозгового центра". Рассмотрим ключевые компоненты этой архитектуры.
Центральный контроллер
Контроллер HI является ядром системы. Его задачи:
- Сбор данных: Постоянный опрос счетчика электроэнергии по цифровой шине (например, Modbus).
- Принятие решений: Выполнение логики сценария, написанной в среде Node-RED, для анализа текущей мощности и принятия решения об отключении или восстановлении нагрузок.
- Управление: Отправка команд на исполнительные устройства (реле, контакторы) для физического включения или выключения потребителей.
- Надежность: Благодаря наличию EEPROM и функции ПЛК, контроллер способен сохранять критические состояния и конфигурации даже при перезагрузке, обеспечивая бесперебойную работу автоматики.
Счетчик электроэнергии (Средство измерения)
Это "глаза" нашей системы. Невозможно управлять тем, что нельзя измерить. Выбор счетчика — критически важный шаг. Для наших задач подходят не бытовые счетчики с импульсным выходом, а промышленные анализаторы сети, передающие точные данные по цифровому протоколу.
| Модель | Протокол | Шина | Преимущества |
| ---------------------- | ------------- | ------------ | ------------------------------------------------------------------------- |
| Wiren Board WB-MAP3E/MAP12E | Modbus RTU | RS-485 | Высокая точность, измерение множества параметров (мощность, напряжение, ток по каждой фазе), прямая совместимость с экосистемой. |
| Eastron SDM630-Modbus | Modbus RTU | RS-485 | Популярная и надежная модель, промышленный стандарт, хорошее соотношение цены и качества. |
| Conto-D4-Pt (ABB) | Modbus RTU / M-Bus | RS-485 | Также измеряет параметры пофазно, надежный европейский бренд. |
| MQTT-счетчики | MQTT | TCP/IP (LAN) | Некоторые современные счетчики или шлюзы могут публиковать данные напрямую в MQTT, что упрощает интеграцию в Node-RED. |
Основной параметр, который нам нужен, — общая активная мощность (Total Active Power). Именно её мы будем считывать с устройства, как правило, из соответствующего Modbus-регистра.
Исполнительные устройства (Средства управления)
Это "руки" нашей системы. Они исполняют команды контроллера, физически размыкая или замыкая цепи питания нагрузок.
- Встроенные реле контроллера HI: Контроллер имеет на борту 22 реле, которые отлично подходят для управления нагрузками малой и средней мощности (до 16А), такими как группы розеток, отдельные конвекторы или бойлеры.
- Внешние контакторы с управлением от реле: Для коммутации мощных нагрузок (электрические котлы, группы теплых полов, целые этажи в здании) используется связка "реле контроллера + силовой контактор". Реле контроллера подает слаботочный управляющий сигнал на катушку контактора, а уже контактор коммутирует силовую цепь.
- Модули реле Modbus: Если нагрузки распределены по объекту, целесообразно использовать внешние релейные модули (например, Wiren Board WB-MR6C), подключенные к той же шине RS-485, что и счетчик. Это экономит кабельные трассы.
- Умные розетки (Zigbee/Wi-Fi): В системах "умного дома" можно использовать умные розетки для отключения отдельных, не самых мощных приборов. Их интеграция в Node-RED обычно происходит через MQTT (например, с помощью Zigbee2MQTT).
Схема потоков данных
Визуализация потока данных помогает понять архитектуру системы в целом:
[Счетчик Modbus] ==(RS-485)==> [Контроллер HI]`^`
`| (Чтение регистра мощности)`
`|`
[Node-RED Flow]`|`
`| (Логика: анализ, решение)`
`v`
[Реле контроллера / Modbus реле] ==(Проводное соединение)==> [Контактор] ==(Силовая линия)==> [Нагрузка]Эта простая и надежная архитектура, построенная на промышленных протоколах, обеспечивает стабильную и предсказуемую работу сценария управления нагрузкой.
---
Определение приоритетов и конфигурация
Прежде чем приступать к написанию кода, необходимо выполнить подготовительную работу: классифицировать нагрузки и создать гибкую конфигурацию. Жесткое кодирование параметров в узлах `function` является плохой практикой, так как любое изменение потребует вмешательства в логику потока.
Практические рекомендации по классификации нагрузок
Процесс классификации — это поиск баланса между комфортом и энергоэффективностью. Проведите аудит всех значимых потребителей на объекте и распределите их по группам.
| Приоритет | Группа | Примеры нагрузок | Логика отключения |
| :-------: | ----------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------- |
| 1 | Неотключаемые | Серверы, СКУД, видеонаблюдение, насосы отопления, холодильники, аварийное освещение. | Никогда не отключаются автоматически. |
| 2 | Краткосрочные | Основное освещение, рабочие станции, бытовая техника (ТВ, аудио). | Отключаются в самую последнюю очередь, если ничего другое не помогло. |
| 3 | Инерционные | Бойлер, кондиционер, конвекторы, вентиляция. | Отключение на 15-60 минут обычно не вызывает дискомфорта. |
| 4 | Низкоприоритетные | Теплые полы, зарядка электромобиля, подогрев бассейна, сауна, обогрев ливнестоков. | Отключаются первыми при малейшем риске перегрузки. |
Этот список должен быть задокументирован и согласован с владельцем объекта.
Создание конфигурационного объекта
Для хранения настроек мы будем использовать объект в контексте потока (`flow context`), который будет инициализироваться при старте Node-RED. Это позволит легко изменять параметры без редактирования кода.
В узле `function`, подключенном к узлу `inject` (в режиме "Inject once after 0.1 seconds"), мы определим всю нашу конфигурацию.
// Этот код выполняется один раз при запуске для инициализации конфигурации
const config = {
// Пороговые значения мощности в Ваттах (W)
thresholds: {
shed: 15000, // Верхний порог: при превышении начинаем отключать
restore: 12000 // Нижний порог: при падении ниже него начинаем восстанавливать
},
// Список управляемых нагрузок
loads: [
{
id: "load-01",
name: "Теплый пол (Гостиная)",
priority: 4, // Самый низкий приоритет
controlTopic: "home/livingroom/floor_heating/set",
statusTopic: "home/livingroom/floor_heating/state",
state: "UNKNOWN", // Текущее состояние: ON, OFF, SHED_OFF (отключено автоматикой)
manual: false // Флаг ручного управления
},
{
id: "load-02",
name: "Электрический бойлер",
priority: 3,
controlTopic: "home/utilityroom/boiler/set",
statusTopic: "home/utilityroom/boiler/state",
state: "UNKNOWN",
manual: false
},
{
id: "load-03",
name: "Зарядка электромобиля",
priority: 4,
controlTopic: "home/garage/ev_charger/set",
statusTopic: "home/garage/ev_charger/state",
state: "UNKNOWN",
manual: false
},
{
id: "load-04",
name: "Основная вентиляция",
priority: 3,
controlTopic: "home/hvac/main_ventilation/set",
statusTopic: "home/hvac/main_ventilation/state",
state: "UNKNOWN",
manual: false
}
]
};
// Сохраняем конфигурацию в контексте потока для доступа из других узлов
flow.set("loadSheddingConfig", config);
node.status({fill:"green", shape:"dot", text:"Конфигурация загружена"});
return null; // Ничего не отправляем дальше
Эта структура данных является "единым источником правды" для нашего сценария.
- `thresholds`: Определяет гистерезис, о котором пойдет речь далее.
- `loads`: Массив объектов, где каждый объект — это управляемая нагрузка.
* `priority`: Числовой приоритет (чем выше число, тем ниже приоритет).
* `controlTopic`: MQTT-топик для отправки команд (`ON`/`OFF`).
* `statusTopic`: MQTT-топик для получения обратной связи о состоянии.
* `state`: Внутреннее состояние автомата (`ON`, `OFF`, `SHED_OFF`). `SHED_OFF` означает, что нагрузка была отключена именно сценарием управления мощностью, а не пользователем.
* `manual`: Флаг, позволяющий исключить нагрузку из автоматического управления.
Такой подход делает систему гибкой, масштабируемой и простой в обслуживании.
---
Реализация алгоритма в Node-RED
Теперь, когда у нас есть четкая архитектура и конфигурация, перейдем к созданию потока в Node-RED. Основная логика будет сосредоточена в одном узле `function`.
> ⚠️ Внимание: В этом сценарии критически важно использовать два разных порога (`shed` и `restore`) для предотвращения "дребезга" системы. Мы применяем здесь паттерн "Гистерезис", который подробно разбирался в уроке `COURSE-07-M04-L01` по управлению климатом.
1. Чтение данных с Modbus-счетчика
Первым шагом является настройка периодического опроса счетчика. Как мы рассмотрели ранее в модуле по протоколам, для этого используется связка `Inject` + `Modbus-Getter`.
* Server: Выбираем преднастроенный Modbus-клиент (например, `/dev/ttyRS485-1`, 9600, 8N1).
* Unit-ID: Адрес вашего счетчика на шине (например, `1`).
* FC: `Read Input Registers`.
* Address: Адрес регистра, хранящего общую активную мощность (например, `258` для WB-MAP3E). Это значение нужно взять из документации на ваш счетчик.
* Quantity: Количество регистров для чтения (обычно 2 для 32-битного значения).
Выход этого узла мы подаем на вход главного узла `function`.
2. Главный узел `function`: логика отключения и восстановления
Этот узел является сердцем сценария. Он получает данные о мощности, обращается к конфигурации из контекста и принимает решение.
// Получаем конфигурацию из контекста потока
let config = flow.get("loadSheddingConfig");
// Если конфигурация еще не загружена, выходим
if (!config) {
node.status({ fill: "red", shape: "dot", text: "Конфигурация не найдена!" });
return null;
}
// Получаем текущую мощность из полезной нагрузки от Modbus-узла.
// Предполагается, что узел Modbus уже преобразовал буфер в число.
// Если нет, здесь нужна обработка msg.payload.buffer.
const currentPower = msg.payload;
// Валидация входных данных
if (typeof currentPower !== 'number' || isNaN(currentPower)) {
node.status({ fill: "yellow", shape: "ring", text: "Некорректные данные мощности" });
return null;
}
node.status({ fill: "blue", shape: "dot", text: `P: ${currentPower} W` });
// ================== ЛОГИКА ОТКЛЮЧЕНИЯ (SHEDDING) ==================
if (currentPower > config.thresholds.shed) {
node.status({ fill: "red", shape: "dot", text: `ПЕРЕГРУЗКА: ${currentPower} W` });
// 1. Найти кандидатов на отключение: те, что сейчас включены ('ON') и не в ручном режиме
let loadsToShed = config.loads.filter(load => load.state === 'ON' && !load.manual);
// 2. Сортировать их по приоритету (от низшего к высшему)
loadsToShed.sort((a, b) => b.priority - a.priority);
// 3. Если есть кого отключать, отключаем первого в списке
if (loadsToShed.length > 0) {
let loadToTurnOff = loadsToShed[0];
// Помечаем, что нагрузка отключена автоматически
loadToTurnOff.state = 'SHED_OFF';
// Обновляем конфигурацию в контексте
flow.set("loadSheddingConfig", config);
// Формируем сообщение для отправки команды на отключение
let newMsg = {
topic: loadToTurnOff.controlTopic,
payload: "OFF"
};
// Отправляем уведомление (можно на отдельный выход узла)
node.send([newMsg, {payload: `Отключена нагрузка: ${loadToTurnOff.name}`}]);
return; // Выходим после одного действия, чтобы переоценить мощность на следующей итерации
}
}
// ================= ЛОГИКА ВОССТАНОВЛЕНИЯ (RESTORATION) ===============
else if (currentPower < config.thresholds.restore) {
// 1. Найти кандидатов на восстановление: те, что были отключены автоматикой ('SHED_OFF')
let loadsToRestore = config.loads.filter(load => load.state === 'SHED_OFF' && !load.manual);
// 2. Сортировать их по приоритету (от высшего к низшему)
loadsToRestore.sort((a, b) => a.priority - b.priority);
// 3. Если есть кого включать, включаем первого в списке
if (loadsToRestore.length > 0) {
let loadToTurnOn = loadsToRestore[0];
// Возвращаем в нормальное состояние
loadToTurnOn.state = 'ON';
// Обновляем конфигурацию в контексте
flow.set("loadSheddingConfig", config);
// Формируем сообщение для отправки команды на включение
let newMsg = {
topic: loadToTurnOn.controlTopic,
payload: "ON"
};
// Отправляем уведомление
node.send([newMsg, {payload: `Восстановлена нагрузка: ${loadToTurnOn.name}`}]);
return; // Выходим после одного действия
}
}
// Если мы находимся в "мертвой зоне" гистерезиса, ничего не делаем.
return null;
Этот код реализует пошаговую логику: за один цикл (2-3 секунды) выполняется только одно действие — либо отключение одной группы, либо включение. Это предотвращает лавинообразные переключения и дает системе время на стабилизацию и корректное измерение новой мощности.
---
Логика восстановления и обратная связь
Корректное восстановление питания и информирование пользователя не менее важны, чем своевременное отключение. Это создает ощущение надежности и предсказуемости умного дома, а не хаотичности.
> 🔗 Связанный материал: Логика работы с режимами AUTO/MANUAL подробно раскрыта в модуле `COURSE-07-M01` "Управление состоянием и режимами". Подход к отключению розеток по системному режиму 'Away' описан в уроке `SCN-ENERGY-001`.
Алгоритм восстановления питания
Как было показано в коде выше, алгоритм восстановления — это зеркальное отражение алгоритма отключения:
ℹ️ Информация: Для предотвращения резкого скачка тока при одновременном включении нескольких мощных потребителей, можно добавить между включениями небольшую задержку (5-10 секунд) с помощью узла `trigger`.
Реализация пользовательских уведомлений
Ничто так не раздражает пользователя, как "умный" дом, который ведет себя непредсказуемо. Если в гостиной внезапно отключился теплый пол, человек должен немедленно узнать, почему это произошло.
В нашем главном узле `function` мы уже предусмотрели второй выход для отправки текстовых сообщений.
* Первый выход используется для отправки управляющих MQTT-команд. Его мы подключаем к узлу `mqtt out`.
* Второй выход используется для уведомлений. Его мы подключаем к узлу-отправщику сообщений (например, `node-red-contrib-telegrambot-plus` или другому, который вы используете).
Пример потока для уведомлений:
`[Main Function Node (Output 2)]` -> `[Telegram Sender]`
Сообщение должно быть четким и информативным:
- `"Внимание: потребляемая мощность достигла 15.2 кВт. Для предотвращения перегрузки отключен 'Теплый пол (Гостиная)'."`
- `"Информация: нагрузка на сеть снизилась. Восстановлено питание 'Электрический бойлер'."`
Переключатель "Ручной/Авто" режим
Иногда автоматику нужно временно отключить (например, во время ремонтных работ или при необходимости гарантированно включить все приборы). Для этого создается глобальный переключатель.
const mode = global.get('loadSheddingMode') || 'AUTO';
if (mode === 'MANUAL') {
node.status({fill:"grey", shape:"ring", text:"Ручной режим"});
return null; // Если режим ручной, прекращаем выполнение любой логики
}
Эта простая доработка дает пользователю полный контроль над системой и повышает доверие к автоматизации.
---
Итоги и лучшие практики
Мы разработали сложный, но чрезвычайно полезный сценарий `SCN-ENERGY-005`, который является признаком профессионально спроектированной системы автоматизации. Он не только повышает безопасность и надежность электроснабжения, но и может принести прямую экономическую выгоду.
Краткий обзор созданного сценария
Лучшие практики и советы по внедрению
- Документируйте всё: Таблица с приоритетами нагрузок и пороговыми значениями должна быть частью проектной документации. Любой инженер, который придет на объект после вас, должен иметь возможность быстро разобраться в логике работы системы.
- Тестируйте тщательно: Перед сдачей объекта в эксплуатацию необходимо провести полное тестирование сценария.
- Информируйте конечного пользователя: Проведите для владельца объекта краткий инструктаж. Объясните, почему автоматика может отключать те или иные приборы. Покажите, как пользоваться ручным режимом. Это снимет 99% потенциальных вопросов и жалоб в будущем. Правильно поданная информация превращает "непонятное отключение" в "умную заботу" системы о безопасности и бюджете.
- Начинайте с малого: При первоначальной настройке установите порог отключения заведомо высоким, а в список управляемых нагрузок добавьте только самые неприоритетные (например, только теплый пол). Понаблюдайте за работой системы в течение нескольких дней, проанализируйте реальные пики потребления и только после этого корректируйте пороги и добавляйте новые группы нагрузок.
Что дальше
В следующем модуле мы перейдем к рассмотрению сценариев, связанных с безопасностью и контролем доступа. Мы научимся интегрировать датчики движения и открытия, управлять замками и создавать комплексные сценарии "Имитация присутствия" для защиты объекта во время отсутствия хозяев.