Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

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

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

 

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

 

Как я уже говорил, с моей точки зрения нет необходимости изобретать "велосипед" и делать все "с нуля" самостоятельно. Вряд ли получится лучше, чем у тех, кто занимается этим годами. Поэтому если какая-та задача или хотя бы элемент в реализации Умного Дома уже решена, нужно постараться использовать чужой опыт. Так мы находим, что функция видеонаблюдения уже решена с помощью программы 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
Любое использование материалов сайта возможно только с разрешения автора и с обязательным указанием источника.


ИмяЕ-mail (необязательно, не отображается на сайте)Комментарий

[!] Какое число изображено?


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

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 | Андрей
Потрясающий сайт, очень понятный и информативный. Казалось бы, простые вещи, а когда все соединены вместе, получается нечто удивительное. Автору огромный респект!



Источник: http://www.ab-log.ru/smart-house/info-flow

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление

Своими руками дистанционное управление