28 августа

«Умный дом» в каждую квартиру многоквартирного дома, или наш MVP

Умный домИнтернет вещей


В прошлой статье мы рассказали о создании нашей команды, но в этой статье хотим рассказать как именно мы реализовали первый наш проект.

Описание объекта


Итак наш первый объект — жилой дом имеющий следующие характеристики:

  • 15 этажей
  • 135 квартир
  • Импульсные приборы учета холодного водоснабжения у каждой квартиры
  • Тепловые счетчики с M-bus у каждой квартиры
  • Счетчики электроэнергии с RS-485 интерфейсом у каждой квартиры
  • Датчик температуры в каждой квартире
  • Один клапан на подающем трубопроводе отопления в квартиру

Первым делом мы поставили перед собой задачи:

  • Накидать принципиальную схему автоматики
  • Подобрать оборудование для тепловых счетчиков и водомеров
  • Подобрать оборудование для регистрации температуры и управления подачи теплового носителя в квартиры
  • Подобрать оборудование для снятия показаний с электросчетчиков и управление реле нагрузки
  • Сделать проект системы диспетчеризации и автоматизации многоквартирного жилого дома
  • Написать первую версию нашего back end и собрать стенд для теста
  • Разработать дизайн для двух веб приложений (для управляющей компании и жильца)
  • Написать приложение для фронта которая будет в свою очередь тянуть данные с БД

Принципиальная схема коммуникации полевого оборудования объекта


Пока мы не знали какое оборудование использовать, мы решили нарисовать принципиальную схему коммуникации оборудования.

У теплового счетчика (Apator LQM) имеются 4 импульсных входа, которые могут конфигурироваться под различные нужды, к примеру, как в нашем случае мы настроили первый импульсный вход на м3, задали вес импульса как у нашего водомера, задали первоначальные показания водяного счетчика, и так для каждой квартиры была создана пара — теплосчетчик / водомер. Получая данные с теплосчетчика мы параллельно получали показания водомера холодного водоснабжения.

Счетчики электроэнергии отдавали данные по DLMS/COSEM (поверх RS485), мы еще не знали что это, как вытянуть от туда данные, но ясно было одно, что с счетчиком надо научится работать. Из общения с заводом производителем прибора учета, он дал нам понять протокол закрытый — вы его не получите, а считывать можно обычным преобразователем RS485 в COM или TCP/IP при помощи их ПО.

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

И самое главное, мы отдали предпочтение получению данных от полевого оборудования по TCP/IP, все последовательные интерфейсы мы переводили в TCP/IP. В подвале дома стоял роутер с поднятым VPN к нашему серверу где были раскатаны все ПО.

image
Принципиальная схема коммуникации оборудования

Схема готова, начинаем подбор оборудования.

Тепловые счетчики


На просторах интернета не так много информации о сборе данных по протоколу M-Bus. В основном это компании разработавшие свои устройства (M-BUS concentrator) которые подключались к 250 ед. приборов учета и выгружали данные в какое то облако с ужасным интерфейсом и без возможности построение аналитики и выгрузки в биллинговые сервисы данных. Единственное, что мы нашли на рынке Украины, это преобразователь интерфейсов и протоколов фирмы Anybus, но его стоимость и сроки поставки нас не устроили. Ну что ж, Леха выдвинул идею купить преобразователь интерфейсов M-BUS/RS-485 и какой то raspberry pi которая по RS-485 будет опрашивать счетчики.

image

Но единственную либу и фреймворк которую мы нашли — OpenMUC, но в тот момент мы не смогли в нем разобраться. Тогда начали шерстить рынок Европы и нашли! Ребята в Польше производили устройство которое нам надо, и цена класс, но как его привезти в Украину? Через посредников нам удалось это сделать.

И вот чудо посылка, распаковываем, подключаем, включаем скан счетчиков и…… не видит. Ну мы так раз 5-7 попробовали, решили, что возможно MBUS Gateway рабочий, а счетчик нет. Я бегу к друзьям, выпрашиваю у них теплосчетчик Sharky, подключаю к Gateway и…… опросил!!! Мы рады, открываем шампанское! Победа! Тосты! Но тут до нас доходит мысль, что на объекте то будет стоять 135 счетчиков Apator которые кстати тоже польского производства, а с ними у нас разговор не задался! Пишем в Польшу на завод Gateway, ждем, пишем еще и еще, и так 4 дня — тишина. Руки не опускаем (господи какими мы были больными на голову), начинаю серфить в FB, находим там Матеуша который работает на заводе, находим его телефон и собираемся позвонить. Я хватаю Леху, говорю: “ты был 3 года подряд в Америке на WT, сейчас будешь Полякам объяснять, что у их Украинских друзей проблемы!”

Он звонит, начинает говорить на английском, но все, что выдавил из себя Матеуш: “Hi! Yes!”, и что вы думаете Леха с ним начинает говорить по Польски, по Польски!!! В итоге вопрос решился так, что необходимо на их форуме саппорта, создать топик с описанием проблемы и данными для подключения к устройству и спустя 2 дня, ребята с Польши научили свое устройство общаться с нашим теплосчетчиком Apator.

Важно отметить, что Gateway записывал данные с MBUS в Modbus регистры, откуда мы их и забирали. Также блок мог опрашивать 60 устройств, а не 250 ед. мы специально на это пошли для увеличения скорости получения данных с дома и надежности.

Счетчики электроэнергии


Тут было вообще эпично! Я долго искал решения получения данных с счетчиков электроэнергии, завод нам на помощь не шел, так что пришлось справляться самому. Снова нас спас Google, на каком то форуме я нашел человека, который очень активно обсуждал тему диспетчеризации счетчика как у нас, и у него были наработки в этом направлении. Я ему написал, он ответил, из разговора стало ясно следующее: он сделал реверс — инжиниринг протокола обмена данными с ПО производителя счетчика. Он просто слушал COM port и разбирал голые байты — наш человек.

image
Результат прослушки порта

Шлюз он собирал из ATMega-32, RS-485 / TTL и RJ-45 для ардуино (уже не помню точной спецификации). То есть шлюз был мастером счетчиков и работал по принципу польского блока. Делаем 2 шлюза, тестим на 5 счетчиках, все класс.

image
Самопальное устройство для счетчиков

Ставим на объект 15 штук по 9 счетчиков на каждый, и на следующее утро сгорают 5 устройств. В чем дело, на стенде все было хорошо, но стенд это стенд, реалии это реалии. Оказывается RS-485 / TTL был без гальванической развязки. Снимаем блоки, покупаем нужные RS-485 / TTL, паяем, ставим и…… снова они же вылетают. Проблему так и не решили с этими блоками, однако мы нашли заводское решение RS-485 / Ethernet, и за двое суток мы сами реверсунли протокол счетчиков. Все получилось.

Управление подачей теплового носителя и регистрация температур в квартирах


Нам необходимо было подобрать контроллер подходящий по цене, по гарантии и сервисной службе. Начали с Siemens, Wago, но из-за цены и отсутствия адекватного сервисного центра (любой подобный контроллер для ремонта необходимо отправлять за границу и ждать недели 3, а при условии, что у нас их было 15 штук это могло сыграть плохую шутку), мы продолжили искать и нашли контроллеры Украинского производства Raut, для наших нужд был идеален — входов/выходов достаточно, программирование гораздо проще чем в том же SoMachine Schneider, цена нас устроила, сервис от 3 до 5 дней, доставка 1 — 2 недели. И качество удовлетворительное, за 2 года мы установили порядка 150 штук и только 1 был отправлен в ремонт (тьфу-тьфу).

image
Первый стенд

Датчики температур мы использовали Pt1000, да аналоговые, да есть погрешность особенно при большой длине провода, а у нас от контроллера до датчика бывало по 35 метров, но по сравнению с цифровыми датчиками температур проще подключение, надежнее, дешевле, и самое главное, когда в квартире приступали делать ремонт, 30% датчиков обычно перекусывают, что при использовании цифрового датчика приводит к короткому замыканию линии и зачастую к зависанию полевого устройства.

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

image
Щит в сборе

Мы приступили к написанию первой версии нашего back`end, параллельно запустили в дизайн два интерфейса (для управляющей компании и жильца), приступили к монтажу на объекте.

Монтаж и пусконаладка


Отдельное слово нужно сказать про монтаж и пусконаладку. На объект ушло:

  • 15 контроллеров
  • 6,5 км FTP cat 5e
  • 2 км ПВС
  • 15 ед. Switch
  • 30 ед. блоков питания 24 В

Работы для первого объекта и прототипа было много, провода необходимо было не просто раскидать под потолком, но и подписать каждый (ведь каждый провод был для определенного квартирного датчика, клапана, водомера/теплосчетчика), после монтажа, каждый провод прозванивался и расключался. Что то перепутал и все — не тот клапан открылся и закрылся для квартиры, у соседей чужие показания и так далее.

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

Дизайн интерфейсов


Пока шел монтаж, и написание первого бэка, наша команда front`end готовила первые дизайны двух интерфейсов (для управляющей компании и жильцов), было предложено порядка 4-х вариантов для каждого из интерфейсов.

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

В управляющей компании работают в основном инженеры и они вообще не привыкли пользоваться чем-то подобным, им давай СКАДу, АСКУЭ и 1-С с тяжелыми интерфейсами.
Я думаю, что у нас получилось создать необходимые дизайны и в будущем их реализовать.

image
Интерфейс жильца

image
Пример страницы для УК

Супер! Впереди еще, осознание проблем:

  • как управлять подачей теплового носителя довольно сложно, особенно если у тебя на квартиру 45 м2 один датчик температур и один клапан
  • как людям донести нашу идею и помочь им принять технологию
  • как сделать систему масштабируемой, быстро и просто
  • надо следить за потреблением ресурсов и выявлять неисправные импульсные водомеры и залипшие клапана, ведь обратная связь отсутствует
  • калибровка датчиков температур
  • перегрев MBus gateway, и перевод памяти в read only
  • с квартирами мы разобрались, а вот котельные, ТП, насосные. Мы ведь хотим реальный BMS!

Но как ни странно тогда без опыта мы щелкали эти проблемы, как орешки и шли вперед.

Всем добра!
Теги:IoTумный домаскуэдиспетчеризацияавтоматическое управлениеавтоматизацияsmart home
Хабы: Умный дом Интернет вещей
+20
8,4k 62
Комментарии 37
Лучшие публикации за сутки