А кто сказал, что ioBroker не умеет MQTT?
Вот только я видел всего одно семейство MQTT устройств, которые к тому же надо перепрошивать.
А вот других протоколов я видел ГОРАЗДО больше.
Я писал подобные системы.
Ничего ты не сможешь сделать, если сетка перегружена, эфир замусорен, источник питания слишком слаб или просто "хардварный" баг в чипе (было действительно, что marvell switch чип портил примерно каждый миллионный пакет).
И может случиться, что дверь склада весом в тонну раз в 100 закрытий со всей дури будет въезжать в стену, только потому, что какое нибудь устройство в той же самой сетке в это время с ошибочным приоритетом решит обновится по сети.
У каждого устройства возникают задержки с той или иной вероятностью!
Какая вероятность на отказ или задержку у твоих "платных систем УД"?
Дело улучшают тысячи часов тестов и такая же тысяча костылей.
Или ты полагаешь, что в "платных системах УД" нет костылей? :)
MQTT, как я уже писал в статье, не обладает встроенным интерфейсом для считывания и записи конфигурации.
Да можно создать топики, которые отвечают за параметрирование устройства, но это будет работать только у тебя дома. И только ну с максимум ста устройствами. А потом ты просто запутаешься в салате топиков.
Edit: Не обновил страницу и написал тоже самое, что предыдущий комментатор.
Ну я, вообще-то, тестировал с Simatic WinCC.
ioBroker не ПЛК. И его нельзя применять для realtime. Он не для этого.
Для realtime надо бы хотя бы SIL 2. Ну или хотя бы с соблюдением норм SIL 1.
На линуксе не возникает никаких проблем. Там только надо написать "sudo apt-get install build-essential".
А вот с windows приходится включать бинарники в пакет.
Причём для x64/x86 и для ходовых версий ноды.
И я не делаю сам "сишные биндинги", хотя отлично знаю C/C++ (точнее "отлично" знал. Сейчас просто "знаю"), а использую готовые.
OPC, Modbus — написаны на чистом JS, а вот для S7, serial port нужны C++.
Стабильность на хорошем железе стабильная. :)
Но из-за того, что ioBroker запускается даже на Raspi1B c 512MB, где памяти катастрофически не хватает (если больше чем 4-5 драйверов), страдает имидж, т.к. на них коммуникация между драйверами тормозит и отваливается.
То есть, если следовать твоей логике (я с вашего позволения на ты :) ). То в начале прошлого века никто не должен был переходить на автомобили с лошадей, т. к. лошади гораздо более распространены и помощь можно найти у любого конюха. :)
На самом деле время отклика очень важно для домашнего управления
99% отклика не дольше 50мс, если железо не тормозное.
Проблема всех этих систем типа OpenHAB и IO Broker — они написаны часто людьми, которые не понимают, как писать реалтайм приложения
У меня за плечами VxWorks (эта, та что в марсаходах), Win RTX (это Real Time eXtensions for Windows — применяется например в Software PLC), и просто разработка на микроконтроллерах — например MSP 430 или ATmega.
И я прекрасно знаю, где надо усердствовать до конца, что бы контейнер с крана тебе на голову не упал или руку не отрезало, а где 99% достаточно.
Ты, надеюсь, не собираешься станок с чпу на OpenHAB автоматизировать?
Есть идея реализовать визуализацию для пром. применения. Проверял работоспособность. При 100000 переменных и секундном обновлении начинает тормозить.
А OPC просто проверял (так сказать proof of concept). Там ещё клиента писать надо. Пока только сервер.
То есть ты даже не знаешь, как в ioBroker и что то доказываешь? :)
Ну не поленился я и достал 3ю малину и ввёл команды сверху.
В погоне уменьшить количество команд, ты неправильно их соединил. Ну ничего.
Установил openhab так:
На малине raspbian jessie lite нет java, так же и как node.js. Ставлю java
sudo apt-get install oracle-java7-jdkпотом
wget -qO — 'https://bintray.com/user/downloadSubjectPublicKey?username=openhab' | sudo apt-key add — echo "deb http://dl.bintray.com/openhab/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/openhab.listпотом
echo "deb http://dl.bintray.com/openhab/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/openhab.listпотом
по адресу http://ipaddress:8080/openhab.app
А теперь, я так понимаю, надо лезть в конфиги.
Вот полная инсталляция на ioBroker
Установка 4го нода
и установка iobroker. Причём его можно поставить в любую папку (с наличием прав)
В итоге на http://ipaddress:8081
Это так что ли?
http://majordomo.smartliving.ru/forum/viewtopic.php?t=1652
А кто сказал, что ioBroker не умеет MQTT?
Вот только я видел всего одно семейство MQTT устройств, которые к тому же надо перепрошивать.
А вот других протоколов я видел ГОРАЗДО больше.
Это всё хорошо. Я тоже очень люблю MQTT, особенно после того, как написал шлюз для IEC61850/IEC60870.
А конфигурировать то как?
Читайте внимательнее комментарии пожалуйста. Я не написал, что это сравнение сегодняшнего дня, а указал время.
Тогда разница была непонятная.
Вот это называется из коробки?
http://majordomo.smartliving.ru/Main/SetupLinux
Да я даже до конца страницы устал мотать. :)
Вот это уже короче:
http://www.openhab.org/getting-started/
Но всё равно я понимаю под "из-коробки" максимум 2-3 команды.
iorboker на Linux, если стоит node меньше пятого, ставится 4мя командами:
Что вы понимаете под термином "из коробки"?
Я писал подобные системы.
Ничего ты не сможешь сделать, если сетка перегружена, эфир замусорен, источник питания слишком слаб или просто "хардварный" баг в чипе (было действительно, что marvell switch чип портил примерно каждый миллионный пакет).
И может случиться, что дверь склада весом в тонну раз в 100 закрытий со всей дури будет въезжать в стену, только потому, что какое нибудь устройство в той же самой сетке в это время с ошибочным приоритетом решит обновится по сети.
У каждого устройства возникают задержки с той или иной вероятностью!
Какая вероятность на отказ или задержку у твоих "платных систем УД"?
Дело улучшают тысячи часов тестов и такая же тысяча костылей.
Или ты полагаешь, что в "платных системах УД" нет костылей? :)
MQTT, как я уже писал в статье, не обладает встроенным интерфейсом для считывания и записи конфигурации.
Да можно создать топики, которые отвечают за параметрирование устройства, но это будет работать только у тебя дома. И только ну с максимум ста устройствами. А потом ты просто запутаешься в салате топиков.
Edit: Не обновил страницу и написал тоже самое, что предыдущий комментатор.
http://www.iobroker.net/?page_id=4643&lang=ru
Доходите до фразы:
//Подключаем библиотеки
Пишут уже :) Москва не сразу строилась.
На всё нужны люди. А пока можно зайти на форум или присоединится к группе в телеграмм.
https://telegram.me/SmartsHome
Я не о вашем комментарии, а о минусе (тоже не вашем). Но я думаю, что эту тему пора закрыть и заняться более конструктивными делами.
Ну я, вообще-то, тестировал с Simatic WinCC.
ioBroker не ПЛК. И его нельзя применять для realtime. Он не для этого.
Для realtime надо бы хотя бы SIL 2. Ну или хотя бы с соблюдением норм SIL 1.
На линуксе не возникает никаких проблем. Там только надо написать "sudo apt-get install build-essential".
А вот с windows приходится включать бинарники в пакет.
Причём для x64/x86 и для ходовых версий ноды.
И я не делаю сам "сишные биндинги", хотя отлично знаю C/C++ (точнее "отлично" знал. Сейчас просто "знаю"), а использую готовые.
OPC, Modbus — написаны на чистом JS, а вот для S7, serial port нужны C++.
Стабильность на хорошем железе стабильная. :)
Но из-за того, что ioBroker запускается даже на Raspi1B c 512MB, где памяти катастрофически не хватает (если больше чем 4-5 драйверов), страдает имидж, т.к. на них коммуникация между драйверами тормозит и отваливается.
То есть, если следовать твоей логике (я с вашего позволения на ты :) ). То в начале прошлого века никто не должен был переходить на автомобили с лошадей, т. к. лошади гораздо более распространены и помощь можно найти у любого конюха. :)
99% отклика не дольше 50мс, если железо не тормозное.
У меня за плечами VxWorks (эта, та что в марсаходах), Win RTX (это Real Time eXtensions for Windows — применяется например в Software PLC), и просто разработка на микроконтроллерах — например MSP 430 или ATmega.
И я прекрасно знаю, где надо усердствовать до конца, что бы контейнер с крана тебе на голову не упал или руку не отрезало, а где 99% достаточно.
Ты, надеюсь, не собираешься станок с чпу на OpenHAB автоматизировать?
Но при 50000 вполне всё "операбельно" :)
Интересная наводка. Спасибо.
Протокол ещё новый (они тоже начали в летом 2014) и я не знал о нём. Ну будет ещё один драйвер. :)
У меня тоже такие подозрения.
Alljoyn это Qualcomm и они уже с 2011 года. Как только будут появляться приборы, надо будет подключить.
Вот ещё один "для-всего-протокол": http://www.lemonbeat.com/
Обязательно почитаю о IoTivity. Ещё раз спасибо.
Есть идея реализовать визуализацию для пром. применения. Проверял работоспособность. При 100000 переменных и секундном обновлении начинает тормозить.
А OPC просто проверял (так сказать proof of concept). Там ещё клиента писать надо. Пока только сервер.