Pull to refresh

Comments 32

Ситуация похожая — OpenHAB, правда, со скриптами (но там — боль! вернулся на 1.8 после 2х недель «любви» с 2.0), Node-Red пока для сбора и отправки на narodmon.ru через самопальный скрипт (есть готовый, но он по HTTP) с нескольких MQTT/Esp8266/MySensors.

За русскоязычное описание — плюсую.
За «развешивание лапши» из блоков… Даже не знаю — мне-то проще написать небольшую функцию, чем разбираться в применении десятка блоков, но это, видимо, не node-red way.

Не помешало бы _вводное_ кратенькое введение о message-oriented логике и содержимом msg, flow, scope и т.п… ИМХО.
За «развешивание лапши» из блоков… Даже не знаю — мне-то проще написать небольшую функцию, чем разбираться в применении десятка блоков, но это, видимо, не node-red way.

Ну для меня написание ручного кода — вообще no way в домашней автоматизации. Преимущество таких графических сред заключается в том, что они быстро осваиваются — гораздо быстрее, чем тот же javascript. Причем рисовать такие блок-схемы могут даже люди без программистского прошлого — по-моему, они даже быстрее осваиваются, так как у них склад ума еще не перестроился на стройный кодерский лад. Ну а таким людям, как электронщики, вообще просто — тут такая же логика.
Также важно то, что данный алгоритм у меня запущен в системе и вернусь к нему я, может быть, лет через 5, когда надо будет что-то добавить или изменить в моем УД. В этом случае мне будет важно быстро вспомнить, что собственно тут было сделано, и опять же графические блок-схемы помогают сделать это гораздо быстрее, чем исследование кода(который, как вы знаете, часто бывает spaghetti).
По поводу введения — да, наверное. Но если честно, я еще сам с данной логикой полностью не разобрался, боюсь неправильно рассказать.
я еще сам с данной логикой полностью не разобрался, боюсь неправильно рассказать.

во-во :)
Для меня, как не только человека с «программистским прошлым», но и с настоящим, как программистским, так и радио-и-пром.контроллерным ;) и то не очень понятно, как и где настраивать эти блоки. Это при более десятка крупных проектов автоматизации зданий на «типа бейсике» и нескольких на «типа блок-схемах»… Надо вчитываться и думать )))

Потому даже простое описание стандартных блоков со способами их применения — большой плюс. Например, не вполне для меня очевидные трюки с задержкой отправки сообщений (раз-в-какое-то-время) и подключение нескольких управляющих сигналов к одному входу — требуют «привыкания» и некоего перестроения мышления, что без примеров и внятного описания, порой, непросто :)

ЗЫ: огромный плюс в карму индусам, сделавшим Menta (TAC, новые продукты Schenider Electric), ощутимо более лёгкий «конструктор» для любителей блок-схем, чем CoDeSys, Step7, IsaGraf и иже с ними…
помучавшись недельку с OpenHAB 2.0 в итоге написал свой велосипед (работает на малине) — https://github.com/kdudkov/tiny-home-automation
Не помешало бы _вводное_ кратенькое введение о message-oriented логике и содержимом msg, flow, scope и т.п… ИМХО.

Да вводная собственно там простая. Весь принцип работы сводится к тому, что система через какой либо источник данных получает объект msg. Это обычный Javascript объект у которого поумолчанию есть одно поле payload — то что пришло извне.
Далее добавляя блоки и связывая их между собой мы задаем функциональность. Т.е. то, что будет происходит с этим msg. Сам payload может быть строкой, массивом или объектом, смотря через что он был получен. При необходимости в msg можно добавлять свои поля через функции
// msg.payload пришел из serial port в виде строки ">DATA:0001:01:123,456,789"
if (msg.payload.indexOf('>DATA:') === 0) {
    var data = msg.payload.split(':');
    if (data.length > 2) {
        msg.deviceID = data[1];
        msg.deviceCMD = data[2];
        if (data.length > 3) {
            msg.deviceParams = String(data[3]).split(',');
        }
    }
    console.log(msg);
}
return msg;

или же через change.
Объект можно посмотреть через обычный console.log(msg);
flow — область видимости всей вкладки. Тоже JS объект.
Ну и глобальный контект.
Пользуюсь уже очень давно, управляет системой отопления…
В вашем случае при перезапуске не будет установлен параметр flow.Light_brightness, я делаю такие настройки с помощью блока inject или с сохранением параметров в MQTT (retain сообщения)
За это мне и нравится MQTT — все сообщения от датчиков настроены как retain и мороки нет. Насчет flow.Light_Brightness вы правы. Можно добавить inject node при старте.
Если можно, запустите ваш flow по отоплению на http://flows.nodered.org/.
Просто, когда похолодает, мне тоже придется делать контроллер отопления на Node-RED и было бы неплохо посмотреть на Ваши наработки.
Постить не буду, это для себя и в вечном процессе доработки… ну и объяснять там много придется.
В основном это система контроля, используется OpenTherm gateway, на батареях стоят электронные термоголовки с термостатами, датчиками открывания окон и кубом, их мониторинг с помощью Ардуины
Т.е. в основном контроль, но добавил управление горячей водой по расписанию, регулировку температуры котла (у меня нельзя управлять термостатом), мониторинг электрической сети с помощью NUT, сбор статистики в emoncms и т.п.
Сделан watchdog для датчиков, т.е. при отсутствии сообщений либо извещение, либо «эмуляция», сейчас делаю управление по СМС и Telegram…
Из железа в планах реализовать термостат, переведя OpenTherm gateway в интерфейсный режим, заменить eQ3 Cube на что-то свое, сделать управление насосами и клапанами, а также панель управления на планшете и телефоне с помощью node-red-dashboard или node-red-vis
Если есть вопросы, спрашивайте, готов поделиться
Панель управления на планшете у меня уже есть. Работает на MQTT, кстати, тоже. Следующая статья будет о ней.
датчики соединены с сервером по проводам?
По проводам — это не удобно. esp8266 <-mqtt-> Node-RED
У меня вообще все на Z-Wave сделано. Но в случае с NodeRed не важно, как подключены датчики. Главное, чтобы в конце концов все коммуникации с ними сводились к MQTT протоколу. Это легко сделать, используя любой софт для умного дома — OpenHAB, MajorDomo, ioBroker, наверное тоже. Вы просто используете тот софт, в котором лучше сделаны драйвера для нужной вам системы связи с датчиками.
А что в качестве z-wave контроллера используете?
Aeon Z-Wave Stick 5 gen + OpenHAB на RPi2.
На openzwave? Я долго ел этот кактус, в итоге вернулся к z-way, благо у меня RaZberry. Они недавно запилили плагин, позволяющий общаться с их стеком через MQTT и стало все совсем хорошо.
Честно говоря, я не знаю, на чем крутится Z-wave в OpenHAB, да и в принципе мне все равно. Будет доставлять проблемы, перелезу на что-то другое. А пока он работает нормально — у меня всего около 20 модулей в сети.
очень интересно как организовывается питание у модулей. каждый в разетку через блок питания?
Спасибо. От предрассудков я не отказался, но мне надо было на чем-то остановиться для реализации сценариев. Решил пока на Node-RED, пока не найду что-то лучшее.
Отличная статья, спасибо!
Хочу только заметить, что топик совершенно не обязательно начинать со слеша.
А есть возможность сделать так, чтобы свет включался плавно?

На работе на лестнице светодиодные лампы с датчиком движения. И когда резко включается в темноте — сильно бьёт по глазам.
Это зависит от того, чем управляются светильники. У меня диммер, и в нем запрограммировано плавное включение. Или не проблема сделать так, чтобы выдавалась рампа из нескольких сообщений с увеличивающайся яркостью. Но как у вас сделано, не знаю.
Разумеется я не про наш, а про ваш случай.

Можно ли с помощью Node-Red, управляющего диммером, реализовать плавное включение светильника? В случае, если в самом диммере отсутствует такая функция.
Я тоже использую NR в своем умном доме, но у меня осталось двоякое впечатление. Во-первых, совсем без программирования обойти не получается. Например, достаточно простой алгоритм включение и выключение света в аквариуме требует подготовки сообщения для z-wave контроллера. Во-вторых, как-раз переносить проект в NR не очень удобно. У меня был опыт переноса действующего проекта с одного сервера на другой — выделять все элементы и копировать их, не очень удобно. Наверное, проще было бы перенести файл проекта. Далее нужно заново устанавливать все узлы — нет файла с зависимостями, чтобы можно было сказать install и все установить. После переноса необходимо прописать в разных местах логины и пароли, что вообще, как мне кажется очень не удобно — не помнишь, где что менять и не понимаешь, почему что-то не работает. Узлы, которые нужно настраивать оказываются разбросанными по разным flow и sub-flow. В третьих, когда проект разрастается и количество flow и sub-flow становится значительным, то навигация по ним не очень удобна. Ну и наконец, обработка ошибок. То, как это реализовано мне очень не нравится. Когда хочешь не просто сделать простую связь, а добавить обработку ошибок, то диаграммы становятся уже запутанными и совсем не такими красивыми.

Вот так например выглядит отправка команд в z-wave


У меня складывается впечатление, что пока Node Red — это лабораторная экспериментальная среда, (еще) не платформа для сложных коммерческих проектов.

Я думаю это потому, что Вы используете Node-Red немного не так, как предлагаю использовать его я. У вас в Node-Red выполняется связь с внешими устройствами, например z-wave. В моей же философии умного дома я считаю, что эти вещи лучше оставить другим, более подходящим приложениям-конвертерам протоколов. А Node-Red должен использоваться только для реализации управляющих алгоритмов со связью с конвертером через один простой протокол — в данном случае MQTT. В итоге подготавливать сообщения не нужно и все проблемы с третими протоколами отлавливать в NR не нужно. Также если у вас возникнут проблемы с каким либо протоколом — например Z-Wave, то нужно просто сменить программу-конвертер или драйвер в ней. В Node-Red это будет сложнее.
MQTT — вещь интересная, но пока далеко не всем оборудованием она поддерживается. Например, мой контроллер z-wave пока не поддерживает MQTT. Тоже самое с готовыми узлами (с этим возможно проще — можно написать свой узел). Например, отправление уведомление в Телеграмм или на почту.
С контроллерами дело потихоньку исправляется Вот, например модуль для z-way.
Отправка уведомления из MQTT куда угодно (Телеграм, слэк, фейсбук, почта...) с помощью node-red делается в 5 кликов мышью.
У меня z-wave — это маленькая часть умного дома. Он используется только для тех мест, куда не проведены провода. )

я отправляю сообщения из NR, не из контроллера. Мне кажется, это более правильным.
> У меня складывается впечатление… (еще) не

Почему еще? Всегда. Node-Red — достойный продолжатель популярного в 40-е/50-е годы прошлого века метода программирования с помощью блок-схем (flowcharts). Процент написанного (и поодерживаемого!) с помощью блок-схем программного обеспечения хорошо показывает, насколько они хороши для этой цели. Очень (?) полезны для простых демо и обучения. Ну и для PR'а картинки хороши, что очень метко подмечено в статье ("… приложений и продуктов с целью популяризировать свои платные платформы. Например, в IBM платной платформой является Bluemix.")
Вы удивитесь, сколько современного промышленного, автомобильного, авиакосмического и прочего управляющего софта сделано на блок-схемах. Это направление вообще-то развивается сейчас.
Sign up to leave a comment.

Articles

Change theme settings