ФОРУМ КУПИТЬ

Последние статьи

ВСЕ СТАТЬИ

Умный дом своими руками. Схема информационного обмена

26/03/2010 20:21:03

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

При создании любых технических устройств человек всегда что-нибудь заимствовал у природы. Так самолет похож на птицу, машина на ползающего жука, а подводная лодка на огромного кита. Все процессы, происходящие вокруг нас, протекают одновременно, часто без видимой связи. Но логика природы такова, что изменяя работу какого-либо процесса, даже очень незначительно, изменяются миллионы внутренних параметров, создается огромное количество зависимостей, мы таким образом влияем на процессы идущие параллельно и зачастую совсем кардинально меняем события последующие. У известного американского писателя-фантаста Рея Бредбери есть рассказ, в котором путешественник во времени всего лишь случайно раздавил бабочку в прошлом, а вернувшись в свое время, очутился совсем в другом мире.

В предыдущей статье, я рассказал об общих принципах, на которых должна строиться система автоматизации дома. Сейчас же, прежде чем приступить к рассмотрению каждого модуля, блока, элемента системы в отдельности, хотелось бы поделиться мыслями относительно общесистемного информационного обмена. С моей точки зрения система Умного Дома энтузиаста (а мы говорим прежде всего о "своих руках") должна строится в идеологии многозадачности, многопоточности, множественности работающих параллельно процессов. Микроклимат в доме, комфорт, безопасность и экономичность - это те природные процессы, которые идут единовременно, но в то же время взаимозависимо. Логичным было бы и управлять этими процессами сразу, с помощью разных программных блоков, связанных между собой информационными связями.

 

Умный дом - конструктор

 

Как я уже говорил, с моей точки зрения нет необходимости изобретать "велосипед" и делать все "с нуля" самостоятельно. Вряд ли получится лучше, чем у тех, кто занимается этим годами. Поэтому если какая-та задача или хотя бы элемент в реализации Умного Дома уже решена, нужно постараться использовать чужой опыт. Так мы находим, что функция видеонаблюдения уже решена с помощью программы ZoneMinder, функция визуализации, представления данных, интерфейса решена с помощью Apache и всевозможных фреймворков и CMS, функция координации, а также планирования задач - с помощью встроенных сервисов операционной системы, а функция для управления датчиками, исполнительными механизмами и прочими устройствами Умного Дома с помощью owfs, если речь идет о 1-wire, или другими библиотеками, программами и решениями, если речь идет о X-10, Modbus и прочих стандартах.

Наша задача заключается в двух вещах:

1. собрать в единое целое и связать между собой в единую систему различные программные блоки;
2. разработать высокоуровневую логику работы всей системы (что, когда и зачем включать и по каким алгоритмам)

В качестве операционной системы я применяю Linux. Эта ОС очень удачно вписывается в идеологию своеобразного конструктора, среды, в которой совершенно различные процессы могут быть связаны между собой десятками различных способов. Безусловно, любая современная ОС, в том числе Windows подходит для решения этой задачи, но в Unix-подобных системах гораздо легче при необходимости проникнуть сквозь визуальный десктоп, вглубь, к системным процессам. В Unix мы найдем больше способов для сопряжения различных программ между собой. Именно в Unix появились и развиваются Интернет-решения, которые я использую - это их родная среда. Но, тем не менее, все это также прекрасно работает в Microsoft Windows, хотя и с определенными сложностями.

Телевизор с доступом в ИнтернетИтак, моя система автоматизации Умного Дома построена на Интернет-решениях, а именно на таких программных блоках как Web-сервер, реляционная база данных, скриптовые языки программирования, на таких протоколах как TCP-IP, HTTP, на таких стандартах как HTML, CSS. И выбор этот далеко не случайный. Интернет-технологии прочно вошли в нашу жизнь и это проникновение продолжается. Уже очень многие бытовые приборы и оборудование имеют поддержку указанных протоколов и стандартов. Таким образом, уже сейчас можно выбирать для дома то оборудование, которое управляется через Интернет-технологии, а в будущем такие устройства будет, думаю, превалировать. Мы уже имеем на сегодняшний день не только бытовые медиа-плееры с поддержкой TCP, SMB, Ethernet, но и холодильники, микроволновые печи и даже стиральные машины. Пусть Вас не пугает тот факт, что иногда к прибору требуется подвести кабель UTP Cat 5. Все больше устройств поддерживают Wi-Fi и прочие радио-технологии. Стандарты Интернет давно уже показали свою перспективность, гибкость, надежность и главное - долговечность. Скриптовые языки программирования, такие как PHP, Perl, Python активно развиваются, просты в использовании, поддерживаются всеми платформами, имеют огромное количество библиотек, баз знаний и решений.

Кабель UTP, RJ-45Программировать интерфейс между системой и человеком тем более нужно именно на Интернет-решениях, так как это позволит контролировать и изменять работу систем Умного Дома не только из локальной сети дома, но и через Интернет или даже мобильный телефон. Большинство современных мобильных телефонов имеют встроенные Web-браузеры. Даже бытовые телевизоры уже начали производить с возможностью доступа в Сеть и браузером Интернет. Сидя на домашнем диване, не включая компьютер можно будет и посмотреть камеры наблюдения и открыть дистанционно дверь соседу. И все это без каких-либо сложных аппаратных конвертеров, мультиплексоров, переходников. Да и сам Web-интерфейс не нужно переделывать под конкретные устройства. Современные средства CSS+HTML позволяют делать так называемые "резиновые" Интерфейсы, которые сами адаптируются к размеру и разрешению экрана. Современные фреймворки и библиотеки сами определяют какие стандарты поддерживает клиентское ПО, а какие нет и используют нужные компоненты.

Важной отличительной особенностью такого подходя является тот факт, что для сопровождения такой системы или ее расширения возможно привлекать сторонних специалистов, занимающихся в сфере Интернет-технологий, Web-программистов и администраторов. Дело в том, что скриптовые языки, такие как PHP или Perl не компилируются и не кодируются. Написанные для Умного Дома программы всегда существуют в виде исходных кодов, что позволяет вносить в них любые коррективы. Кстати, эта особенность также интересна и с точки зрения удаленной коррекции кода программы. Например, будучи в отъезде, я смог удаленно с помощью SSH зайти на свой сервер через Интернет и исправить замеченную ошибку в регулировании отопления, связанную с ошибкой в управлении 3-х ходовым смесителем.

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

 

 

Центром системы является СУБД. В моем случае используется MySQL, но можно использовать любые системы управления базами данных, такие, например, как Oracle или Microsoft SQL. MySQL очень небольшая и функциональная система, удобная для хранения не очень большого количества данных. Однако в этой СУБД нет многих возможностей, доступных в Oracle. Последний гораздо более адаптирован для работы с большим количеством пользователей и огромными массивами данных. Впрочем, для работы систем Умного Дома достаточно простой и удобной СУБД MySQL.

В СУБД хранится вся текущая информация об элементах системы, состояние ключей, значения датчиков, а также история значений. В ней также хранятся конфигурационные данные модулей управления, такие как требуемая температура в помещении, количество и параметры контуров отопления, адреса датчиков. Кроме того, в базу записываются логи работы программы, их расчетные значения. Так, значением температуры в помещении может воспользоваться любой программный модуль. Любой программный модуль может (если это необходимо для работы его собственного алгоритма) "посмотреть" в каком состоянии находится соседний программный модуль, как он реагирует на какие-то изменения. Это важно, например, для параллельной работы системы отопления и кондиционирования. Эти системы могут работать по отдельности, но будучи запущенными вместе, они должны координировать свою работу. Если пользователь включил режим интенсивного проветривания дома, в результате чего температура в доме начала резко падать, система отопления должна понимать что происходит и не отвечать на это резким поднятием температуры в радиаторах, чтобы избежать раскачки системы после выключения активной вентиляции и не допустить перерасхода газа.

 

 

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

Такая идеология и подход к решению проблемы автоматизации дома очень удобен с точки зрения расширения системы или ее изменения, когда все блоки работают параллельно, связаны между собой, но в тоже время независимы друг от друга. У нас всегда есть возможность завершить работу любого блока без какого-либо существенного влияния на работу других систем. Единственным критически-важным элементом в этой схеме является сама СУБД, без которой вся дальнейшая работа невозможна. Но в действительности потенциально "рискованные" элементы этой схемы все-таки самописные скрипты управления, а такой надежный и стабильный продукт как MySQL.

Автор: Andrey_B
Любое использование материалов сайта возможно только с разрешения автора и с обязательным указанием источника.



Добавить комментарий:

(необязательно, не отображается на сайте)


Сортировка комментариев: Последние сверху | Первые сверху

2013-10-03 10:26:28 | Andrey_B
Александр, вы задаете слишком общий вопрос. Весь мой сайт отвечает на него, но я не могу все написанное упаковать в два предложения. Это первое. И второе - это используемый подход. На страницах сайта я описываю свое видение и пытаюсь объяснить почему был выбран такой путь, но многим он не подходит. А общие вопросы целесообразно задавать на нашем форуме - заходите.


2013-10-01 07:51:28 | Александр
Уважаемый Андрей прочел вашу статью и загорелся сделать что то подобное. По образованию я электрик ,скажите не могли бы вы мне помочь в моем начинании. Подсказать советом а так же пошагово проинструктировать во всем процессе. Я имею ввиду какие именно устройства мне использовать и где взять програмное обеспечение. С уважением Александр.


2013-05-14 10:35:13 | Andrey_B
Ivan, да, испсользую AJAX (в составе фреймворка jQuery).


2013-05-14 09:22:17 | Ivan
Андрей, а скажите пожалуйста, как на php реализовано отображение текущих данных? Ведь php-скрипт выполняется 1 раз при загрузке страницы. Или вы используете AJAX?


2012-07-30 10:52:46 | Andrey_B
Alter, на сайте же есть про это целая большая статья
Считывание данные со счетчика Меркурий-230


2012-07-30 08:41:09 | Alter
А расскажите как реализован сбор данных со счетчика Меркурий ?


2010-10-04 23:10:03 | Andrey_B
Spepan, десяток розеток и десяток выключателей - пример менее удачный, так как при соответствующем подходе 1-wire справится с этим весьма успешно. Conditional Search ROM command обеспечит мгновенную идентификацию сработавшего выключателя, а команда исполнительному ключу тем более отправится очень быстро.
Знаете, когда я пересаживаюсь с десктопного Intel Core i5, на ноутбучный Core 2 Duo, я не ощущаю разницы. Дело не в том, что эти процессоры существенно отличаются по производительности. Дело в том, что я не ставлю перед ними серьезные задачи. Загрузить страницу в Интернете сможет и i80386.
С моей точки зрения ПК (или мини-роутеры, embedded устройства) также как Ocelot или Leopard в X-10 технологии должны играть ключевую роль в логической схеме Умного дома. Это идеологическое, если хотите, политическое решение, которое я отстаиваю. Я прекрасно понимаю недостатки этого подхода точно также как понимаю недостатки конкурирующего подхода. На исполнительные узлы и механизмы можно вынести только функцию байпаса, бэкапа, то есть функцию, когда программа МК отрабатывает аварийный механизм работы.
Я не ощущаю, что LonWork, *-Bus, EIB имеет мощный вектор развития в области домашней автоматизации. Полагаю, что в конечном итоге эти решения останутся только в промышленности или в очень специализированных системах. А в доме их вытеснял более распространенные стандарты, применяемые в бытовых гаджетах и сетях Интернет, а это Ethernet, Wi-Fi, Bluetooth, I2C и то, что придет им на замену. При этом останется обратная совместимость.
Скажите чем конкретно я могу помочь развитию вашего проекта?
Я лично в самом ближайшем будущем планирую применение AVR или PIC для создания интеллектуальных модулей для систем Умного Дома, но идеологически они будут коренным образом отличаться от ваших.


2010-10-04 13:20:17 | Stepan
Диммер это просто пример более менее ресурсоемкого (в смысле пропускной способности шины) потребителя. Можно было привести пример десяток розеток + десяток выключателей + десяток других датчиков, которые могут выключать эти розетки, но это дольше расписывать.
Ну вы же работаете с компьютером, знаете как нервирует когда пересядешь с нового компа на старый и он жутко тормозит открывает папку не за одну секунду а за 5… Вот и на 1-wire в плане удобства интерфейса будет примерно то же самое. И выше на данном протоколе не поднять. Так что это не рельса, это просто дерево потверже, из которого вы захотите сделать себе УДОБНЫЙ и ПРОЧНЫЙ диван, но «японская бензопила» не потянет.
Кстати, я не против использования компьютера для выполнения сложных программ и согласования различных интерфейсов, обеими руками за! Но я не хочу отдавать ему весь функционал. Помимо головного мозга должен быть ещё и спиной, более устойчивый к софтварным бзикам, для бессознательных рефлексов. А компьютер пусть будет высокоинтеллектуальным рядовым устройством или маршрутизатором или ещё кем-нибудь, их в этом случае может быть и несколько.
И децентрализованная концепция развивается в настоящий момент более прогрессивно относительно централизованной: LonTalk, C-BUS, EIB… В данном проекте была попытка сделать более дешевый и доступный вариант таких систем. Возможно, что придумывание своего протокола действительно неоправданно (очень уж хотелось увидеть сразу что-нибудь работающее, без долгих чтений и выборов протоколов), но это дело наживное. Возьмем те же C-bus или LonTalk открытые протоколы и переделаем прошивки.
Я не дошел пока до применения компьютера, поэтому и хочу склонить Вас к сотрудничеству в этом проекте :) . Надеюсь на рост проекта за счет популярности и доступности данных микроконтроллеров, а также его открытости.


2010-10-03 22:23:38 | Andrey_B
Stepan, ваш пример мне напомнил старый бородатый анекдот, который я позволю себе процитировать:
===
Прислали суровым сибирским мужикам японскую бензопилу. Решили они ее испытать.
Положили на нее доску.
— Вжик, — сказала японская бензопила.
— Хм, — сказали суровые сибирские мужики и положили бревно.
— Вж-жик, — сказала японская бензопила.
— Хм-м, — сказали суровые сибирские мужики и положили целое дерево.
— Вж-ж-жик, — сказала японская бензопила.
— Хм-м-м, — сказали суровые сибирские мужики и положили рельс.
— Вж-ж-ж-ж-КРЯК! — сказала японская бензопила и сломалась.
— Ага-а-а! — сказали суровые сибирские мужики…
===
Вы еще, простите, предложите "раздавать" по 1-wire видео. Не знаю почему так сложилось, но когда речь заходит об Умном Доме, то всегда на передний план выходит этот чудо-прибор, вершина человеческой мысли, олицетворение всемогущества современной электроники - диммер. И почему-то совершенно не важно, что бОльшей части населения планеты он и вовсе не нужен, что 99% выпускаемых КЛЛ не работают с диммерами, что современная индустрия вообще идет по пути применения полупроводниковых приборов для освещения - светодиодов, для которых диммер для лампы накаливания как мертвому припарка. И речь даже не о том, что 1-wire поддерживает режим Overdrive, в котором скорость увеличивается в 10 раз. Прежде всего, главная мысль конкретно этой статьи, квинтэссенция текста - это, так сказать, мультиплатформенность, возможность сочетать различные подходы, где 1-wire живет рядом с RS232 и CAN, рядом с Ethernet и Wi-Fi и т.д.
Мне лично диммер не нужен. Когда-то, ввиду того что одинокая лампочка Ильича была в комнате единым источником света - это имело смысл. Сейчас, когда есть возможность управлять десятками источников освещения независимо, лично мне проще и понятнее управлять степенью освещенности световыми схемами. Но и это для меня не цель. Для меня Умный Дом - это система, позволяющая экономить, поддерживать комфорт и повышать качество жизни. Умный Дом - система, которая автоматически регулирует отопление, вентиляцию, кондиционирование, водоподготовку, экономит газ, электричество и воду, следит за аварийными ситуациями. Для меня Умный Дом - это гидромеханическая автоматическая коробка передач, а не китайский псевдоксенон. "Ехать", а не "шашечки".
Если ваша задача не вписывается в рамки какой-то определенной технологии, зачем упорно пытаться заворачивать саморезы плоскогубцами, когда есть шуруповерт? Можно завернуть, но неудобно, медленно и саморез некрасивый получается. Как я уже неоднократно заявлял в различных форумах - моноподход в системах энтузиастов (не в коммерческих системах) - это нелогично, нецелесообразно, неинтересно и непонятно. Почему бы не объединить различные задачи, протоколы, модули и подходы в единый алгоритм? В этом смысле понятно, почему я за применение ПК в роли головного мозга. Ваш Atmega с такими задачами по понятным причинам не справится, но тем интереснее в вашем случае разработать распределенную систему между модулями на Atmega, с какой-нибудь хитрой технологией обмена алгоритмами. Я не о протоколе, а о том, как построить единую, понятную и управляемую систему, где есть несколько мини-мозгов, чтобы они образовали единую систему.
А рассуждать - распилит японская пила рельсу или не распилит мне неинтересно.


2010-10-03 15:46:58 | Stepan
И всё равно считаю что 1-wire слишком медленный даже для включения выключения лампочек, простой пример: вы хотите управлять диммером. Для этого в передающей части используете обычный ИК пульт, который осуществляет постоянную посылку пакетов, каждый пакет при этом изменяет яркость на одну ступеньку, а в принимающей ИК приёмник + МК с 1-wire.
Посчитаем сколько будет посылаться один пакет по 1-wire:
1 мс – инициализация обмена данными
+
64байта адреса опрашиваемого устройства на предельной скорости в 15кБит = 4 мс
+
Код операции
+
Содержание самого пакета данных с ИК кодом и т.д.
Итого получаем 6 мс на опрос.

А пакеты в обычном пульте идут через 5-10 мс. Значит 1-wire уже не хватает, чтобы передать все пакеты, или хватает, но на пределе. А если таких устройств на одной шине висит штуки три? И ведь надо опрашивать ещё и остальные устройства.
А количество устройств и событий, по которым они должны быстро реагировать растёт лавинообразно. Вот и получается что 1-wire удобен только для инерционных вещей типа термостатов. И закладывать такую шину в развивающийся проект неперспективно, всё в конце концов и упрется в её пропускную способность, что я думаю и случилось с известным проектом Бенукс.


2010-10-03 10:52:49 | Andrey_B
Stepan, пропускная способность определяется не только шириной дороги, но и количеством и размером транспорта, передвигающегося по этой дороге. Если у нас есть только одна полоса шириной 3 метра, по которой активно двигаются колесные тракторы К-700 или десяток скоростных автомобилей класса Формула-1 - это проблема. Но если по этой дороге пустить россыпь радиоуправляемых машин, то даже чтобы специально столкнуть их - надо постараться. Другой пример, по сегодняшним временам 10Base-T - это ужасно медленно. Но так ли это в отношении коммуникации оборудования умного дома?
Некоторые промышленные шины, которые широко применяются для автоматизации сложнейших производственных процессов, ГОРАЗДО медленнее 1-wire, но у них есть и свои преимущества.
Stepan, для домашней автоматизации, особенно учитывая простую и дешевую логику, а также возможность объединять в единую систему неограниченное количество 1-wire сегментов, скорость - не главный недостаток этой технологии.

RS485 - это не протокол. Это стандарт передачи данных по проводам (физический уровень). Стандарт не оговаривает протокол передачи данных.

Прочитал всю ветку. Использование МК - не новость в рамках этой тематики. А что еще? Самодельный протокол обмена данными - это несерьезно. Чтобы спроектировать качественный протокол канального, сетевого и транспортного уровней модели OSI - нужно иметь соответствующую квалификацию и специализироваться на таких разработках. Любителям и разработчикам систем "Умный Дом" можно доверить, пожалуй, только сеансовый и прикладной уровни. Иначе весьма велика вероятность возникновения проблем с ростом количества элементов системы. Тоже самое касается реализации задуманного в виде прошивки для МК. Чтобы идея развивалась, нужна команда разработчиков. В одиночку, на коленке я бы не рискнул. Работать то будет, только в каких пределах, на каких нагрузках и задачах.

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

А что касается зависимости, то, в той или иной степени, зависимость всегда присутствует, от Maxim ли она, или от Atmel.

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


2010-10-03 09:28:43 | Stepan
Здорово расписано. Но считаю что 1-wire имеет слишком низкую пропускную способность. Есть открытые радиолюбительские проекты и на более продвинутых шинах rs485, как здесь:
описание /radiokot.ru/forum/download/file.php?id=44179
страница на форуме /radiokot.ru/forum/viewtopic.php?f=25&t=14583&start=140 .
Думаю если донести этот проект до масс то исчезнет боязнь того что фирма закроется вместе с поддержкой.


2010-08-27 10:39:31 | Андрей
Потрясающий сайт, очень понятный и информативный. Казалось бы, простые вещи, а когда все соединены вместе, получается нечто удивительное. Автору огромный респект!