Comments 84
Ссылки на Али подправьте — часть требует логина.
С Алиэкспрессом вечно такая проблема — товар то появляется то исчезает. Скорректировал/подобрал аналоги для ссылок, вышедших в тираж.
И до кучи можно убрать из них «ru.»
Тем, у кого в куках сидит русский — и так откроется русский вариант. А вот те, кто пользуются «Global version», скажут спасибо.
Тем, у кого в куках сидит русский — и так откроется русский вариант. А вот те, кто пользуются «Global version», скажут спасибо.
Да, действительно. Поправил.
скрипт для расширения
//всегда переходить на английский сайт.
var url = document.location.href;
if(document.querySelector("[data-role=goto-globalsite]") !== null) {
document.querySelector("[data-role=goto-globalsite]").click();
document.location.href = url.replace('://ru.', '://');
}
//var trackNumber = document.querySelector('td.no').innerText;
//возвращаем возможность выделять текст
document.body.onselectstart = function() { return true; };
Скажите, есть ли бд в системе для логгирования (показания датчиков, комманды, не суть важно) нет ли доступа к логам извне? Пытаюсь понять ввша система именно то ли что я ищу по функционалу?
Тут я описываю контроллер, который, сам по себе, никакого доступа к БД не имеет. И не должен иметь. Его задача — получать команды по шине, включать-выключать устройства, а также, передавать на шину значения сенсоров. А вот ПО более высокого уровня — Openhab — получает эти данные с шины и может записывать их в БД. В моем случае Openhab пишет температуры в базу формата RRD4J для построения графиков. В поставке Openhab есть возможность подключить, практически, любую БД. См. документацию
NodeRed тоже имеет компоненты для интеграции с БД
NodeRed тоже имеет компоненты для интеграции с БД
Большое спасибо, значит почитаю про Openhab, хочется найти готовое решение без велосипедов. Изначально вопрос тут задавал: toster.ru/q/474369, если вычитаю что интересное добавлю туда ссылочку на Вас.
Лучше всего, ИМХО, в OpenHab для логгирования и построения графиков использовать influxdb+grafana. community.openhab.org/t/influxdb-grafana-persistence-and-graphing/13761
Действительно, графики посимпатичнее чем родные Openhab-овские.
Но так как в мобильное приложение графики из Grafana, судя по всему, передаются через Webview — для доступа извне локальной сети, похоже, потребуется вывешивать Grafan-у во внешний мир.
Сейчас для доступа из внешнего мира с мобильных приложений я использую Openhab Cloud Connector. Он сам вытягивает все данные и графики во внешний мир.
Но так как в мобильное приложение графики из Grafana, судя по всему, передаются через Webview — для доступа извне локальной сети, похоже, потребуется вывешивать Grafan-у во внешний мир.
Сейчас для доступа из внешнего мира с мобильных приложений я использую Openhab Cloud Connector. Он сам вытягивает все данные и графики во внешний мир.
У меня что-то так и не получилось передать графики в мобильное приложение. Только в браузерный интерфейс Openhab. Передается как image с заданным интервалом обновления. Один image — один график, а у меня их несколько. Поэтому проще зайти браузером на графану, где все графики показаны на одном дашборде. Ну и у меня, честно говоря, нет необходимости смотреть их из внешнего мира, поэтому порт не прокидывал.
Это дашборд из самой графаны.
Это дашборд из самой графаны.
Графики красивые. Но проблема с доступом из единого приложения, особенно, извне, конечно, убивает. В мобильном приложении графики — штука достаточно информативная. Позволяет одним взглядом издалека оценить, что происходит дома. Возможно, выход в дублировании графиков — для приложения — родные Опенхабовские, дополнительно, поднять Grafan-у
Возможно, подумаю над миграцией на ESP-8266 для расширения RAM
Свечку не держал, но по слухам у ESP'хи сложности с real time'ом (необходимым для DMX). Плюс — мало GPIO портов. И самое главное — WiFi полезен, очень полезен, но лишать контроллер Ethernet порта было бы, imho, ошибкой.
Самое очевидное — оставить ATMega для работы с периферией и Ethernet'ом, а ESP использовать как шлюз в WiFi и при необходимости вынести на неё часть бизнес-логики.
В принципе, вижу, что есть библиотеки для DMX-512 под ESP. Так что портировать вполне получится. GPIO портов у ESP, действительно, мало, но зато этих копеечных штук можно поставить много. В каждом углу. Или подразетниках даже. И прилично сэкономить на проводах. Для критических цепей (нагрев, например) я бы все равно оставил проводное подключение к LAN+ATMega, так как ESP у меня, периодически, все же от сети отваливается.
А для управления светом (DMX, пара реле, пара выключателей) WiFi+ESP вполне сгодится.
Пожалуй, попробую все же портировать, хотя-бы частично, как время появится.
Делать гибрид ESP+ATMega, все же, достаточно трудозатратно.
А для управления светом (DMX, пара реле, пара выключателей) WiFi+ESP вполне сгодится.
Пожалуй, попробую все же портировать, хотя-бы частично, как время появится.
Делать гибрид ESP+ATMega, все же, достаточно трудозатратно.
UFO just landed and posted this here
Неплохой вариант. А если в виде такой вот платы — то вообще, идеальный. Надо только разобраться как там реализован проводной LAN. Пожалуй, закажу.
Update — ценник, если заказывать на 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 не дает гарантий от повреждений или потери перевозчиком.
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 не дает гарантий от повреждений или потери перевозчиком.
Я бы в подрозетник не советовал… Во-первых — ESP'шки греются они сильно, а во-вторых = туда придется засовывать и БП, а найти таковой готовый с защитой по КЗ, току и температуре будет проблематично.
Лично у меня одна платка 8266 задымилась при питании от БП с USB-выходом.
Лично у меня одна платка 8266 задымилась при питании от БП с USB-выходом.
Собственно, поэтому я не тороплюсь с диммером. Хотя мне проще, по нужным подрозетникам разведен кабель CAT5, у которого одна из пар — 12В. (другие три — как раз 1-wire, DMX и Modbus) Поэтому задача Блока Питания решается простым DC-DC преобразователем на 3,3 В. Есть, конечно, сетевые блоки питания на 3,3 В но рука не поднимается запихивать их в подрозетник вместе с ESP. Но пока не подключал диммер к этому кабелю. Есть подозрение, что DC-DC будет наводить сильную помеху на соседние пары. Вообщем, тут еще простор для экспериментов.
Ну… Я бы передавал по кабелю все-таки не 12, а 48 вольт, по стандарту PoE, т.к. даже при 10 метрах кабеля на приемнике будет уже не 12 — все таки сопротивление на 0,2 квадратах будет великовато…
Такой вариант а тоже рассматривал, но… в частном доме провод может быть и длинее 10-ти метров, и при грозе там может появиться нехилый потенциал. Так что преобразователь я бы тоже искал с тройной защитой по току, КЗ и температуре с самовосстанавливающимся предохранителем. Буду благодарен, если подскажете модельку, которая залезет в подрозетник вместе с ESP'шкой.
Такой вариант а тоже рассматривал, но… в частном доме провод может быть и длинее 10-ти метров, и при грозе там может появиться нехилый потенциал. Так что преобразователь я бы тоже искал с тройной защитой по току, КЗ и температуре с самовосстанавливающимся предохранителем. Буду благодарен, если подскажете модельку, которая залезет в подрозетник вместе с ESP'шкой.
Согласен, что 12В маловато. Уже планировал перейти, как минимум, на 24В.
Надо только убедиться что диммеры, которые питаются от этой же шины, выдержат.
Вот такой DC-DC преобразователь у меня влезал в штатный диммер вместе с ESP. Минус в том, что регулируемый и можно его нечаяно перерегулировать. Ну и, конечно, суперзащит там нет. Но ESP от него работала вполне нормально.
Надо только убедиться что диммеры, которые питаются от этой же шины, выдержат.
Вот такой DC-DC преобразователь у меня влезал в штатный диммер вместе с ESP. Минус в том, что регулируемый и можно его нечаяно перерегулировать. Ну и, конечно, суперзащит там нет. Но ESP от него работала вполне нормально.
Если дом деревянный, без защит пихать что-то в подрозетник стремно… Да и все защиты реализовать не так сложно. Было бы образование, сделал бы блочек универсальный, типа такого, как здесь. Там от 220 питают (что еще удобнее), правда, к сожалению, не ESP'шку.
Да, с деревянным домом я бы тоже не стал экспериментировать. По крайней мере, с 220В. Только с низковольтным питанием. Тогда вероятность пожара, как мне кажется, примерно равна нулю, так как снять с провода, сечением 0,2 на 24В мощность, требуемую для возгорания, скорее всего, не получится. Предохранитель, например, на 1А лучше поставить прямо на выходе БП, чтобы избежать перегрева тонкого провода в случае КЗ. С номиналом предохранителя и нагревом лучше поэкспериментировать с мощным БП, амперметром и бухтой кабеля.
Вот проверенное решение с достаточным уровнем защит
Похоже вы не то искали. Сделать самому диммер на ардуино у меня руки так и не дошли, купил готовый.
Фишка в том, что управляет светом отдельный контроллер, а панель с энкодером на стену и кнопочный пульт — дистанционные и на батарейках. Они только передают сигналы по радиоканалу, а контроллер в глубине шкафа — подключен к 24 вольтам от отдельного блока питания, уже управляет лентами. В этом случае от контроллера не требуется особой компактности, не требуется питать его от 220, а управляющим устройствам нет необходимости пускать через себя большой ток.
Удовольствие это не из дешевых, если брать готовые решения. Но если делать такое самому на ардуинобразных компонентах — то не особо сложно и не очень дорого, если есть опыт.
Фишка в том, что управляет светом отдельный контроллер, а панель с энкодером на стену и кнопочный пульт — дистанционные и на батарейках. Они только передают сигналы по радиоканалу, а контроллер в глубине шкафа — подключен к 24 вольтам от отдельного блока питания, уже управляет лентами. В этом случае от контроллера не требуется особой компактности, не требуется питать его от 220, а управляющим устройствам нет необходимости пускать через себя большой ток.
Удовольствие это не из дешевых, если брать готовые решения. Но если делать такое самому на ардуинобразных компонентах — то не особо сложно и не очень дорого, если есть опыт.
Да, готовые устройства видел. Тут проблема даже не только в том, что они дороговаты, а в том, что часто это «вещь в себе», которая сама управляет, но не позволяет управлять извне. Если, конечно, тут описан не ZWave, например, вариант. Также, бюджетными Noolight-ами, вроде бы, научились управлять. Но там другие проблемы — отсутствие обратной связи. Ну и там диммер с кнопками а не с ручкой. Хотелось именно с Rotary Encoder
Именно поэтому сделал свой прототип, по которому, думаю, напишу отдельную статью. Может кто доведет до ума.
А с идеей, что лучше разделить это устройство с силовыми цепями согласен.
Именно поэтому сделал свой прототип, по которому, думаю, напишу отдельную статью. Может кто доведет до ума.
А с идеей, что лучше разделить это устройство с силовыми цепями согласен.
Ноолайт — они только на 220? Полазил по их сайту и не нашел ничего на слаботочку. А хочется то 24 вольта.
Плюс, как мне показалось, у народа были претензии на тему, что все слишком компактно и электроопасно, может перегреться и тп. А если разделить беспроводной контроллер и беспроводные управляющие устройства — то можно решить проблему работы с 220 вольт, не перекладывая их на устройства управления.
Плюс, как мне показалось, у народа были претензии на тему, что все слишком компактно и электроопасно, может перегреться и тп. А если разделить беспроводной контроллер и беспроводные управляющие устройства — то можно решить проблему работы с 220 вольт, не перекладывая их на устройства управления.
Напишите, будет интересно почитать! Тоже давно собирался собрать диммер на базе ATmega8 с энкодером и управлением по Modbus, но пока руки дошли только до реализации протокола на нём, непосредственно диммирование ещё предстоит сделать.
Возможно я ошибаюсь, но не данный девайс имеется ввиду? Arduino Mega 2560 R3 с интегрированным чипом WiFi ESP8266 b
Такой можно, но не обязательно. WiFi модуль если только для удобства перепрограммирования по воздуху, как тут описано, для работы вайфай не нужен.
Можно взять что-то вроде этого
Можно взять что-то вроде этого
Респект! Хороший проект!!! Я тоже думал делать на esp потом вернулся в ардуинку. Сейчас изучаю фреймворк souliss. Из фишечек хочу сделать панель управления в подрозетник с красивым oled экраном и управлением энкодером. Главный сервер cubieboard с опенхабом для умного дома и logitech media server для музыки (динамики в потолке по квартире)
Спасибо! Два года назад я начал именно с souliss. Именно тогда, соорудил диммер, управляемый энкодером, первая версия которого работала (пыталась) именно на этом фреймворке. Но в то время фреймворк был еще слегка сыроват. Поняв, что мне достаточно только механизма Publish/Subscribe я перешел на MQTT. Единственное, чем пришлось пожертвовать — возможностью автономной работы устройств без брокера. Но, учитывая то, что брокер можно поднять и на роутере (не поднимал, так как есть полноценный сервер, но в openwrt/ddwrt Mosquitto видел) — потеря не сильно большая. Я все еще подписан на souliss, вижу, что проект активно развивается, но портировать назад пока подожду. Тем более, что сейчас скрестить Lighthub и Souliss будет непросто — я пошел не по пути фреймворка а по пути универсального конфигурируемого устройства, которое с одной и той же прошивкой делает разное, в зависимости от конфига. А у Souliss предполагается, что для разных применений делаются разные скетчи, компилируются, загружаются в устройства.
Тему диммера на ESP пока год как забросил, хотя, вполне работающий прототип есть. Он отлично регулирует как локальную нагрузку AC 220В, так и удаленную RGB ленту (цвет, яркость, насыщенность) через MQTT. Ну и локальная нагрузка тоже управляется по MQTT. В принципе, могу выложить на Github для развития.
Тему диммера на ESP пока год как забросил, хотя, вполне работающий прототип есть. Он отлично регулирует как локальную нагрузку AC 220В, так и удаленную RGB ленту (цвет, яркость, насыщенность) через MQTT. Ну и локальная нагрузка тоже управляется по MQTT. В принципе, могу выложить на Github для развития.
… выложил
https://github.com/anklimov/rotary_mqtt_dimmer
В принципе, это тема отдельной статьи. Надеюсь, руки дойдут довести до ума.
https://github.com/anklimov/rotary_mqtt_dimmer
В принципе, это тема отдельной статьи. Надеюсь, руки дойдут довести до ума.
Спасибо. Интересно посмотреть. Соулис хорош, но документирован не очень хорошо, наверное из-за этого и не очень популярен. Долго приходится вникать в его логику. Может просто для меня непривычен.Автономную работу устройств поставил в приоритет. По этому соулисс. У соулиса тоже есть publish/subscribe варианты если что. Я еще как-то не очень доверяю esp… хотя зря наверное-)). Если есть проекты под Souliss киньте сссылочку поизучать.
Нашел поделку почти двухлетней давности, выложил на Github
Это тот-же диммер, но вместо MQTT прикручен Souliss.
По-моему, оно даже работало, но как-то не настолько красиво, как мне хотелось. Хотелось, чтобы при локальном управлении, изменение яркости сразу визуально отображалось на Openhab, к которому был подключен Souliss. Но этого не происходило. Я написал вопрос автору фреймворка Dario. И тут же переключился на MQTT. А вот сейчас поискал в почте и нашел ответ/рекомендацию Dario добавить всего одну команду, для того, чтобы локальные изменения транслировались в сеть. Добавил в проект. Если получится использовать/развивать — плс. форкайте на Гитхабе, чтобы можно было использовать всем.
Это тот-же диммер, но вместо MQTT прикручен Souliss.
По-моему, оно даже работало, но как-то не настолько красиво, как мне хотелось. Хотелось, чтобы при локальном управлении, изменение яркости сразу визуально отображалось на Openhab, к которому был подключен Souliss. Но этого не происходило. Я написал вопрос автору фреймворка Dario. И тут же переключился на MQTT. А вот сейчас поискал в почте и нашел ответ/рекомендацию Dario добавить всего одну команду, для того, чтобы локальные изменения транслировались в сеть. Добавил в проект. Если получится использовать/развивать — плс. форкайте на Гитхабе, чтобы можно было использовать всем.
у меня получается сразу же видеть изменения в мобильном клиенте. Там что-то типа logic или апдейт комьюникейшн надо делать. Чем вкусен еще соулис, так это поддержкой недорогих модулей nrf24l01. Да и построением сложных сетей. Я как начинаю в него больше вникать все больше мне он нравится. Сначала у меня была проба пера на mqtt+esp8266 сейчас вот пришел к ардуинке с соулисом, а уже в розетке с экраном и энкодером наверное что-то типа stm32 +nrf24 поставлю. Если досконально изучу соулис то можно и статью по нему запилить, авось кому-то жизнь облегчит. Родная дока ну очень уж не фонтан. Изучаю его реально по коду.
У вас динамики в потолке по зонам разделены? Как это аппаратно выглядит?
Разделены по зонам. Несколько usb-audio устройств подключены на cubieboard. Синхронизацию звука выполняет logitech media server. Каждое аудиоустройство видится как отдельный плеер в сервере. Если надо один источник на все выводить то там есть кнопочка и потоки все идут синхронно.
а какие звуковухи использовали?
за Logitech Media Server отдельное спасибо!
ЗЫ: ток не понял, оно только с GUI?
за Logitech Media Server отдельное спасибо!
ЗЫ: ток не понял, оно только с GUI?
купил на али цап ссылка он видится как обычное alsa устройство. GUI у сервера это мобильное приложение или сайт. которым полностью рулим сервером. Logitech squuezelite это программные плеера-рендеры. Их на один сервер вешаем несколько это и есть зоны. У того же опенхаба есть биндинги (Logitech Media Server ) для управления плеерами, но до этого пока не дошли руки.
А где же технопорно? Сколько лет увлекаюсь электроникой, а не перестаю ощущать лёгкий экстаз при виде качественно изготовленного изделия. Фото в студию!
Не хотел я этого делать. Честно писал, что интерфейсный шилд пока спаян на макетках. Поэтому эстетического экстаза не обещаю. Немножко хардкорное технопорно получилось.
Просьба не троллить и не минусовать.
Добавил в текст статьи.
Пара фоток покрупнее тут.
На шилде первого контроллера DC-DC преобразователь для питания, три штуки max-485 и 1-wire мост (сейчас не используется, так как 1-wire отдал второму контроллеру).
ESP нужна только для удаленного перепрограммирования AVR-ки.
В «целевом» дизайне на шилд надо будет добавить пачку опторазвязок. Пока, сорри, без них.
Просьба не троллить и не минусовать.
Добавил в текст статьи.
Пара фоток покрупнее тут.
На шилде первого контроллера DC-DC преобразователь для питания, три штуки max-485 и 1-wire мост (сейчас не используется, так как 1-wire отдал второму контроллеру).
ESP нужна только для удаленного перепрограммирования AVR-ки.
В «целевом» дизайне на шилд надо будет добавить пачку опторазвязок. Пока, сорри, без них.
Начали проектировать нормальную печатную плату с развязками и защитами. Подробности добавил в конец статьи.
У меня под рукой полностью готовая система orange pi + home assistant + modbus. Сейчас жду печатные платы для rs485 адаптера. По готовности изложу на пару статей.
Вот например — пятачок за пучок RS485 адаптеров. В чем смысл делать свой?
Мне кажется, если мигрировать — то сразу на stm32f4xx, или даже f7xx. Там и аппаратный Ethernet, и Can, и USB, и порядка полутора сотен GPIO, и даже АППАРАТНОЕ ШИФРОВАНИЕ. RAM — до 2 МБ, и вообще, AVR несколько устарел, а Arduino — просто не серьезно. К тому же, из-за ARM ядра, проект на stm32 легче будет перенести на более мощный контроллер при небходимости, чем проект на AVR.
Дело в том, что даже ESP8266 по ресурсам (не считая периферии) избыточна для этой штуки. Делать какие-то сложные алгоритмы, непосредственно, на контроллере ИМХО смысла не имеет — для этого есть системы более высокого уровня.
Ардуино — прежде всего, это огромное кол-во уже написанных библиотек и огромное сообщество. Конечно, можно нужные из них портировать на stm, но трудозатраты велики, а цель не очень ясна — получается «суперконтроллер», там, где достаточно существенно меньшего. Ну и дороже, (хотя, конечно, в абсолютных величинах и то и другое недорого).
Ардуино — прежде всего, это огромное кол-во уже написанных библиотек и огромное сообщество. Конечно, можно нужные из них портировать на stm, но трудозатраты велики, а цель не очень ясна — получается «суперконтроллер», там, где достаточно существенно меньшего. Ну и дороже, (хотя, конечно, в абсолютных величинах и то и другое недорого).
Так и не понял, на чём крутиться openhab?
У большинства — на чем-то вроде Raspberry или чем-то подобном. Этого вполне хватает. Но у меня на HP Proliant MicroServer Gen8 под Debian.
Просто сервер есть, он включен, работает NAS-ом, вебсервером, Opencloud и много чем еще. Логично было Openhab и NodeRed, также, запустить на нем.
Просто сервер есть, он включен, работает NAS-ом, вебсервером, Opencloud и много чем еще. Логично было Openhab и NodeRed, также, запустить на нем.
Я правильно понимаю, что физически есть доступ из тырнета по проводам к контроллеру дома?
Да, и даже без проводов. Мобильное приложение из 3G работает как дома в WIFI. Для этого просто надо:
1. Зарегистрироваться на myopenhab.org
2. Установить Openhab Cloud Connector в Misc Addons Опенхаба. Настроить ключ доступа в конфиге (ключ берется с myopenhab.org).
3. Настроить Remote URL мобильного приложения как myopenhab.org а также, логин и пароль.
И для этого не требуется фиксированный IP дома или dyndns
1. Зарегистрироваться на myopenhab.org
2. Установить Openhab Cloud Connector в Misc Addons Опенхаба. Настроить ключ доступа в конфиге (ключ берется с myopenhab.org).
3. Настроить Remote URL мобильного приложения как myopenhab.org а также, логин и пароль.
И для этого не требуется фиксированный IP дома или dyndns
я не в этом ключе интересовался.
Когда IoT девайсы подключены к тырнету — это миллион возможностей, и пара тысяч дыр. Как вы от них закрываетесь?
Кстати, проводили ли какие-то анализы на взлом прошивки? Банальные переполнения буферов? cppcheck натравливали хотя бы?
Когда IoT девайсы подключены к тырнету — это миллион возможностей, и пара тысяч дыр. Как вы от них закрываетесь?
Кстати, проводили ли какие-то анализы на взлом прошивки? Банальные переполнения буферов? cppcheck натравливали хотя бы?
Там немного другая схема.
Никто не открывает порты на Firewall'е и не даёт прямого доступа к контроллеру.
В локальном openhab'е прописывается работа с облаком, openhab сам поднимает исходящее соединение в сторону облака, клиентское приложение также подключается к облаку. Т.е. всё взаимодействие идёт через облако как через прокси.
Для взлома потребуется сначала сломать myopehab.org, а уже потом — пытаться что-то сделать с установленными у людей дома устройствами.
Это тоже возможно, но на порядок сложнее, чем сломать какой-нибудь «умный чайник».
Никто не открывает порты на Firewall'е и не даёт прямого доступа к контроллеру.
В локальном openhab'е прописывается работа с облаком, openhab сам поднимает исходящее соединение в сторону облака, клиентское приложение также подключается к облаку. Т.е. всё взаимодействие идёт через облако как через прокси.
Для взлома потребуется сначала сломать myopehab.org, а уже потом — пытаться что-то сделать с установленными у людей дома устройствами.
Это тоже возможно, но на порядок сложнее, чем сломать какой-нибудь «умный чайник».
Дополню по вопросу ИБ: контроллер, в данном случае, устройство простейшее.
1. Он подключен только к внутренней локальной сети и не имеет прямого доступа извне.
2. Он не имеет открытых портов, на которых можно делать атаку. Сервером не является. Является только клиентом, подключенным к MQTT брокеру (Mosqitto или другой).
3. На нем нет операционной системы. Рут получать не от чего.
Соответственно, уровень безопасности определяется уязвимостями MQTT брокера. Если злоумышленник подключился к брокеру — он может видеть все события и всем управлять.
Но тот же Mosquitto имеет большое сообщество, которое исправляет уязвимости.
А в нашем случае, просто не открывайте порты извне к MQTT брокеру. Это ни для чего не требуется.
В принципе, на брокере можно настроить авторизацию, чтобы защититься от несанкционированного подключения изнутри домашней сети. (я пока не настраивал, попробую)
Следующая потенциальная уязвимость — Openhab
Но там тоже нет прямых открытых портов, смотрящих во внешний мир (если вы их зачем-то туда не открыли).
Так что, действительно, придется ломать myopehab.org
Возможности после такого гипотетического взлома я бы тоже не переоценивал — поиграть со светом-теплом-холодом, последить за температурой?
1. Он подключен только к внутренней локальной сети и не имеет прямого доступа извне.
2. Он не имеет открытых портов, на которых можно делать атаку. Сервером не является. Является только клиентом, подключенным к MQTT брокеру (Mosqitto или другой).
3. На нем нет операционной системы. Рут получать не от чего.
Соответственно, уровень безопасности определяется уязвимостями MQTT брокера. Если злоумышленник подключился к брокеру — он может видеть все события и всем управлять.
Но тот же Mosquitto имеет большое сообщество, которое исправляет уязвимости.
А в нашем случае, просто не открывайте порты извне к MQTT брокеру. Это ни для чего не требуется.
В принципе, на брокере можно настроить авторизацию, чтобы защититься от несанкционированного подключения изнутри домашней сети. (я пока не настраивал, попробую)
Следующая потенциальная уязвимость — Openhab
Но там тоже нет прямых открытых портов, смотрящих во внешний мир (если вы их зачем-то туда не открыли).
Так что, действительно, придется ломать myopehab.org
Возможности после такого гипотетического взлома я бы тоже не переоценивал — поиграть со светом-теплом-холодом, последить за температурой?
При этом, полноценно осветить комнату около 16-18 кв. м оказалось возможным при помощи 4-х ключей.
А можно фото комнаты с включеным освещением? Тоже интересуюсь этим вопросом…
Если возможно, то напишите статейку отдельно про DMX. Как, что, куда и сколько…
Очень мало про эту в сети.
Очень мало про эту в сети.
Да, попробую написать на досуге.
DMX-512 в данном проекте я выбрал:
1. Потому что он очень просто реализуется. Как программно (много готовых библиотек), так и аппаратно — одной дешевой микросхемой (MAX-485), которая преобразует сигнал с PIN Arduino в требуемый — RS-485. На тот случай, если с паяльником нет дружбы — много дешевых готовых модулей на том же Aliexpress;
2. Потому что очень много готовой дешевой периферии, которая может управляться по этому протоколу. Коротко это описал тут.
3. Удобно то, что не надо стягивать провода от светодиодных лент к центральному контроллеру. См. картинку в статье — провода локально к плате диммера, все диммеры вешаются параллельно на одну витую пару, идущую к контроллеру. У каждого диммера задается начальный адрес и все.
Подробнее, конечно, в следующей статье.
DMX-512 в данном проекте я выбрал:
1. Потому что он очень просто реализуется. Как программно (много готовых библиотек), так и аппаратно — одной дешевой микросхемой (MAX-485), которая преобразует сигнал с PIN Arduino в требуемый — RS-485. На тот случай, если с паяльником нет дружбы — много дешевых готовых модулей на том же Aliexpress;
2. Потому что очень много готовой дешевой периферии, которая может управляться по этому протоколу. Коротко это описал тут.
3. Удобно то, что не надо стягивать провода от светодиодных лент к центральному контроллеру. См. картинку в статье — провода локально к плате диммера, все диммеры вешаются параллельно на одну витую пару, идущую к контроллеру. У каждого диммера задается начальный адрес и все.
Подробнее, конечно, в следующей статье.
А почему именно ModBus, а не что-нибудь полегче?
Сложно найти для реализации на микроконтроллере что-то легче и стандартнее. Масса библиотек (правда, пришлось подправить код) и такой же MAX-485. И уйма совместимых устройств. Поищите на Алиэкспрессе по слову modbus — сейчас 1851 результат. Реле, входы, диммеры, термометры. Тот же частотный регулятор для приточной вентиляции — тоже управляется по modbus. Конечно, недостатки есть. Основной — это однонаправленность протокола — один Мастер, который последовательно обращается к устройствам по адресам. Поэтому от устройств никакой инициативы не ожидается — придет время — Мастер спросит. Но простота и стандартность перекрывает недостатки.
Куда уж легче-то? Среди проводных протоколов Modbus один из лучших претендентов на стандарт для устройств «умного дома».
А что на счёт протоколов, поддерживающих мультимастер? Были попытки работать с ними?
ModBus всем хорош, но у него на шине может быть только один master, а это значит, что будут сложности с:
— автоматическим обнаружением новых устройств на шине (они не смогут рапортовать о своём подключении)
— подключением устройств типа «датчик открытия»/«выключатель» (их нужно постоянно опрашивать)
Вроде бы CAN лишен этих недостатков (кстати, у ATMEL'овских камней есть свой аналог — TWI, который также поддерживает мультимастер) и массово применяется в автомобилях, но вот в «умном доме» встречается значительно реже. Осталось понять — почему. Толи чипы дорогие, толи есть какие-то подводные камни по сравнению с ModBus/RS-485.
ModBus всем хорош, но у него на шине может быть только один master, а это значит, что будут сложности с:
— автоматическим обнаружением новых устройств на шине (они не смогут рапортовать о своём подключении)
— подключением устройств типа «датчик открытия»/«выключатель» (их нужно постоянно опрашивать)
Вроде бы CAN лишен этих недостатков (кстати, у ATMEL'овских камней есть свой аналог — TWI, который также поддерживает мультимастер) и массово применяется в автомобилях, но вот в «умном доме» встречается значительно реже. Осталось понять — почему. Толи чипы дорогие, толи есть какие-то подводные камни по сравнению с ModBus/RS-485.
TWI это же I2C вроде бы.
Ну на ESP32 будет CAN и с ним можно будет поэкспериментировать.
CAN хорош всем, вот только набор готовой копеечной переферии под CAN отсутствует.
CAN мог бы использоваться для взаимодействия между контроллерами, но с этим справляется MQTT брокер. Это, несколько, понижает надежность межпроцессорного взаимодействия (так как в цепочку добавляется сетевая инфраструктура и сам Брокер), поэтому, критичные процессы (например, терморегуляцию) держу в пределах одного контроллера.
По поводу опроса датчиков — планировал делать на 1-Wire, изначально, так как у многих устройств (например DS2408) есть функция «Conditional Search», которая позволяет не опрашивать все устройства, чтобы понять не изменилось ли что на входе у них, а сразу адресоваться к устройству, которое «хочет что-то сказать».
Возможно, доберусь до этой идеи. Хотя, сейчас эти вопросы решены подключением датчиков непосредственно на порты контроллера. Там цикл опроса позволяет не пропустить событие.
CAN хорош всем, вот только набор готовой копеечной переферии под CAN отсутствует.
CAN мог бы использоваться для взаимодействия между контроллерами, но с этим справляется MQTT брокер. Это, несколько, понижает надежность межпроцессорного взаимодействия (так как в цепочку добавляется сетевая инфраструктура и сам Брокер), поэтому, критичные процессы (например, терморегуляцию) держу в пределах одного контроллера.
По поводу опроса датчиков — планировал делать на 1-Wire, изначально, так как у многих устройств (например DS2408) есть функция «Conditional Search», которая позволяет не опрашивать все устройства, чтобы понять не изменилось ли что на входе у них, а сразу адресоваться к устройству, которое «хочет что-то сказать».
Возможно, доберусь до этой идеи. Хотя, сейчас эти вопросы решены подключением датчиков непосредственно на порты контроллера. Там цикл опроса позволяет не пропустить событие.
для dmx 512 длительность одного тика в посылке пакета 4 мкс… это 250 кГц
чем реализовали такую частоту «ногодрыга» на atmega 2560?
чем реализовали такую частоту «ногодрыга» на atmega 2560?
Я использую библиотеку DmxSimple, а она реализована следующим образом:
1. Программируется таймер (было 2 мс, я уменьшил до 1 мс.)
2. В обработчике прерывания реализована передача данных нескольких каналов, далее, управление возвращается основной программе. На следующем цикле таймера — еще несколько каналов выдаются на шину и так до последнего канала (у меня сейчас используются 60 каналов)
3. Передача самих данных реализована ассемблерной вставкой (код можно посмотреть тут, начиная со строки 120), четко таймированной по тактам для AVR (для ARM — проще). Пока процессор выдает очередную посылку (1/4 всего времени) — он больше ничем другим не занимается.
Выглядит это так:
В принципе, есть возможность (и это намного эффективнее) использовать аппаратный UART (Как это сделано в библиотеке DMXSerial)
Но эта библиотека у меня используется для приема DMX, А работать сразу в двух режимах она пока не умеет. Может быть, со временем, доработаю.
1. Программируется таймер (было 2 мс, я уменьшил до 1 мс.)
2. В обработчике прерывания реализована передача данных нескольких каналов, далее, управление возвращается основной программе. На следующем цикле таймера — еще несколько каналов выдаются на шину и так до последнего канала (у меня сейчас используются 60 каналов)
3. Передача самих данных реализована ассемблерной вставкой (код можно посмотреть тут, начиная со строки 120), четко таймированной по тактам для AVR (для ARM — проще). Пока процессор выдает очередную посылку (1/4 всего времени) — он больше ничем другим не занимается.
Выглядит это так:
В принципе, есть возможность (и это намного эффективнее) использовать аппаратный UART (Как это сделано в библиотеке DMXSerial)
Но эта библиотека у меня используется для приема DMX, А работать сразу в двух режимах она пока не умеет. Может быть, со временем, доработаю.
глядел эту либу — не понравилось.
В итоге забросил ее и делал на stm32F4… там как то комфортнее было (freeRTOS, частота шины выше). Задачка была отвязать серию диджейских светильников (dialighting и Martin) от компа и реализовать их включалку на 60 минут с возможностью корректировки стоп\старт и времени работы.
В итоге забросил ее и делал на stm32F4… там как то комфортнее было (freeRTOS, частота шины выше). Задачка была отвязать серию диджейских светильников (dialighting и Martin) от компа и реализовать их включалку на 60 минут с возможностью корректировки стоп\старт и времени работы.
Вообще, странно, что не понравилась — либа абсолютно простая и безглючная. Работать начинает за 5 минут с начала изучения. Правда, как большинство Ардуиновских либ, считает, что кроме нее на контроллере ничего работать не должно, поэтому выделяет статический буфер сразу и на все 512 каналов. Но я этот вопрос решил в своем форке., так же как со слишком большой задержкой при передачи фреймов.
Вы молодец, провели столь большую работу, но не боитесь что ардуинку лихорадит во время грозы и от сигнала работающего рядом мобильника?
Ничего не имею против, но у ардуины, как у дешёвого макетного конструктора, проблемы с развязками что на входах, что на выходах.
Ничего не имею против, но у ардуины, как у дешёвого макетного конструктора, проблемы с развязками что на входах, что на выходах.
Ну там нет проблем с развязками — развязок просто нет как класс )
Развязки обязательно добавим в Shield, через который идут все подключения от датчиков/выключателей на этапе разводки нормальной платы. (Уже скоро)
Пока подключил провода прямо на порты. Причем, с программной подтяжкой портов к +5В
Я не предполагал, в принципе, что такое может работать, не выжигая порты и не имея, как минимум, ложных срабатываний. Подключил, исключительно, для проверки/тестирования прошивки. Был готов поменять Мегу, благо, недорого. Но, на удивление, работает вообще без проблем. Длина проводов, в среднем, метров 5. Идут, местами, рядом с токонесущими. Вобщем — удивлен.
Но, конечно же, защиту-развязку портов сделаем. В таком виде оставлять на века не собираюсь.
По поводу лихорадит: Со стабильностью Openhab проблемы были (не от работающего мобильника, конечно), но со стабильностью Ардуины — пока не отмечал.
Развязки обязательно добавим в Shield, через который идут все подключения от датчиков/выключателей на этапе разводки нормальной платы. (Уже скоро)
Пока подключил провода прямо на порты. Причем, с программной подтяжкой портов к +5В
Я не предполагал, в принципе, что такое может работать, не выжигая порты и не имея, как минимум, ложных срабатываний. Подключил, исключительно, для проверки/тестирования прошивки. Был готов поменять Мегу, благо, недорого. Но, на удивление, работает вообще без проблем. Длина проводов, в среднем, метров 5. Идут, местами, рядом с токонесущими. Вобщем — удивлен.
Но, конечно же, защиту-развязку портов сделаем. В таком виде оставлять на века не собираюсь.
По поводу лихорадит: Со стабильностью Openhab проблемы были (не от работающего мобильника, конечно), но со стабильностью Ардуины — пока не отмечал.
Со стабильностью Openhab проблемы были
А можно поподробнее? А то я уже почти всю доку перечитал и почти напечатал футболку openhab…
Изредка (не чаще раз в месяц-два), OpenHab2 отваливается от шины. При этом, все остальное нормально работает -контроллеры, MQTT, NodeRed. Но вот мобильное приложение перестает управлять. Так как на OpenHab у меня не завязано какого-то там критического управляющего функционала, практически, я его использую как пульт — все продолжает работать на автопилоте.
Изначально, было чаще, но поправил проблему с Astro Binding — см. тут
То, что осталось — проблема редкая, возможно, уникальная для меня, так как в форумах такое не описано. Возможно, надо просто полностью обновить OH на последний билд — проект очень активно развивается. Ну или просто рестартовать на автомате раз в неделю.Также, думаю попробовать IOBroker вместо.
Изначально, было чаще, но поправил проблему с 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 набежит
Лампы-ленты-их блоки питания-выключатели — провода — за скобкой, это по-любому покупать.
Вентиляцию (задвижки, само вентоборудование) — тоже
Софт — весь опенсорсный
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 набежит
Лампы-ленты-их блоки питания-выключатели — провода — за скобкой, это по-любому покупать.
Вентиляцию (задвижки, само вентоборудование) — тоже
Софт — весь опенсорсный
Хотелось бы узнать подробнее про вопросы стабильной работы. Насколько часто приходиться вмешиваться и «подкручивать»?
Есть два варианта «подкручивания» — условно это Техподдержка и Развитие. Про Техподдержку: После того, как система настроена, стабилизировалась и просто работает — я про нее просто забывал. Что касается самого контроллера, он внимания не требовал от слова совсем. Что касается «сторонних» систем управления — один или два раза за год, опенсорсный OpenHab отваливался по каким-то внешним причинам от своего облака (что делало невозможным управление из за пределов жилища). Один раз он самовосстановился, во второй — я не стал ждать этого момента и перегрузил его. Надо сказать, что стабильность Опенхаб прилично выросла в его последних релизах. И теперь с этой системой, в принципе, можно начинать пробовать связываться и в коммерческих инсталляциях. Тем не менее, скоро по-нормальному скрещу свой контроллер с HomeAssistant и IOBroker. Будет из чего выбрать.
Про Развитие: ну в этом смысле, система своей гибкостью просто провоцирует что-то в ней постоянно подкручивать. Так как постоянно приходят какие-то новые идеи и очень хочется их быстро воплотить. Для такого у меня используется NodeRed, где в визуальном интерфейсе из кубиков просто конструируешь новые сценарии. Например, за полчаса сконструировал отключение теплых полов в часы, когда электроэнергия самая дорогая и уменьшение температуры по ночам. (экономия около 1 тыс/мес) Или за два часа — счетчик воды и контроль протечек. От таких вариантов, боюсь, никуда не деться. И это хорошо)
Про Развитие: ну в этом смысле, система своей гибкостью просто провоцирует что-то в ней постоянно подкручивать. Так как постоянно приходят какие-то новые идеи и очень хочется их быстро воплотить. Для такого у меня используется NodeRed, где в визуальном интерфейсе из кубиков просто конструируешь новые сценарии. Например, за полчаса сконструировал отключение теплых полов в часы, когда электроэнергия самая дорогая и уменьшение температуры по ночам. (экономия около 1 тыс/мес) Или за два часа — счетчик воды и контроль протечек. От таких вариантов, боюсь, никуда не деться. И это хорошо)
Sign up to leave a comment.
Opensource контроллер умного дома на базе Arduino Mega 2560 с поддержкой MQTT, DMX-512, 1-Wire, Modbus и Openhab