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

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

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

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

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

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

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

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

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

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

Еще один вариант -
наткнулся на вот такой редактор связей - http://nodered.org/
Как они рекламируют, позволяет в графическом виде легко соединять разные вещи в Интернет Вещей. Т. е. производить связи между различным железом и сервисами. Поддерживает кучу железа и сервисов, включая всякие ардуины и пр. Родоначальник этого проекта - IBM, поэтому ессно поддержка MQTT больше других. Ну и облако свое они рекламируют.
На досуге хочу поиграться и с помощью этого подключить Z-wave <-> MQTT, а потом еще и Codesys через OPC UA присобачить. Вот тебе и домашняя автоматика.

Наигрался я с этим.
Крайне неудобная и тормознутая вещь.
Мои впечатления от сервисов IBM здесь - https://geektimes.ru/post/268164/
Запускал я там и приложение сделанное в Node-RED
Запаритесь отлаживать такое приложение и разбираться в логике работы компонентов.
Шаг влево шаг вправо и вам предлагают там взять коммерческие компоненты.
Еще у IBM постоянные проблемы с доступностью сервисов.

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

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

Сообщение отредактировал mantech - Mar 21 2016, 14:21

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

В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные.
Переменные всегда сопровождаются их именами и местом в дереве динамических структур.
Современные NoSQL базы данных легко такую информацию обрабатывают.

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

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



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

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

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



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

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

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

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

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

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