Сегодня я решился вынести на суд общественности проект, работу над которым вел на протяжении последней пары лет: «LightHub». То, что получилось в итоге, можно назвать, пожалуй, самым дешевым решением для создания Умного дома, которое, тем не менее, умеет:- Управлять освещением и силовыми устройствами(Реле, диммеры DMX-512 и Modbus RTU)
- Управлять теплыми полами (в качестве термодатчиков используются полтора десятка дешевых DS18B20, разведенных по квартире)
- Управлять задвижками вентиляции/кондиционера
- Управлять самодельной системой приточной вентиляции.
- Многое такого, о чем я изначально не задумывался, просто в силу того, что контроллер получился абсолютно открытым, гибко конфигурируемым, и прекрасно дополняющим Опенсорсные решения Openhab+Mosquitto+NodeRed
На вход контроллера подключаются обычные выключатели, кнопки, контактные датчики, датчики протечки и пр. которые могут управлять как локальными нагрузками так и устройствами, подключенными к другим таким же контроллерам или ко всему, что понимает протокол MQTT. У меня, например, подключен геркон, установленный в коробке входной двери. Когда закрываю замок на три оборота — выключаются свет, теплые полы, бойлеры, AV ресивер. Когда возвращаюсь — состояние этих приборов восстанавливается как было до ухода.
На выход — например, такие вот релейные модули, DMX, Modbus переферия.
Контроллеры конфигурируются при помощи JSON файлов, которые при старте контроллера загружаются по http (далее, конфиг можно сохранить в NVRAM через Serial CLI). Ну и, конечно, все это управляется системой Openhab 2, через штатное мобильное приложение.
Задачи «малой автоматизации» решены как при помощи штатных openhab rules (не очень удобных), так и при помощи NodeRed. (По поводу NodeRed вот статья, которая прекрасно описывает пример автоматизации.)
Исходники, вместе с примерами конфигов, выложены на GIThub, описание понемногу выкладываю на сайте проекта. Соответственно, более полная история под катом.
Началось все с ремонта в квартире, в процессе которого я решил сделать дом прилично умнее.
При этом, тратить серьезные деньги на «Брендовое» решение Умного Дома, откровенно, не хотелось. Тем более, что многие «Серьезные» решения использовали закрытые стандарты и интегрировались друг с другом при помощи откровенных костылей.
Соответственно, я поставил перед собой задачу собрать Умный Дом из максимально готовых и недорогих компонент.
В качестве Hardware для контроллера я выбрал Arduino Mega 2560+Ethernet shield.
Копеечная цена, огромное кол-во портов ввода вывода, 4 аппаратных UART, приличный размер NVRAM, который мне пока удалось только на 30% занять прошивкой и в который умещается с запасом весь конфиг, причем, прямо в формате JSON подтвердили разумность выбора.
После обновления Bootloader, и корректировки библиотеки Ethernet удалось успешно задействовать аппаратный Watchdog процессора, что добавило решению «промышленности» а мне спокойствия, хотя, прошивка и без этого не была замечена в зависании.
Отсутствие на контроллере какой либо операционной системы позволяет считать его «системой реального времени», что позволяет, например, программно генерировать тот же сигнал DMX.
Узкое место — размер RAM. И это не позволяет использовать всю необъятную переферию контроллера. Хотя, более 30-ти разнообразных каналов (items, в терминах конфига) в память вполне умещаются. А подключить столько, сколько позволяет плата Arduino Mega — задача, все же, не имеющая отношение к реальности.
Также, масштабируемость достигается увеличением числа устройств. У меня, например, задействованы два контроллера. Они разнесены по квартире (это, также, позволяет не тянуть все провода в одну точку). Для взаимодействия друг с другом, а также, с системами Openhab и NodeRed используется MQTT брокер Mosquitto.
В качестве драйвера шины 1-wire я использовал чип (I2C драйвер) ds2482-100 с Aliexpress, который при цене в 60 руб обеспечивает устойчивую работу с шиной до 100М.
Для гибкого конфигурирования устройства я доработал библиотеку AJSON для Arduino, таким образом, что она имеет возможность как загружать объект по http так читать и записывать объект из/в NVRAM контроллера. Форк доступен на Github.
Serial CLI при создании нового контроллера надо прописать в NVRAM уникальный MAC адрес. Именно MAC является ключом, по которому изначально загружается конфигурация c http сервера.
В качестве управляющего ПО я взял Openhab 2, имеющий весь нужный мне функционал, плюс, мобильное приложение, плюс «Облако» — роль которого, правда, только в том, чтобы предоставлять доступ к домашней инфраструктуре извне, не прокидывая портов на роутере и не обладая фиксированным IP. Также, Openhab имеет интеграцию с HomeKit от Apple, что позволяет управлять устройствами дома с iPhone, вообще без установки аппликации. (Возможность интересная, но пользуюсь, в основном, «родным» приложением).
Наличие в проекте квартиры большого кол-ва светодиодного освещения, также, требовало какого-то разумного управления.
Подумав, я заказал на АliExpress пару плат, каждая из которых может управлять 30-ю каналами LED с номинальным током до 2А на канал.
Для того, чтобы увеличить максимальную мощность одного канала, я перешел со светодиодных лент на 12В на 24В ленты. При этом, полноценно осветить комнату около 16-18 кв. м оказалось возможным при помощи 4-х ключей. БОльшие по площади помещения пришлось зонировать — в гостиной подключил независимо 4 ленты по 5 м, задействовав при это 16 каналов.
Для синхронного управления всей комнатой, пришлось придумать тип канала «группа»
Вот как выглядит описание гостиной в JSON конфиге:
"kuh":[7,["kuhline","kuhfre","kuhwork","kuhwin"]],
"kuhwin":[1,5],
"kuhline":[1,13],
"kuhfre":[1,25],
"kuhwork":[1,1],
Первый элемент массива — тип канала, второй — параметр канала, который может являться массивом.
Для элемента типа 7 (группа) — аргументом является массив элементов, входящих в группу.
Рекурсия, конечно же, поддерживается.
Для элемента типа 1 (лента RGBW) — аргумент — базовый DMX адрес канала.
Со стандартной библиотекой EasyDMX платы не заработали сразу. Как оказалось, китайский LED контроллер не переваривал 2ms задержку между фреймами DMX (interframe delay). Несложная модификация кода библиотеки (сокращение цикла в два раза) помогла.
Форк библиотеки на GitHub-е
Обычное AC 220В освещение у меня получилось управлять китайскими диммерами с Aliexpress, имеющими поддержку Modbus RTU (стандартный промышленный протокол управления поверх RS-485). Эти диммеры прекрасно управляются локально (выключателями без фиксации), в то же время, контроллер имеет возможность считывать яркость и управлять ими по шине Modbus (реализовано пока для двухканального устройства).
На момент публикации статьи, диммеры пропали с Алиэкспресса, но я нашел китайского производителя по лейблу на печатной плате устройства. Привожу ссылку на их аскетичный сайт. На вопросы по e-mail отвечают охотно, прислали даже куцую документацию.
Еще вариант управления 220В освещения — использовать DMX-512 AC диммер. На e-bay таких в ассортименте, любого формфактора — плата или на DIN рейку. От одного до восьми каналов.
Я, в начале, поостерегся этого варианта, так как контроллер был еще в очень эксперементальном виде и, для надежности, хотелось сохранить автономное локальное управление. Но сейчас бы уже использовал такой вариант.
Далее — я установил канальный кондиционер, который в состоянии как нагреть так и охладить всю квартиру. Чтобы как-то распределять холод и тепло по спальням, я установил сервоприводы с управлением сигналом 0-10В. Угол открытия задвижек регулируется автоматически при помощи NodeRed, в котором для этого нашелся удобный PID регулятор.
К сожалению, на Aliexpress этих устройств уже не вижу, но на e-bay — пожалуйста
Преобразователи великолепно заработали сразу, пришлось только перепрограммировать таймер ШИМ выходов для того, чтобы задать подходящую частоту.
Ниже пример перепрограммирования таймеров 3 и 4 (отвечают за pin-ы 2, 3, 5, 6, 7, 8 Arduino Mega на частоту 4000Гц).
pinMode(iaddr,OUTPUT);
//timer 0 for pin 13 and 4
//timer 1 for pin 12 and 11
//timer 2 for pin 10 and 9
//timer 3 for pin 5 and 3 and 2
//timer 4 for pin 8 and 7 and 6
int tval = 7; // 111 in binary - used as an eraser
TCCR4B &= ~tval; // set the three bits in TCCR2B to 0
TCCR3B &= ~tval;
tval=2; //prescaler = 2 ---> PWM frequency is 4000 Hz
TCCR4B|=tval;
TCCR3B|=tval;
analogWrite(iaddr,k=map(Value,0,100,0,255));
Далее, я начал искать WiFi контроллеры теплых полов. Нашел, в целом, неплохое устройство стоимостью около 6 тыс руб от Теплолюкс, но оно имело некоторые существенные для меня недостатки.
Несмотря на наличие мобильного приложения, протокол управления был закрыт. Я провел некоторый реверс-инженеринг, который показал, что, теоретически, протокол можно расшифровать. Возможно, я бы этим и занялся, но обнаружил, что без переустановки подразетников сие устройство не устанавливается в один ряд с выключателями. Это определило судьбу устройства: продав его, я реализовал функционал простого термостата на своем контроллере, сэкономив почти 30 тыс руб на 5-ти теплых полах.
- Все управление — локально на контроллере и независимо от домашней ИТ инфраструктуры
- Используются измерения с 1-wire термодатчиков. Если датчик долгое время не может быть опрошен — нагреватель отключается.
- Через MQTT можно включить/выключить теплый пол и задать его температуру. Соответственно, полы управляемы через интерфейсы и мобильное приложение Openhab
- Я не стал реализовывать хитрые сценарии и расписания на контроллере. При желании, это легко реализуется правилами Openhab или Node-Red. Я ограничился только отключением устройств, когда люди покидают дом.
Вот пример конфига для одного теплого пола:
"ow":{
"2807FFD503000036":{"emit":"t_bath1","item":"h_bath1"}
},
"items":{
"h_bath1":[5,24,33],
},
Данные при опросе термометра OneWire с указанным адресом передаются на шину MQTT в топик t_bath1, а также, внутри контроллера, объекту h_bath, имеющему тип №5 (термостат), реле подключено к pin#24 контроллера, уставка — 33 градуса (можно корректировать по MQTT)
Входы устройства
В конфиге для каждого входа можно задать как передачу команды локальному объекту так и выдачу команды в MQTT топик. Причем, отдельно как на условное «нажатие» кнопки так и на «отпускание».
"in":{
"41":{"emit":"/myhome/in/all","scmd":"HALT","rcmd":"REST"},
"38":{"item":"spots_en"},
"37":{"emit":"/myhome/in/light","scmd":"ON","rcmd":"OFF"},
"40":{"emit":"/myhome/in/gstall","scmd":"TOGGLE","rcmd":"TOGGLE"},
"35":{"emit":"/myhome/s_out/water_leak"}
}
Pin 41: Геркон на замке входной двери — при запирании — выдаем в топик /myhome/in/all команду HALT, при отпирании — команду REST.
У меня это приводит к полному «засыпанию» и «просыпанию» дома. К слову — команды не входят в стандартный набор OpenHab, но получились крайне удобны — HALT — выключает устройство, REST — восстанавливает параметры устройства до последнего значения (цвет, яркость, температура), но только для того устройства, которое было выключено командой HALT а не OFF. Это позволяет не включать то, что было выключено на момент покидания дома.
Pin 38: Просто обычный выключатель света. При замыкании — выдает (по умолчанию) команду ON, при размыкании — команду OFF. Эти значения передаются объекту «spots_en». Понятно, что состояние обьекта можно изменить с мобильного приложения. В этом случае, выключатель, как бы, остается, например, во включенном положении, но свет выключен.
Для любителей классических проходных выключателей, подойдет синтаксис Pin 40: И при включении и при выключении выдается команда TOGGLE (тоже, кстати, новая, относительно OpenHab), меняющая положение Вкл-Выкл устройства (в данном примере, лампа управляется не локально, а через MQTT другим контроллером).
Если это не перекидной выключатель а кнопка — достаточно просто скорректировать «rcmd»:"" — при этом команда на переключение будет выдаваться только при нажатии.
А, ну и почти забыл описать DMX-IN — вход, ради которого, можно сказать, я и начинал эту разработку.
На рынке масса удачных с дизайнерской точки зрения и, в целом, эргономичных DMX контроллеров светодиодных лент.
Один из таких (сенсорную панель) я и купил в самом начале для экспериментов с DMX. Все хорошо, но архитектура DMX не предусматривает никакого управления из более чем одного места. Существует один Мастер, который постоянно транслирует в шину яркости каналов. Но в этом проекте данная проблема решена. Контроллер LightHub отслеживает изменения каналов DMX на входе, подключенном к сенсорной панели. Если они изменяются — транслирует изменения на выход (с маппингом на сконфигурированные устройства, в том числе, на группы светодиодных лент).
Пока ничего не меняется — устройства нормально управляются удаленно. Стоит сенсорной панели поменять значения яркости каналов — эти изменения транслируются на DMX выходы.
Как не странно, этот костыль получился вполне эргономичным. Хотя, как показал опыт, мы все реже используем сенсорную панель и все чаще смартфоны для управления устройствами.
Заключение
К сожалению, в одной статье невозможно описать все нюансы, заложенные в разработку.
Например, совсем за кадром осталась тема подключения Modbus устройств, их пуллинг и синхронизация локального состояния устройства с системой Умного Дома, интеграция с простой приточной установкой. Ну и, возможно, сравнение с существующими системами близких классов, такими, например, как MegaD-328, AMS и, даже, WirenBoard. Возможно, если будет заинтересованность — продолжу.
Также, пока за кадром то, что с использованием NodeRed удалось проинтегрировать систему с Telegram. Пока работает для получения оповещений, но можно создать полноценный Bot.
Относительно проекта LightHub — при всей дешевизне, контроллеры оказались вполне рабочим решением. Честно говоря, я сам не верил, что на основе Arduino можно создать стабильно работающую систему, но, по-моему, это удалось.
Конечно, надо многое еще доделать: полностью уйти от хардкода (осталось совсем чуть-чуть), немного и местами почистить и рефакторить код, тщательно документировать проект, развести печатную плату (сейчас интерфейсные Шилды спаяны просто на основе макетных плат и содержат три MAX-485 — (DMX-IN, DMX-OUT, Modbus) и 1-Wire мост) — и это станет, по сути, очень бюджетным готовым решением.
Warning: Напоминаю, что проект пока на уровне макетных плат. Открывая следующий спойлер, вы можете нанести урон своим эстетическим чувствам.
Первый контроллер, управляющий LED (60 каналов DMX-512), Modbus (диммеры, приточка), заслонки ветиляции;
Это DMX-512 декодер, который удобно размещать там, где светодиодные ленты приходят к трансформаторам. У меня — под фальшпотолком в кладовке.
А это-второй контроллер, обслуживающий 1-wire, выключатели/датчики и релейный модуль. (Сам релейный модуль разместился прямо в распаечной коробке, где ему и место вместе с тремя фазами. Соседство 380В и слаботочки я искоренил везде, где возможно, после одного неудачного происшествия)
Понятно, что надо расширять функционал. Как минимум, в направлении беспроводных датчиков/устройств. (Хотя, например, ZWave и так сейчас можно использовать через стандартные биндинги Openhab).
Возможность подключения, например, бюджетного NooLight, вероятно, неплохая идея. Возможно, подумаю над миграцией на ESP-8266 для расширения RAM, хотя, уход на WiFi с проводного подключения к LAN мне не нравится с точки зрения надежности. Да и ESP не обладает такой богатой переферией как Arduino Mega. Еще планирую сделать учет электроэнергии через датчики тока и подключение Rotary Encoder на вход.
Также, полезно было бы сделать конфигурирование и запуск контроллера более User Friendly (визуальные конфигураторы и пр.). При этом, сознательно не хочется превращать контроллер в вебсервер с файлами/картинками, AJAX и пр. На мой взгляд, это уже должно являться прерогативой сервера. Хотя бы на основе Raspberry.
Но поскольку проект абсолютно Опенсорсный — возможны разные варианты, присоединяйтесь.
Также, с нетерпением ожидаю ваших отзывов.
Комментарии (65)
ExecuterP
06.11.2017 01:26Скажите, есть ли бд в системе для логгирования (показания датчиков, комманды, не суть важно) нет ли доступа к логам извне? Пытаюсь понять ввша система именно то ли что я ищу по функционалу?
anklimov Автор
06.11.2017 01:38Тут я описываю контроллер, который, сам по себе, никакого доступа к БД не имеет. И не должен иметь. Его задача — получать команды по шине, включать-выключать устройства, а также, передавать на шину значения сенсоров. А вот ПО более высокого уровня — Openhab — получает эти данные с шины и может записывать их в БД. В моем случае Openhab пишет температуры в базу формата RRD4J для построения графиков. В поставке Openhab есть возможность подключить, практически, любую БД. См. документацию
NodeRed тоже имеет компоненты для интеграции с БДExecuterP
06.11.2017 01:46Большое спасибо, значит почитаю про Openhab, хочется найти готовое решение без велосипедов. Изначально вопрос тут задавал: toster.ru/q/474369, если вычитаю что интересное добавлю туда ссылочку на Вас.
Estranged01
06.11.2017 15:35Лучше всего, ИМХО, в OpenHab для логгирования и построения графиков использовать influxdb+grafana. community.openhab.org/t/influxdb-grafana-persistence-and-graphing/13761
anklimov Автор
06.11.2017 17:33Действительно, графики посимпатичнее чем родные Openhab-овские.
Но так как в мобильное приложение графики из Grafana, судя по всему, передаются через Webview — для доступа извне локальной сети, похоже, потребуется вывешивать Grafan-у во внешний мир.
Сейчас для доступа из внешнего мира с мобильных приложений я использую Openhab Cloud Connector. Он сам вытягивает все данные и графики во внешний мир.Estranged01
07.11.2017 01:58У меня что-то так и не получилось передать графики в мобильное приложение. Только в браузерный интерфейс Openhab. Передается как image с заданным интервалом обновления. Один image — один график, а у меня их несколько. Поэтому проще зайти браузером на графану, где все графики показаны на одном дашборде. Ну и у меня, честно говоря, нет необходимости смотреть их из внешнего мира, поэтому порт не прокидывал.
Это дашборд из самой графаны.anklimov Автор
07.11.2017 12:38Графики красивые. Но проблема с доступом из единого приложения, особенно, извне, конечно, убивает. В мобильном приложении графики — штука достаточно информативная. Позволяет одним взглядом издалека оценить, что происходит дома. Возможно, выход в дублировании графиков — для приложения — родные Опенхабовские, дополнительно, поднять Grafan-у
Estranged01
07.11.2017 12:46Я не исключаю, что это мои кривые руки не могут настроить передачу графиков в приложение.
vp7
06.11.2017 02:27Возможно, подумаю над миграцией на ESP-8266 для расширения RAM
Свечку не держал, но по слухам у ESP'хи сложности с real time'ом (необходимым для DMX). Плюс — мало GPIO портов. И самое главное — WiFi полезен, очень полезен, но лишать контроллер Ethernet порта было бы, imho, ошибкой.
Самое очевидное — оставить ATMega для работы с периферией и Ethernet'ом, а ESP использовать как шлюз в WiFi и при необходимости вынести на неё часть бизнес-логики.anklimov Автор
06.11.2017 03:10В принципе, вижу, что есть библиотеки для DMX-512 под ESP. Так что портировать вполне получится. GPIO портов у ESP, действительно, мало, но зато этих копеечных штук можно поставить много. В каждом углу. Или подразетниках даже. И прилично сэкономить на проводах. Для критических цепей (нагрев, например) я бы все равно оставил проводное подключение к LAN+ATMega, так как ESP у меня, периодически, все же от сети отваливается.
А для управления светом (DMX, пара реле, пара выключателей) WiFi+ESP вполне сгодится.
Пожалуй, попробую все же портировать, хотя-бы частично, как время появится.
Делать гибрид ESP+ATMega, все же, достаточно трудозатратно.dernuss
06.11.2017 16:38Esp32 ?
anklimov Автор
06.11.2017 17:48Неплохой вариант. А если в виде такой вот платы — то вообще, идеальный. Надо только разобраться как там реализован проводной LAN. Пожалуй, закажу.
anklimov Автор
06.11.2017 18:42Update — ценник, если заказывать на www.olimex.com:
Item Quantity Price Value
1 ESP32-EVB 1 pcs 26.0000 EUR 26.00 EUR
2 EMS ZONE4 29.00 EUR
3 EXTRA PayPal 2.75 EUR
4 VAT 0.00
Total: EUR57.75EUR
Доставка EMS-ом получается даже дороже платы. Еще и комиссию PayPal в счет включают. А братья-китайцы пока не клонировали. Но все впереди. Аналоги появятся и очень скоро.
Плюс, olimex не дает гарантий от повреждений или потери перевозчиком.
Nikolay_Ch
06.11.2017 23:05Я бы в подрозетник не советовал… Во-первых — ESP'шки греются они сильно, а во-вторых = туда придется засовывать и БП, а найти таковой готовый с защитой по КЗ, току и температуре будет проблематично.
Лично у меня одна платка 8266 задымилась при питании от БП с USB-выходом.anklimov Автор
06.11.2017 23:48Собственно, поэтому я не тороплюсь с диммером. Хотя мне проще, по нужным подрозетникам разведен кабель CAT5, у которого одна из пар — 12В. (другие три — как раз 1-wire, DMX и Modbus) Поэтому задача Блока Питания решается простым DC-DC преобразователем на 3,3 В. Есть, конечно, сетевые блоки питания на 3,3 В но рука не поднимается запихивать их в подрозетник вместе с ESP. Но пока не подключал диммер к этому кабелю. Есть подозрение, что DC-DC будет наводить сильную помеху на соседние пары. Вообщем, тут еще простор для экспериментов.
Nikolay_Ch
07.11.2017 00:58Ну… Я бы передавал по кабелю все-таки не 12, а 48 вольт, по стандарту PoE, т.к. даже при 10 метрах кабеля на приемнике будет уже не 12 — все таки сопротивление на 0,2 квадратах будет великовато…
Такой вариант а тоже рассматривал, но… в частном доме провод может быть и длинее 10-ти метров, и при грозе там может появиться нехилый потенциал. Так что преобразователь я бы тоже искал с тройной защитой по току, КЗ и температуре с самовосстанавливающимся предохранителем. Буду благодарен, если подскажете модельку, которая залезет в подрозетник вместе с ESP'шкой.anklimov Автор
07.11.2017 01:13Согласен, что 12В маловато. Уже планировал перейти, как минимум, на 24В.
Надо только убедиться что диммеры, которые питаются от этой же шины, выдержат.
Вот такой DC-DC преобразователь у меня влезал в штатный диммер вместе с ESP. Минус в том, что регулируемый и можно его нечаяно перерегулировать. Ну и, конечно, суперзащит там нет. Но ESP от него работала вполне нормально.Nikolay_Ch
07.11.2017 01:28Если дом деревянный, без защит пихать что-то в подрозетник стремно… Да и все защиты реализовать не так сложно. Было бы образование, сделал бы блочек универсальный, типа такого, как здесь. Там от 220 питают (что еще удобнее), правда, к сожалению, не ESP'шку.
anklimov Автор
07.11.2017 01:45Да, с деревянным домом я бы тоже не стал экспериментировать. По крайней мере, с 220В. Только с низковольтным питанием. Тогда вероятность пожара, как мне кажется, примерно равна нулю, так как снять с провода, сечением 0,2 на 24В мощность, требуемую для возгорания, скорее всего, не получится. Предохранитель, например, на 1А лучше поставить прямо на выходе БП, чтобы избежать перегрева тонкого провода в случае КЗ. С номиналом предохранителя и нагревом лучше поэкспериментировать с мощным БП, амперметром и бухтой кабеля.
Nikolay_Ch
07.11.2017 02:32Ну не знаю, не знаю… мы в детстве и от 9 вольт делали возгорание серы :)
В общем — мое образование не электрическое и не радиоэлектронное, я бы купил проверенный девайс, а сам паять не хочу.
fotofan
07.11.2017 16:07+1Вот проверенное решение с достаточным уровнем защит
Nikolay_Ch
08.11.2017 23:07Спасибо, я такие рассматривал уже. Вот только в даташите к нему не указана типовая схема подключения и я не понимаю, нужна ли обвязка ему или нет? А если нужна, то какая?
fotofan
09.11.2017 14:11Обвязка не нужна. Можно напрямую питать МК. По моим наблюдениям, напряжение менвелы держат стабильно. Сам делаю сигнализацию на таком
vconst
07.11.2017 11:59Похоже вы не то искали. Сделать самому диммер на ардуино у меня руки так и не дошли, купил готовый.
Фишка в том, что управляет светом отдельный контроллер, а панель с энкодером на стену и кнопочный пульт — дистанционные и на батарейках. Они только передают сигналы по радиоканалу, а контроллер в глубине шкафа — подключен к 24 вольтам от отдельного блока питания, уже управляет лентами. В этом случае от контроллера не требуется особой компактности, не требуется питать его от 220, а управляющим устройствам нет необходимости пускать через себя большой ток.
Удовольствие это не из дешевых, если брать готовые решения. Но если делать такое самому на ардуинобразных компонентах — то не особо сложно и не очень дорого, если есть опыт.anklimov Автор
07.11.2017 17:44Да, готовые устройства видел. Тут проблема даже не только в том, что они дороговаты, а в том, что часто это «вещь в себе», которая сама управляет, но не позволяет управлять извне. Если, конечно, тут описан не ZWave, например, вариант. Также, бюджетными Noolight-ами, вроде бы, научились управлять. Но там другие проблемы — отсутствие обратной связи. Ну и там диммер с кнопками а не с ручкой. Хотелось именно с Rotary Encoder
Именно поэтому сделал свой прототип, по которому, думаю, напишу отдельную статью. Может кто доведет до ума.
А с идеей, что лучше разделить это устройство с силовыми цепями согласен.vconst
07.11.2017 17:55Ноолайт — они только на 220? Полазил по их сайту и не нашел ничего на слаботочку. А хочется то 24 вольта.
Плюс, как мне показалось, у народа были претензии на тему, что все слишком компактно и электроопасно, может перегреться и тп. А если разделить беспроводной контроллер и беспроводные управляющие устройства — то можно решить проблему работы с 220 вольт, не перекладывая их на устройства управления.
deNULL
08.11.2017 00:57Напишите, будет интересно почитать! Тоже давно собирался собрать диммер на базе ATmega8 с энкодером и управлением по Modbus, но пока руки дошли только до реализации протокола на нём, непосредственно диммирование ещё предстоит сделать.
pistoletov
06.11.2017 09:15Респект! Хороший проект!!! Я тоже думал делать на esp потом вернулся в ардуинку. Сейчас изучаю фреймворк souliss. Из фишечек хочу сделать панель управления в подрозетник с красивым oled экраном и управлением энкодером. Главный сервер cubieboard с опенхабом для умного дома и logitech media server для музыки (динамики в потолке по квартире)
anklimov Автор
06.11.2017 12:10Спасибо! Два года назад я начал именно с souliss. Именно тогда, соорудил диммер, управляемый энкодером, первая версия которого работала (пыталась) именно на этом фреймворке. Но в то время фреймворк был еще слегка сыроват. Поняв, что мне достаточно только механизма Publish/Subscribe я перешел на MQTT. Единственное, чем пришлось пожертвовать — возможностью автономной работы устройств без брокера. Но, учитывая то, что брокер можно поднять и на роутере (не поднимал, так как есть полноценный сервер, но в openwrt/ddwrt Mosquitto видел) — потеря не сильно большая. Я все еще подписан на souliss, вижу, что проект активно развивается, но портировать назад пока подожду. Тем более, что сейчас скрестить Lighthub и Souliss будет непросто — я пошел не по пути фреймворка а по пути универсального конфигурируемого устройства, которое с одной и той же прошивкой делает разное, в зависимости от конфига. А у Souliss предполагается, что для разных применений делаются разные скетчи, компилируются, загружаются в устройства.
Тему диммера на ESP пока год как забросил, хотя, вполне работающий прототип есть. Он отлично регулирует как локальную нагрузку AC 220В, так и удаленную RGB ленту (цвет, яркость, насыщенность) через MQTT. Ну и локальная нагрузка тоже управляется по MQTT. В принципе, могу выложить на Github для развития.anklimov Автор
07.11.2017 20:36… выложил
https://github.com/anklimov/rotary_mqtt_dimmer
В принципе, это тема отдельной статьи. Надеюсь, руки дойдут довести до ума.
seri0shka
06.11.2017 15:37А где же технопорно? Сколько лет увлекаюсь электроникой, а не перестаю ощущать лёгкий экстаз при виде качественно изготовленного изделия. Фото в студию!
anklimov Автор
07.11.2017 00:22Не хотел я этого делать. Честно писал, что интерфейсный шилд пока спаян на макетках. Поэтому эстетического экстаза не обещаю. Немножко хардкорное технопорно получилось.
Просьба не троллить и не минусовать.
Добавил в текст статьи.
Пара фоток покрупнее тут.
На шилде первого контроллера DC-DC преобразователь для питания, три штуки max-485 и 1-wire мост (сейчас не используется, так как 1-wire отдал второму контроллеру).
ESP нужна только для удаленного перепрограммирования AVR-ки.
В «целевом» дизайне на шилд надо будет добавить пачку опторазвязок. Пока, сорри, без них.
dbrr
06.11.2017 17:48У меня под рукой полностью готовая система orange pi + home assistant + modbus. Сейчас жду печатные платы для rs485 адаптера. По готовности изложу на пару статей.
nick32
06.11.2017 23:05+1Мне кажется, если мигрировать — то сразу на stm32f4xx, или даже f7xx. Там и аппаратный Ethernet, и Can, и USB, и порядка полутора сотен GPIO, и даже АППАРАТНОЕ ШИФРОВАНИЕ. RAM — до 2 МБ, и вообще, AVR несколько устарел, а Arduino — просто не серьезно. К тому же, из-за ARM ядра, проект на stm32 легче будет перенести на более мощный контроллер при небходимости, чем проект на AVR.
anklimov Автор
06.11.2017 23:19Дело в том, что даже ESP8266 по ресурсам (не считая периферии) избыточна для этой штуки. Делать какие-то сложные алгоритмы, непосредственно, на контроллере ИМХО смысла не имеет — для этого есть системы более высокого уровня.
Ардуино — прежде всего, это огромное кол-во уже написанных библиотек и огромное сообщество. Конечно, можно нужные из них портировать на stm, но трудозатраты велики, а цель не очень ясна — получается «суперконтроллер», там, где достаточно существенно меньшего. Ну и дороже, (хотя, конечно, в абсолютных величинах и то и другое недорого).anklimov Автор
07.11.2017 02:16+1Немного поразмыслив — если идти предложенным путем в направлении ARM, то уже смысл поднимать Linux и дальше строить все на нем. Такой проект уже есть, это Wirenboard. Это уже немного другое устройство и оно уже есть.
utya
06.11.2017 23:06Так и не понял, на чём крутиться openhab?
anklimov Автор
06.11.2017 23:41У большинства — на чем-то вроде Raspberry или чем-то подобном. Этого вполне хватает. Но у меня на HP Proliant MicroServer Gen8 под Debian.
Просто сервер есть, он включен, работает NAS-ом, вебсервером, Opencloud и много чем еще. Логично было Openhab и NodeRed, также, запустить на нем.
Godless
07.11.2017 11:56Я правильно понимаю, что физически есть доступ из тырнета по проводам к контроллеру дома?
anklimov Автор
07.11.2017 12:30Да, и даже без проводов. Мобильное приложение из 3G работает как дома в WIFI. Для этого просто надо:
1. Зарегистрироваться на myopenhab.org
2. Установить Openhab Cloud Connector в Misc Addons Опенхаба. Настроить ключ доступа в конфиге (ключ берется с myopenhab.org).
3. Настроить Remote URL мобильного приложения как myopenhab.org а также, логин и пароль.
И для этого не требуется фиксированный IP дома или dyndnsGodless
07.11.2017 13:12я не в этом ключе интересовался.
Когда IoT девайсы подключены к тырнету — это миллион возможностей, и пара тысяч дыр. Как вы от них закрываетесь?
Кстати, проводили ли какие-то анализы на взлом прошивки? Банальные переполнения буферов? cppcheck натравливали хотя бы?vp7
07.11.2017 15:41Там немного другая схема.
Никто не открывает порты на Firewall'е и не даёт прямого доступа к контроллеру.
В локальном openhab'е прописывается работа с облаком, openhab сам поднимает исходящее соединение в сторону облака, клиентское приложение также подключается к облаку. Т.е. всё взаимодействие идёт через облако как через прокси.
Для взлома потребуется сначала сломать myopehab.org, а уже потом — пытаться что-то сделать с установленными у людей дома устройствами.
Это тоже возможно, но на порядок сложнее, чем сломать какой-нибудь «умный чайник».
anklimov Автор
07.11.2017 17:32+1Дополню по вопросу ИБ: контроллер, в данном случае, устройство простейшее.
1. Он подключен только к внутренней локальной сети и не имеет прямого доступа извне.
2. Он не имеет открытых портов, на которых можно делать атаку. Сервером не является. Является только клиентом, подключенным к MQTT брокеру (Mosqitto или другой).
3. На нем нет операционной системы. Рут получать не от чего.
Соответственно, уровень безопасности определяется уязвимостями MQTT брокера. Если злоумышленник подключился к брокеру — он может видеть все события и всем управлять.
Но тот же Mosquitto имеет большое сообщество, которое исправляет уязвимости.
А в нашем случае, просто не открывайте порты извне к MQTT брокеру. Это ни для чего не требуется.
В принципе, на брокере можно настроить авторизацию, чтобы защититься от несанкционированного подключения изнутри домашней сети. (я пока не настраивал, попробую)
Следующая потенциальная уязвимость — Openhab
Но там тоже нет прямых открытых портов, смотрящих во внешний мир (если вы их зачем-то туда не открыли).
Так что, действительно, придется ломать myopehab.org
Возможности после такого гипотетического взлома я бы тоже не переоценивал — поиграть со светом-теплом-холодом, последить за температурой?
Keroro
07.11.2017 06:08При этом, полноценно осветить комнату около 16-18 кв. м оказалось возможным при помощи 4-х ключей.
А можно фото комнаты с включеным освещением? Тоже интересуюсь этим вопросом…
vtec
07.11.2017 11:04Если возможно, то напишите статейку отдельно про DMX. Как, что, куда и сколько…
Очень мало про эту в сети.anklimov Автор
07.11.2017 18:45Да, попробую написать на досуге.
DMX-512 в данном проекте я выбрал:
1. Потому что он очень просто реализуется. Как программно (много готовых библиотек), так и аппаратно — одной дешевой микросхемой (MAX-485), которая преобразует сигнал с PIN Arduino в требуемый — RS-485. На тот случай, если с паяльником нет дружбы — много дешевых готовых модулей на том же Aliexpress;
2. Потому что очень много готовой дешевой периферии, которая может управляться по этому протоколу. Коротко это описал тут.
3. Удобно то, что не надо стягивать провода от светодиодных лент к центральному контроллеру. См. картинку в статье — провода локально к плате диммера, все диммеры вешаются параллельно на одну витую пару, идущую к контроллеру. У каждого диммера задается начальный адрес и все.
Подробнее, конечно, в следующей статье.
jaiprakash
07.11.2017 22:11А почему именно ModBus, а не что-нибудь полегче?
anklimov Автор
07.11.2017 23:10Сложно найти для реализации на микроконтроллере что-то легче и стандартнее. Масса библиотек (правда, пришлось подправить код) и такой же MAX-485. И уйма совместимых устройств. Поищите на Алиэкспрессе по слову modbus — сейчас 1851 результат. Реле, входы, диммеры, термометры. Тот же частотный регулятор для приточной вентиляции — тоже управляется по modbus. Конечно, недостатки есть. Основной — это однонаправленность протокола — один Мастер, который последовательно обращается к устройствам по адресам. Поэтому от устройств никакой инициативы не ожидается — придет время — Мастер спросит. Но простота и стандартность перекрывает недостатки.
deNULL
08.11.2017 01:01Куда уж легче-то? Среди проводных протоколов Modbus один из лучших претендентов на стандарт для устройств «умного дома».
vp7
08.11.2017 02:18А что на счёт протоколов, поддерживающих мультимастер? Были попытки работать с ними?
ModBus всем хорош, но у него на шине может быть только один master, а это значит, что будут сложности с:
— автоматическим обнаружением новых устройств на шине (они не смогут рапортовать о своём подключении)
— подключением устройств типа «датчик открытия»/«выключатель» (их нужно постоянно опрашивать)
Вроде бы CAN лишен этих недостатков (кстати, у ATMEL'овских камней есть свой аналог — TWI, который также поддерживает мультимастер) и массово применяется в автомобилях, но вот в «умном доме» встречается значительно реже. Осталось понять — почему. Толи чипы дорогие, толи есть какие-то подводные камни по сравнению с ModBus/RS-485.jaiprakash
08.11.2017 08:23TWI это же I2C вроде бы.
vp7
08.11.2017 12:04Да, действительно, про TWI помнил с давних времён, а то, что это i2c — забыл :)
TWI поддерживает Slave и Single/MultiMaster режимы i2c.
anklimov Автор
08.11.2017 15:09Ну на ESP32 будет CAN и с ним можно будет поэкспериментировать.
CAN хорош всем, вот только набор готовой копеечной переферии под CAN отсутствует.
CAN мог бы использоваться для взаимодействия между контроллерами, но с этим справляется MQTT брокер. Это, несколько, понижает надежность межпроцессорного взаимодействия (так как в цепочку добавляется сетевая инфраструктура и сам Брокер), поэтому, критичные процессы (например, терморегуляцию) держу в пределах одного контроллера.
По поводу опроса датчиков — планировал делать на 1-Wire, изначально, так как у многих устройств (например DS2408) есть функция «Conditional Search», которая позволяет не опрашивать все устройства, чтобы понять не изменилось ли что на входе у них, а сразу адресоваться к устройству, которое «хочет что-то сказать».
Возможно, доберусь до этой идеи. Хотя, сейчас эти вопросы решены подключением датчиков непосредственно на порты контроллера. Там цикл опроса позволяет не пропустить событие.
Mr_0wl
08.11.2017 14:00для dmx 512 длительность одного тика в посылке пакета 4 мкс… это 250 кГц
чем реализовали такую частоту «ногодрыга» на atmega 2560?anklimov Автор
08.11.2017 14:55Я использую библиотеку DmxSimple, а она реализована следующим образом:
1. Программируется таймер (было 2 мс, я уменьшил до 1 мс.)
2. В обработчике прерывания реализована передача данных нескольких каналов, далее, управление возвращается основной программе. На следующем цикле таймера — еще несколько каналов выдаются на шину и так до последнего канала (у меня сейчас используются 60 каналов)
3. Передача самих данных реализована ассемблерной вставкой (код можно посмотреть тут, начиная со строки 120), четко таймированной по тактам для AVR (для ARM — проще). Пока процессор выдает очередную посылку (1/4 всего времени) — он больше ничем другим не занимается.
Выглядит это так:
В принципе, есть возможность (и это намного эффективнее) использовать аппаратный UART (Как это сделано в библиотеке DMXSerial)
Но эта библиотека у меня используется для приема DMX, А работать сразу в двух режимах она пока не умеет. Может быть, со временем, доработаю.
Mr_0wl
08.11.2017 17:06глядел эту либу — не понравилось.
В итоге забросил ее и делал на stm32F4… там как то комфортнее было (freeRTOS, частота шины выше). Задачка была отвязать серию диджейских светильников (dialighting и Martin) от компа и реализовать их включалку на 60 минут с возможностью корректировки стоп\старт и времени работы.anklimov Автор
08.11.2017 20:05Вообще, странно, что не понравилась — либа абсолютно простая и безглючная. Работать начинает за 5 минут с начала изучения. Правда, как большинство Ардуиновских либ, считает, что кроме нее на контроллере ничего работать не должно, поэтому выделяет статический буфер сразу и на все 512 каналов. Но я этот вопрос решил в своем форке., так же как со слишком большой задержкой при передачи фреймов.
DimkaI
08.11.2017 21:41Вы молодец, провели столь большую работу, но не боитесь что ардуинку лихорадит во время грозы и от сигнала работающего рядом мобильника?
Ничего не имею против, но у ардуины, как у дешёвого макетного конструктора, проблемы с развязками что на входах, что на выходах.
eka1939
Ссылки на Али подправьте — часть требует логина.
anklimov Автор
С Алиэкспрессом вечно такая проблема — товар то появляется то исчезает. Скорректировал/подобрал аналоги для ссылок, вышедших в тираж.
0o0
И до кучи можно убрать из них «ru.»
Тем, у кого в куках сидит русский — и так откроется русский вариант. А вот те, кто пользуются «Global version», скажут спасибо.
anklimov Автор
Да, действительно. Поправил.
rustavelli
скрипт для расширения