VCucumber 0 7 июля, 2015 Опубликовано 7 июля, 2015 · Жалоба а если предусмотреть специальную низковольтную розетку и специальную вилку ? есть какие-нибудь на примете, чтобы в рамку вместе с обычными евророзетками входили ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 7 июля, 2015 Опубликовано 7 июля, 2015 · Жалоба есть розетки со штырьком https://yandex.ru/images/search?text=%D1%80...%BA%D0%BE%D0%BC предположительно, немецкий стандарт если поступить наоборот - штырёк вкрутить в центр вилки, вместо оригинального винта, а в розетке использовать винт с отверстием, то всё складывается итого имеем блок из четырех розеток, двух обычных, одной с резервным питанием, и одной низковольтной, для питания девайсов умного дома Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 7 июля, 2015 Опубликовано 7 июля, 2015 · Жалоба и кстати, по трем проводам подключить три розетки - можно, как три фазы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 26 октября, 2015 Опубликовано 26 октября, 2015 · Жалоба В свете изучения ESP8266 понравился мне протокол MQTT - простое решение обмена сообщениями между датчиками без привязки к какой либо среде. Есть куча реализаций, свободный стек лежит в сети. Сервак или Брокер, как они его называют - легко поднялся на Распберри и помимо простой отладки, автоматом сохраняет все логи всех сообщений между устройствами. Доставка сообщений гарантируется. Собственно поэтому вырисовывается новая топология домашней автоматизации - построенная на модульности вокруг MQTT. Т.е. основная задача всей периферии - это трансляция всевозможных протоколов в сообщения MQTT и обратно. Т.е. нужны(и вообще-то уже существуют) гейтвеи: Z-Wave<->MQTT, WEB<->MQTT, Arduino<->MQTT и т.д. На каком железе реально они будут работать - неважно. Хоть на том же самом Распберри. Зато обновлять и конфигурировать их будет очень просто, так как функциональность полностью независимая и домашняя сеть не угробится из-за глюка одного гейтвея. MQTT Брокер ессно в системе должен быть один и желательно надежный. Под него можно выделить тот же Рапберри или использовать любую линуксовую машину. Ну а для автоматизации подключаем любой софт, который тоже будет брать сообщения с MQTT брокера и отсылать команды ему же. Это тот же OpenHAB, Domotique и куча других. Главное - теперь автоматизационный софт полностью развязан от всех протоколов. Т.е. проблем с поддержкой гораздо меньше. Я даже думаю этот софт теперь можно будет замутить как модель в Матлабе, чтобы можно было легко обновлять и отлаживать все алгоритмы умного дома платформо-независимо. Нужно только будет подключить из исходников функции приема/посылки сообщений по MQTT. Логи MQTT тогда можно будет скармливать модели, чтобы проверить правильно ли она работает. И настройка такой сети - одна песня. Просто взял, прописал нужные топики в панели управления каким-нибудь текстовичком - и все работает. Хочешь - делай централизованную систему - т.е датчики пишут в одни топики, а команды генерятся автоматизационным софтом в другие, на которые подписаны исполнительные устройства. Хочешь - распределенную - подписываешь релюшку прямо на топик, куда пишет датчик, минуя автоматизатор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Еще один вариант - наткнулся на вот такой редактор связей - http://nodered.org/ Как они рекламируют, позволяет в графическом виде легко соединять разные вещи в Интернет Вещей. Т. е. производить связи между различным железом и сервисами. Поддерживает кучу железа и сервисов, включая всякие ардуины и пр. Родоначальник этого проекта - IBM, поэтому ессно поддержка MQTT больше других. Ну и облако свое они рекламируют. На досуге хочу поиграться и с помощью этого подключить Z-wave <-> MQTT, а потом еще и Codesys через OPC UA присобачить. Вот тебе и домашняя автоматика. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Еще один вариант - наткнулся на вот такой редактор связей - http://nodered.org/ Как они рекламируют, позволяет в графическом виде легко соединять разные вещи в Интернет Вещей. Т. е. производить связи между различным железом и сервисами. Поддерживает кучу железа и сервисов, включая всякие ардуины и пр. Родоначальник этого проекта - IBM, поэтому ессно поддержка MQTT больше других. Ну и облако свое они рекламируют. На досуге хочу поиграться и с помощью этого подключить Z-wave <-> MQTT, а потом еще и Codesys через OPC UA присобачить. Вот тебе и домашняя автоматика. Наигрался я с этим. Крайне неудобная и тормознутая вещь. Мои впечатления от сервисов IBM здесь - https://geektimes.ru/post/268164/ Запускал я там и приложение сделанное в Node-RED Запаритесь отлаживать такое приложение и разбираться в логике работы компонентов. Шаг влево шаг вправо и вам предлагают там взять коммерческие компоненты. Еще у IBM постоянные проблемы с доступностью сервисов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Да? Жалко. Просто это единственное решение, которое я нашел пока, которое позволяет связать в единую систему интерфейсы, применяемые в умном доме и в промышленной автоматике. На практике пока либо то, либо другое и связь в лучшем случае через тормознутый HTTP или Modbus TCP лепят - но блин ему ж уже сколько лет-то. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 21 марта, 2016 Опубликовано 21 марта, 2016 (изменено) · Жалоба или Modbus TCP лепят - но блин ему ж уже сколько лет-то. А какая разница, сколько чему лет, если работает надежно и выполняет свои функции?? По мне RS-232\485 - самый лучший интерфейс, и модбас уже проверенный десятилетиями. И стараюсь использовать именно их вместо всяких усб и т.п. Если надо скорость повыше есть эзернет, и "тормознутый HTTP" совсем необязательно использовать... Изменено 21 марта, 2016 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба А какая разница, сколько чему лет, если работает надежно и выполняет свои функции?? По мне RS-232\485 - самый лучший интерфейс, и модбас уже проверенный десятилетиями. И стараюсь использовать именно их вместо всяких усб и т.п. Если надо скорость повыше есть эзернет, и "тормознутый HTTP" совсем необязательно использовать... MODBUS не катит для IoT по причине своей жесткой схематизации. Т.е. сторона общающаяся с устройством по MODBUS должна точно знать структуру, типы, адреса переменных, входов и выходов. В IoT это неприемлемо. Такая схематизация вызывает огромную избыточность баз данных и перегрузки по администрированию, как например точный учет схем структур данных и их версий. В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные. Переменные всегда сопровождаются их именами и местом в дереве динамических структур. Современные NoSQL базы данных легко такую информацию обрабатывают. В протоколе MQTT например имя переменной может быть как в топике так и в поле значения. И значение переменной может быть и в топике и в поле значения. Полная свобода. Само поле значения может быть контейнером другого кодирования например JSON. JSON может представлять еще одно динамическое дерево разных переменных. И NoSQL определит это автоматом. А у MODBUS нет свободы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба В IoT приняты schemaless базы данных и неструктурированные жестко(заранее) данные. Переменные всегда сопровождаются их именами и местом в дереве динамических структур. Современные NoSQL базы данных легко такую информацию обрабатывают. Иными словами - это винегрет, который нужно еще "переварить", при помощи кучи костылей и заплаток, которые кто-то, как-то должен настраивать и может быть оно заработает... Мм да, нее, модбас куда лучше, по крайне мере с точки зрения промавтоматики. А у MODBUS нет свободы. И не должно быть тут никаких свобод, это оборудование передачи данных и управления, начнем вводить разброд и шатание - получим винду в лучшем виде - да, она вроде, как все поддерживает, вопрос только один, как хорошо она это делает, думаю риторический... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Иными словами - это винегрет, который нужно еще "переварить", при помощи кучи костылей и заплаток, которые кто-то, как-то должен настраивать и может быть оно заработает... Мм да, нее, модбас куда лучше, по крайне мере с точки зрения промавтоматики. Какие костыли если нет пациента? Вы можете любую заранее не согласованную дурь послать MQTT серверу и он ее запомнит и выведет в виде графиков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба В протоколе MQTT например имя переменной может быть как в топике так и в поле значения. И значение переменной может быть и в топике и в поле значения. Полная свобода. Само поле значения может быть контейнером другого кодирования например JSON. JSON может представлять еще одно динамическое дерево разных переменных. И NoSQL определит это автоматом. А что это дает в "реальной жизни", вопрос в управлении какой-либо железкой с помощью ПЛК или какой-нибудь системы управления... Это ж не контейнеры для всяких видеоформатов и звука... Тут должен быть простой протокол управления и желательно общестандартный. Какие костыли если нет пациента? Вы можете любую заранее не согласованную дурь послать MQTT серверу и он ее запомнит и выведет в виде графиков. Кто этим будет заиматься?? Искусственный интеллект?? Если нет, то вот как раз эти и костыли, в виде всяких программ, баз и т.п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Тут должен быть простой протокол управления ... Да не протокол должен быть простой, а создание системы управления, развертывание и поддержка должны быть простыми. Не путайте средства с целью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба а создание системы управления, развертывание и поддержка должны быть простыми. Только пока ничего интуитивно понятного и стандартизированного в данной области, не слышно и не видно, а разноформатица простоты не добавляет и подавно... Вообщем, поживем увидим.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Иными словами - это винегрет, который нужно еще "переварить", при помощи кучи костылей и заплаток, которые кто-то, как-то должен настраивать и может быть оно заработает... Мм да, нее, модбас куда лучше, по крайне мере с точки зрения промавтоматики Винегрет, не винегрет, но даже с точки зрения автоматики - в Модбасе нужно настраивать адреса, регистры, катушки - то есть как минимум один лишний документ, который нужно поддерживать и в соответствии с которым настраивать систему. Имхо - это анахронизм. Зачем придумывать и следить за адресами, если можно прямо передавать названия переменных вместе со значением и типом? Вот упрощение в конфигурировании. Также при добавлении новых переменных в Модбасе, ее адрес надо задать, что тоже лишняя работа. Особенно, если вдруг выделенного адресного пространства не хватает. Также поллинг в случае с Modbus TCP - смысл отсутствует - медленно и загружает сеть. С этой точки зрения опять тот же MQTT выигрывает - подписался на обновления, и ни о чем не думаешь. Вот по крайней мере две вещи, отличающие протоколы 20-и летней давности от современных. По крайней мере для меня. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться