Комментарии 41
С ходу не понял, как происходит взаимодествие с железом?
Вероятно, при помощи тех же плагинов…
Статья просто о другом, другой уровень — интерфейс системы, а реализация взаимодействия с железом у каждого может быть своя.
Статья просто о другом, другой уровень — интерфейс системы, а реализация взаимодействия с железом у каждого может быть своя.
Работа с железом может происходить любыми способами, доступными для компьютера (USB, Ethernet, COM-порт....) Весь функционал системы находится в плагинах. Для добавления нового железа нужно подключить плагин, который реализует взаимодействие с ним. Сейчас есть плагин для управления светом через USB-адаптер nooLite + в ближайших планах есть написание плагина для общения по протоколу MQTT.
Про железо сюда не писал, т.к. хотел рассказать именно про пользовательский интерфейс.
Про железо сюда не писал, т.к. хотел рассказать именно про пользовательский интерфейс.
Правильно ли я понял, что при этом вся система завязана на какой-то центральный компьютер? Всё-таки интересно узнать именно про железо. Какие требования к этому компьютеру?
Вижу, что проект завязан на .NET, а следовательно и Windows. Как-то накладно для умного дома держать постоянно работающий компьютер с Windows, тем более страшно представить, на сколько падает надёжность системы, если всё завязано на него. Или я всё-таки что-то не так понял?
Вижу, что проект завязан на .NET, а следовательно и Windows. Как-то накладно для умного дома держать постоянно работающий компьютер с Windows, тем более страшно представить, на сколько падает надёжность системы, если всё завязано на него. Или я всё-таки что-то не так понял?
По поводу архитектуры домашней системы и роли в ней компьютера:
Насколько я себе представляю, система должна состоять из нужного количества исполнительных устройств, каждое из которых реализует некоторую простую логику по управлению домом, и может работать в нескольких режимах. Также я представляю, что есть управляющее устройство, которое на основе информации от домашних устройств и из внешних сервисов, управляет режимами работы исполнительных устройств + получает с них информацию и предоставляет UI для нее.
Например, в доме может быть видеонаблюдение (это — «исполнительное устройство», на самом деле, может состоять из нескольких физических устройств). В пассивном режиме просто ведется лог, а в режиме отсутствия хозяев при обнаружении движения дополнительно отправляет оповещения. Соответственно, управляющее устройство может, на основе информации с датчиков движения, автоматически переключить систему видеонаблюдения в нужный режим + оно может предоставить пользовательский интерфейс для просмотра текущего изображения с камер.
Я встречал много вариантов реализации управляющих устройств, от устройств на основе ардуино/raspbery pi и различных роутеров с linux до облачных платформ типа Ninja Blocks. На мой взгляд, компьютер (неттоп) — оптимальный вариант. Он находится в вашей локальной сети (в отличие от облачных платформ, у вас не исчезнет возможность включения света, если пропадет интернет). При этом у него больше ресурсов, чем у arduino/raspbery pi/роутеров. Туда можно поставить дополнительное ПО, нужное для системы (например, сервер видеонаблюдения) или организовать на жестком диске медиа-архив. По стоимости — можно купить хороший неттоп в пределах 10 тыс.р. — если человек потратил 15-20 тыс.р. на управляемые выключатели и датчики, то, думаю, он вполне может позволиоть купить себе неттоп для управляющего устройства. Это на несколько тыс.р. дороже аналогов, но сильно экономит время и нервы.
Насколько я себе представляю, система должна состоять из нужного количества исполнительных устройств, каждое из которых реализует некоторую простую логику по управлению домом, и может работать в нескольких режимах. Также я представляю, что есть управляющее устройство, которое на основе информации от домашних устройств и из внешних сервисов, управляет режимами работы исполнительных устройств + получает с них информацию и предоставляет UI для нее.
Например, в доме может быть видеонаблюдение (это — «исполнительное устройство», на самом деле, может состоять из нескольких физических устройств). В пассивном режиме просто ведется лог, а в режиме отсутствия хозяев при обнаружении движения дополнительно отправляет оповещения. Соответственно, управляющее устройство может, на основе информации с датчиков движения, автоматически переключить систему видеонаблюдения в нужный режим + оно может предоставить пользовательский интерфейс для просмотра текущего изображения с камер.
Я встречал много вариантов реализации управляющих устройств, от устройств на основе ардуино/raspbery pi и различных роутеров с linux до облачных платформ типа Ninja Blocks. На мой взгляд, компьютер (неттоп) — оптимальный вариант. Он находится в вашей локальной сети (в отличие от облачных платформ, у вас не исчезнет возможность включения света, если пропадет интернет). При этом у него больше ресурсов, чем у arduino/raspbery pi/роутеров. Туда можно поставить дополнительное ПО, нужное для системы (например, сервер видеонаблюдения) или организовать на жестком диске медиа-архив. По стоимости — можно купить хороший неттоп в пределах 10 тыс.р. — если человек потратил 15-20 тыс.р. на управляемые выключатели и датчики, то, думаю, он вполне может позволиоть купить себе неттоп для управляющего устройства. Это на несколько тыс.р. дороже аналогов, но сильно экономит время и нервы.
Я всё-таки придерживаюсь архитектуры, когда все устройства полностью независимы друг от друга, а скрипты определяющие реакцию на различные события прописываются прямо в них.
Почему?
При такой организации при большом количестве скриптов начинается бардак + возможно, начинаются проблемы производительности (из-за того, что все очень универсально и низкий уровень оптимизации).
При такой организации при большом количестве скриптов начинается бардак + возможно, начинаются проблемы производительности (из-за того, что все очень универсально и низкий уровень оптимизации).
Да просто надёжнее, ничего не завязано на какой-то один узел. Практика показывает, что никакого бардака нет. Все исходники хранятся централизованно, а при необходимости уже компилируются и удалённо закачиваются на устройство. Про проблемы производительности вообще странно слышать — всё же начинает дружить друг с другом напрямую, а следовательно и реагировать моментально.
Если что, я ничего не навязываю, просто высказываю свою точку зрения :) У меня у самого раньше всё контролировалось центральным компьютером на Windows. Разницу для себя я осознал.
Если что, я ничего не навязываю, просто высказываю свою точку зрения :) У меня у самого раньше всё контролировалось центральным компьютером на Windows. Разницу для себя я осознал.
Спасибо, про централизованное хранение исходников и загрузку обновлений на устрйоства — интересно.
На счет проблем производительности — имел в виду случаи, когда, например, нужна совместная работа устройств, использующих разные протоколы — появляются различные костыли, которые при большом их количестве ухудшают производиотельность и усложняют систему в целом. Если все «умные» устройства используют общий протокол или есть возможность модифицировать их, все становится значительно легче.
Буду продолжать автоматизацию и следить за своими ощущениями. Возможно, действительно потом откажусь от центрального сервера.
На счет проблем производительности — имел в виду случаи, когда, например, нужна совместная работа устройств, использующих разные протоколы — появляются различные костыли, которые при большом их количестве ухудшают производиотельность и усложняют систему в целом. Если все «умные» устройства используют общий протокол или есть возможность модифицировать их, все становится значительно легче.
Буду продолжать автоматизацию и следить за своими ощущениями. Возможно, действительно потом откажусь от центрального сервера.
Крайности. Крайности всегда плохи. Прописывая всю логику в конечные устройства вы теряете гибкость. только представьте что вам предстоит для того чтобы изменить логику работы для десятка другого конечных устройств…
Устройства должны быть автономны но только в малой степени — выключатель к примеру иметь ручное управление и т.д. Логикой взаимодействия преимущественно должно заниматься центральное устройство! Так как оно может быть гибче и иметь гораздо больше ресурсов. Выход из строя центрального блока при этом не приводит к параличу всей системы — ей по прежнему можно управлять вручную, теряется только удобство управления.
Конечно при этом необходимо предусмотреть процедуры аварийного состояния — например если центральный блок не дает команды в течении десяти минут и не было ручных команд то переходить в безопасное состояние — свет отключить, нагреватель отключить, водопровод перекрыть и т.д.
Устройства должны быть автономны но только в малой степени — выключатель к примеру иметь ручное управление и т.д. Логикой взаимодействия преимущественно должно заниматься центральное устройство! Так как оно может быть гибче и иметь гораздо больше ресурсов. Выход из строя центрального блока при этом не приводит к параличу всей системы — ей по прежнему можно управлять вручную, теряется только удобство управления.
Конечно при этом необходимо предусмотреть процедуры аварийного состояния — например если центральный блок не дает команды в течении десяти минут и не было ручных команд то переходить в безопасное состояние — свет отключить, нагреватель отключить, водопровод перекрыть и т.д.
По поводу Windows — есть распространенный стереотип, что это ненадежная, ресурсоемкая ОС. Действительно, в 90-х годах так и было, но с тех пор уже прошло 15 (!) лет — не думаю, что есть повод волноваться.
Например, я несколько лет работаю с сервером на Windows Server 2008R2, он включен постоянно и перезагружался за пару лет 2-3 раза (нужно было при установке ПО). Также у меня ноутбук на Windows 8.1, который я не выключаю по пол года — никаких проблем с ресурсами замечено не было. Кроме того, вы же понимаете, что на управляющем устройстве умного дома у вас не будет браузера с сотней открытых вкладок, flash-плеера и других приложений, из-за которых появляются проблемы с производительностью.
И последняя причина… Согласитесь, написать программу, которая жрет память можно на любом языке программирования и в любой ОС. Платформа .NET имеет отличные средства разработки и огромное количество библиолтек готовых компонентов (в т.ч .open source). Visual Studio — лучшая IDE, из всего, что я видел. Я получаю удовольствие во время разработки. На мой взгляд, эта причина — удобство разработки — не менее важна, чем остальные.
Например, я несколько лет работаю с сервером на Windows Server 2008R2, он включен постоянно и перезагружался за пару лет 2-3 раза (нужно было при установке ПО). Также у меня ноутбук на Windows 8.1, который я не выключаю по пол года — никаких проблем с ресурсами замечено не было. Кроме того, вы же понимаете, что на управляющем устройстве умного дома у вас не будет браузера с сотней открытых вкладок, flash-плеера и других приложений, из-за которых появляются проблемы с производительностью.
И последняя причина… Согласитесь, написать программу, которая жрет память можно на любом языке программирования и в любой ОС. Платформа .NET имеет отличные средства разработки и огромное количество библиолтек готовых компонентов (в т.ч .open source). Visual Studio — лучшая IDE, из всего, что я видел. Я получаю удовольствие во время разработки. На мой взгляд, эта причина — удобство разработки — не менее важна, чем остальные.
Позвольте, .NET приложения отлично работают на Mono. Уже даже стартапы начали хостить в linux + mono-fastcgi + nginx. Естественно в качестве БД — PostgreSQL.
Если только само приложение не использует платформо-зависимые штучки то всё работает прекрасно и без windows.
Если только само приложение не использует платформо-зависимые штучки то всё работает прекрасно и без windows.
Без Windows, но не без сервера :)
Бред это. Я работаю в .net компании, и как мы не печалимся о том что мы .net — перейти на mono никак не можем, a все потому что compatibility. Я не спорю, список выглядит намного лучше чем год назад, но скажите, какой смысл идти по пути «совместимости» если Вам нужно зарабатывать деньги, или у Вас есть время на отлов багов Mono? Сейчас, когда мир Unix развивается гораздо быстрее чем мир Windows, ИМХО вообще нет смысла касаться технологий от MS — всегда будете отставать в «развитии». И это только потому, что основа всего — проприетарная, в отличие от Java, где каждый компонент открыт (не считая закрытых реализаций Oracle).
По поводу статьи — спасибо, приятно почитать, но интересна причина выбора именно .net? Почему тот же python, node или даже Java? К примеру Вы смогли бы хостить Ваше чудо на raspberry pi или dd/openwrt.
По поводу статьи — спасибо, приятно почитать, но интересна причина выбора именно .net? Почему тот же python, node или даже Java? К примеру Вы смогли бы хостить Ваше чудо на raspberry pi или dd/openwrt.
Я тоже работал в .net компании, и у нас было слишком много зависимостей от проприетарных компонентов, поэтому никакого Mono с таким legacy нам не светило. С самого начала писать совместимо вполне можно, но это надо делать прямо с самого начала, потому что так дешевле и быстрее.
По поводу совместимости — действительно нужны async фичи MVC4? Можете привести пример, зачем вам это могло понадобиться в web-приложении?
PHP-шники живут без этих кунштюков и запиливают крутые проекты.
Если без холиваров то я просто привел пример, что некоторые стартапы успешно используют связку unix и CLR и у них всё получается.
По поводу совместимости — действительно нужны async фичи MVC4? Можете привести пример, зачем вам это могло понадобиться в web-приложении?
PHP-шники живут без этих кунштюков и запиливают крутые проекты.
Если без холиваров то я просто привел пример, что некоторые стартапы успешно используют связку unix и CLR и у них всё получается.
Так никаких холиваров, я знаю что многие (точнее некоторые) стартапы используют эту связку, и да, Visual Studio — действительно одна из лучших IDE. У нас более миллиона уникальных посетителей в день, async фичи MVC4 используются для работу SOA Api, в частности. Все дело в масштабе, и когда он большой — очень легко принять страх перед багами mono за какую-то реальную проблему, поэтому никто не рискует. Да и как мы все уже поняли, что то что было когда-то стартапом в идеале должно быть переписано раз 5 до близкого к «более чем хорошему» коду, а это значит что придется изобретать велосипед почти каждый раз (создавать что-то лучшее чем было до этого). Короче говоря говнокод который делал деньги будет выкинут, а новый продукт/ проект будет переписан на Scala/Akka и, надеюсь будет делать еще больше денег в неблокирующем режиме :)
У нас смешанная архитектура, и я печалюсь когда смотрю в сторону контейнеров LXC и Docker, а также тонну модулей puppet/chef/ansible которые написаны только под Linux и скрипя сердцем продолжаю знакомить Windows с миром opensource (что-то вроде этого и этого). Для DevOps как я — Windows это не выбор, это данное «свыше». Но в тех проектах где есть выбор я не посмотрю в сторону Windows, потому что экосистема совсем не та…
У нас смешанная архитектура, и я печалюсь когда смотрю в сторону контейнеров LXC и Docker, а также тонну модулей puppet/chef/ansible которые написаны только под Linux и скрипя сердцем продолжаю знакомить Windows с миром opensource (что-то вроде этого и этого). Для DevOps как я — Windows это не выбор, это данное «свыше». Но в тех проектах где есть выбор я не посмотрю в сторону Windows, потому что экосистема совсем не та…
Мы выбрали .NET для нашего проекта потому, что нет опыта программирования под другие платформы (если честно, вопрос выбора даже не стоял: просто убедились, что на .NET возможно решить задачу). Мы решили, что качественный проект на .NET лучше, чем кривой велосипед на других платформах.
Кроме того, как оказалось, .NET имеет еще несколько преимуществ над другими платформами (например, для .NET имеется отличный движок синтеза и распознавания голоса). В целом, по количеству достоинств и недостатков .NET примерно на одном уровне с другими платформами.
Кроме того, как оказалось, .NET имеет еще несколько преимуществ над другими платформами (например, для .NET имеется отличный движок синтеза и распознавания голоса). В целом, по количеству достоинств и недостатков .NET примерно на одном уровне с другими платформами.
НЛО прилетело и опубликовало эту надпись здесь
Эх как жаль что все на .net завязано, а так идея интересная.
Не расстраивайтесь, не все так плохо, посмотрите, комментарии чуть выше. .NET — просто одна из особенностей системы со своими «плюсами» и «минусами», причем «плюсов» не так уж и мало.
А на OpenRemote смотрели? А почему?
Смотрели. Там нет поддержки из коробки нужного железа (т.е. все равно это реализовывать самостоятельно). На счет использования в качестве платформы — имхо, не очень гибкая платформа, перегруженная возможностями. Кроме того, написано на Java, хотелось бы .NET (из-за его средств разработки) — но это не критичный недостаток, если бы первых двух не было, то смирились бы с ним.
У каждого свои задачи (свое «железо», свои привычки, которые он хочет автоматизировать). Использовать универсальную систему с богатым функционалом будет неудобно, т.к. реально из всего функционала используестя 5-10%, а оставшиеся 90% накладывают ограничения и тратят время/нервы. Начали писать свою систему потому, что хотели простой «конструктор», из которого каждый может собрать то, что ему нужно (а если какой-то детали не хватает — самостоятельно ее сделать).
У каждого свои задачи (свое «железо», свои привычки, которые он хочет автоматизировать). Использовать универсальную систему с богатым функционалом будет неудобно, т.к. реально из всего функционала используестя 5-10%, а оставшиеся 90% накладывают ограничения и тратят время/нервы. Начали писать свою систему потому, что хотели простой «конструктор», из которого каждый может собрать то, что ему нужно (а если какой-то детали не хватает — самостоятельно ее сделать).
del
Вот же блин, только я обрадовался, что не нужно городить свой велосипед (который я ни шатко ни валко понемногу рожаю на питоне), как дочитал до ".net" :( А у меня в доме, не поверите, ни одной Windows-машины.
Видимо, придется и дальше пилить.
Видимо, придется и дальше пилить.
Может есть ссылочка на гитхаб? Я бы присоединился )
Пока стыдно. Но «я вас запомнил» :)
А меняяя? Меня можете запомнить?
Сейчас пилю проект под Linux на Mono-3.6.
Monodevelop 5 уже вполне вменяемая IDE, которая избавилась от половины или двух третей своих косяков. Ставьте из ppa и наслаждайтесь жизнью
ASP.Net Owin в связке с Nancy вполне работает и в винде и в линухе. С SignalR говорят бывают проблемы в Mono, так что обойдусь SuperWebSocket
Monodevelop 5 уже вполне вменяемая IDE, которая избавилась от половины или двух третей своих косяков. Ставьте из ppa и наслаждайтесь жизнью
ASP.Net Owin в связке с Nancy вполне работает и в винде и в линухе. С SignalR говорят бывают проблемы в Mono, так что обойдусь SuperWebSocket
Очень интересно!
Можете рассказать подробнее, в каком все состоянии (и, если есть возможность, дать посмотреть исходники)?
Можете рассказать подробнее, в каком все состоянии (и, если есть возможность, дать посмотреть исходники)?
Пока оно в весьма промежуточном состоянии. По сути приложение ASP.NET в режиме Self Host на HttpListener, для базы данных использую SQLite через ServiceStack.OrmLite.
С исходниками сомневаюсь — вроде как проект коммерческий, так что я несколько связан по рукам договором. Может быть попробую сделать «похожий продукт» для Open Source.
С исходниками сомневаюсь — вроде как проект коммерческий, так что я несколько связан по рукам договором. Может быть попробую сделать «похожий продукт» для Open Source.
Вот скажите, не для холивару ради, а просто интересно, что для Вас Mono? Почему не Java?
Потому что на Java я писал суммарно пару дней, а на C# пишу лет пять. Так что писать на привычной платформе быстрее и удобнее.
Ну и какая-то сферическая кроссплатформенность все равно сохраняется и если не брать платформозависимые вещи(вроде работы с mpg123, который в винде ну никак работать не хочет через консоль управления) — то проект просто запускается и на винде и на пингвине. Хотя чем дальше буду писать, тем больше линуксозависимых особенностей появится, вроде работы с window manager.
А, и еще я терпеть не могу Eclipse
Ну и какая-то сферическая кроссплатформенность все равно сохраняется и если не брать платформозависимые вещи(вроде работы с mpg123, который в винде ну никак работать не хочет через консоль управления) — то проект просто запускается и на винде и на пингвине. Хотя чем дальше буду писать, тем больше линуксозависимых особенностей появится, вроде работы с window manager.
А, и еще я терпеть не могу Eclipse
:) Последняя строка впечатлила, и я, пожалуй, соглашусь. Именно поэтому я люблю IntelliJ Idea и PyCharm :)
>Потому что на Java я писал суммарно пару дней, а на C# пишу лет пять. Так что писать на привычной платформе быстрее и удобнее.
Если бы я так рассуждал, то свой аналог сабжа мне пришлось бы писать не на Python, а на C++ :)
Если бы я так рассуждал, то свой аналог сабжа мне пришлось бы писать не на Python, а на C++ :)
В качестве пользовательских сценариев. Возможно, вам будет интересно. Будильники я у себя предустановил на 6, 7, 8, 9, 10 часов и запускаю их одним кликом. Мне кажется, вам необходимо собрать подобный набор повседневных сценариев и оптимизировать их, поскольку экономия на микрособытиях, всегда очень продуктивна.
Во-первых, да, я поддержу автора, однозначно стоит иметь единый «центр управления», сервер. Это охрененно удобно, потому что иметь сто устройств, когда каждое само по себе, значит создавать себе лишние проблемы. Это убеждение подкреплено некоторым опытом обслуживания объектов промышленности и проведения на них ПНР. Да, когда есть единое управляющее устройство, при его отключении мы теряем все блага автоматизации, но и зорко следить нужно за чем-то одним. Поиск неисправностей (которые обязательно будут) выглядит вполне линейно — от проверки нижнего устройства, через проверку связи с ним, ввод/вывод сигналов до логической их обработки. Если у нас будет всё само по себе, то и искать косяк нужно везде, что очень усложнит задачу. Конечно, это не отменяет управления устройствами напрямую на случай выхоа из строя сервер. Те же выключатели на освещение должны быть, вода должна в дополнение перекрываться и обычными кранами и т.п.
Во-вторых, по поводу веб-интерфейса :) Дизайнер из меня уровня «любитель», но как субъективное мнение примете? Бутстрап это хорошо, уже лучше 99% самодельных GUI) Но пока выглядит как «сделано программистами для программистов», а не разработчиками для пользователей. Для ориентировки можно пошариться на dribbble.com (не всё с исходниками) или на 365psd.com (всё с исходниками). На дрибббле очень любят делать как раз такие плиточные шаблоны.
Во-вторых, по поводу веб-интерфейса :) Дизайнер из меня уровня «любитель», но как субъективное мнение примете? Бутстрап это хорошо, уже лучше 99% самодельных GUI) Но пока выглядит как «сделано программистами для программистов», а не разработчиками для пользователей. Для ориентировки можно пошариться на dribbble.com (не всё с исходниками) или на 365psd.com (всё с исходниками). На дрибббле очень любят делать как раз такие плиточные шаблоны.
Спасибо за обратную связь! Мы в курсе, на счет неидеального дизайна )
Внешний вид важен для хорошего восприятия пользователями, но сейчас дизайн — далеко не самая важная задача. Намного важнее качественно реализовать запланированный функционал и при этом сохранять систему простой. Мы выбрали bootstrap не потому, что там крутой дизайн, а потому, что это самый легкий способ быстро сделать приемлемый интерфейс (т.е. чтобы не писать самостоятельно стили для элементов интерфейса). Дизайн системы — отдельная большая задача, мы обязательно до нее доберемся в будущем.
Внешний вид важен для хорошего восприятия пользователями, но сейчас дизайн — далеко не самая важная задача. Намного важнее качественно реализовать запланированный функционал и при этом сохранять систему простой. Мы выбрали bootstrap не потому, что там крутой дизайн, а потому, что это самый легкий способ быстро сделать приемлемый интерфейс (т.е. чтобы не писать самостоятельно стили для элементов интерфейса). Дизайн системы — отдельная большая задача, мы обязательно до нее доберемся в будущем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой web-интерфейс управления умной квартирой