Jump to content

    

Оборудование, протоколы

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

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

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
Еще один вариант -

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

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

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

 

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

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

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

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

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

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

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

 

 

Share this post


Link to post
Share on other sites

Да? Жалко.

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

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

Share this post


Link to post
Share on other sites
или Modbus TCP лепят - но блин ему ж уже сколько лет-то.

 

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

Edited by mantech

Share this post


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

 

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

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

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

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

 

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные.

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

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

 

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

 

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

 

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

Share this post


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

 

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

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

Share this post


Link to post
Share on other sites
В протоколе MQTT например имя переменной может быть как в топике так и в поле значения. И значение переменной может быть и в топике и в поле значения. Полная свобода.

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

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites
Тут должен быть простой протокол управления ...

 

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

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

 

Share this post


Link to post
Share on other sites
а создание системы управления, развертывание и поддержка должны быть простыми.

 

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

Share this post


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

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this