«Умный дом» в каждую квартиру многоквартирного дома. Детально о контроллере и шлюза. Demo доступы к приложениям

Всех приветствую!

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

В данной статье хотел бы немного рассказать о:

• программировании контроллера
• настройки mbus шлюза и его выхода из строя
• примеры экономии и графики с реального объекта

Программирование контроллера

Используемые нами контроллеры — это свободно программируемые контроллеры, с языком FBD программирования. Есть заготовленные блоки от производителя такие как: математические функции, преобразователи типов, переключатели, счетчики импульсов, задатчики и т.д. И ты соединяя эти блоки в цепь пишешь нужную логику.

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

Нам необходимо было к каждой квартире привязать следующие параметры которые необходимо было по Mod-Bus TCP вытягивать в приложение:

1. Температура.
2. Положение клапана.
3. Заданная температура.
4. Величина ночного снижения.
5. Время ночного снижения.
6. Параметры режима подачи отопления по времени.
7. Корректировка датчика температур.

К каждому параметру необходимо было выделит от 1 до 3 регистров ModBus, в сумме у нас получилось 17 регистров, и так 17 квартир на этаже, нужно 289 регистров. Опа, а контроллера то 225 регистров. Если интересно расскажу в комментариях как мы вышли из положения. Вот как выглядит наша программка.

Она огромная. И мы поняли, что даже в FBD необходимо создавать свою библиотеку и документацию, так как объемы росли, задач было много, и новый человек просто не в силах был осилить этот ужас. Нужно было упрощать жизнь.

Контроллер обладает очень гибким функционалам и характеристиками, хочешь 19 входов для датчиков температур, держи, 9 входов для датчиков температур, 5 дискретных входов и 5 входов 0-10 В — пожалуйста. При этом 10 дискретных выходов 220 В до 6 А. То что нужно для умного дома. И мы приступили к созданию индивидуальных решений с использованием подобных промышленных контроллеров, и в этом есть ряд плюсов:

• Надежность.
• Качество.
• Техподдержка.
• Взаимозаменяемость.
• Простота.
• Цена.

Но и минусы есть:

• Внешний вид.
• Слабое железо.
• Открытые протоколы передачи данных.

К Новому Году планируем запустить прототип и МВП, и приступить к нескольким шоурумам.

MBus Gateway

Наши концентраторы/шлюзы опрашивали до 60 приборов учета с MBus. Сам шлюз состоит грубо говоря из 2 частей:

• NanoPi NEO
• Mbus плата

На NanoPI NEO установлен Linux с фреймворком OpenMUC. Сам находит счетчики, сам парсит MBus фрейм, но не со всеми счетчиками гладко, нужно играться и настраивать, НО работает.

Данные от приборов учета NanoPI NEO получает посредством MBus платы. Тут я ничего сказать не могу. Не паяем.

И так когда шлюз просканировал всю сеть, он создает конфиг файл, который потом использует приложуха для считывания данных с приборов учета и записи их в ModBus регистры. Все просто казалось бы, но каждый раз после скана сети, регистры перемешиваются, и ты точно не можешь сказать, что в регистре 175 лежит информация с прибора учета с №1055021, выход — конфигурируем сами этот чудо файлик.

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

Плюсы :

1. Цена.
2. Техподдержка.
3. Настройка.
4. Решает нашу проблему, с Mbus в TCP.

Минусы:

1. Долго ждать чтоб привезти его в Украину.
2. Плата MBus очень перегревается, температура элементов доходит до 120 градусов.
3. СД карточка NanoPI NEO.

И так в следствии перегрева MBus платы, вечно память NanoPI NEO уходила в Read Only, можно было тупо его перезагружать, но после 3-4 перезагрузок устройство не запускалось. Оказалось, что необходимо было сначала выполнить команду HALT, а потом только перезагружать, в противном случае ты просто убивал карту памяти. Мы решили проблему с перегревом следующим образом:

1. Установка вентиляторов в щиты.
2. Вентиляционные отверстия в шлюзе.
3. Автоматизация команды HALT с последующим отводом и подачей 24 В.

Сейчас завод производитель ушел от NanoPI NEO, и устанавливает одноплатные компьютеры с распаянным SSD диском. Для индивидуальных решений мы тоже решили осторожно подходить к использованию одноплатных компьютеров с SD картой.

Немного реальных данных

Мы за последние 2 года совершили много ошибок, и самая ужасная была в том, что когда получилось запустить систему, мы не стали расти и масштабироваться — это привело к многим последствиям, мы чуть не распались, но слава богу пока держимся. Но для роста не достаточно просто печатать код и релизится, нужно выпускать нужные новшества опираясь на мнение людей. И такой информацией я бы хотел поделится, на сайте есть эта информация. Мы решились опросить наших жильцов, и выбрали для этого прохождение онлайн формы, на опросник откликнулись 51 человек из 500+ пользователей на тот момент. Лично для меня это был успех. Многим зашла идея и многие в будущем будут обращать внимание на наличие подобных систем при покупке жилья.

Еще как пример реальных данных хотел бы привести две квартиры с нашей системой и без нее. Квартиры близнецы: в одинаковых секция, одинаково ориентированы, соседи везде живут, в общем идентичные квартиры.

В квартире с нашей системой была выставлена ночная температура 20 градусов, и дневная температура 22 градуса. В квартире без нашей системы было жарко, жильцы жаловались, что очень жарко. Есть нюанс, что квартира без нашей системы платила по квадратуре, без теплового счетчика. Поэтому приведу третью квартиру близнец в который жилец просто выбросил клапан подачи отопления и платил просто по счетчику.

Разница существенная, на общем фоне котельная секции с нашей системой потребляет на 10-12% меньше газа за отопительный период чем идентичные ей, не 30% и 40%, а только потому, что многие люди пока не приняли подобные продукты.

Умный дом, умные решения это не панацея от всех болячек, если жилец/человек не захочет пользоваться чем либо, получать от этого выгоду, то ничего не получится. Любая умная система — это инструмент в руках жильца, как в нашем случае. И как пример две картинки с реального объекта, эти же данные доступны на сайте в демках.

Данные температур и потребления тепловой энергии взяты за один период одной квартиры.

Спасибо за внимание! Всем удачи!