[Умный дом, Интернет вещей] «Умный дома» в каждую квартиру многоквартирного дома, или наш MVP
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В прошлой статье мы рассказали о создании нашей команды, но в этой статье хотим рассказать как именно мы реализовали первый наш проект.
Описание объекта
Итак наш первый объект — жилой дом имеющий следующие характеристики:
- 15 этажей
- 135 квартир
- Импульсные приборы учета холодного водоснабжения у каждой квартиры
- Тепловые счетчики с M-bus у каждой квартиры
- Счетчики электроэнергии с RS-485 интерфейсом у каждой квартиры
- Датчик температуры в каждой квартире
- Один клапан на подающем трубопроводе отопления в квартиру
Первым делом мы поставили перед собой задачи:
- Накидать принципиальную схему автоматики
- Подобрать оборудование для тепловых счетчиков и водомеров
- Подобрать оборудование для регистрации температуры и управления подачи теплового носителя в квартиры
- Подобрать оборудование для снятия показаний с электросчетчиков и управление реле нагрузки
- Сделать проект системы диспетчеризации и автоматизации многоквартирного жилого дома
- Написать первую версию нашего back end и собрать стенд для теста
- Разработать дизайн для двух веб приложений (для управляющей компании и жильца)
- Написать приложение для фронта которая будет в свою очередь тянуть данные с БД
Принципиальная схема коммуникации полевого оборудования объекта
Пока мы не знали какое оборудование использовать, мы решили нарисовать принципиальную схему коммуникации оборудования.
У теплового счетчика (Apator LQM) имеются 4 импульсных входа, которые могут конфигурироваться под различные нужды, к примеру, как в нашем случае мы настроили первый импульсный вход на м3, задали вес импульса как у нашего водомера, задали первоначальные показания водяного счетчика, и так для каждой квартиры была создана пара — теплосчетчик / водомер. Получая данные с теплосчетчика мы параллельно получали показания водомера холодного водоснабжения.
Счетчики электроэнергии отдавали данные по DLMS/COSEM (поверх RS485), мы еще не знали что это, как вытянуть от туда данные, но ясно было одно, что с счетчиком надо научится работать. Из общения с заводом производителем прибора учета, он дал нам понять протокол закрытый — вы его не получите, а считывать можно обычным преобразователем RS485 в COM или TCP/IP при помощи их ПО.
Для управления подачей теплового носителя и регистрации температуры необходимо было установить на этаже контроллер который имел бы достаточное количество входов и выходов, для измерения температуры и управления клапаном в каждой квартире.
И самое главное, мы отдали предпочтение получению данных от полевого оборудования по TCP/IP, все последовательные интерфейсы мы переводили в TCP/IP. В подвале дома стоял роутер с поднятым VPN к нашему серверу где были раскатаны все ПО.
Принципиальная схема коммуникации оборудования
Схема готова, начинаем подбор оборудования.
Тепловые счетчики
На просторах интернета не так много информации о сборе данных по протоколу M-Bus. В основном это компании разработавшие свои устройства (M-BUS concentrator) которые подключались к 250 ед. приборов учета и выгружали данные в какое то облако с ужасным интерфейсом и без возможности построение аналитики и выгрузки в биллинговые сервисы данных. Единственное, что мы нашли на рынке Украины, это преобразователь интерфейсов и протоколов фирмы Anybus, но его стоимость и сроки поставки нас не устроили. Ну что ж, Леха выдвинул идею купить преобразователь интерфейсов M-BUS/RS-485 и какой то raspberry pi которая по RS-485 будет опрашивать счетчики.
Но единственную либу и фреймворк которую мы нашли — 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 и разбирал голые байты — наш человек.
Результат прослушки порта
Шлюз он собирал из ATMega-32, RS-485 / TTL и RJ-45 для ардуино (уже не помню точной спецификации). То есть шлюз был мастером счетчиков и работал по принципу польского блока. Делаем 2 шлюза, тестим на 5 счетчиках, все класс.
Самопальное устройство для счетчиков
Ставим на объект 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 был отправлен в ремонт (тьфу-тьфу).
Первый стенд
Датчики температур мы использовали Pt1000, да аналоговые, да есть погрешность особенно при большой длине провода, а у нас от контроллера до датчика бывало по 35 метров, но по сравнению с цифровыми датчиками температур проще подключение, надежнее, дешевле, и самое главное, когда в квартире приступали делать ремонт, 30% датчиков обычно перекусывают, что при использовании цифрового датчика приводит к короткому замыканию линии и зачастую к зависанию полевого устройства.
Оборудование подобрали, научились с ним работать, на полевом уровне в доме все должно работать и функционировать, собираем щиты.
Щит в сборе
Мы приступили к написанию первой версии нашего back`end, параллельно запустили в дизайн два интерфейса (для управляющей компании и жильца), приступили к монтажу на объекте.
Монтаж и пусконаладка
Отдельное слово нужно сказать про монтаж и пусконаладку. На объект ушло:
- 15 контроллеров
- 6,5 км FTP cat 5e
- 2 км ПВС
- 15 ед. Switch
- 30 ед. блоков питания 24 В
Работы для первого объекта и прототипа было много, провода необходимо было не просто раскидать под потолком, но и подписать каждый (ведь каждый провод был для определенного квартирного датчика, клапана, водомера/теплосчетчика), после монтажа, каждый провод прозванивался и расключался. Что то перепутал и все — не тот клапан открылся и закрылся для квартиры, у соседей чужие показания и так далее.
Каждый теплосчетчик квартиры нужно синхронизировать с показаниями водомера квартиры и правильно подключить. К каждой квартире относятся 3 серийных номера прибора учета, их тоже перепутать нельзя, или в бухгалтерии будет труба.
Дизайн интерфейсов
Пока шел монтаж, и написание первого бэка, наша команда front`end готовила первые дизайны двух интерфейсов (для управляющей компании и жильцов), было предложено порядка 4-х вариантов для каждого из интерфейсов.
Сложность состояла в том, что эти интерфейсы будут не просто сайтами для продажи, они должны быть легкими, простыми и удобными потому, что если у жильца не будет хорошего впечатления и UX, по какой то из причин (непонятно как управлять, где температура и тд) то он просто съест управляющую компанию и это будет проблема, так как нас съест заказчик.
В управляющей компании работают в основном инженеры и они вообще не привыкли пользоваться чем-то подобным, им давай СКАДу, АСКУЭ и 1-С с тяжелыми интерфейсами.
Я думаю, что у нас получилось создать необходимые дизайны и в будущем их реализовать.
Интерфейс жильца
Пример страницы для УК
Супер! Впереди еще, осознание проблем:
- как управлять подачей теплового носителя довольно сложно, особенно если у тебя на квартиру 45 м2 один датчик температур и один клапан
- как людям донести нашу идею и помочь им принять технологию
- как сделать систему масштабируемой, быстро и просто
- надо следить за потреблением ресурсов и выявлять неисправные импульсные водомеры и залипшие клапана, ведь обратная связь отсутствует
- калибровка датчиков температур
- перегрев MBus gateway, и перевод памяти в read only
- с квартирами мы разобрались, а вот котельные, ТП, насосные. Мы ведь хотим реальный BMS!
Но как ни странно тогда без опыта мы щелкали эти проблемы, как орешки и шли вперед.
Всем добра!
===========
Источник:
habr.com
===========
Похожие новости:
- [Python, Big Data, Визуализация данных] Tableau Hyper API – BI-команда скажет вам спасибо
- [Open source, Системное администрирование, IT-инфраструктура, Визуализация данных] Grafana+Zabbix: Визуализация работы производственной линии
- [Умный дом, Будущее здесь] В МТИ разработали систему, которая без камер отслеживает действия и перемещения людей
- [Тестирование IT-систем, Управление разработкой, Конференции] 26 августа приглашаем на круглый стол QA&SDET
- [Интернет-маркетинг, Развитие стартапа, Управление продуктом, Облачные сервисы, Дизайн] [Подборка] 6 no-code инструментов для быстрого запуска продуктов и автоматизации процессов
- [Интернет вещей] Старый строительный бизнес и новые технологии, или история одного стартапа
- [Реверс-инжиниринг, Умный дом] Исследование протокола системы контроля давления воздуха в шинах автомобиля (TPMS)
- [Финансы в IT] Зачем Google инвестирует $450 млн в компанию-разработчика систем домашней безопасности ADT
- [Беспроводные технологии, Интернет вещей, Будущее здесь, Интервью] Жизнь в 2030 (перевод)
- [Дизайн мобильных приложений, Agile, Управление продуктом, Интернет вещей, Будущее здесь] Как мы хакнули умные подушки и запустили приложение для умной спальни «Асконы»
Теги для поиска: #_umnyj_dom (Умный дом), #_internet_veschej (Интернет вещей), #_iot, #_umnyj_dom (умный дом), #_askue (аскуэ), #_dispetcherizatsija (диспетчеризация), #_avtomaticheskoe_upravlenie (автоматическое управление), #_avtomatizatsija (автоматизация), #_smart_home, #_umnyj_dom (
Умный дом
), #_internet_veschej (
Интернет вещей
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:51
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В прошлой статье мы рассказали о создании нашей команды, но в этой статье хотим рассказать как именно мы реализовали первый наш проект. Описание объекта Итак наш первый объект — жилой дом имеющий следующие характеристики:
Первым делом мы поставили перед собой задачи:
Принципиальная схема коммуникации полевого оборудования объекта Пока мы не знали какое оборудование использовать, мы решили нарисовать принципиальную схему коммуникации оборудования. У теплового счетчика (Apator LQM) имеются 4 импульсных входа, которые могут конфигурироваться под различные нужды, к примеру, как в нашем случае мы настроили первый импульсный вход на м3, задали вес импульса как у нашего водомера, задали первоначальные показания водяного счетчика, и так для каждой квартиры была создана пара — теплосчетчик / водомер. Получая данные с теплосчетчика мы параллельно получали показания водомера холодного водоснабжения. Счетчики электроэнергии отдавали данные по DLMS/COSEM (поверх RS485), мы еще не знали что это, как вытянуть от туда данные, но ясно было одно, что с счетчиком надо научится работать. Из общения с заводом производителем прибора учета, он дал нам понять протокол закрытый — вы его не получите, а считывать можно обычным преобразователем RS485 в COM или TCP/IP при помощи их ПО. Для управления подачей теплового носителя и регистрации температуры необходимо было установить на этаже контроллер который имел бы достаточное количество входов и выходов, для измерения температуры и управления клапаном в каждой квартире. И самое главное, мы отдали предпочтение получению данных от полевого оборудования по TCP/IP, все последовательные интерфейсы мы переводили в TCP/IP. В подвале дома стоял роутер с поднятым VPN к нашему серверу где были раскатаны все ПО.  Принципиальная схема коммуникации оборудования Схема готова, начинаем подбор оборудования. Тепловые счетчики На просторах интернета не так много информации о сборе данных по протоколу M-Bus. В основном это компании разработавшие свои устройства (M-BUS concentrator) которые подключались к 250 ед. приборов учета и выгружали данные в какое то облако с ужасным интерфейсом и без возможности построение аналитики и выгрузки в биллинговые сервисы данных. Единственное, что мы нашли на рынке Украины, это преобразователь интерфейсов и протоколов фирмы Anybus, но его стоимость и сроки поставки нас не устроили. Ну что ж, Леха выдвинул идею купить преобразователь интерфейсов M-BUS/RS-485 и какой то raspberry pi которая по RS-485 будет опрашивать счетчики.  Но единственную либу и фреймворк которую мы нашли — 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 и разбирал голые байты — наш человек.  Результат прослушки порта Шлюз он собирал из ATMega-32, RS-485 / TTL и RJ-45 для ардуино (уже не помню точной спецификации). То есть шлюз был мастером счетчиков и работал по принципу польского блока. Делаем 2 шлюза, тестим на 5 счетчиках, все класс.  Самопальное устройство для счетчиков Ставим на объект 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 был отправлен в ремонт (тьфу-тьфу).  Первый стенд Датчики температур мы использовали Pt1000, да аналоговые, да есть погрешность особенно при большой длине провода, а у нас от контроллера до датчика бывало по 35 метров, но по сравнению с цифровыми датчиками температур проще подключение, надежнее, дешевле, и самое главное, когда в квартире приступали делать ремонт, 30% датчиков обычно перекусывают, что при использовании цифрового датчика приводит к короткому замыканию линии и зачастую к зависанию полевого устройства. Оборудование подобрали, научились с ним работать, на полевом уровне в доме все должно работать и функционировать, собираем щиты.  Щит в сборе Мы приступили к написанию первой версии нашего back`end, параллельно запустили в дизайн два интерфейса (для управляющей компании и жильца), приступили к монтажу на объекте. Монтаж и пусконаладка Отдельное слово нужно сказать про монтаж и пусконаладку. На объект ушло:
Работы для первого объекта и прототипа было много, провода необходимо было не просто раскидать под потолком, но и подписать каждый (ведь каждый провод был для определенного квартирного датчика, клапана, водомера/теплосчетчика), после монтажа, каждый провод прозванивался и расключался. Что то перепутал и все — не тот клапан открылся и закрылся для квартиры, у соседей чужие показания и так далее. Каждый теплосчетчик квартиры нужно синхронизировать с показаниями водомера квартиры и правильно подключить. К каждой квартире относятся 3 серийных номера прибора учета, их тоже перепутать нельзя, или в бухгалтерии будет труба. Дизайн интерфейсов Пока шел монтаж, и написание первого бэка, наша команда front`end готовила первые дизайны двух интерфейсов (для управляющей компании и жильцов), было предложено порядка 4-х вариантов для каждого из интерфейсов. Сложность состояла в том, что эти интерфейсы будут не просто сайтами для продажи, они должны быть легкими, простыми и удобными потому, что если у жильца не будет хорошего впечатления и UX, по какой то из причин (непонятно как управлять, где температура и тд) то он просто съест управляющую компанию и это будет проблема, так как нас съест заказчик. В управляющей компании работают в основном инженеры и они вообще не привыкли пользоваться чем-то подобным, им давай СКАДу, АСКУЭ и 1-С с тяжелыми интерфейсами. Я думаю, что у нас получилось создать необходимые дизайны и в будущем их реализовать.  Интерфейс жильца  Пример страницы для УК Супер! Впереди еще, осознание проблем:
Но как ни странно тогда без опыта мы щелкали эти проблемы, как орешки и шли вперед. Всем добра! =========== Источник: habr.com =========== Похожие новости:
Умный дом ), #_internet_veschej ( Интернет вещей ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:51
Часовой пояс: UTC + 5