В конце прошлой статьи я остановился на перечислении того бесконечного списка технических решений, которые очень хочется реализовать в рамках автоматизации всей, ну не страны, но дачи.
Раньше общее потребление контролировал однофазный счетчик с Modbus-интерфейсом. Следить за текущими показаниями потребления полезно, чтобы не превышать разумные лимиты и не дожидаться отключения групповых автоматов. С этой задачей он справлялся на «ура». Но гораздо интереснее следить за каждым потребителем в отдельности. Для чего и как это сделать попробую рассказать в этой статье.
Прежде всего я хотел сказать большое спасибо вам, коллеги, за проявленный интерес к предыдущей статье. Отвечать на ваши комментарии было не менее увлекательно, чем писать саму статью. Один наблюдательный читатель обратил внимание, что фильтр грубой очистки воды установлен вверх ногами!
Wiren Board производит несколько моделей многоканальных modbus-счетчиков электроэнергии: четырехканальный трехфазный монстр WB-MAP12H (и его одноканальный младший брат WB-MAP3H), шестиканальный однофазный WB-MAP6S и отдельную модель WB-MAP3E, которая применяется в специальных случаях, когда требуется диагностировать короткие и мощные всплески напряжения.
Счетчики серии WB-MAP измеряют огромное количество параметров сети: мгновенные параметры напряжения, тока, частоты, мощности (активной, реактивной, полной), коэффициентов мощности, фазовые углы; накопленные значения энергий по каждому каналу. Кроме всего прочего, счетчики MAP позволяют измерять коэффициенты гармоник по напряжению и току, что важно для оценки качества электроэнергии в сетях со “злобными” потребителями.
Напряжение подается непосредственно на клеммы счетчиков, а ток для каждого канала измеряется разъемными токовыми трансформаторами. Это очень удобно при установке счетчика в готовом щите.
Монтаж счетчиков
 |
 |
В демонстрационных щитах трансформаторы тока выглядят красиво и аккуратно (как на картинке в заглавии поста), в реальной жизни приходится размещать трансформаторы там, где это получается. И да, щиты должны быть большими!
Проект автоматизации моего дачного дома, как я подробно рассказывал в предыдущей статье, сделан на основе предыдущей версии нашего контроллера Wiren Board 5, к которому по интерфейсу Modbus подключены различные релейные модули, исполнительные устройства и датчики.
Перед очередными выходными я вооружился двумя счетчиками WB-MAP6S и одним WB-MAP12H и занялся делом. Первоначальные прикидки по количеству каналов измерения оказались, конечно, неверными: потребителей, за которыми хотелось наблюдать, оказалось больше, так что некоторое время пришлось потратить на размышления, по каким группам измерять потребление.
Были выбраны общий ввод, нагрузки после стабилизатора и инвертора, конвекторы и кондиционеры (каждый по отдельности), два бойлера, телекоммуникационный шкаф, автоматические ворота, холодильник, теплый пол.
Счетчики собирают огромное количество параметров (WB-MAP12H имеет более тысячи регистров), но даже постоянный опрос нескольких десятков параметров с каждого счетчика становится значительной нагрузкой на шину RS-485, если опрашивать их слишком часто. Стандартные шаблоны, которые идут вместе с контроллером, я сократил до необходимого минимума параметров.
Счетчики я перенес на вторую шину RS-485 контроллера Wiren Board, чтобы не мешать нормальной работе релейных модулей и датчиков, и увеличил скорость до 115200 кбит/с. В такой конфигурации опрос счетчиков стал выполняться довольно бодро и не мешал функционированию остальной автоматики.
Прежде чем приступить к практическому использованию полученных результатов, их необходимо проанализировать со всех сторон. Контроллер Wiren Board имеет встроенную базу данных и простые средства визуализации, но для серьезных задач стоит использовать более серьезные средства.
Вспомнив, что я как-никак Zabbix CP, решил было развернуть мониторинг на нем, но тяга к новому пересилила и я решился попробовать использовать для хранения и отображения данных популярную связку Influxdb + Grafana. Контроллер транслирует все данные в виде mqtt-топиков на отдельный mqtt-брокер на сервере, где скрипт на Python обрабатывает их и сохраняет в Influx. Там же установлена Grafana для отображения всего и вся.
Первые же результаты меня не разочаровали. Вот несколько примеров.
Напряжение в сети
Все провалы, за редким исключением, приходятся на время около 21:00 — 23:00 часов и в выходные особенно заметны. Пики — раннее утро.
Так выглядит работа двух стабилизаторов (желтая и голубая линии):
Это обычные релейные стабилизаторы известного в широких кругах латвийско-китайского производителя, с достаточно большим шагом меняющие напряжение на выходе. Ничего особенного, хотя видно, что один из них склонен к переключению на совсем уж предельные (укладывающиеся, правда, в рамки ГОСТа) значения напряжения. Первый кандидат на замену.
Мгновенные значения отображаются в виде таких графановских виджетов:
Просто и наглядно, годится для вывода на информационный экран или планшет на стене.
Очень живописно выглядит график мгновенной мощности для всех потребителей (щелкните на рисунке, чтобы открыть в полном масштабе):
Большое и зеленое — это не крокодил, а общая мощность на входе.
Grafana позволяет выбрать на графике не только все, но один или несколько показателей, представляющих интерес.
Коэффициент мощности (cos ?). У современных бытовых устройств он вполне себе неплох. Я исследовал работу трех потребителей: кондиционера, холодильника и водонагревателя.
У водонагревателя в момент активной работы коэффициент мощности 1 — “высокий” (0,95…1), у холодильника 0,85 — “хороший” (0,8…0,95); коэффициент мощности кондиционера (0,76) находится у верхней границы “удовлетворительного” диапазона (0,65…0,8).
Инверторный кондиционер:
 |
 |
Работа в штатном режиме охлаждения и структура отдельного пика включения компрессора (справа)
Видны пики при начальном запуске компрессора внешнего блока, стабильный режим работы, дежурный режим.
Как работает холодильник? “Др-др-др-др-др-др-др?” Почти что. Компрессор запускается периодически, по мере потепления внутри камер:
Периодические включения компрессора холодильника
Структура отдельного пика энергопотребления
Отдельный цикл: виден бросок мощности при включении компрессора холодильника. Счетчики WB-MAP достаточно чувствительные: видите эти маленькие пики, около десятка Ватт? Это загоралась лампочка внутри холодильника: кто-то в него лазил!
Полотенцесушитель работает в цикле постоянного включения/выключения для поддержания заданной температуры:
 |
 |
Справа более детальное изображение отдельных пиков потребления
Примерно так же работает варочная поверхность:
Кажется, это варился мой утренний кофе.
Интересный профиль энергопотребления у автоматических ворот:
Около 5 Ватт потребляют они в дежурном режиме, при работе профиль энергопотребления позволяет увидеть отдельные фазы движения створок: начинает открываться первая, затем начинает вторая, затем они открываются вместе, а затем по очереди стопорятся и двигатели приводов отключаются.
Бойлер поддерживает температуру воды, частота и время включений зависят от потребления горячей воды:
Не буду утомлять дальше читателей графиками — покажу табличку! (Grafana умеет не только строить графики, но и отображать данные в таблицах и на столбчатых диаграммах.)
Табличка простая и позволяет отслеживать общее потребление энергии по часам, а также оценить, во что обошелся каждый час в соответствии с текущим тарифом. Старая версия Influxdb, которая ставится из репозиториев текущей версии Ubuntu на сервере, не умеет делать привычные выборки из выборок, поэтому добавить столбец со стоимостью каждого часа не удалось.
На диаграмме потребление выглядит так:
Учитывая, что Gafana может генерировать тревожные сообщения, полученного результата вполне хватает для light-версии мониторинга энергоснабжения.
Однако хочется решить и более увлекательные задачи.
- Гармоники тока и напряжения. Несут ли они полезную информацию для дома? Часто плохие потребители или искрящие контакты генерируют гармоники высоких порядков. Насколько хватит временного разрешения счетчиков, чтобы их детектировать и принимать какие-то решения об отключении “плохих нагрузок”? Или просто выдавать алерты?
- Кондиционеры и конвекторы. Если отталкиваться от температуры в помещении, можно понять, в каком режиме работает кондиционер: пытается ли он с диким упорством охладить конвектор (конвектор следует отключить) или они сотрудничают вместе, чтобы побыстрее нагреть помещение, если кондиционер работает в обратном режиме, на нагрев?
- Ворота. Если профиль энергопотребления меняется и начинает значительно отличаться от штатного, то это может говорить о том, что есть какое-то препятствие, загустело масло в приводах от низкой температуры, кто-то слишком часто открывает-закрывает ворота. Тут можно отправлять предупреждения, отключать питание. Хватит ли для этого средств контроллера, Influx и Grafana? Возможно, такие вещи надо реализовывать отдельным скриптом, подписанным только на сообщения со значениями параметров энергопотребления ворот.
- Насосная станция и скважинный насос. Вместе с оценкой расхода воды возможно отследить падение производительности из-за каких-то неисправностей, течи, проблем с накопительными баками.
- Работу компрессора септика тоже можно оценить по энергопотреблению, хотя расход воздуха более информативен, на мой взгляд.
- Водонагреватели. В скважине очень жесткая вода, накипь образуется достаточно быстро. Соответственно, нагревательным элементам приходится работать больше и в более жестком режиме, нагревая воду из-под дополнительного кожуха накипи (он еще и пригорать начинает, если довольно толстый). Интересно будет понять, хватит ли анализа потребляемой мощности для детектирования образовавшейся накипи (у бойлеров нет интерфейса для сообщения о температуре воды в баке)?
- Общее энергопотребление — если токи подходят к предельным значениям, можно отключать низкоприоритетные нагрузки.
Буду рад, если кто-нибудь предложит неожиданный и интересный вариант использования мониторинга энергопотребления отдельных устройств.
До новых встреч, друзья!
Комментарии (28)
VioletGiraffe
30.08.2018 10:58Не вполне понял вот этот момент:
В скважине очень жесткая вода, накипь образуется достаточно быстро. Соответственно, нагревательным элементам приходится работать больше и в более жестком режиме, нагревая воду из-под дополнительного кожуха накипи
Это же нагреватель, он преобразует примерно 100% потребляемой мощности в тепло. Да, сам нагревательный элемент будет нагреваться до более высоких температур, но это никак не должно повлиять на потребляемую им мощность. Поправьте меня, если не так.kilpio Автор
30.08.2018 11:06Всё верно, да он будет дольше нагревать, но, возможно, если теплоотдача из-за накипи будет хуже, то температура тэна повысится, сопротивление уменьшится и мощность возрастет. Посмотрим!
shtirlitsus
30.08.2018 11:37+2Я думал, сопротивление ТЭНа при нагревании увеличивается. Иначе он при нагревании перегорит. Отрицательная обратная связь получается.
anonymous
30.08.2018 12:36+1И давно у нагревателей стал отрицательный температурный коэффициент сопротивления?
Как раз таки при нагреве потребляемая мощность падает.
А из-за накипи ухудшается отвод тепла от нагревателя, что приближает его кончину, и очень быстро.
voted
30.08.2018 12:50Эх, красиво то как. Я вот два года назад сам задумал похожую систему в квартире. Но ремонт штука такая… Уже постепенно и запал спадает. Но именно такие статьи меня вдохновляют не сдаваться и таки довести дело до конца (даже несколько статей самому написать о своём опыте)
kilpio Автор
30.08.2018 13:44Спасибо! Я вот все жду того момента, когда щиты закрою пластронами и скажу «остановись мгновенье». Но столько всего интересного, что окончание отодвигается и отодвигается.
DeeZ
30.08.2018 13:26+1не умеет делать привычные выборки из выборок, поэтому добавить столбец со стоимостью каждого часа не удалось.
Не совсем понял что вы имеете ввиду, ведь у вас стоимость каждого часа и так выведена. Полагаю опечатка и мелось ввиду месяц?
У меня счетчик только общий, отдельно показывает накоплеттную активную и реактивную. За месяц вывожу на виджет таким запросом:
SELECT (max("ENERGY_Total")-min("ENERGY_Total"))+(max("ENERGY_Total Reactive Power")-min("ENERGY_Total Reactive Power")) FROM "mqttc" WHERE $timeFilter GROUP BY time(720d)
немного коряво, что разбивается по 30 дней, но мне такой «точности» достаточно.
А на вкладке Time range в поле Override relative time указать now/M (текущий месяц).
Для виджита цены — то же самое с умножением на тариф.
Получаестся примерно так:
ЗЫЖ Провалы это корявое обновление :)kilpio Автор
30.08.2018 13:56Красиво!
У вас структура базы данных слегка отличается от той, что я использую, вам проще. У меня все mqtt-значения пишутся в одну табличку типа таймстемп, значение, устройство, mqtt-топик; и запрос расхода выглядит примерно так:
SELECT difference(last("value_f")) FROM "mqtt_data" WHERE ("client" = 'MainWirenBoard' AND "channel" = 'wb-map12h_11/Ch 1 AP energy L3') AND $timeFilter GROUP BY time(1h) fill(previous)
А цена — вот так:
SELECT first("value_f") FROM "mqtt_data" WHERE ("client" = 'MainWirenBoard' AND "channel" = 'energyTariff/price') AND $timeFilter GROUP BY time(1h) fill(previous)
И первый SELECT на второй в Influxdb 1.1.1 я так и не смог помножить. Надо добраться до консерватории и что-то в ней поменять.DeeZ
30.08.2018 14:43У вас тариф от куда берется? он часто меняется часто?
kilpio Автор
30.08.2018 18:06Трехтарифный счетчик, тариф меняется 5 раз в день. Есть виртуальное устройство на контроллере, в котором хранится тип тарифа и стоимость кВтч. По таймеру обновляетсяю При обновлении приходит соответствующtt mqtt-сообщение. Это чтобы не плодить сущности и хранить информацию о тарифе в одном месте.
ish
31.08.2018 10:09А поделитесь кодом, пожалуйста :). Я сделал разделение тарифов на wb по времени суток, но как-то некрасиво и ненадежно получилось. Кстати, можно же наверное в счетчике прошивку допилить, чтобы расход по тарифам отдельно считался?
kilpio Автор
31.08.2018 22:52Хорошо, поделюсь, конечно. Вставлю следующим комментарием сюда на выходных.
DeeZ
01.09.2018 09:03А почему на скрипте остановились а не «родной» telegraf? Он складывает значения немного более уникально. Тогда будет возможно такое
SELECT difference(last("ENERGY_Total")) * last("ENERGY_Cost") FROM "mqttc" WHERE $timeFilter GROUP BY time($__interval) fill(previous)
Сообщения пушить так
mosquitto_pub -t 'tele/sdm/stat' -m {"ENERGY":{"Total":240,"Cost":3.2}}
alexhott
30.08.2018 13:50А эти счетчики только для собственного пользования или их можно как расчетные устанавливать?
kilpio Автор
30.08.2018 14:01Дя, для собственного пользования: только технический учет пока, не коммерческий. И, похоже, что в ближайшей перспективе такими эти счетчики и останутся. Общее потребление всегда можно по какому-нибудь интерфейсу получить с коммерческого, там, «Меркурия» — а у WB-MAP другая ниша.
Но это самый популярный вопрос про эти счетчики, верно!
VaalKIA
30.08.2018 15:50Если бы мог, поставил бы сразу плюс, только за то, что дача автоматизированная, а не умная.
kilpio Автор
30.08.2018 16:55Благодарю! «Умная дача решила, что самый большой расход энергии и сложность алгоритмов управления возникают исключительно благодаря дачникам и перестала пускать их на дачу!»
seri0shka
30.08.2018 17:47Действительно, редко сейчас встретишь. Всё «умное», аж бесит! Пора бы уже установить какие-то нормы для определения «умный». Вы действительно считаете умной свою кофеварку? Да у неё же IQ меньше 80!
Am0ralist
30.08.2018 17:53Вы действительно считаете умной свою кофеварку? Да у неё же IQ меньше 80!
Так IQ прибора не должно превышать IQ его пользователя…
catharsis
31.08.2018 16:39вариант использования мониторинга энергопотребления
по графику ответить на вопрос «выключен ли утюг» :)
Google когда-то показывал графики домашнего потребления электричества, но не взлетело.
Наверное это был Google PowerMeter
zzorgg
31.08.2018 22:54Я тоже очень люблю графики, гаджеты, статистику. Но какой практический смысл всего вашего мониторинга? Т.е. если отделить удовольствие от реализации и просмотра данных, которое (удовольствие) я полностью разделяю, как применить полученное себе (своей семье) в пользу? Этого статье очень не хватает.
Иначе получается, что мы узнали график потребления мощности холодильника или бойлера… и что? Кроме общего повышения уровня эрудиции профит в чем?kilpio Автор
31.08.2018 23:00Ну, совершенно верно — мне нравится мониторинг! Практика может быть довольно обширной: есть очевидные вещи, котрые я реализую в первую очередь, напрмер, следить за исправностью оборудования: при удаленном включении потребителей это не лишне. Потом есть вопросы, которые требуют дополнительного исследования, их я перечислил в конце статьи. Ну, и в третьих, я ожидаю идей от читателей: возможно, я далеко не все предусмотрел.
zzorgg
01.09.2018 13:53Слежение заключается в проверке запустилось / не запустилось? А на случай серьезного выхода из строя предусмотрен ли какой-нибудь способ реагирования и на сколько он автоматизирован? Самое опасное, что приходит на ум — возгорание. Есть ли контроль и система тушения? Может статься так, что он системы пожаротушения будет гораздо больше практической пользы, чем от всего мониторинга открытий холодильников.
Впрочем, система пожаротушения это отдельная область, и завязка на мониторинг энергопотребления ей не особо нужна.
А вот автоматическое определение неправильно работающего оборудования сравнением с «правильными профилями», и автоматическое же отключение таковых от сети — вполне имеет практическую пользу.
Вообще, я бы постарался всю систему сделать самостоятельной и в штатном режиме не беспокоящей хозяина. Какие либо сообщения должны приходить только при нештатных ситуациях. Красивые графики регулярно смотреть рано или поздно надоест.
Обязательно должен быть отдельный канал, сигнализирующий только о проблемах. Иначе в общем потоке легко не заметить важного, требующего вмешательства.
NordicEnergy
Честно говоря не очень понимаю вашу железку, ПЛК от того же сименса выглядит более логичным для применения (субъективно конечно), но дизайн gui и информативность мониторинга действительно очень крутые. Спасибо за статью, будет куда «подсмотреть» как надо делать))