Как стать автором
Обновить

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

Разработка для интернета вещей *Умный дом Интернет вещей

image


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


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


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


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

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


Мы используем свободно-программируемые контроллеры, поддерживающие программирование на языке FBD (IEC 61161-3). ПО от производителя содержит заготовленные блоки: математические функции, преобразователи типов, переключатели, счетчики импульсов, задатчики и т.д; соединяя эти блоки в цепь пишется нужная логика.


image


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


Нам необходимо было к каждой квартире в приложении привязать параметры, считываемые по Modbus TCP:


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

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


image


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


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


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

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


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

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


MBus Gateway


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


  • NanoPi NEO
  • Mbus плата

image


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


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


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


image


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


Плюсы :


  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, и устанавливает одноплатные компьютеры с распаянным NVMe памятью. Для индивидуальных решений мы тоже решили осторожно подходить к использованию одноплатных компьютеров с SD картой.


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


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


image


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


image


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


image


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


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


image


image


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


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

Теги:
Хабы:
Всего голосов 5: ↑4 и ↓1 +3
Просмотры 13K
Комментарии Комментарии 11