Открытый проект MajorDoMo.
Интересные решения, модули, применяемое оборудование, свой голосовой ассистент Алиса...

На Хабре интересная статья: Типичный день под присмотром Алисы

upd

Есть и демо-ролик на youtube, в котором сама система про себя рассказывает

Круто.
Автоматизация вся написанная на PHP.
Чистые как слеза исходники, ни строчки комментариев.

Конечно не все так просто, этот PHP базируетcя на каких-то темных сторонних PHP API и сторонних dll тоже не документированных. Искать скрытые зависимости будет настоящим приключением.
А отлаживать и программировать такую систему будет полной катастрофой.

Вещь на очень большого любителя.

Много лишнего и ненужного. Многое уже и так есть.
Термостат сам знает в какой день недели во сколько что включить или выключить.
Датчики движения? То есть если я лег на диван книжку почитать, система отопление отрубит?
Оверкилл. Излишества. Кнопку открыть гараж как и видеокамеру вывести в интернет можно.
Но восход/заход солнца, какие компьютеры онлайн.. Счастливые люди, не знают чем занятся.
Вагон времени

Интересный проект openHAB с поддержкой "взрослых" протоколов, мобильные приложения на все платформы, дизайнер под все платформы.

Также интересный франкоязычный проект Jeedom, есть свое брендированное оборудование, поддержка множества протоколов и внешнего оборудования, многоязычность (русский не поддержан).

Давно занимаюсь тематикой Умного дома.
Есть много своих наработок. Много делал устройств для сопряжения протоколов.
Кое что выложил в сеть http://www.yakorev.com.ru . Остальное пока не могу раскрыть.
Основная проблема в том, что заказчик сначала пытается осилить постройку дома, затем отделочные работы. А на проектирование системы необходимых устройств и проведение подготовительных работ по прокладке труб для удобного монтажа, для закладки проводов - у него на это нет времени, желания и средств.
Для большинсва главное чтоб вид был. Даже когда с людьми, у которых есть средсва предлагаю:
1 нужно предусмотреть телефонную сеть - а мне "зачем? есть сотовый"
2 нужно делать локальную сеть - У меня все на планшете
3 нужно продумать систему охраны -сигнализаци и интеграции в систему - Придут люди с фирмы и сделают
4 Нужно электрику делать под умный дом и управляемость - вот электрик дешево делает , пусть делает как знает
Коммуникации с учетом расширения нужно делать перед отделкой. Но кто об этом думает. А потом когда в дом надо интернет провести, то витая пара прокладывается в коробах, потому что за плинтус уже не помещается , так как там спутниковое уже все заняло.
И это очень часто.

@smart_pic: Делали ли Вы шлюзы для поддержки протоколов KNX или HDL Bus?

Делали для поддержки протоколов KNX для сопряжения с ДМХ512.
Система состоит из двух частей : сервера и блоков ДМХ512.
Серверную часть делали другие. Я делал исполнительные и командные модули для ДМХ512, которые получали и передавали данные на сервер.
Еще делал конверторы ( да и продолжаю делать ) конверторы ДМХ512-->ТСР, ТСР -->ДМХ512, ИК -->ТСР , ТСР -->ИК, ТСР <-->RS232, ТСР <-->RS485, С настройками через ВЕБ интерфейс

так а вроде сами производители и делают в 232/485/422. Cамому делать накладно - сколько их потом продашь, чтобы ниокр окупить? Выгоднее купить. сугубо имхо.

Шлюз можно сделать программный, если есть хоть какой-то намек на централизованную систему. Тогда на верхнем уровне можно сделать софтовый шлюз. Собственно, меня это и интересовало Хотел найти описание протокола HDL Bus

Производить самим приходится по двум причинам:
1. Поджерживаем свой бренд
2. Интегрировать решения получается выгоднее чем использовать только одно решение.
3. Гибкая интеграция с оборудованием , которое выбирает заказчик, или с оборудованием , которое у него уже есть.

Взять например HDL Bus диммер на 4 канала 2А на канал стоит $550 , это получается около 8000руб за канал, а ДМХ512 диммер даже с лучшими характеристиками и встроенными автоматами защиты выходит по 2000руб за канал.
Вот и получается , что выгоднее интегрировать решения.
Потом у нас трудно покупать все одного производителя и на одной шине . И не все доставаемо и цена высока.

А если самому собрать шкаф управления освещением то имеем 8 каналов по 10-20А на канал , защита , плюс управление по ТСР и ВЕБ интерфейсу при цене 2000-2500руб на канал.
В качестве панели управления планшет (недавно купил за 3500руб 8' ) который есть в каждом доме уже.
Интегрировать все же выгодней.
Перепродавать проще. Но мы имеем 200-300% на производстве и продаже своего оборудования

Поделитесь, пожалуйста, ссылками на описания протоколов KNX и HDL Bus, вроде они открытые, но я не нашел пока в явном виде. Возможно, плохо искал...

кнх, он же eib - проприетарный протокол, может кто и хакнул, но протокол не открыт.

Для работы с KNX можно использовать сервис EIBD -- сайт вот. Штука уже не поддерживается, но сделано добротно и работает отлично.
Немного танцев с бубном и этот сервис запускается на том же Raspberry и в качестве аппаратного гейта может использовать IP-шлюз или USB-шлюз (поддерживаются многие модели). Собственно нужен этот сервис ради своего SDK, которое уже достаточно хорошо описано и приведены примеры для разных языков программирования. Ну т.е. как напрямую (на аппаратном уровне) с шиной KNX работать я не знаю, но вышеописанное мои задачи решает

Отличный вариант выхода из ситуации

Сергей, все-таки меня убивает такая сложная установка системы и последующие настройки, требующие навыков программирования.

Присмотритесь к инсталлятору jeedom. Поищите среди участников сообщества знатоков, сделают не хуже.

Не успокаивайтесь на Windows решении, так как Linux версия позволяет устанавливать систему на встраиваемые платформы, что часто для такой системы благо.

Вот нашел еще одну open source систему - http://domoticz.com

Интересная система, много чего реализовано. Хоть и делают вид, что поддерживают разные платформы, видно, что делали фанаты Rasberry Pi, видна заточка даже интерфейсов под RPi.

Я извиняюсь за кучу ссылок, счас лажу по инету, но вот нашел еще одну - http://www.mysensors.org/ - с open source wireless железом на ардуино. Там же есть куча ссылок на платный и бесплатный софт, с которым это все можно связать. Помимо указанных здесь систем есть еще куча, которые могут запускаться в том числе и на Распберри http://forum.mysensors.org/topic/175/open-...ation-raspberry

Этот ресурс самый популярный у многих опенсоурсных УД, так как является отлиной отправной точкой для начинающих

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

Можно попробовать комбинировать: железо и низкоуровневый софт от опенсоурс, а верхний уровень реализовать на коммерческом ПО. Ведь для себя же строим.

Недавно только обнаружил (к своему стыду) давно и успешно развивающийся проект CyberWRT,основанный на OpenWRT.
На основе недорогого роутера люди делают и УД и роботов автоматизируют. Демо можно посмотреть здесь
Описание прошивки здесь
Завидую белой завистью тому, каких успехов смогло добиться Сообщество, вместе разрабатывая CyberWRT

Я так тоже думаю. Но есть несколько вопросов по преимуществам и гибкости таких систем.

Пока я нашел только пару софтверных систем, не привязанных к определенному железу - это тот же iRidium и IP-Symcon. При этом в первом неизвестно, как реализуются сценарии и все-таки привязка к железу есть из-за особенностей лицензирования.
Остальные - типа Fibaro, HomeMatic - требуют покупки родного железа, по крайней мере контроллера, что обычно есть обыкновенный атомный одноплатник либо еще хуже.

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

Ну и по поводу сценариев - лично меня, как матлабщика, очень бы заинтересовала возможность интегрирования в систему сценариев, просто написанных на Cи или Си++. Тогда я мог бы все сценарии рисовать и отлаживать в симулинке и stateflow, а затем просто автоматически генерить код для контроллера умного дома. По-моему это идеальный вариант разрабатывать и отлаживать все такие системы. Правда дорогой, к сожалению для дома.
Представьте - то же самое обсуждаемое отопление подогреваемым полом по датчику температуры. Классика теории регулирования. Вместо долгого подбора коефициентов, наблюдения часами, обеспечения устойчивости и быстрого отклика, с помощью УД генерим циклы полный ON, полный OFF и по логам снимаем показания температуры в комнате. Загрузили это дело в матлаб - получили законченную модель объекта управления. Далее - пара кликов для линеаризации и оптимизации - и получили все коэфициенты для контроллера - максимально быстрый отклик, без перерегулирования, да еще и промоделированный по циклам день, ночь, лето, зима и т.д.
Но к сожалению, все что я вижу - PHP максимум, а то и Java. Может можно Си переделать в PHP или Javу?

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

Та мне пофиг, что там. Я просто хочу, чтобы исходные файлы, сгенерированные Матлабом, а точнее Simulink Coderом, без изменений компилировались нужной системой УД в свои сценарии. Пусть там хоть фортран будет - все равно я их смотреть не буду.

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

Сегодня пролучил NXP-шный кит для Jennic 5168, так в нем до кучи нафиг ненужный Rasberry Pi B+. Запихнуть что-ли SD c образом, посмотреть в живую?

так это ж надо матлаб спросить, я бы на их месте поддержал



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

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

только вот симулинк ни о вас, ни о вашем доме ничего не знает и знать не будет
а свою систему можно научить понимать тот же симулинк - вставил евойные скрипты в свои квадратики и запустил

Я бы остановился на iRidium, он мне больше всех понравился по реализации, дизайну и поддержке. При построении такой важной системы ведь за что-то нужно платить, буду платить за красоту и тех.поддержку
Останется только привязать свою железку к их HWID, пройдя стандартную процедуру.


Если есть возможность, почему бы действительно не потренировать железку

2 syoma: а вы с физическим интерфейсом уже определились ?

Я зарегистрировался на их Веб-семинар, так как до сих пор не нашел упоминание о каких-либо возможностях разработки сценариев. Только связь кнопка-актуатор.
Ну и ценовая политика у них неправильная. Такие цены отметают домашних энтузиастов напрочь, оставляя интеграторов, которые ищут богатых клиентов. Лично я собираюсь сделать УД уделом не только богатых, позволяя экономить на той же проводке. Т. Е цена автоматизационного софта должна быть тоже адекватной - одна лицензия на всю квартиру, и цена на уровне 2-х 3-х цен за операционку. Также лучше сделать различные версии - с меньшими и большими возможностями.

В соседней теме.

Сначала надо понять, а что мне лично нужно добавить в доме от его нынешнего состояния, и нужно-ли вообще. Если в выходные выкрою время, то попробую описать текущее состояние оборудования дома и попробовать обсудить смысл сливать все в то, что ныне считается "умным" домом.

Можно не всё,а только часть для начала, а дальше, как пойдет

Вот еще одна open-source система: fhem.de/fhem.html
Очень популярная в немецкоязычной среде (на форуме более 13000 пользователей, 32000 тем, 288 тыс. сообщений). Возможно это связано с тем, что ее можно установить прямо на Wifi роутеры Fritzbox - самые популярные домашние роутеры в Германии.
Очень широкая поддержка всяких протоколов, оборудования и USB стиков. Работает на Perl. Вроде есть аpps для Андроида и Айос. По сравнению с openHAB неплохая визуализация.
Но все на немецком, к сожалению.

Вышел мой старый знакомый на пенсию, с очевидным появлением кучи свободного времени. Сам он бывший схемотехник, но вполне уверенно пишет несложные вещи на С для МК. На выходных он попросил помочь ему с переносом имеющегося умного дома (куча скриптов) со старой писишки на Raspberry PI B+. В качестве среды передачи у него везде разведен RS485 с репитерами и Modbus RTU поверх.

В качестве ОС поставлен Raspbian. Для начала решили поставить OpenHab - круто, все есть, но демка "искаропки" работала с ошибками в логах, а гугление указало только на то, что нужно ставить яву 1.7, а не дефолтную 1.8. Поскольку предполагалось допиливание собственных модулей, а знание явы у него на нуле, этот вариант отпал.

Domoticz тоже не подошел, поскольку нет встроенной поддержки Modbus'a.

Следующим попробовали fhem - все заработало сразу (поддержка Modbus появилась после выхода версии 5.6, поэтому ставить надо из svn). Конфигурируется все понятно и легко, плюс, товарищ вполне владеет perl'ом, что снимает проблему написания дополнительных скриптов. На немецком, конечно, информации в разы больше, но гугл эту проблему решает. На английском есть интересный блог, где мужик описывает двухлетние итерации для своей системы отопления с выдержками из конфига: http://www.ply.me.uk/bits_and_pieces/fhem.html . Лично мне понравилась поддержка графиков на базе gnuplot'a, но немного расстроило отсутствие встроенной поддержки rrd базы.

А вы разве не слышали про опенсорсный фреймворк AllJoyn?
Это гораздо круче MQTT будет.

Вы уверены, что хотели об этом сказать именно отвечающему на конкретный вопрос о конкретной платформе syoma?

Лет 10-15 назад точно так же растопыривал пальцы BACnet. И кто его сейчас вспомнит? А MQTT никаких авансов не раздает, в барабан не лупит и флагами не размахивает, а просто работает.

Ну сравнили, какой-то низкоуровневый протокол родственник MODBUS и целый готовый софтварный фреймворк.
Это все равно что сравнивать электрорубанок и мебельный завод.

Против MQTT ничего не имею, сам его сейчас портирую, но он только плагин к AllJoyn.
Закончу с MQTT и возьмусь за AllJoyn.

Судя по этой реплике, вы совсем не понимаете, что такое БАКнет. В истоках его лежит точно такая же инициатива, как у AllJoyn: объединить в одно целое разнородные устройства разных производителей. Только проявлена эта инициатива была на 25 лет раньше и, соответственно, названа так, как было модно называть что-то новое в то время - "протокол". Сейчас слово "протокол" вышло из моды, поэтому AllJoyn использует то слово, которое модно в настоящий момент, "фреймворк". А по сути это ничем от БАКнета не отличается, БАКнет тоже можно "фреймворком" назвать, если хочется. И перспективы у AllJoyn точно такие же, как у БАКнета, если не хуже.

Прям BACnet надо понимать.
Это довольно примитивный протокол клиент-сервер. Похож на MODBUS. Добавили там более сложную организацию примитивов.
Теперь у каждого бита есть тип, имя, счетчик, валидность, инициализатор, и кастомизируемые свойства.
Вообщем ненужная и бестолковая детализация.
Для M2M протокола слишком заумо, для IoT слишком примитивно.

Скомпилировал я его сегодня, порефакторил, но пользы не увидел. Видимо пойдет фтопку.

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

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

Ну и конечно AllJoin это несколько уровней выше чем BACnet.
Кстати с ходу так и не нашел нормального описания BACNet с графической нотацией описания пакетов или чего нибудь там.

Довольно смешно это читать, зная что AllJoyn тоже использует модель клиент-сервер. БАКнет - он старенький, громоздкий и кривой. Зато он уже есть и кое-где применяется, a его опенсорс с либеральной лицензией для разных платформ на Соурсфордже лежит. А AllJoyn будет ли жить или нет - бабушка надвое сказала, особенно учитывая наличие прямого конкурента в виде OIC/IoTivity. Наслушавшись прогнозов, все дружно бросились столбить участки в полях IoT, надеясь на золотые россыпи. Надувают очередной пузырь, а получится как всегда.

Где вы такое знание получили?

Смотрите исходники. В AllJoyn в тонком клиенте для embedded (клиенте фреймворка, а не сетевом, если понимаете разницу ) применяется peer-to-peer обмен.

А BACNet, как я уже писал, порван на несовместимые реализации. На sourceforge лежит кастрированная неполная реализация. Опять же смотрите исходники.

А если смотреть исходники OIC/IoTivity , то он в зачаточном состоянии для embedded , есть только порт для Arduino ATMega 2560 with Ethernet Shield. Там сам Ethernet Shield это отдельная смешная история.

Сравните сколько есть портов и под что у AllJoyn , и больше сравнивать его с IoTivity не захочется.