Комментарии 14
А как работает nooLiteCMD.exe? Какие протоколы связи с оборудованием? Какое оборудование поддерживает? Какой функционал у этой программы?
мне одному хостинг вспомнился?
То есть я должен сидеть и выискивать среди хостинговых предложений внезапно вот это smartliving.ru/
Я зашёл почитать посмотреть понять что это. Три раза прочитал пока не решил в профиль перейти.
Я зашёл почитать посмотреть понять что это. Три раза прочитал пока не решил в профиль перейти.
Если нужно только ручное управление светом через браузер, то проще сделать вот так (там тоже noolite).
Ни слова о архитектуре. Контролер домашнеей автоматизации, єто не ООП изучить, а связать воедино устройстав в доме, получать, обрабатывать, анализироавть и реагировать на события в системе. UI же возникает как следствие.
Архитектуре самого проекта? Об этом написано на сайте самого проекта в разделе «Азбука», здесь же я хотел показать, как применяется ООП для интеграции устройств. События, реакции, UI и прочее так же есть, но, как вы правильно заметили, они следствие и статья как раз не про UI, а про возможности внутренней организации собственных объектов на этой системе.
Спасибо посмотрел. К сожалению главной задачи домашней автоматизации вы не решаете. Вы взялись то что ближе вам UI.
С тех задач что я зараз рассматриваю:
— Device discovery
— Multiprotocol processing
— Extending network
— Network topology
Не решается никакая. Возможно для вашей топологии это и подходит, но мне нет.
Вот сравните ваше решение например с github.com/stianeikeland/homeautomation
Уже четко видно что event-based архитектура, я могу предвидеть точки расширения.
В самом примитивном виде home automation контролер должен существовать вообще без UI.
По прерыванию от внешнего события будится демон, который принимает или отправляет сообщение, кладет его в service bus и все его работа на этом окончена. Другие модули в том числе и UI просто подписчики на события шины. ZeroMQ/Crosroads + возможно redis как слой сохранения данных как будто для таких систем созданы. В результате части системы не завязаны один на другой и могут быть взаимозаменяемыми и опциональными. По сути из обязательных, слушающий демон, service bus, и накопитель данных, дальше добавляем обработчик который будет тригерится по определенным событиям.
Для работы с топологией уже есть некоторые задумки, но пока еще не оформились в окончательное решение. Пока едет BBB гуглю альтернативы, чтобы не изобретать велосипед.
С тех задач что я зараз рассматриваю:
— Device discovery
— Multiprotocol processing
— Extending network
— Network topology
Не решается никакая. Возможно для вашей топологии это и подходит, но мне нет.
Вот сравните ваше решение например с github.com/stianeikeland/homeautomation
Уже четко видно что event-based архитектура, я могу предвидеть точки расширения.
В самом примитивном виде home automation контролер должен существовать вообще без UI.
По прерыванию от внешнего события будится демон, который принимает или отправляет сообщение, кладет его в service bus и все его работа на этом окончена. Другие модули в том числе и UI просто подписчики на события шины. ZeroMQ/Crosroads + возможно redis как слой сохранения данных как будто для таких систем созданы. В результате части системы не завязаны один на другой и могут быть взаимозаменяемыми и опциональными. По сути из обязательных, слушающий демон, service bus, и накопитель данных, дальше добавляем обработчик который будет тригерится по определенным событиям.
Для работы с топологией уже есть некоторые задумки, но пока еще не оформились в окончательное решение. Пока едет BBB гуглю альтернативы, чтобы не изобретать велосипед.
Я не буду спорить с тем, что с точки зрения красоты архитектурного решения всё можно сделать лучше. У меня очень практичный подход и система развивается по мере роста потребностей. Я бы не сказал, что в текущем виде она не решает задачи автоматизации хотя бы потому, что она работает у пользователей, которые как раз для автоматизации её выбрали. Система вполне хорошо работает без UI и так же имеет событийную модель для обработки входящих запросов (веб-сервер как один из протоколов принятия событий). Мульти-протокольность поддерживается засчёт различных модулей, каждый из которых отвечает за взаимодействие с «железным» протоколом, будь-то ZWave, MQTT-брокер, 1-wire или тот же HTTP. В конкретно этой системе UI очень важная составляющая, но далеко не единственная. Да и не может она быть таковой в системе, основная задача которой обеспечивать адаптацию среды без участия пользователя.
Я не агитирую, просто надеюсь, что наша дискуссия даст понять, что всё не так категорично и в том или ином виде присутствует и слушающий демон и накопитель данных и подписчики на события.
Я не агитирую, просто надеюсь, что наша дискуссия даст понять, что всё не так категорично и в том или ином виде присутствует и слушающий демон и накопитель данных и подписчики на события.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы программирования объектов Умного Дома в MajorDoMo