Соглашусь со всеми:
1. На улице ленту всегда только в силиконе
2. Ленту надо ставить только на теплоотвод (алюминевая полоса). Со временем портится. Проверено.
Дополнительно:
3. В потенциально сырых местах, блок питания надо брать соответствующего климатического исполнения.
4. Кнопки на улице зиму пережить не должны (лучше отклеить и унести в дом)
Я вот такую приточку соорудил: http://www.lazyhome.ru/index.php/14-myhome/35-fresh-air
С блэкджеком и управлением через мобильное приложение Опенхаб.
Пока доволен! На 1500 RPM почти не слышно, сейчас ТЭН греет примерно на 40%, субъективно, воздуха стало хватать. Посмотрим, что будет зимой.
Заказал пару датчиков CO2 — планирую скорость увязать с уровнем CO2 через программный PID регулятор.
Изредка (не чаще раз в месяц-два), OpenHab2 отваливается от шины. При этом, все остальное нормально работает -контроллеры, MQTT, NodeRed. Но вот мобильное приложение перестает управлять. Так как на OpenHab у меня не завязано какого-то там критического управляющего функционала, практически, я его использую как пульт — все продолжает работать на автопилоте.
Изначально, было чаще, но поправил проблему с Astro Binding — см. тут
То, что осталось — проблема редкая, возможно, уникальная для меня, так как в форумах такое не описано. Возможно, надо просто полностью обновить OH на последний билд — проект очень активно развивается. Ну или просто рестартовать на автомате раз в неделю.Также, думаю попробовать IOBroker вместо.
Навскидку:
Arduino Mega 2560 — 500 руб
Ethernet Shield — 360 руб
DMX-512 decoder аж на 30 каналов — 2500 руб
Релейный модуль на 8 реле — 700 руб (годится как для освещения так и для теплых полов)
Адаптеры RS485 — 150 руб 5 штук (с запасом)
Блок питания — около 900 руб
Термодатчики — рублей по 50 обычные, по 85 влагозащищенные
1-wire adapter придется спаять — микросхема стоит 60 руб. Работа — ну как получится
Ну всякой мелочовки еще рублей на 800 набежит
Лампы-ленты-их блоки питания-выключатели — провода — за скобкой, это по-любому покупать.
Вентиляцию (задвижки, само вентоборудование) — тоже
Софт — весь опенсорсный
Нашел поделку почти двухлетней давности, выложил на Github
Это тот-же диммер, но вместо MQTT прикручен Souliss.
По-моему, оно даже работало, но как-то не настолько красиво, как мне хотелось. Хотелось, чтобы при локальном управлении, изменение яркости сразу визуально отображалось на Openhab, к которому был подключен Souliss. Но этого не происходило. Я написал вопрос автору фреймворка Dario. И тут же переключился на MQTT. А вот сейчас поискал в почте и нашел ответ/рекомендацию Dario добавить всего одну команду, для того, чтобы локальные изменения транслировались в сеть. Добавил в проект. Если получится использовать/развивать — плс. форкайте на Гитхабе, чтобы можно было использовать всем.
Ну там нет проблем с развязками — развязок просто нет как класс )
Развязки обязательно добавим в Shield, через который идут все подключения от датчиков/выключателей на этапе разводки нормальной платы. (Уже скоро)
Пока подключил провода прямо на порты. Причем, с программной подтяжкой портов к +5В
Я не предполагал, в принципе, что такое может работать, не выжигая порты и не имея, как минимум, ложных срабатываний. Подключил, исключительно, для проверки/тестирования прошивки. Был готов поменять Мегу, благо, недорого. Но, на удивление, работает вообще без проблем. Длина проводов, в среднем, метров 5. Идут, местами, рядом с токонесущими. Вобщем — удивлен.
Но, конечно же, защиту-развязку портов сделаем. В таком виде оставлять на века не собираюсь.
По поводу лихорадит: Со стабильностью Openhab проблемы были (не от работающего мобильника, конечно), но со стабильностью Ардуины — пока не отмечал.
Вообще, странно, что не понравилась — либа абсолютно простая и безглючная. Работать начинает за 5 минут с начала изучения. Правда, как большинство Ардуиновских либ, считает, что кроме нее на контроллере ничего работать не должно, поэтому выделяет статический буфер сразу и на все 512 каналов. Но я этот вопрос решил в своем форке., так же как со слишком большой задержкой при передачи фреймов.
Ну на ESP32 будет CAN и с ним можно будет поэкспериментировать.
CAN хорош всем, вот только набор готовой копеечной переферии под CAN отсутствует.
CAN мог бы использоваться для взаимодействия между контроллерами, но с этим справляется MQTT брокер. Это, несколько, понижает надежность межпроцессорного взаимодействия (так как в цепочку добавляется сетевая инфраструктура и сам Брокер), поэтому, критичные процессы (например, терморегуляцию) держу в пределах одного контроллера.
По поводу опроса датчиков — планировал делать на 1-Wire, изначально, так как у многих устройств (например DS2408) есть функция «Conditional Search», которая позволяет не опрашивать все устройства, чтобы понять не изменилось ли что на входе у них, а сразу адресоваться к устройству, которое «хочет что-то сказать».
Возможно, доберусь до этой идеи. Хотя, сейчас эти вопросы решены подключением датчиков непосредственно на порты контроллера. Там цикл опроса позволяет не пропустить событие.
Я использую библиотеку DmxSimple, а она реализована следующим образом:
1. Программируется таймер (было 2 мс, я уменьшил до 1 мс.)
2. В обработчике прерывания реализована передача данных нескольких каналов, далее, управление возвращается основной программе. На следующем цикле таймера — еще несколько каналов выдаются на шину и так до последнего канала (у меня сейчас используются 60 каналов)
3. Передача самих данных реализована ассемблерной вставкой (код можно посмотреть тут, начиная со строки 120), четко таймированной по тактам для AVR (для ARM — проще). Пока процессор выдает очередную посылку (1/4 всего времени) — он больше ничем другим не занимается.
Выглядит это так:
В принципе, есть возможность (и это намного эффективнее) использовать аппаратный UART (Как это сделано в библиотеке DMXSerial)
Но эта библиотека у меня используется для приема DMX, А работать сразу в двух режимах она пока не умеет. Может быть, со временем, доработаю.
Сложно найти для реализации на микроконтроллере что-то легче и стандартнее. Масса библиотек (правда, пришлось подправить код) и такой же MAX-485. И уйма совместимых устройств. Поищите на Алиэкспрессе по слову modbus — сейчас 1851 результат. Реле, входы, диммеры, термометры. Тот же частотный регулятор для приточной вентиляции — тоже управляется по modbus. Конечно, недостатки есть. Основной — это однонаправленность протокола — один Мастер, который последовательно обращается к устройствам по адресам. Поэтому от устройств никакой инициативы не ожидается — придет время — Мастер спросит. Но простота и стандартность перекрывает недостатки.
Да, попробую написать на досуге.
DMX-512 в данном проекте я выбрал:
1. Потому что он очень просто реализуется. Как программно (много готовых библиотек), так и аппаратно — одной дешевой микросхемой (MAX-485), которая преобразует сигнал с PIN Arduino в требуемый — RS-485. На тот случай, если с паяльником нет дружбы — много дешевых готовых модулей на том же Aliexpress;
2. Потому что очень много готовой дешевой периферии, которая может управляться по этому протоколу. Коротко это описал тут.
3. Удобно то, что не надо стягивать провода от светодиодных лент к центральному контроллеру. См. картинку в статье — провода локально к плате диммера, все диммеры вешаются параллельно на одну витую пару, идущую к контроллеру. У каждого диммера задается начальный адрес и все.
Подробнее, конечно, в следующей статье.
Да, готовые устройства видел. Тут проблема даже не только в том, что они дороговаты, а в том, что часто это «вещь в себе», которая сама управляет, но не позволяет управлять извне. Если, конечно, тут описан не ZWave, например, вариант. Также, бюджетными Noolight-ами, вроде бы, научились управлять. Но там другие проблемы — отсутствие обратной связи. Ну и там диммер с кнопками а не с ручкой. Хотелось именно с Rotary Encoder
Именно поэтому сделал свой прототип, по которому, думаю, напишу отдельную статью. Может кто доведет до ума.
А с идеей, что лучше разделить это устройство с силовыми цепями согласен.
Дополню по вопросу ИБ: контроллер, в данном случае, устройство простейшее.
1. Он подключен только к внутренней локальной сети и не имеет прямого доступа извне.
2. Он не имеет открытых портов, на которых можно делать атаку. Сервером не является. Является только клиентом, подключенным к MQTT брокеру (Mosqitto или другой).
3. На нем нет операционной системы. Рут получать не от чего.
Соответственно, уровень безопасности определяется уязвимостями MQTT брокера. Если злоумышленник подключился к брокеру — он может видеть все события и всем управлять.
Но тот же Mosquitto имеет большое сообщество, которое исправляет уязвимости.
А в нашем случае, просто не открывайте порты извне к MQTT брокеру. Это ни для чего не требуется.
В принципе, на брокере можно настроить авторизацию, чтобы защититься от несанкционированного подключения изнутри домашней сети. (я пока не настраивал, попробую)
Следующая потенциальная уязвимость — Openhab
Но там тоже нет прямых открытых портов, смотрящих во внешний мир (если вы их зачем-то туда не открыли).
Так что, действительно, придется ломать myopehab.org
Возможности после такого гипотетического взлома я бы тоже не переоценивал — поиграть со светом-теплом-холодом, последить за температурой?
Графики красивые. Но проблема с доступом из единого приложения, особенно, извне, конечно, убивает. В мобильном приложении графики — штука достаточно информативная. Позволяет одним взглядом издалека оценить, что происходит дома. Возможно, выход в дублировании графиков — для приложения — родные Опенхабовские, дополнительно, поднять Grafan-у
Да, и даже без проводов. Мобильное приложение из 3G работает как дома в WIFI. Для этого просто надо:
1. Зарегистрироваться на myopenhab.org
2. Установить Openhab Cloud Connector в Misc Addons Опенхаба. Настроить ключ доступа в конфиге (ключ берется с myopenhab.org).
3. Настроить Remote URL мобильного приложения как myopenhab.org а также, логин и пароль.
И для этого не требуется фиксированный IP дома или dyndns
Немного поразмыслив — если идти предложенным путем в направлении ARM, то уже смысл поднимать Linux и дальше строить все на нем. Такой проект уже есть, это Wirenboard. Это уже немного другое устройство и оно уже есть.
Да, с деревянным домом я бы тоже не стал экспериментировать. По крайней мере, с 220В. Только с низковольтным питанием. Тогда вероятность пожара, как мне кажется, примерно равна нулю, так как снять с провода, сечением 0,2 на 24В мощность, требуемую для возгорания, скорее всего, не получится. Предохранитель, например, на 1А лучше поставить прямо на выходе БП, чтобы избежать перегрева тонкого провода в случае КЗ. С номиналом предохранителя и нагревом лучше поэкспериментировать с мощным БП, амперметром и бухтой кабеля.
1. На улице ленту всегда только в силиконе
2. Ленту надо ставить только на теплоотвод (алюминевая полоса). Со временем портится. Проверено.
Дополнительно:
3. В потенциально сырых местах, блок питания надо брать соответствующего климатического исполнения.
4. Кнопки на улице зиму пережить не должны (лучше отклеить и унести в дом)
С блэкджеком и управлением через мобильное приложение Опенхаб.
Пока доволен! На 1500 RPM почти не слышно, сейчас ТЭН греет примерно на 40%, субъективно, воздуха стало хватать. Посмотрим, что будет зимой.
Заказал пару датчиков CO2 — планирую скорость увязать с уровнем CO2 через программный PID регулятор.
Изначально, было чаще, но поправил проблему с Astro Binding — см. тут
То, что осталось — проблема редкая, возможно, уникальная для меня, так как в форумах такое не описано. Возможно, надо просто полностью обновить OH на последний билд — проект очень активно развивается. Ну или просто рестартовать на автомате раз в неделю.Также, думаю попробовать IOBroker вместо.
Arduino Mega 2560 — 500 руб
Ethernet Shield — 360 руб
DMX-512 decoder аж на 30 каналов — 2500 руб
Релейный модуль на 8 реле — 700 руб (годится как для освещения так и для теплых полов)
Адаптеры RS485 — 150 руб 5 штук (с запасом)
Блок питания — около 900 руб
Термодатчики — рублей по 50 обычные, по 85 влагозащищенные
1-wire adapter придется спаять — микросхема стоит 60 руб. Работа — ну как получится
Ну всякой мелочовки еще рублей на 800 набежит
Лампы-ленты-их блоки питания-выключатели — провода — за скобкой, это по-любому покупать.
Вентиляцию (задвижки, само вентоборудование) — тоже
Софт — весь опенсорсный
Это тот-же диммер, но вместо MQTT прикручен Souliss.
По-моему, оно даже работало, но как-то не настолько красиво, как мне хотелось. Хотелось, чтобы при локальном управлении, изменение яркости сразу визуально отображалось на Openhab, к которому был подключен Souliss. Но этого не происходило. Я написал вопрос автору фреймворка Dario. И тут же переключился на MQTT. А вот сейчас поискал в почте и нашел ответ/рекомендацию Dario добавить всего одну команду, для того, чтобы локальные изменения транслировались в сеть. Добавил в проект. Если получится использовать/развивать — плс. форкайте на Гитхабе, чтобы можно было использовать всем.
Развязки обязательно добавим в Shield, через который идут все подключения от датчиков/выключателей на этапе разводки нормальной платы. (Уже скоро)
Пока подключил провода прямо на порты. Причем, с программной подтяжкой портов к +5В
Я не предполагал, в принципе, что такое может работать, не выжигая порты и не имея, как минимум, ложных срабатываний. Подключил, исключительно, для проверки/тестирования прошивки. Был готов поменять Мегу, благо, недорого. Но, на удивление, работает вообще без проблем. Длина проводов, в среднем, метров 5. Идут, местами, рядом с токонесущими. Вобщем — удивлен.
Но, конечно же, защиту-развязку портов сделаем. В таком виде оставлять на века не собираюсь.
По поводу лихорадит: Со стабильностью Openhab проблемы были (не от работающего мобильника, конечно), но со стабильностью Ардуины — пока не отмечал.
CAN хорош всем, вот только набор готовой копеечной переферии под CAN отсутствует.
CAN мог бы использоваться для взаимодействия между контроллерами, но с этим справляется MQTT брокер. Это, несколько, понижает надежность межпроцессорного взаимодействия (так как в цепочку добавляется сетевая инфраструктура и сам Брокер), поэтому, критичные процессы (например, терморегуляцию) держу в пределах одного контроллера.
По поводу опроса датчиков — планировал делать на 1-Wire, изначально, так как у многих устройств (например DS2408) есть функция «Conditional Search», которая позволяет не опрашивать все устройства, чтобы понять не изменилось ли что на входе у них, а сразу адресоваться к устройству, которое «хочет что-то сказать».
Возможно, доберусь до этой идеи. Хотя, сейчас эти вопросы решены подключением датчиков непосредственно на порты контроллера. Там цикл опроса позволяет не пропустить событие.
1. Программируется таймер (было 2 мс, я уменьшил до 1 мс.)
2. В обработчике прерывания реализована передача данных нескольких каналов, далее, управление возвращается основной программе. На следующем цикле таймера — еще несколько каналов выдаются на шину и так до последнего канала (у меня сейчас используются 60 каналов)
3. Передача самих данных реализована ассемблерной вставкой (код можно посмотреть тут, начиная со строки 120), четко таймированной по тактам для AVR (для ARM — проще). Пока процессор выдает очередную посылку (1/4 всего времени) — он больше ничем другим не занимается.
Выглядит это так:
В принципе, есть возможность (и это намного эффективнее) использовать аппаратный UART (Как это сделано в библиотеке DMXSerial)
Но эта библиотека у меня используется для приема DMX, А работать сразу в двух режимах она пока не умеет. Может быть, со временем, доработаю.
https://github.com/anklimov/rotary_mqtt_dimmer
В принципе, это тема отдельной статьи. Надеюсь, руки дойдут довести до ума.
DMX-512 в данном проекте я выбрал:
1. Потому что он очень просто реализуется. Как программно (много готовых библиотек), так и аппаратно — одной дешевой микросхемой (MAX-485), которая преобразует сигнал с PIN Arduino в требуемый — RS-485. На тот случай, если с паяльником нет дружбы — много дешевых готовых модулей на том же Aliexpress;
2. Потому что очень много готовой дешевой периферии, которая может управляться по этому протоколу. Коротко это описал тут.
3. Удобно то, что не надо стягивать провода от светодиодных лент к центральному контроллеру. См. картинку в статье — провода локально к плате диммера, все диммеры вешаются параллельно на одну витую пару, идущую к контроллеру. У каждого диммера задается начальный адрес и все.
Подробнее, конечно, в следующей статье.
Именно поэтому сделал свой прототип, по которому, думаю, напишу отдельную статью. Может кто доведет до ума.
А с идеей, что лучше разделить это устройство с силовыми цепями согласен.
1. Он подключен только к внутренней локальной сети и не имеет прямого доступа извне.
2. Он не имеет открытых портов, на которых можно делать атаку. Сервером не является. Является только клиентом, подключенным к MQTT брокеру (Mosqitto или другой).
3. На нем нет операционной системы. Рут получать не от чего.
Соответственно, уровень безопасности определяется уязвимостями MQTT брокера. Если злоумышленник подключился к брокеру — он может видеть все события и всем управлять.
Но тот же Mosquitto имеет большое сообщество, которое исправляет уязвимости.
А в нашем случае, просто не открывайте порты извне к MQTT брокеру. Это ни для чего не требуется.
В принципе, на брокере можно настроить авторизацию, чтобы защититься от несанкционированного подключения изнутри домашней сети. (я пока не настраивал, попробую)
Следующая потенциальная уязвимость — Openhab
Но там тоже нет прямых открытых портов, смотрящих во внешний мир (если вы их зачем-то туда не открыли).
Так что, действительно, придется ломать myopehab.org
Возможности после такого гипотетического взлома я бы тоже не переоценивал — поиграть со светом-теплом-холодом, последить за температурой?
1. Зарегистрироваться на myopenhab.org
2. Установить Openhab Cloud Connector в Misc Addons Опенхаба. Настроить ключ доступа в конфиге (ключ берется с myopenhab.org).
3. Настроить Remote URL мобильного приложения как myopenhab.org а также, логин и пароль.
И для этого не требуется фиксированный IP дома или dyndns