Comments 114
Может он написал что-то лучшее? Так расскажи! Я по-учусь. Или за грамматические ошибки заботливо не указанные в приватных сообщениях?
А уж тем более — задавать этот вопрос в первые минуты/часы после публикации!
Кто-то поставил минус. Не объяснил его. Человек может даже в комментарии не заглядывал и не будет. Он не прочтет вашего «За что?! Это не справедливо!». Зато прочтут остальные и подумают, что вы первый день в интернете ))
А что еще ждать, если поднимать\опускать статью позволяется кому угодно с одинаковым весом?
Как и любой человек, написавший статью на 100% тебя понимаю. Считаю, что оценивать труд должен только равный, то есть оцивают статьи только те кто что то сами написали, а не как сейчас — любой «Не читал, но осуждаю!» (с).
Сам работаю в сфере автоматизации, прочитал бегло ибо голова не настроена уже. Однако чисто интуитивно (внутренне) не верится в связь всего со всем.
Видимо от понимания того, что подружить две железяки (устройство knx, например, и пк с этим ioBroker) всегда не просто. А здесь предлагается после этого процесса подружить ещё два компонента разных ioBroker друг с другом.
Верно?
Ставьте минус «за такое Ваше отношение». Ничего переживу.
KNX драйвер переписывается сейчас во второй раз.
А может стоит попробовать? Я ужасаюсь каждый раз, когда люди делают выбор в пользу openhab.
Что вы понимаете под термином "из коробки"?
Вот это называется из коробки?
http://majordomo.smartliving.ru/Main/SetupLinux
Да я даже до конца страницы устал мотать. :)
Вот это уже короче:
http://www.openhab.org/getting-started/
Но всё равно я понимаю под "из-коробки" максимум 2-3 команды.
iorboker на Linux, если стоит node меньше пятого, ставится 4мя командами:
sudo mkdir /opt/iobroker
sudo chmod 777 /opt/iobroker
cd /opt/iobroker
sudo npm install iobroker --unsafe-permвообще я говорил про «работает», но если хочется про установку поговорить…
в инструкции мажордомо речь про установку всех зависимостей, редактора, ссх. смотреть зависимости ноде лень.
в инструкции опенхаба теже несколько команд.
чтоже до сабжа, сначала надо выяснить какая версия ноды нужна, потом версия нпм. ни из логов ни из инструкции это не понять. потом выяснить что инструкция как не совсем инструкция. найти решение на форуме. слегка поправить и вот оно встало.
но не работает :)
а вот мажордомо и домотикс менеджером пакета ставятся одной командой и работают :)
Я тоже могу сказать, что OH на RPi устанавливается 4 командами:
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
sudo apt-get update
sudo apt-get install openhab-runtime
Только после этого еще нужно установить драйвера под нужные протоколы: Z-wave, KNX и т.д. Это по команде на каждый. Лично у меня их 6
sudo apt-get install openhab-addon-persistence-rrd4j
sudo apt-get install openhab-addon-binding-z-wave
sudo apt-get install openhab-addon-binding-mqtt
sudo apt-get install openhab-addon-binding-http
sudo apt-get install openhab-addon-binding-ntp
sudo apt-get install openhab-addon-binding-weather
А потом еще создать свою конфигурацию. А в ioBroker как?
То есть ты даже не знаешь, как в ioBroker и что то доказываешь? :)
Ну не поленился я и достал 3ю малину и ввёл команды сверху.
pi@raspberrypi:~ 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
gpg: no valid OpenPGP data found.
pi@raspberrypi:~ $ sudo apt-get update
....
....
pi@raspberrypi:~sudo apt-get install openhab-runtime
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package openhab-runtimeВ погоне уменьшить количество команд, ты неправильно их соединил. Ну ничего.
Установил 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
потом
sudo apt-get install openhab-runtime
sudo /etc/init.d/openhab startпо адресу http://ipaddress:8080/openhab.app
HTTP ERROR 500
Problem accessing /openhab.app. Reason:
Sitemap 'default' could not be foundА теперь, я так понимаю, надо лезть в конфиги.
Вот полная инсталляция на ioBroker
Установка 4го нода
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y build-essential python-rpi.gpio nodejsи установка iobroker. Причём его можно поставить в любую папку (с наличием прав)
sudo mkdir /opt/iobroker
sudo chmod 777 /opt/iobroker
cd /opt/iobroker
sudo npm install iobroker --unsafe-permВ итоге на http://ipaddress:8081
После этого мышкой нажать на плюсик напротив тех драйверов, что нужны и настроить их через браузер на 3х языках, включая на русском
И всё из браузера, не заходя в консоль. Хотя из консоли тоже можно устанавливать драйвера.
Потом рисуется интерфейс
Или просто приборам присваиваются (кликаньем) свойства (свет/жалюзи/..) и/или комната и готов мобильный интерфейс.
Вот создание интерфейса
Вот ещё (правда на немецком)
С другой стороны насчет перелазить — следует учитывать риск, что с любым софтом можно столкнуться с тем, что он вдруг перестанет выполнять свои функции — то ли поддержка community исчезнет, то ли при очередном обновлении появится критический баг именно в данной системе, а откат невозможен. То ли просто задолбает стабильность. Выход будет, скорей всего, в переходе на другую систему УД, но тут-то и кроется проблема — стоимость перехода может быть достаточно высокой, так как придется много вещей переделывать с нуля и потратить на это много времени — инсталляция и первоначальная настройка только часть из них. Именно поэтому в этих случаях рекомендуется переходить на модульные архитектуры со стандартизированными интерфейсами, чтобы в случае чего можно было поменять один софтверный или хардварный модуль без необходимости замены или модернизации всей системы.
В конкретном случае с УД я вижу две особенности:
— Интерфейс пользователя — если реализовать все эти Web и мобильные интерфейсы средствами ioBroker, то при переходе на другую систему УД наработки, скорей всего потеряются и их придется рисовать обратно. С этой точки зрения в OH проще — там есть только гаджетный вид, который рисовать не надо. Поэтому в моей системе я стараюсь разъединить эти вещи — по крайней мере мой планшетный GUI для настенных панелей сделан на другой проге и коннектится к УД по MQTT — так я могу спокойно переключиться на любой другой контроллер УД без изменений в этой части.
— вторая особенность — сценарии и правила. Графические они или нет, при переходе на другую систему опять все придется рисовать заново, так как будет, скорей всего, другой язык программирования. Именно поэтому движек правил в моей системе будет независим от системы УД и связан с ней опять таки стандартным интерфейсом. В этом случае, опять же, переход с на другой контроллер УД позволит мне спокойно продолжать использовать мои уже написанные правила.
Это всё абсолютно верно, что очень трудно слезть с одной системы. Но что ж мне теперь останавливаться, только потому, что openhab популярнее, хотя iobroker удобнее?
У OH своё сообщество, у IoB своё. Я же не призываю сжечь OH :)
Тогда вы получите множество довольных пользователей, а точнее интеграторов, включая меня, конечно, и сможете развиваться в конкретном направлении.
Просто охватить все и вся сейчас с вашими разработченскими ресурсами не получится, и лучше сделать одну функцию, но сделать ее хорошо, чем пытаться угодить сотне человек, не понимающих, зачем им этот УД не из коробки, реализовывая разные хотелки, которые можно было бы сделать на другом продукте лучше.
В погоне уменьшить количество команд, ты неправильно их соединил. Ну ничего.
Судя по всему, это geektimes их так соединяет. Сори.
Слишком поздно сообразил, что надо было засунуть картинки под спойлер.
Странно почему? Он гораздо более популярен — всегда можно найти помощь.
А также ставится практически из коробки и работает месяцами без сбоев и перезагрузок. А вот как со стабильностью у ioBroker?
То есть, если следовать твоей логике (я с вашего позволения на ты :) ). То в начале прошлого века никто не должен был переходить на автомобили с лошадей, т. к. лошади гораздо более распространены и помощь можно найти у любого конюха. :)
Стабильность на хорошем железе стабильная. :)
Но из-за того, что ioBroker запускается даже на Raspi1B c 512MB, где памяти катастрофически не хватает (если больше чем 4-5 драйверов), страдает имидж, т.к. на них коммуникация между драйверами тормозит и отваливается.
Время шло. Уже 14000 домов и мелких производств, автоматизированных на ioBroker. Собственный KNX прибор, в самом популярном немецком магазине для интеграторов, и пара мелких на amazon, #iobroker #voltus #KNX #professional #homeautomation
https://lnkd.in/g_26kdm
То ли еще будет ой ой ой :-) Буду рад любой кооперации с дизайнерами, программистами, продавцами, интеграторами и креативными людьми.
Сижу на OpenHab, но уже местами рамки зажимают, а графики так вообще грусть печалька, хоть костыль чего сбоку.
По MQTT в режиме брокера — правильно понимаю, что по умолчанию он транслирует все свое дерево устройств? По каким правилам?
У меня например сейчас «ручное дерево», например для ночника у кровати:
home/lamp_A/0 — нулевой канал лампы, на него подписан сервер, сюда шлет лампа при изменении состояния
home/lamp_A/0/set — ветка установки состояния, на него подписана лампа, сюда шлет любое устройство, которое хочет поменять состояние этой лампы.
Как в случае ioBrocker это будет работать из документации я не понял, проясни по возможности.
Топики создаются автоматически из топологии устройств. Но есть возможность создать собственные названия и обновлять их через скрипты. Хочу только сказать, что это редко используется.
Имя топика используется и для сообщения о статусе и для управления. При изменении состояния, сервер получает уведомление. Если необходимо переключить состояние, то при записи в топик оно воспринимается, как команда.
Такая топология имеет минус — оконечное устройство не имеет канала для сообщения об отработки команды, не всегда set = get. Команда может быть не отработана (устройство отключено), может быть отработана с ощутимой задержкой (долгая операция, сервопривод например)
В самом брокере у каждой переменной есть флаг, говорящий о том что это — команда или состояние.
Хм, очень похоже на openhab, каждая переменная биндится на две ветки — одну для состояния, вторая — для отправки команд.
Может тебе так же сделать — у каждой переменной атрибут для биндинга на mqtt ветку.
Если переменная состояние — она подписывается на эту ветку: home/lamp_A/0, если команда — шлет в home/lamp_A/0/set
>>>можно было поставить галочку в настройках, что писать только через set
Это топорно в лоб, пользователь может не использовать set, вариант как выше описал более гибкий ИМХО.
Не понял — куда отослать? В какой топик?
Если делать единый топик для подтверждений — то будет помойка и что бы ее разобрать будет огромный switch case, то есть та же "куча топиков", только в другой обертке.
Сейчас любое устройство, подписавшееся на home/lamp_A/0 будет реагировать на ИЗМЕНЕНИЕ состояния объекта, а не пожелания Мастера, которые еще не факт что исполнятся.
На самом деле происходит так:
- Клиент шлёт команду "on" =>
- mqtt брокер в ioBroker шлёт команду лампе "on" и рассылает всем другим клиентам "лампа" = "on" =>
- Внутреннее состояние переменной "лампа" меняется на "on/command", =>
- потом лампа шлёт подтверждение =>
- Внутреннее состояние переменной "лампа" меняется на "on/state", =>
- mqtt брокер в ioBroker отсылает всем клиентам по тому же топику "лампа" = "on".
Проблема только в том, что другие клиенты не знают какой из двух полученных "on" команда, а какой состояние.
С решением "лампа" и "лампа/set" последовательность будет выглядеть так:
- Клиент шлёт команду "on" =>
- mqtt брокер в ioBroker шлёт команду лампе "on" и рассылает всем другим клиентам, что "лампа/set" = "on" =>
- Внутреннее состояние переменной "лампа" меняется на "on/command", =>
- потом лампа шлёт подтверждение =>
- Внутреннее состояние переменной "лампа" меняется на "on/state", =>
- mqtt брокер в ioBroker отсылает всем клиентам по тому же топику "лампа" = "on".
И все довольны :)
>>>Проблема только в том, что другие клиенты не знают какой из двух полученных "on" команда, а какой состояние.
Вопрос — может ли у тебя Лампа внутри себя обработать команду на включение (например по кнопке), и только проинформировать Мастера?
Так понимаю — нет, по твоей логике Мастер воспримет сейчас любую запись в ветку home/lamp_A/0 как команду на включение.
Еще одну фигню не понимаю, если у тебя сейчас один топик и на команды и на подтверждение то как это работает? почему в цикле не умирает?
Если мастер подписан на home/lamp_A/0 и шлет в нее сообщение 1, то он через мсек в обратк получит от MQTT брокера сообщение — в топике home/lamp_A/0 новое сообщение и получит свое же "1".
Так как у тебя не падает — тут стопудова какой то костыль, ты похоже не шлешь Мастеру сообщения с топика home/lamp_A/0, если он сам туда его отправил. Москито точно шлет в обратку, ему пофиг кто отправил — все подписанты должны получить и это правильно, я ведь могу использовать MQTT как внутреннюю шину (один модуль отправил, другой считал)
Ты правильно догадался, что клиент не получает собственного сообщения.
А зачем?
MQTT брокер не является сердцем ioBroker и в ioBroker своя шина (socket.io или redis).
Но даже если клиент получит своё сообщение обратно, зачем клиенту отсылать это снова к брокеру?
А зачем?
Так устроен стандарт MQTT. Теперь понятно почему народ пишет, что с левыми MQTT брокерами ioBrocker не дружит.
Ребята — такой костыль надо писать красным жирным текстом в описании mqtt брокера, для вас это нормально, но весь остальной мир(после Москито и HiveMQ) будет долго понимать почему не работает.
Но даже если клиент получит своё сообщение обратно, зачем клиенту отсылать это снова к брокеру?
Потому что клиент MQTT — лампа (у тебя на рисунке redis замени на mqtt). Она обработает сообщение, включит свет и вернет состояние в ту же ветку по текущей твоей логике ioBrocker.
У тебя по архитектуре — выключи ioBrocker и все встанет, у меня — пока жив москито — все будет включаться\выключаться, только сложные скрипты Openhab сдохнут.
Поэтому бестпрактис — разделять топики на командный и состояния — так работает с любым MQTT брокером и появляется гибкость работы без Openhab\ioBrocker\ т.д.
Вообще меня три уровня логики:
1) рефлексы — то что закодено в контролере, например включение лампы от кнопки. Это будет работать при погашенном mqtt и openhab
2) связи — это подписки на set топики, таким образом команды могут прилетать между устройствами без работы "высшего разума"
3) мозги — openhab, дает историю, веб морду, мобильного клиента, сложные скрипты учитывающие состояние нескольких датчиков.
Так что и при сдохшем MQTT свет включу :), так ИМХО надежнее и правильнее. Думал что у всех так, хоть статью пиши.
Да не буду я лампу по MQTT подключать. Обычно тут всё, кроме MQTT: serial, xml-rpc/tcp, wireless 433Mhz, modbus, opc,…; но только не mqtt.
В том и удобство ioBroker, что он самодостаточен. Не надо mosquitto или баз данных. Базы данных можно опционально подключить.
Мир не состоит только из MQTT устройств (которые тоже прекрасно подключаются).
Кстати можешь назвать готовые MQTT устройства? Розетку например? Давно ищу.
У меня тоже 3 уровня логики:
- локально на устройстве я могу нажать кнопку (открыть жалюзи или включить свет)
- устройства соединены между собой (например беспроводная кнопка соединена с выключателем по своему протоколу).
- ну и ioBroker для лога и графиков, скриптов, визуализации и высшего разума :)
И что ты привязался к этому москито. Я уже давно код написал, а ты всё костыль, костыль… :)
Кстати можешь назвать готовые MQTT устройства? Розетку например? Давно ищу.
На esp8266 смотри, например https://www.itead.cc/smart-socket-eu.html
https://github.com/ioBroker/ioBroker.mqtt#changelog
1.1.0 (2016-07-23)
add new setting: Use different topic names for set and get
— удобная отладка: подписавшись на все топики в MQTT вы полностью видите обмен между устройствами во всех направлениях и можете легко проследить какие команды были получены и какие статусы обновлены. У меня такой подписчик пишет все принятые сообщения в файл вместе с временными штампами и потом этот файл можно спокойно открыть в екселе и отфильтровать нужные топики для анализа. Я даже event log OpenHABа просматриваю таким образом, так как MQTT в этом случае его просто копирует.
— удобное подключение своих девайсов: У меня из готовых MQTT устройств к стене прибит андроидный планшет с кастомным GUI для отображения погоды и управления освещением, диммерами и жалюзями в комнате. Там крутится бесплатная аппликуха с MQTT интерфейсом.
Ключевой момент в том, что вы приводите по-своему. Другой разработчик сделает иначе (другой формат данных, другая иерархия в топиков и т. д.) Так что MQTT в своем изначальном виде для домашней автоматизации малопригоден.
А вот если обвешать его допольнительными спеками и заставить всех эти спеки соблюдать — то тогда вполне. По крайней мере для малых проектов. Для распределенных, в которых много брокеров соединены в бриджи, между ними будет гоняться слишком много лишнего трафика
MQTT, как я уже писал в статье, не обладает встроенным интерфейсом для считывания и записи конфигурации.
Да можно создать топики, которые отвечают за параметрирование устройства, но это будет работать только у тебя дома. И только ну с максимум ста устройствами. А потом ты просто запутаешься в салате топиков.
Edit: Не обновил страницу и написал тоже самое, что предыдущий комментатор.
Под сердцем УД я имел ввиду то, что MQTT может заменить все простые популярные сегодня протоколы обмена данными между контроллером и удаленными узлами, подключенными через интернет, например, Modbus TCP — лично для меня MQTT заменяет его полностью и предлагает намного более продвинутые возможности: отсутствие необходимости поллинга, отсутствие привязки к адресам и необходимости их конфигурации, аутентификация, возможность работы в сетях с большой латентностью и фаерволами, передача любых типов переменных и даже файлов.
Поэтому я и отказываюсь от других протоколов обмена данными в сторону негою
а я буду, ибо контроллер должен уметь все вменяемые протоколы.
а девай должен уметь популярный протокол.
.
А если предложить на базе этой системы систему автоматизации здания и территории небольшого предприятия?
Понятно, что такая система должна быть платной для пользователей.
— жрёт память как каннибал
— понятие «тайминг» оооочень растяжимое
— «упадёт» от «чиха» и узнаешь об этом, когда уже котел в подвале взорвался
— много, очень много претензий к JavaScript.
Вероятно я не прав, мнение субъективно, но оно таково.
Если есть желание и возможность его оспорить — пожалуйста, я всегда готов услышать адекватное мнение.
Насчёт realtime: зачем мне дома это? А так на обычной Windows тоже нет realtime. Ну включится лампа на 100 мс позже. И что?
Память это действительно ахилесова пята. Но слава прогрессу, мини компьютеров уже достаточно с 2мя Gb и как раз на них ioBroker показывает отличную стабильность.
Но зато, как положительная черта у JS имеется огромная гибкость и разнообразие готовых модулей.
Проблема всех этих систем типа OpenHAB и IO Broker — они написаны часто людьми, которые не понимают, как писать реалтайм приложения. Например могут запросто вызвать какую-нибудь функцию динамического выделения памяти в драйвере. И в итоге 20 раз все нормально, а на 21-ый приехали — ОС решила, что надо что-то подчистить и задержала выделение памяти на 300мс. Такие вещи — зло для таймингов.
На самом деле время отклика очень важно для домашнего управления
99% отклика не дольше 50мс, если железо не тормозное.
Проблема всех этих систем типа OpenHAB и IO Broker — они написаны часто людьми, которые не понимают, как писать реалтайм приложения
У меня за плечами VxWorks (эта, та что в марсаходах), Win RTX (это Real Time eXtensions for Windows — применяется например в Software PLC), и просто разработка на микроконтроллерах — например MSP 430 или ATmega.
И я прекрасно знаю, где надо усердствовать до конца, что бы контейнер с крана тебе на голову не упал или руку не отрезало, а где 99% достаточно.
Ты, надеюсь, не собираешься станок с чпу на OpenHAB автоматизировать?
Я писал подобные системы.
Ничего ты не сможешь сделать, если сетка перегружена, эфир замусорен, источник питания слишком слаб или просто "хардварный" баг в чипе (было действительно, что marvell switch чип портил примерно каждый миллионный пакет).
И может случиться, что дверь склада весом в тонну раз в 100 закрытий со всей дури будет въезжать в стену, только потому, что какое нибудь устройство в той же самой сетке в это время с ошибочным приоритетом решит обновится по сети.
У каждого устройства возникают задержки с той или иной вероятностью!
Какая вероятность на отказ или задержку у твоих "платных систем УД"?
Дело улучшают тысячи часов тестов и такая же тысяча костылей.
Или ты полагаешь, что в "платных системах УД" нет костылей? :)
По моему субъективному мнению ОС и Real-time не совместимы, разве что RTOS.
И в конечном счёте всё упирается в приоритеты прерываний даже на микроконтроллерах.
И фаталити: не бывает 100% универсальных решений.
И в заключение:
я очень рад, что существуют проекты подобные Вашему.
Очень сожалею, что Вам приходится «выхватывать» столько минусов, но это хабр:
в этой песочнице сегодня ты царь горы, а завтра машинкой по спине выхватываешь :)
Больше чем уверен, что однажды мне понадобятся спеки протокола от какой-нибудь железки, а рабочий код будет только в Ваших open-драйверах.
OpenSource is future.
Это как, есть конструктор из которого могу собрать всё, но мне мало что нужно!
В наше время, идей и железок для «Умного дома» полно, а пользуются этим не многие. Интернет вещей как грязи, а подходит это всё не всем и не важно на каких протоколах это всё соединяется.
Хотелось бы понять мнение автора, что же реально нужно...? а потом принимать решение и делать вывод ioBroker подходит для этого или не очень.
Мне нужно что то одно, моему соседу второе, а гику третье. И это есть в ioBroker и первое (например управление с планшета в коридоре) и второе (иногда управление с телефона) и третье (управление голосом).
Мне нужны скрипты, не знающему JS — blockly, а кто то и сценами обойдётся.
ioBroker это конструктор на котором можно много что сделать.
Это же нормально, что: вот есть язык программирования и на нём можно писать что угодно и тот, кто этот язык написал, не знает — будет ли язык применяться для клепания серверов или для распознавания картинок. Задача языка подключить интерфейсы (сеть, диск, шифрование, ...), предоставить инструменты (array, sort, for), а вот задача пользователя сваять что нибудь на этом языке.
И это должен решать ты, что ты будешь ваять.
можно сходу инструкцию нагуглить по установке?
права 777 уже не нужны?
графики работают из коробки?
Node: желательно 4.x.
Npm: желательно 2.x
Права: если человек разбирается в правах, то можно запустить и с меньшими правами. Просто основная часть пользователей падает в обморок при надписи доступ запрещён и проще сказать: используйте 777
Графики работают из коробки. Вот только если нужно сохранять большое количество данных, то SQLite и JSON драйвера слабоваты. На этом месте нужно установить нормальную базу: MySQL, MS-SQL, PostgreSQL или InfluxDB. Они тоже подключаются в 3 клика.
можно сходу инструкцию нагуглить по установке?
http://www.iobroker.net/?page_id=2630&lang=ru
на счет прав — система должна их выставит, а не пользователь.
вот только чтобы взлетело пришлось нагуглить http://forum.iobroker.net/viewtopic.php?f=17&t=2526&p=22655#p22467
и да, mqtt уже соответствует rfc?
не работают графики из коробки.
Может у нас разные понятия термина "из коробки". Или я что то пропустил. Можешь линк прислать?
и да, mqtt уже соответствует rfc?
Я так понимаю, что речь идёт о LWT?
Мне везде приходится расставлять приоритеты. Эта функция не имеет для меня высшего приоритета. При 90 драйверах приходится это делать. Какое это имеет практическое применение (substitute values) в домашней автоматизации?
http://forum.iobroker.net/viewtopic.php?f=27&t=2889
про mqtt ответили выше.
Это так что ли?
http://majordomo.smartliving.ru/forum/viewtopic.php?t=1652
Ну от вас, я так и не увидел ссылки на linux.
Вот минимальная последовательность для установки (с учётом, что Apahce, PHP, MySQL, wget, phpmyadmin уже установлены и настроены):
mkdir /home/majordomo
cd /home/majordomo
wget http://majordomo.smartliving.ru/download/_majordomo_linux_100b.tar.gz
tar xvfz _majordomo_linux_100b.tar.gz
sudo cp -rp /home/majordomo/html/* /var/www
sudo cp -rp /home/majordomo/html/.htaccess /var/www
sudo chmod -R 777 /var/wwwПотом:
Заходим по адресу http://majordomo_IP/phpmyadmin (http://localhost/phpmyadmin4) Создаем базу данных db_terminal и импортируем в нее db_terminal из папки с дистрибутивом. Создаем пользователя и даем ему права на базу данных.
sudo nano /var/www/config.php
Запуск основного цикла
crontab -e -u majordomo
добавляем строки
@reboot /usr/bin/php /var/www/cycle.php
Все, теперь вы можете зайти на веб интерфейс Majordomo
http://majordomo_IP/ (http://localhost/)
Взято с офф сайта: http://majordomo.smartliving.ru/Main/SetupLinux
Ну если я не прав, то покажите же наконец, как ставить MJD из коробки...
То то я смотрю, что ник знакомый :)
Такое ощущение, что у тебя очень старый node.js.
А ты не написал, ни тип операционки, ни браузер.
Даже на русском: http://www.iobroker.net/?page_id=4268&lang=ru
>После перезагрузки в браузере наберем адрес: http://localhost:8081
>Вы должны будете увидеть окно приветствия.
Зашёл по адресу, увидел картинку, а что делать дальше? У меня есть ардуина, как её подключить и помигать светиком?
Поставил систему на Raspberry Pi 1 model B (http://www.iobroker.net/?page_id=3489&lang=ru)
Далее поставил MQTT брокер (http://www.iobroker.net/?page_id=4643&lang=ru)
Взял esp8266 + bme180 (датчик температуры + барометр), написал небольшую программку, которая отправляет данные на Raspberry
Линк на либу и пример (https://github.com/knolleary/pubsubclient)
Сейчас хочу прикрутить график по этой инструкции (http://www.iobroker.net/?page_id=4034&lang=ru)
Как-то так.
Буду рад, если смогу чем то помочь.
Зайдите на форум. Там уже есть такой топик:
http://forum.iobroker.net/viewtopic.php?f=16&t=714
Похоже этот протокол будет сильно завязан на платформу Brillo от гугл. Если это так, то «общим знаменателем» для всех новых и существующих технологий и протоколов ему не быть. Ведь кто-то захочет сервер на OpenWrt, кто-то на Windows-десктопе…
> Каждый из производителей при этом, обязательно изобретает свой велосипед протоколов взаимодействия и никто не хочет уступать другому.
А вы не смотрели на полностью открытые Alljoyn и IoTivity?
Alljoyn это линуксовый dbus, расширенный для работы в распределенных системах. А IoTivity ближе к REST-сервисам. Оба поддерживают «PlugAndPlay» устройств, рефлексию API, стандартные профили (свет, кондиционеры, етц) и всё-всё чтобы носить звание протокола IoT (в отличие от MQTT, который больше паттерн pub/sub для сырых данных)
Судя по последним новостям эти группы собираются объединить свои усилия в пользу IoTivity
Интересная наводка. Спасибо.
Протокол ещё новый (они тоже начали в летом 2014) и я не знал о нём. Ну будет ещё один драйвер. :)
Похоже этот протокол будет сильно завязан на платформу Brillo от гугл
У меня тоже такие подозрения.
Alljoyn это Qualcomm и они уже с 2011 года. Как только будут появляться приборы, надо будет подключить.
Вот ещё один "для-всего-протокол": http://www.lemonbeat.com/
Обязательно почитаю о IoTivity. Ещё раз спасибо.
Подскажите, а как вы делаете сишные биндинги (всяких modbus и прочего) к ноде? Не вызывает ли этот процесс затруднений? Я в свое время отказался от ноды, осознав что придется использовать C++ и V8 API. Перешел на чистый libuv и lua. Может зря
На линуксе не возникает никаких проблем. Там только надо написать "sudo apt-get install build-essential".
А вот с windows приходится включать бинарники в пакет.
Причём для x64/x86 и для ходовых версий ноды.
И я не делаю сам "сишные биндинги", хотя отлично знаю C/C++ (точнее "отлично" знал. Сейчас просто "знаю"), а использую готовые.
OPC, Modbus — написаны на чистом JS, а вот для S7, serial port нужны C++.
Есть идея реализовать визуализацию для пром. применения. Проверял работоспособность. При 100000 переменных и секундном обновлении начинает тормозить.
А OPC просто проверял (так сказать proof of concept). Там ещё клиента писать надо. Пока только сервер.
Я вот установил вместо OpenHAB, подключил Мегу с датчиками температуры и влажности, но а дальше то что? На сайте нет каких то значимых примеров, как и куда двигаться дальше. Описание взаимосвязей системы и пр… Есть отрывочное описание разных драйверов, но как это может помочь.
Пишут уже :) Москва не сразу строилась.
На всё нужны люди. А пока можно зайти на форум или присоединится к группе в телеграмм.
Открыл вашу ссылку по установке:
http://www.iobroker.net/?page_id=4268&lang=ru
долго-долго мотак колесиком вниз…
UPD: прошу прощения, под windows действительно, инсталлятор. Но похоже, без пхп-мскл все равно не обойтись? ЗЫ. И никаких команд в командой строке!)))
Похоже, я действительно старею)) Первый, кто сделает систему с обычным инсталлятором под windows, после которого сразу «все заработает» — тот и победит!
«Чтобы раскрыть преступление, нужно мыслить как преступник»
Я вроде инженер, вроде по АСУТП, но мне в мои неполные 30 уже как-то… Не то, чтобы тяжело, скорее — лениво во все это вникать, читать и изучать.
Ориентируйтесь, я бы сказал на «инженера-домохозяйку», эдакий микс современного инженера не-профильного-специалиста. Пингануть — ладно, согласен, посмотреть, что в логах, если нет обмена — ладно, можно.
«Вот минимальная последовательность для установки (с учётом, что Apahce, PHP, MySQL, wget, phpmyadmin уже установлены и настроены):»
Што, опять?!.. поставьте сами в инсталяторе апач, пхп, тхт, мскл, вгет, пхпмайадмин, логвьювер, службу удаленного мониторинга, сетевой протокол межшлюзового взаимодействия…
Это вам пишет человек, который хотя бы просто знает, что такое «апач» и «мускуль». Представьте, какой порог вхождения у остальных пользователей.
Да и я, собственно, дальше вот этого пакета для локального тестирования «пхп-мскл» — видите, даже забыл как он называется, — вряд ли бы пошел. А параллельно с ним вылезут траблы с кодировками, форматами, сетевыми, о, Госпади, не знаю чем.
Инсталятор в 1 ехе-файле. Это все, что нужно.
На рабочем столе несколько ярлыков — «конфигурация», «рантайм», «служебное», ну или как-то так. В меню пуск сразу побольше ярлыков на путик к логам и т.д. и т.д.
Вашей системе нужен пхп — пусть ваша система его и ставит!)
Не воспринимайте тектс как написанный «по-злому». Он наоборот из добрых побуждений.
Потенциал вашей системы действительно, хороший. Я конечно, понимаю, что любая система начинается с «мяса» и «хадкора» а потом уже приближается к обычному пользователю.
Успехов!
Дальше настал черёд Vis — установил пакет, открыл редактор — оооо, прикольно. Кнопочек много, функционал, похоже, хороший.
Но что делать дальше?!.. Как это всё работает? На какие кнопки жать, чтобы получился результат?(
Задумка и, возможно, реализация IObroker — очень даже хорошая, редактор интерфейсов, огромное количество каналов — это всё огонь.
Но… отсутствие какой-либо вменяемой исчерпывающей документации всё губит на корню((. Я не знаю что делать дальше и где искать ответы…
Как заменить стартовую страницу Vis на другую? Почему изменения на странице показываются в браузере но не показываются в мобильном приложении?..
В общем, вангую платформе иоброкер достойное место наравне ( а то и выше) OpenHab, прикольное решение, но впереди еще нужно много сделать, чтобы понизить порог вхождения до более приемлемого уровня.
Все это решается, как мне кажется, мануалами по типу quick start и в виде уроков «меняем цвет кнопки по срабатыванию датчика» или «отправляем имейл по сработке датчика» ну и всё в таком духе. Потому, что даже наличие Blocky сейчас особо не помогает — непонятно, что и как делать с системой дальше.
Домашняя автоматизация с ioBroker