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

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

Технические детали

База Данных

Муки творчества, связанные с выбором СУБД были поистине титаническими. Изначальный выбор технологии был достаточно широк - mySQL, Postgresql и FireBird.

Технически, все эти системы удовлетворяют поставленным условиям, но выбирать все же пришлось. "Мускул" отпал практически сразу - теперь это коммерческий проект, нелюбимой мной, фирмы Oracle. Таки да! Они оставили покоцанный вариант этой СУБД для свободного использования, но в нем нет поддержки бизнес-логики на стороне Базы Данных. Да и кто знает - когда именно "за свой нелегкий труд" по вложению денег в эту систему сия корпорация призовет к ответу конечных разработчиков?

Вот выбор между двумя оставшимися системами был не столь очевиден. С одной стороны, у слоника великолепная поддержка на уровне драйверов и интенсивное развитие, с другой - птичка, являющаяся продолжением, некогда весьма серьезной системы, interbase и имеющая встроенный механизм оповещения клиентов о событиях, что очень приятно при работе в трехзвенке. Думы думались далеко не одну неделю. Победило смешное - юношеский опыт работы с прародителем жареной птички. Впрочем, сожалений нет и не предвидится - несмотря на скудный набор встроенных функций, его вполне достаточно для решения поставленных задач, да и написание собственных расширений языка, в отличии от того же MS SQL, не представляет сложностей - это банальные подгружаемые библиотеки, для своего написания даже не требующие какого-либо SDK.

Пользовательский интерфейс

Эксплуатация предыдущего проекта показала, что основное взаимодействие между пользователем и системой происходит в очень узком месте - просмотр информации по датчикам и выполнение действий по управлению аппаратурой. Все остальные операции, как то: управление топологией системы и ее объектами, изменение глобальных настроек доступа (календари, зоны, права и прочее) и даже раздача ключей доступа (тех же карточек); не требуют беготни между компами, осуществляются редко и на одном-двух рабочих местах. Посему было принято решение отказаться от сомнительного удобства использования единого web интерфейса для управления всей системой. Но кроссплатформенность управляющей программы сохранить хотелось бы (чисто из принципа!).

Давно пишу. Много видел. Еще больше - слышал. Слышал сказание о возникновении языков кроссплатформенной разработки. И вам скажу - для обеспечения переносимости программ между компами, имеющими разную архитектуру, были придуманы высокоуровневые языки программирования (fortran, basic, pascal...). Дальнейшим и, на мой взгляд, тупиковым развитием этой концепции явилось создание "виртуальных машин", обслуживающих промежуточный код, высранный компилятором какой-нибудь Жабы (java) или (ну совсем смешно!) точечного минета (.net). Это в мире, где количество архитектур сократилось до пары-тройки!

Ну да БГ им судья. Наш удел - кодить для железа. Как ни странно, гимора с "универсальным" "С--" в такой ситуации будет больше всего. Но мне пофиг! Пока есть FPC и его визуальная среда разработки Lazarus, наша не пропадет нигде - эта парочка компилирует под любую ОС и для любого процессора.

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

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

Хочется также иметь управляющие консоли на Android, но тут я все еще надеюсь на дите - оно ОБЕЩАЛОСЬ написать сию невероятно сложную программу.

Архитектура

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

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

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

Железо

Основная задача системы - управление умным домом. Концепция проекта - сервер получает данные и принимает решения, клиенты - много мелких и дешевых микрокомпьютеров, умеющих измерять и переключать, но никак не думать. Строго говоря, "микрокомпьютер" - слишком гордое название для данных девайсов исходя из современных технологий и понятий. Лет 30 назад - таки да! То был бы КОМПЬЮТЕР. А сейчас - это мелкий таракан, со скоростью каких-нибудь 10-20 мегафлоп, выполняющий команды в своей куцей памяти (килобайт 8, а может и менее). О времена! О нравы!

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

Что до "удобства настройки", тут тоже все весьма относительно. Есть системы, расчитаные на "настройку конечным пользователем". Господа, это полный бред! С удовольствием подключать новую лампочку и настраивать ее реакции будет только гик! А он априори способен разобраться в настройке сети устройств, обладающих свойствами и умеющих выполнять действия по событиям. И в чем разница? Пожалуй только в том, что система на базе устройств "для чайников" имеет меньшую функциональность и глубину настроек. Посему, "нафиг! нафиг!". Если кухарка захочет умного дома, ей его построит и настроит инженер, а она, в свою очередь, сготовит ему пожрать. Чисто чтобы каждый занимался своим делом.

Что до "а если что-то случится, я в сортир сходить не смогу!?", тут есть ровно два момента:

1. случись что с канализацией, вы сами не лезете ее ремонтировать, а вызываете СПЕЦИАЛИСТА
2. ЭТА система проста, как кирпич (в ней тупо нечему зависать), и за два года эксплуатации простаивала только один раз - когда я старую версию менял на новую.
   

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

Минимально, проект способен работать даже на Raspberry Pi, в качестве сервера системы. Хоть это и не очень хорошо для обработки потоков с камер видео наблюдения (около половины секунды на полную обработку кадра Full HD).

Функциональные возможности

Система ориентирована на принятие решений на основе данных полученных от "сенсоров". Таковыми могут являться любые источники аналоговой и цифровой информации. В частности: датчики температуры, влажности, давления, скорости и направления ветра, напряжения, тока в проводах, банальные контакты и многое другое. Для вывода информации, система располагает как простыми релейными, так и цифровыми выходами.

В результате выполнения определенных условий, прописанных для данного датчика, программа дает команды на устройства, описанные, как исполнители. Например, если в вечернее время (календари определяются при настройке системы), датчик влажности почвы у цветка в "кибернетическом горшке" покажет менее 80%, нужно на 15 секунд включить мотор полива этого горшка и пробубнить на кухне (человеческим голосом), что нехорошо не ухаживать за растениями.

Также, можно собирать информацию с нескольких датчиков и применять решения на ее основе.

Чтобы отражать в БД такой важный параметр, как пожелания пользователя, существует концепция "Регистр". Он, как и датчик, может принимать разные значения и, при изменении или проверке, вызывать цепочки событий, как и сенсоры. События сенсоров и регистров могут связываться в единые цепочки.

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

Со стороны конечного пользователя все это выглядит примерно так:

• Температура в помещении регулируется автоматически в зависимости от времени суток.
• Освещение живет своей жизнью - когда и где надо включается на требуемое время.
• Цветы поливаются сами по себе, лишь только водяной бак эпизодически шлет на почту сообщения, что пора бы и пополнить его ненасытное брюхо.
• Вся эта канитель управляется с ИК пультов; компов; телефонов; выключателей; настенных панелей, сделанных из недорогих PDA.
• Находясь в другом городе, пользователь видит, что к нему в гости приперся очередной "а не заплатите ли вы наличными за свет?", со своим талмудом, и может запечатлеть это жалкое зрелище в виде фотографии события, не только на своем компе, но и в системе, где эта фотка станет частью отчетов.
• Есть желание знать - какая погода на даче? Достаточно открыть страничку на сайте и посмотреть сколько там "наградусило", а то и просто в камеру глянуть.
• Погода офигенная и есть желание померзнуть за городом - дачный дом получает команду выйти из режима консервации и прогреться к приезду хозяев...
  

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

Со стороны настройщика, тоже не все печально. Устройства, подключенные к общей сети, автоматически определяются в системе (опция автонастройки должна быть разрешена для данной линии), их типовые датчики и выходы сами появляются в описании прибора и остается только прописать - что делать, если, например, летом влажность воздуха поднимется выше 85%. Да! Придется переложить сухие цифры состояний на алгоритм действий! Но если человек способен соединить десяток устройств, его ума вполне хватит на сей великий подвиг.

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