[VCucumber 0]

а если предусмотреть специальную низковольтную розетку и специальную вилку ?

есть какие-нибудь на примете, чтобы в рамку вместе с обычными евророзетками входили ?

 

[VCucumber 0]

есть розетки со штырьком

 

https://yandex.ru/images/search?text=%D1%80...%BA%D0%BE%D0%BC

 

предположительно, немецкий стандарт

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

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

 

[VCucumber 0]

и кстати, по трем проводам подключить три розетки - можно, как три фазы

 

[syoma 1]

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

 

Собственно поэтому вырисовывается новая топология домашней автоматизации - построенная на модульности вокруг MQTT.

Т.е. основная задача всей периферии - это трансляция всевозможных протоколов в сообщения MQTT и обратно. Т.е. нужны(и вообще-то уже существуют) гейтвеи: Z-Wave<->MQTT, WEB<->MQTT, Arduino<->MQTT и т.д. На каком железе реально они будут работать - неважно. Хоть на том же самом Распберри. Зато обновлять и конфигурировать их будет очень просто, так как функциональность полностью независимая и домашняя сеть не угробится из-за глюка одного гейтвея.

 

MQTT Брокер ессно в системе должен быть один и желательно надежный. Под него можно выделить тот же Рапберри или использовать любую линуксовую машину.

 

Ну а для автоматизации подключаем любой софт, который тоже будет брать сообщения с MQTT брокера и отсылать команды ему же. Это тот же OpenHAB, Domotique и куча других. Главное - теперь автоматизационный софт полностью развязан от всех протоколов. Т.е. проблем с поддержкой гораздо меньше. Я даже думаю этот софт теперь можно будет замутить как модель в Матлабе, чтобы можно было легко обновлять и отлаживать все алгоритмы умного дома платформо-независимо. Нужно только будет подключить из исходников функции приема/посылки сообщений по MQTT. Логи MQTT тогда можно будет скармливать модели, чтобы проверить правильно ли она работает.

 

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

[syoma 1]

Еще один вариант -

наткнулся на вот такой редактор связей - http://nodered.org/

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

На досуге хочу поиграться и с помощью этого подключить Z-wave <-> MQTT, а потом еще и Codesys через OPC UA присобачить. Вот тебе и домашняя автоматика.

[AlexandrY 2]

Еще один вариант -

наткнулся на вот такой редактор связей - http://nodered.org/

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

На досуге хочу поиграться и с помощью этого подключить Z-wave <-> MQTT, а потом еще и Codesys через OPC UA присобачить. Вот тебе и домашняя автоматика.

 

Наигрался я с этим.

Крайне неудобная и тормознутая вещь.

Мои впечатления от сервисов IBM здесь - https://geektimes.ru/post/268164/

Запускал я там и приложение сделанное в Node-RED

Запаритесь отлаживать такое приложение и разбираться в логике работы компонентов.

Шаг влево шаг вправо и вам предлагают там взять коммерческие компоненты.

Еще у IBM постоянные проблемы с доступностью сервисов.

 

 

[syoma 1]

Да? Жалко.

Просто это единственное решение, которое я нашел пока, которое позволяет связать в единую систему интерфейсы, применяемые в умном доме и в промышленной автоматике.

На практике пока либо то, либо другое и связь в лучшем случае через тормознутый HTTP или Modbus TCP лепят - но блин ему ж уже сколько лет-то.

[mantech 33]

или Modbus TCP лепят - но блин ему ж уже сколько лет-то.

 

А какая разница, сколько чему лет, если работает надежно и выполняет свои функции?? По мне RS-232\485 - самый лучший интерфейс, и модбас уже проверенный десятилетиями. И стараюсь использовать именно их вместо всяких усб и т.п. Если надо скорость повыше есть эзернет, и "тормознутый HTTP" совсем необязательно использовать...

Изменено 21 марта, 2016 пользователем mantech

[AlexandrY 2]

А какая разница, сколько чему лет, если работает надежно и выполняет свои функции?? По мне RS-232\485 - самый лучший интерфейс, и модбас уже проверенный десятилетиями. И стараюсь использовать именно их вместо всяких усб и т.п. Если надо скорость повыше есть эзернет, и "тормознутый HTTP" совсем необязательно использовать...

 

MODBUS не катит для IoT по причине своей жесткой схематизации.

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

В IoT это неприемлемо.

Такая схематизация вызывает огромную избыточность баз данных и перегрузки по администрированию, как например точный учет схем структур данных и их версий.

 

В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные.

Переменные всегда сопровождаются их именами и местом в дереве динамических структур.

Современные NoSQL базы данных легко такую информацию обрабатывают.

 

В протоколе MQTT например имя переменной может быть как в топике так и в поле значения. И значение переменной может быть и в топике и в поле значения. Полная свобода.

Само поле значения может быть контейнером другого кодирования например JSON. JSON может представлять еще одно динамическое дерево разных переменных. И NoSQL определит это автоматом.

А у MODBUS нет свободы.

[mantech 33]

В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные.

Переменные всегда сопровождаются их именами и местом в дереве динамических структур.

Современные NoSQL базы данных легко такую информацию обрабатывают.

 

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

 

А у MODBUS нет свободы.

 

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

[AlexandrY 2]

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

 

Какие костыли если нет пациента?

Вы можете любую заранее не согласованную дурь послать MQTT серверу и он ее запомнит и выведет в виде графиков.

[mantech 33]

В протоколе MQTT например имя переменной может быть как в топике так и в поле значения. И значение переменной может быть и в топике и в поле значения. Полная свобода.

Само поле значения может быть контейнером другого кодирования например JSON. JSON может представлять еще одно динамическое дерево разных переменных. И NoSQL определит это автоматом.

 

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

 

Какие костыли если нет пациента?

Вы можете любую заранее не согласованную дурь послать MQTT серверу и он ее запомнит и выведет в виде графиков.

 

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

[AlexandrY 2]

Тут должен быть простой протокол управления ...

 

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

Не путайте средства с целью.

 

[mantech 33]

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

 

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

[syoma 1]

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

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

Зачем придумывать и следить за адресами, если можно прямо передавать названия переменных вместе со значением и типом? Вот упрощение в конфигурировании.

Также при добавлении новых переменных в Модбасе, ее адрес надо задать, что тоже лишняя работа. Особенно, если вдруг выделенного адресного пространства не хватает.

 

Также поллинг в случае с Modbus TCP - смысл отсутствует - медленно и загружает сеть. С этой точки зрения опять тот же MQTT выигрывает - подписался на обновления, и ни о чем не думаешь.

 

Вот по крайней мере две вещи, отличающие протоколы 20-и летней давности от современных. По крайней мере для меня.