Как я уже писал недавно (Первая краткая статья о MQTT/UDP), MQTT/UDP — протокол на базе MQTT, но:
- Ходит поверх UDP broadcast (не нужен брокер, почти не нужна конфигурация)
- До неприличия простой в реализации (10 строк на си + UDP/IP стек — и вы отправляете данные с сенсора)
- Все слышат всех
В некотором смысле это CAN, но поверх Ethernet-а.
Зачем.
Моя квартира реально несколько лет живёт под управлением системы типа «дом не совсем олигофрен». Умом это назвать было бы избыточно, но — свет и климат автоматизированы. Чтобы представить себе масштаб бедствия — система занимает полную битком набитую стойку о 19 дюймах ширины и двух метрах высоты. Две стенки стойки заняты почти до пола.
Когда я всё это проектировал, вопрос отказоустойчивости стоял на первом месте. Несколько лет эксплуатации показали: оно и верно. Отказывает всё. Рано или поздно. Вот только электромеханические реле ещё пока не отказывали, а именно на них последний эшелон защиты от отказа.
Следующая после отказоустойчивости проблема — зоопарк. В силу естественного течения жизни, моего любопытства и насущных потребностей, в системе живут обычный Юникс на обычном PC, ПЛК Овен, Raspberr+Orange PI, модули на Atmega, модули на базе NodeMCU (ESP8266), и всё это ходит друг к другу через modbus 485, modbus TCP, http, и сбоку висит неприкаянный MQTT брокер, как наследие неудачной попытки перейти на него всем табором.
Почему попытка перейти на MQTT неудачна. Во-первых, для части железа он тяжеловат или сложноват. На том обломке Паскаля, который прячется в CodeSys ПЛК написать MQTT может только мазохист. А ведь потом надо и отладить. Аналогично на atmega: запихать можно, но тесно. Но и это не вся беда.
MQTT как он есть (а заимплеменчен везде 3.1.1) настаивает на том, чтобы посылать PUBLISH пакет (то есть наше сообщение в сторону брокера) всем получателям, в том числе и отправителю. Эффект от этого маразма фееричен — тот же OpenHAB не может отправлять и получать данные в MQTT под одним и тем же именем. Это означает, что организовать на базе MQTT шину (несколько модулей, которые обновляют значение одного и того же объекта и пользуются им же) нельзя. А именно так должна быть организована связь ПЛК, в котором живёт основное управление светом, ОпенХАБа, который управляет светом с веб-интерфейса и мобильного приложения, и смарт-выключателей, которые я хотел бы иметь возможность добавлять там и тут. То есть, конечно, и эту проблему можно обойти, но фактически это означает построить свой протокол ПОВЕРХ MQTT, а это уже кажется перебором.
В то же время, что мне нужно? Отправить апдейт значения параметра и получить его на всех заинтересованных точках. Для чего, собственно, деды и сделали UDP на бродкастный адрес.
После прошлого поста на Хабре один из читателей долго упрекал меня ненадёжностью протокола UDP. Я же умозрительно отвечал ему, что для IoT оный UDP БОЛЕЕ надёжен, чем TCP: при 50% потерь пакетов в сети TCP не просто ляжет, а ляжет ВООБЩЕ, а температурный датчик, посылающий измерения по UDP, просто потеряет половину отсчётов, что скажется на работе системы примерно никак. Вообще.
Но это было умозрительно. Однако, новогодние каникулы и даны человеку для того, чтобы допив шампанское спросить себя: а положим сегодня домашнюю локалку на лопатки? А что бы и нет.
Я взял MQTT/UDP и написал примитивный тест. Одна сторона шлёт последовательные пакеты без паузы между пакетами, сколько может. Вторая считает скорость и потери пакетов. Эксперимент был прост: запускаем это издевательство, а параллельно два HD телевизора показывают кино из интернета, а настольный комп пишет на NAS огромный файл.
Оцените итог. Я ждал всего, но… максимум потерь на UDP достиг целого полупроцента, а оба телевизора остановили показ. Так что я ещё был пессимистом. В реальной домашней сети надёжность доставки UDP близка к абсолюту. Тем не менее, версию с подтверждениями и перепосылками пакетов я, видимо, сделаю. Сложности немного, а вопрос снимает совсем.
Второй вопрос — секьюрити, но, право, если мне взломают домашнюю сеть, потеря данных с датчиков температуры — последнее, о чём я буду горевать. Впрочем, опять же, задача цифровой подписи пакетов в issue tracker'е присутствует, и я уже понимаю, как расширить MQTT-шные пакеты под её реализацию.
В общем, я планирую по первой паре устройств в домашней сети перейти на MQTT/UDP буквально на днях.
И вам предлагаю его попробовать в своих программах и устройствах: Репозиторий и документация на английском.
Что есть в наличии:
Довольно полные реализации на Яве, Питоне и Си. Базовая реализация на Lua. Пока только отправка для Arduino и CodeSys ПЛК (тестировалось и работает на Овене, но должно пойти на чём угодно).
GUI инструмент для того, чтобы глядеть на происходящее и вмешиваться:
Программы для отправки и приёма данных на Питоне, Луа и Яве.
Коннекторы на Питоне для интеграции с обычным MQTT и напрямую с OpenHAB. Они отрабатывают защиту от циклов, запрещая обратную трансляцию сообщения в течение 5 сек после прохода в прямом направлении. Кроме того есть библиотека для ограничения потока повторных данных. Она проверяет, был ли уже апдейт данного топика в течение указанного времени, и если был, то пропускает новый апдейт только если данные изменились.
Я планирую постепенно переехать на этот протокол полностью, и вот один из примеров того, что я хочу получить с датчиками:
Здесь три датчика в одной комнате (ну, или на улице, не принципиально). Они отправляют отсчёты через MQTT/UDP. Получают эти отсчёты одновременно основная система умного дома (OpenHAB), база исторических данных и настенный монитор, который показывает температуру жителям.
Вся прелесть MQTT/UDP в том, что в такой схеме отказ любого блока не создаёт никаких проблем всем остальным. И это при феерической простоте протокола.
Более того, в этой же схеме легко реализуются и избыточные схемы управления с дублированием. Сервер БД можно сдублировать вообще без проблем. Хитрее будет сдублировать модули, которые занимаются управлением. Например, слушая температуру выдают управляющее воздействие на батареи отопления. Но, наверное, это уже следующая история. На сегодня я планирую остановиться на сборе сигналов с датчиков и обмене между модулями умного дома.
Комментарии (96)
IRT
08.01.2019 23:12MQTT как он есть (а заимплеменчен везде 3.1.1) настаивает на том, чтобы посылать PUBLISH пакет (то есть наше сообщение в сторону брокера) всем получателям, в том числе и отправителю. Эффект от этого маразма фееричен — тот же OpenHAB не может отправлять и получать данные в MQTT под одним и тем же именем. Это означает, что организовать на базе MQTT шину (несколько модулей, которые обновляют значение одного и того же объекта и пользуются им же) нельзя.
Есть такое. Для управления светом не критично, допустим при нажатии аппаратной кнопки включается свет через Wi-Fi Async TCP командой (лампы Xiaomi Yeelight) и тут же пишется сообщение «1» в MQTT топик home/lights/room. Контроллер ловит еденицу в топике и еще раз отправляет команду на включение света через Wi-Fi, которая ни на что не влияет, свет уже включился.
Если сильно критично, то к топику можно дописать set/get, например home/lights/room/set
Но это изврат. Так делает, например, homebridge-mqtt, мост с яблочным Homekit.
Я у себя текущие значения всех топиков храню в ОЗУ своей управляющей программы-демона. И вся логика прописана в ней, она разруливает все ситуации. Но теряется автономная связь модулей между собой, все идет через центр.
Кстати, а если сделать UNSUBSCRIBE от топика, послать сообщение, а потом заново подписаться? Если сообщение не с Retain флагом, то, по идее, мы его у себя уже не увидим?
Правда, там все асинхронное, и сообщение неизвестно когда дойдет, так что идея так себе.dzavalishin Автор
09.01.2019 01:40Вот это вот «всё через центр» я и хочу извести на корню. У меня два ПЛК110, OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных. И хочется не думать о том, работает юниксовая машина, или нет — модуль управления климатом должен свои данные получать в любом случае. Сейчас он почти всё получает почти напрямую от датчиков температуры, но будут и другие датчики. Часть — запасные, часть — для более сложных алгоритмов. Хочу иметь конструктор, в котором от модуля требуется только умение говорить параметр на шину и читать параметр с шины.
ProstoUser
09.01.2019 18:10100% поддерживаю!
Все, что может работать без центра, должно работать автономно. Центр — только для каких-то сложных алгоритмов, которые требуют нетривиального взаимодействия нескольких подсистем. К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.
У меня приятель уже ездил пару раз незапланированно на дачу из за того, что зависал Raspberry, управляющий всем, в том числе и дежурным отоплением.lingvo
10.01.2019 15:56К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.
Помимо простоты реализации, также потому что надежность такой системы можно повысить гораздо легче, чем для распределенной — ставите второй хост в горячем или холодном резерве и получаете много девяток надежности.
ProstoUser
10.01.2019 17:27Не однозначный вывод. Я не уверен, что можно взять вот так второй OpenHab какой-нибудь и запустить параллельно. Чтобы еще он управление в нужный момент перехватил. Или какой-нибудь Овен.
lingvo
10.01.2019 17:34Да легко. Положите рядом вторую малинку с точной копией вашей основной малины и включите ей питание через реле, которое будет переключаться, например, если основная малина перестанет подавать признаки жизни — например периодически дергая какую-либо ногу — это называется ватчдог.
Это же реле будет отключать питание от основной малины. Таким образом при зависании вы получите автоматическое переключение на холодный резерв. Единственное, что не будет синхронизации последнего состояния, но это в принципе не так критично для УД.ProstoUser
10.01.2019 18:50Если состояние не критично, то, в принципе, так сделать можно. Согласен. Останется только переключить всякие устройства, которые могут быть включены в малину. У приятеля, который ездил на дачу ее перезагружать, к GPIO линиям малины подключены блоки реле для управления термоголовками радиаторов отопления. Но это тоже решается блоком реле с переключающими контактами.
Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает? Я не говорю, что проблема не решается. Просто это не так уж тривиально, как вы описываете.lingvo
10.01.2019 20:31Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает?
Вы описываете горячий резерв, я же описал холодный — вы не заметили, что резервная малина полностью обесточена, пока основная не выйдет из строя и не переключит реле?
Вероятность зависания выключенной малины нулевая.Ivanii
10.01.2019 20:38Зато вероятность повиснуть по совокупности входных сигналов которые привели к зависанию 1 практически 100%
Контроллеры управляющие обогревом, светом и т.д. должны быть простейшими, без ethernet интерфейсов и всегда с возможностью отключения по внешним аварийным датчикам.lingvo
10.01.2019 21:03Зато вероятность повиснуть по совокупности входных сигналов которые привели к зависанию 1 практически 100%
Чего-чего? Если у вас в системе встречаются такого рода проблемы, то у вас серьезные проблемы с программированием и резервирование тут мало поможет — оно не предназначено для защиты от кривых рук.
Ivanii
10.01.2019 22:10Как линух и остальной софт на малине отнесется к TCP/UDP флуду, конфликту IP, отказу DHCP или NTP?
На линуксовых микрокомпьютерах гигабайты софта и 100% прогнозировать его поведение не возможно.
Для мелкой однокристалки без скоростных интерфейсов написать гарантировано рабочее ПО много проще.
ProstoUser
10.01.2019 21:14Понятно. То есть арбитром будет еще какая-то схема, которая сбрасывает таймер по дрыганию ноги основной малины, а при отсутствия такого дрыгания переключает на резервную. Я сначала решил, что этим занимается как раз резервная. Но был не прав.
Да в таком случае резервная не повиснет. Другое дело, что такую схему надо все-таки сделать и отладить. Предусмотреть ее блокировку на время загрузки после включения питания, остановку на время техгнологических работ и т.п. То есть это не два транзистора.lingvo
10.01.2019 21:36арбитром будет еще какая-то схема, которая сбрасывает таймер по дрыганию ноги основной малины, а при отсутствия такого дрыгания переключает на резервную.
И она должна быть надежной и простой. Такая схема называется Watchdog и существует в миллионах готовых для применения вариантов. В случае с малиной вам подойдет простое реле-ватчдог на дин-рейку.
dzavalishin Автор
09.01.2019 01:41А через что у Вас лампы умные заинтегрированы?
IRT
09.01.2019 07:34esp8266. К пинам подведены старые, отвязанные от 220В выключатели. И прошивка (Arduino IDE) поддерживает двусторонний постоянный мост между Acync TCP подключением к порту 55443 лампы и MQTT брокером.
Если лампу включить извне через внешний сервер фирменным приложением, она напишит JSON сообщение об этом через открытое TCP соединение в esp8266, он отправит сообщение в топик MQTT. И наоборот.
IRT
08.01.2019 23:19Одно дело, если у вас пара значений с датчика температуры по UDP потеряется, и совсем другое, если потеряется сообщение об открытии входной двери / срабатывания датчика движения, если в эту же систему завязать охранную сигнализацию. В MQTT все-таки можно прописать QoS = 2 с гарантированной доставкой.
dzavalishin Автор
09.01.2019 01:36Будет, будет QoS 2. :)
Но большинство каналов у меня в квартире — именно датчики. Только прямых аналоговых входов pt1000 порядка двадцати.
Кстати, смысл QoS в обычном MQTT от меня ускользает. Если TCP работает, то доставка гарантирована и так. Если не работает, то какие биты в пакете не выставляй — всё прахом.
netricks
09.01.2019 12:56А как реализуется QoS2 для broadcast? Или для таких случаев все таки использовать брокера?
dzavalishin Автор
09.01.2019 21:20Я полагаю, что делать QoS по принципу «точно получили все» муторно и неестественно для такой концепции. Для этого нужно мониторить список всех получателей, проверять все ACK-и, плюс трафик в сети будет в разы выше. У меня есть два варианта.
Первый — ждать одного подтверждения, и исходить из того, что в современной сети шанс, что один получил, а остальные нет практически нулевой.
Второй — ждать столько же подтверждений, сколько было к предыдущему пакету. Но тут сразу столько вопросов, что ну его нафиг.
Есть промежуточный вариант. Ждать одного подтверждения, но при QoS 2 и подтверждение имеет QoS, причём для каждого получателя в конфигурации указывается максимальный QoS. Например, настенный индикатор вообще на QoS не реагирует и подтверждений не отправляет. Уровень 0. БД хранения истории шлёт подтверждения только на пакеты с QoS 1. А основной процессор событий отвечает с QoS 2. Тогда и отправителям можно выставить уровни важности, и каждый из них будет дожидаться подтверждения от получателя своего уровня важности. Остальные получатели — по остаточному принципу.
Мало того, можно 9 пакетов слать без QoS, а 10-й — с высоким уровнем.
Я к этой схеме склоняюсь.netricks
09.01.2019 22:27Могу предложить еще такой вариант.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.netricks
09.01.2019 22:40Собственно, в таком варианте, мы опять потрошим брокера, передавая некоторые это функции шине, а некоторые навязываем нодам, а а в целом получаем похожий функционал.
Whuthering
09.01.2019 20:53Там QoS скорее не на случай потерь на сети (там как раз коррекция ошибок TCP все решит), а на случай проблем с брокером и/или подписчиками.
dzavalishin Автор
09.01.2019 21:22И как они решаются, эти проблемы? Никак. Лёг и лёг. Сделать опять ничего нельзя.
Whuthering
10.01.2019 17:07Если лёг подписчик, брокер будет пытаться повторить доставку. Если брокер не дал подтверждения получения, источник будет пытаться повторить публикацию. И т.д. Видимо что-то в этом роде.
Ivanii
09.01.2019 07:29Основные датчики к жизненно важным системам должны быть подключены прямым ПРОВОДОМ, далее в систему «умный дом» можно собирать по IP и Wi-Fi и очень желательна автономная работа всех систем, очень неприятно остаться без света в коридоре из-за повисшего роутера.
trapwalker
09.01.2019 16:50Повисший роутер в такой схеме — это не самое страшное. Хуже когда он или его блок питания прикажет долго жить, а в квартире родственники проживают пока
кулибинхозяин в отпуске без хорошего интернета.
Я бы ещё и на каждом выключателе предусмотрел физический микропереключатель, который переводит управляемый им свет в стандартный «тупой» режим.
Не придумал до конца как этого добиться. Есть только ряд соображений:
- Нужно разрабатывать и выпускать в производство универсальный управляющий блочок который:
- помещается в штатный «подрозетник» за обычный выключатель,
- способен управлять нагрузкой хотя бы до киловатта как бистабильное реле,
- способен получать питание будучи подключенным в разрыв с лампочкой,
- поддерживает стандартный выключатель или кнопку на входе (желательно 2 канала),
- поддерживает CAN-шину через 485 интерфейс,
- легко переключается в «тупой» автономный режим управления нагрузкой по триггерной схеме (для кнопки) или стандартной вкл/выкл (для выключателя)
- умеет возвращать свой статус,
- управляется адреснымсигналом,
- регистрируется в сети без прошивки и каких-то спец-настроек,
- имеет интегрированный термо-датчик и датчик влажности;
- Все узлы должны быть стандартные и однотипные с запасом для замены;
- Во все точки (выключатели, розетки, люстры, бра) подведена витая пара из щитка (идеально) или ближайшей распред, коробки (не так идеально, но для 485 интерфейса норм)
- К каждой точке должен идти отдельный провод ВВГнг от щитка под потолком и в кабельканале под штукатуркой в сетене;
- Шпаргалка с, QR-кодом (ссылка на документацию), идентификатором точки, схемой соединения спрятана в каждом выключателе и каждой розетке (не так актуально, если каждая точка без соединений в стенах подключена к щитку);
А остальное как у топикстартера=)
Вообще грустно становится, когда в стоимлсть хорошего умного дома включается полный ресмонт с заменой всей проводки. Часть выше приведённых пунктов относится к случаю, когда этот ремонт и так необходим или производится первичная отделка помещений. Часть пунктов можно исключить, если нет необходимости поддерживать «классическую» схему электроразводки с распачеными коробками и алюминиевой лапшой в стенах.
Казалось бы кинуть везде до выключателей только слаботочку и все… но нет. Эту схему не отыграть назад.safari2012
09.01.2019 18:44У меня в хозяйстве были древние x-10 диммеры, которые питались по симисторной схеме в разрыве питания 220В. Все подохли за год. А их релейные собраться того же производителя проработали около 10 лет и были заменены более современными модулями на esp8266.
dernuss
09.01.2019 19:46А можно увидеть схему включения esp8266 в разрыв лампы?
safari2012
10.01.2019 11:22Нельзя, пришлось в каждый подрозетник протянуть ноль. Такое вполне возможно сделать незаметно, по крайней мере для комнат, но придется на время снимать дверной косяк.
dernuss
10.01.2019 21:09Жаль, что у нас в помещениях такая дурацкая проводка;((
Но я тоже постараюсь что нибудь придумать)
Например сейчас есть кинетические беспроводные выключатели) найти бы ещё механизм этот отдельно, и тогда можно свой такой выключатель сделать)safari2012
10.01.2019 22:02Гораздо проще сделать на zigbee или z-vawe. Там мк на батарейках работать может годами.
dernuss
11.01.2019 09:53Проще конечно, но батарейки(((
Допустим:
1. выключатель на батарейке работает 5 лет
2. в квартире 10 выключателей
Если батарейки в выключателях садятся по очереди, то два раза в год придётся менять какую нибудь батарейку.safari2012
11.01.2019 12:47Где-то видел статью, как один чел сделал в разрыв, с питанием от симистора, БП с зарядкой и li-ion аккумулятором. Пока выключено, мк (ESP8266) питается от сети и заряжается аккумулятор, когда включено, всё питается от аккумулятора.
Из 10 выключателей сколько у вас сдвоенных?
dzavalishin Автор
09.01.2019 21:29У меня есть выключатели, которые заведены через реле, работают при полном отказе электроники, но с ней не спорят и мирно сосуществуют. Можно включить свет таким выключателем, а выключить с веб-интерфейса или мобильного приложения. Я к этому решению шёл лет двадцать. Оно довольно простое и, по сути, есть в каждом учебнике сельского электрика. :) Описать, или дать время на подумать? :)
vanxant
10.01.2019 04:01Проходной выключатель. Один вумный, второй дубовый из сельпо. Гениально!
dernuss
10.01.2019 21:14Жаль только с симистором схемы проходного выключателя нет(
dzavalishin Автор
10.01.2019 23:55xor (155ЛП5). но лучше взять 176-ю серию и питание 12 вольт.
Alexeyslav
11.01.2019 10:42176-я вообще не очень удачная, какой-то компромисс между TTL и CMOS — и питание нестандартное в узких пределах, потребление конское(по сравнению с современными CMOS), и нежность слишком высокая… 561-я серия и то лучше. А современные CMOS могут и от 1.5В работать.
Но это всё фигня, проходной выключатель предполагает что в случае отказа вторая сторона зависнет в определённом положении, но если оно не зависнет а начнет глючить? Стробить будет с частотой 10Гц, например? проще уж тогда логику делать по событиям — автоматика выдает команды-события вкл-выкл-переключить, и локальный выключатель тоже даёт события вкл-выкл и управляют одним триггером состояния. Вся эта логика вмещается в маленький МК и по надёжности равна обычному механическому выключателю, при сгорании меняется из запаса как обычный выключатель.safari2012
11.01.2019 12:52У меня простейшая схема на ESP8266. В случае пропадания связи МК с сервером умного дома (раз в год бывает, когда обновляю много всего сразу на малине или обновляю прошивку МК), МК продолжает отрабатывать кнопки локально и локальный выключатель работает как задумано изначально. Чтобы МК завис такого не припомню ни разу за >5 лет.
dzavalishin Автор
10.01.2019 23:52Точно. :) С одной добавкой — состояние дубового нужно завести в контроллер. Тогда контроллер всегда будет знать, в какую сторону включить, а в какую — выключить.
- Нужно разрабатывать и выпускать в производство универсальный управляющий блочок который:
dzavalishin Автор
09.01.2019 21:25Согласен.
В моей системе три уровня дубовости.
Нижний (для критичных светильников, минимум 2 на комнату) — прямой провод и реле, работает вообще без всего.
Второй — через промышленный контроллер Овен. За три года дал сбой один раз в самом начале работы, ошибка программы. Это — большинство выключателей на стенах, и все групповые/сценарные кнопки.
Третий — через сеть и OpenHAB. С появлением MQTT/UDP будет путь мимо OpenHAB-а, прямо в ПЛК.
Scratch
09.01.2019 07:50Не надо цифровую подпись, это избыточно. Достаточно HMAC или AEAD, если хочется еще и шифровать
dzavalishin Автор
09.01.2019 21:46О, спасибо. Я тоже думал про какие-то простые hash-based решения, но Вы мне сократили время поиска.
HMAC-MD5 вот отсюда, например?
github.com/mygityf/cipher/blob/master/cipher/hmac.cScratch
10.01.2019 16:04+1Ну только не MD5, упаси господь. Возьмите Blake2 или на худой конец SHA-256
firegurafiku
11.01.2019 02:15Насколько мне известно, непосредственно сам HMAC-MD5 ещё никто не взломал.
Stronix
09.01.2019 09:17А топология сети так и остаётся звезда?
dzavalishin Автор
09.01.2019 21:48Ну, где-то я должен остановиться. Сетью пусть уж другие занимаются. :)
Но, на практике, тут отказов пока вообще не было. Разве провод вывалится.
Для этого достаточно пропингивать всё критичное, по идее.
Aquahawk
09.01.2019 11:01Блин круто. Только завёл свой базовый климат на идею с MQTT и просто центральной шиной. Смысл такой. Датчики вещают, исполнительные девайсы только слушают но не датчики а свои каналы. И есть отдельный центральный контроллер который принимает решение что делать и уже транслирует решение. И мне нравится идея об исключении MQTT сервера оттуда. Может сделаю пакет на NodeJS.
dzavalishin Автор
09.01.2019 21:49Отлично. Буду очень рад! Если от меня нужна какая-то помощь — эффективнее всего ставить в репозиторий issue.
netricks
09.01.2019 12:42Использивание бродкаста UDP — это очешуительно хорошая идея.
Aquahawk
09.01.2019 13:31Вы это сейчас с сарказмом или серьёзно? Для автоматика обычно выделяется отдельная сеть. Автор пропагандирует идею общей щины с маркированными сообщениями. Так много где делают. И MQTT брокер тут как раз такая общая шина. Ну и почему бы не сделать на бродкасте который тоже общая шина? Да возможны проблемы с амплификацией. Но если все сделать адекватно то тх не будет
netricks
09.01.2019 15:43Без сарказма. Сам я не догадался, что так можно делать. Этот прием поможет заткнуть некоторые дыры.
П.С. в теории то все очевидно… Когда тебе уже показали и рассказали.
unwrecker
09.01.2019 14:28А у меня вот как раз реле недавно отказало. Залипает от мороза.
Ksiw
09.01.2019 15:03Твердотельное надо. Дороже, но и проблем на порядок меньше.
Alexeyslav
09.01.2019 18:03В чём-то меньше, а в чем-то больше. Не залипает, конечно, но имеет свои недостатки — особенности работы на индуктивную нагрузку, может сработать ОТ ПОМЕХИ в сети — достаточно превысить скорость изменения напряжения на выводах реле… и оно откроется минимум на один полупериод. т.е. например в момент подачи напряжения, во время грозы и т.д.
safari2012
09.01.2019 18:47тоже сдохли две стандартные синие релюшки, заменил на SSR, нет проблем больше.
dernuss
09.01.2019 19:48А симистор не поможет в этом ?
dzavalishin Автор
09.01.2019 21:50SSR — это симистор и есть. С оптроном.
safari2012
10.01.2019 11:32это если для переменного. в SSR для постоянного тока — мосфет.
dernuss
10.01.2019 21:04для переменного наверное тоже мосфеты подойдут)
safari2012
10.01.2019 22:04Ага, только с парой мосфетов, плюс всякая мелочь, что существенно удорожает изделие. Зачем так изгаляться, когда проще симистор использовать...
Alexeyslav
11.01.2019 10:51+1Это если управлять чисто активной нагрузкой достаточно большой мощности. Когда диапазон нагрузки очень широк, симистор может просто не удержать нагрузку и закрыться. Я с этим столкнулся и не один раз.
Потом — индуктивная нагрузка(двигатели, вентиляторы), у симисторов с ней тоже проблемы.
Тут скорей такая логика — SSR на транзисторах лучше всего и универсальней, а симисторный подходит ТОЛЬКО для переменного тока с ограничением по коммутируемой мощности нагрузки снизу и её характеру. Вот честно, я бы не стал коммутировать симистором электромагнит замка — он просто выйдет из строя или не будет работать.
Ksiw
09.01.2019 22:44Ок. Тогда RC дугогаситель параллельно катушки обычного реле. В момент разрыва цепи как раз и происходит худшее.
Alexeyslav
10.01.2019 15:48Это называют снабберной цепью. И её ставят обычно параллельно симистору, что порождает определённые проблемы.
ProstoUser
09.01.2019 18:59У меня наоборот. Замок калитки не открывается иногда в мороз. Надо несколько раз нажимать и без гарантии. От чего — не понятно. Может замерзает что-то, может лед на контактах — все это на улице висит.
Все собираюсь разобрать и повесить туда обычный транзистор/полевик вместо реле.Alexeyslav
10.01.2019 16:00Намерзает после того как подал ток — катушка и сам замок немного нагревается, и тут же намерзает влага. здорово помогает всё это утопить в плотном слое вазелина. А реле поидее должно быть герметичным.
ProstoUser
10.01.2019 17:24Не совсем так. Сам замок не при чем. Там нет контактов и он густо залит смазкой. Проблема именно в реле, которое по идее должно быть герметичным. Я слышу, что именно звук щелчка реле немного другой. Не такой как обычно. И замок при этом не срабатывает. Надо, конечно, повесить лампочку на замок, чтобы было видно, есть на нем напряжение, или нет. Но эта проблема проявляется только при -20...-25 (при том, что по паспорту приемник должен работать от 0 до +40 градусов, так что я не в обиде), так что давно уже не случалось.
А вообще, сам по себе замок работает уже почти 20 лет. Польская радиокнопка UMB-100 поменьше, но лет 10 точно. При этом, повторюсь, приемник кнопки явно для indoor установки, а висит под козырьком на улице. Так что надежность всей конструкции меня более чем устраивает. Да и при -25 достаточно несколько раз нажать брелок и замок срабатывает.lingvo
10.01.2019 17:28Какое напряжение и ток коммутирует реле?
ProstoUser
10.01.2019 18:5012 вольт. Ток примерно 1А.
lingvo
10.01.2019 20:33Я бы предположил, что напряжение маловато и может не пробивать оксидную пленку на контактах при низких температурах. Для многих типов контактов нужно минимум 24В для надежной коммутации.
ProstoUser
10.01.2019 21:31Может и так.
Я не специалист в электронике, особенно, по ее работе в экстремальных условиях, выходящих за паспортные. Пока это меня не слишком волнует. По крайней мере, радиокнопка работает надежнее даже механической кнопки, которая иногда оказывается покрытой коркой льда и не нажимается совсем.
За то узнал массу всего интересного, что может приводить к подобному поведению. :-) Спасибо большое!
Alexeyslav
11.01.2019 10:54Это очень злая плёнка должна быть, обычно речь идёт о десятых долях вольта для обычных реле.
Alexeyslav
10.01.2019 17:53Что-то мне подсказывает, дело там вовсе не в реле а в управляющем транзисторе — на холоде ему не хватает усиления чтобы дать на реле номинальное напряжение, после первого раза транзистор прогревается и реле срабатывает. Эту проблему можно решить, заменив транзистор с большим усилением или повысив ток базы, уменьшив номинал резистора, можно ещё ввести стабилизацию в схему поставив резистор с конденсатором в цепь эмиттера транзистора, будет меньше зависеть усиление от температуры. Или вовсе применив драйвер вроде L293 где всё уже реализовано.
ProstoUser
10.01.2019 18:58Тоже вариант.
Проблема в том, что очень сложно это тестировать. Давно не было -25 :-)Но, конечно, можно посмотреть номиналы и прикинуть, какой там запас по коэффициенту усиления.Alexeyslav
11.01.2019 10:53для -25 есть морозилка. там порядка -20, а если регулятор выкрутить может и больше(злее).
Segmentq
09.01.2019 14:35система занимает полную битком набитую стойку о 19 дюймах ширины и двух метрах высоты. Две стенки стойки заняты почти до пола.
Простите, но чем вы ее забили?
У меня два ПЛК110,
Это все помещается в охапке. Или наличие дома 19" стойки в два метра должно вызвать дикий восторг?OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных.Alexeyslav
09.01.2019 17:56Бесперебойники, как само собой разумеющееся, силовая часть с реле и исполнительными устройствами если надо, блоки питания, сама разводка(кросс), сетевое оборудование…
dzavalishin Автор
09.01.2019 22:08Сам не ожидал, брал стойку с запасом, думал, будет полупустая.
Правая стена — автоматы и SSR тёплого пола, тут я немного параноик и все группы нагрузки имеют свой 2-ной автомат, плюс УЗО на пять групп автоматов, плюс вводные автомат, УЗО, трансформаторы тока, варисторы, модуль измерения МЭ110, блоки питания низковольтки * 3, розетки, клеммники света, кормушки — это занимает 80% стенки.
Передняя стена: клеммники выключателей, три модуля МДВВ (8 вых каналов, 12 вх — прямые линии управления и группы), три МВА (8 аналоговых каналов), около 30 реле, контроллер ПЛК110.60 (свет), ПЛК110.30 (климат), два tcp to RS485 модуля, 4-канальный боевой и 1-канальная МОХА для отладки и конфигурирования, два модуля самодельных.
Это ровно пол-фронтальной поверхности. Верите, нет? :)
Дальше — патч-панель для слаботочки (датчики и мелочь) на плинтах, девять плинтов, два юнита. Потом в 2 юнита высотой рейка с CCU825, ещё одним Овен-ом (пока не задействован) и предохранителями питания вынесенной из шкафа слаботочки. Иначе хорошие питальники легко выжгут витую пару в стенах при КЗ.
Патч-панель на 48 портов (да, 24 не хватает), роутер и свитч.
Ниже полка для мелкого безвентиляторного писи, мониторчика и др. нерековой ерунды. Потом раздатка питания и подвал. Туда должны были пойти UPS, но так и не дошли.
Всё.
А ещё на верхней полке живут WiFi и два NAS. И справа стоит полноразмерный комп. Договорюсь с жабой и куплю ему встроенную замену.
И всё это стоит жутко тесно, так что монтажные короба уже не влезли, и монтаж некрасивый.
Знал бы — поставил бы две.
PR200SD
09.01.2019 20:52Для возможности интеграции промышленного программируемого реле встроил в интерфейс mqtt, стандартный не UDP. Плюсы:
-вся логика ложится на мозги прибора, критически важные сигналы заводим на ПР, даже если канал ляжет, есть возможность отработать алгоритм прибором
-возможность подключить к домашнему брокеру и иметь доступ из сети на ПК или планшете
-возможность использовать внешний сервис и получать доступ с разных устройств
-легко интегрировать в систему любые устройства с RS по сетевому порту ПР200
-легко интегрировать в систему любые нестандартные устройства чрез mqtt
пример работы www.youtube.com/watch?v=Ogp0U0pHQqA&feature=youtu.be&t=481
dzavalishin Автор
09.01.2019 22:11У меня сейчас три уровня системы, выше описал. С MQTT/UDP исключу из жизни ещё одну точку потенциального отказа. Надо бы про это отдельно написать…
krug2000
11.01.2019 01:38Если автору интересно, у меня есть рабочий MQTT клиент под Codesys. Успешно работает с Home Assisstant уже около 4 месяцев. Думаю автор преувеличивает по поводу разработки и отладки подобных вещей под ПЛК.
dzavalishin Автор
11.01.2019 01:41Да, по идее, этот боржоми мне пить уже поздно. :)
А что за контроллер? И — TCP строго в асинхронной модели обвязан?
У меня ощущение, что в ПЛК110 от Овена таски тупо запускаются по кругу, и если в TCP есть хоть малейшая задержка — встаёт весь цикл.
krug2000
11.01.2019 01:52ПЛК100. Сокет работает в неблокирующем режиме. Таски должны вызываться согласно установленной частоте из вызова, если её не задать, то по кругу. Цикл в плк вставать не должен, за этим следит вотчдог.
merhalak
Во сколько обходится обслуживание такого умного дома в пересчете на месяц (потребление)? И какого порядка получилась стоимость железа?
dzavalishin Автор
Энергопотребление вряд ли заметно на фоне остальной квартиры. Два блока питания на 100Вт суммарно, компьютер с OpenHAB — load average 0.08, то есть спит. Мелочь, которая стоит по квартире кормится с тех же блоков питания. Есть несколько десятков реле на 220 вольт, но тоже вряд ли уж они много едят. Думаю, в 200 Вт он точно укладывается суммарно.
По деньгам — сложно сказать. Вряд ли меньше ста т.р., вряд ли больше 200.
safari2012
Ужас какой. У меня весь мой умный (ну или не очень) дом вряд ли превысит 10 тыс. руб., включая RPi 3.0 c ИБП…
Но у меня никаких сяомей и бродлинков. Только хардкор на arduino/ESP.