С новым годом, с новым MQTT/UDP

    Привет.

    Как я уже писал недавно (Первая краткая статья о 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 инструмент для того, чтобы глядеть на происходящее и вмешиваться:

    image

    Программы для отправки и приёма данных на Питоне, Луа и Яве.

    Коннекторы на Питоне для интеграции с обычным MQTT и напрямую с OpenHAB. Они отрабатывают защиту от циклов, запрещая обратную трансляцию сообщения в течение 5 сек после прохода в прямом направлении. Кроме того есть библиотека для ограничения потока повторных данных. Она проверяет, был ли уже апдейт данного топика в течение указанного времени, и если был, то пропускает новый апдейт только если данные изменились.

    Я планирую постепенно переехать на этот протокол полностью, и вот один из примеров того, что я хочу получить с датчиками:



    Здесь три датчика в одной комнате (ну, или на улице, не принципиально). Они отправляют отсчёты через MQTT/UDP. Получают эти отсчёты одновременно основная система умного дома (OpenHAB), база исторических данных и настенный монитор, который показывает температуру жителям.

    Вся прелесть MQTT/UDP в том, что в такой схеме отказ любого блока не создаёт никаких проблем всем остальным. И это при феерической простоте протокола.

    Более того, в этой же схеме легко реализуются и избыточные схемы управления с дублированием. Сервер БД можно сдублировать вообще без проблем. Хитрее будет сдублировать модули, которые занимаются управлением. Например, слушая температуру выдают управляющее воздействие на батареи отопления. Но, наверное, это уже следующая история. На сегодня я планирую остановиться на сборе сигналов с датчиков и обмене между модулями умного дома.
    Поделиться публикацией

    Похожие публикации

    Комментарии 112

      0
      Во сколько обходится обслуживание такого умного дома в пересчете на месяц (потребление)? И какого порядка получилась стоимость железа?
        0
        Энергопотребление вряд ли заметно на фоне остальной квартиры. Два блока питания на 100Вт суммарно, компьютер с OpenHAB — load average 0.08, то есть спит. Мелочь, которая стоит по квартире кормится с тех же блоков питания. Есть несколько десятков реле на 220 вольт, но тоже вряд ли уж они много едят. Думаю, в 200 Вт он точно укладывается суммарно.

        По деньгам — сложно сказать. Вряд ли меньше ста т.р., вряд ли больше 200.
          0
          Ужас какой. У меня весь мой умный (ну или не очень) дом вряд ли превысит 10 тыс. руб., включая RPi 3.0 c ИБП…
          Но у меня никаких сяомей и бродлинков. Только хардкор на arduino/ESP.
        0
        MQTT как он есть (а заимплеменчен везде 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 флагом, то, по идее, мы его у себя уже не увидим?
        Правда, там все асинхронное, и сообщение неизвестно когда дойдет, так что идея так себе.
          +2
          Вот это вот «всё через центр» я и хочу извести на корню. У меня два ПЛК110, OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных. И хочется не думать о том, работает юниксовая машина, или нет — модуль управления климатом должен свои данные получать в любом случае. Сейчас он почти всё получает почти напрямую от датчиков температуры, но будут и другие датчики. Часть — запасные, часть — для более сложных алгоритмов. Хочу иметь конструктор, в котором от модуля требуется только умение говорить параметр на шину и читать параметр с шины.
            +1
            100% поддерживаю!

            Все, что может работать без центра, должно работать автономно. Центр — только для каких-то сложных алгоритмов, которые требуют нетривиального взаимодействия нескольких подсистем. К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.

            У меня приятель уже ездил пару раз незапланированно на дачу из за того, что зависал Raspberry, управляющий всем, в том числе и дежурным отоплением.
              0
              К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.

              Помимо простоты реализации, также потому что надежность такой системы можно повысить гораздо легче, чем для распределенной — ставите второй хост в горячем или холодном резерве и получаете много девяток надежности.

                0
                Не однозначный вывод. Я не уверен, что можно взять вот так второй OpenHab какой-нибудь и запустить параллельно. Чтобы еще он управление в нужный момент перехватил. Или какой-нибудь Овен.
                  0

                  Да легко. Положите рядом вторую малинку с точной копией вашей основной малины и включите ей питание через реле, которое будет переключаться, например, если основная малина перестанет подавать признаки жизни — например периодически дергая какую-либо ногу — это называется ватчдог.
                  Это же реле будет отключать питание от основной малины. Таким образом при зависании вы получите автоматическое переключение на холодный резерв. Единственное, что не будет синхронизации последнего состояния, но это в принципе не так критично для УД.

                    +1
                    Если состояние не критично, то, в принципе, так сделать можно. Согласен. Останется только переключить всякие устройства, которые могут быть включены в малину. У приятеля, который ездил на дачу ее перезагружать, к GPIO линиям малины подключены блоки реле для управления термоголовками радиаторов отопления. Но это тоже решается блоком реле с переключающими контактами.

                    Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает? Я не говорю, что проблема не решается. Просто это не так уж тривиально, как вы описываете.
                      0
                      Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает?

                      Вы описываете горячий резерв, я же описал холодный — вы не заметили, что резервная малина полностью обесточена, пока основная не выйдет из строя и не переключит реле?
                      Вероятность зависания выключенной малины нулевая.

                        0
                        Зато вероятность повиснуть по совокупности входных сигналов которые привели к зависанию 1 практически 100%
                        Контроллеры управляющие обогревом, светом и т.д. должны быть простейшими, без ethernet интерфейсов и всегда с возможностью отключения по внешним аварийным датчикам.
                          0
                          Зато вероятность повиснуть по совокупности входных сигналов которые привели к зависанию 1 практически 100%

                          Чего-чего? Если у вас в системе встречаются такого рода проблемы, то у вас серьезные проблемы с программированием и резервирование тут мало поможет — оно не предназначено для защиты от кривых рук.

                            +1
                            Как линух и остальной софт на малине отнесется к TCP/UDP флуду, конфликту IP, отказу DHCP или NTP?
                            На линуксовых микрокомпьютерах гигабайты софта и 100% прогнозировать его поведение не возможно.
                            Для мелкой однокристалки без скоростных интерфейсов написать гарантировано рабочее ПО много проще.
                          0
                          Понятно. То есть арбитром будет еще какая-то схема, которая сбрасывает таймер по дрыганию ноги основной малины, а при отсутствия такого дрыгания переключает на резервную. Я сначала решил, что этим занимается как раз резервная. Но был не прав.

                          Да в таком случае резервная не повиснет. Другое дело, что такую схему надо все-таки сделать и отладить. Предусмотреть ее блокировку на время загрузки после включения питания, остановку на время техгнологических работ и т.п. То есть это не два транзистора.
                            0
                            арбитром будет еще какая-то схема, которая сбрасывает таймер по дрыганию ноги основной малины, а при отсутствия такого дрыгания переключает на резервную.

                            И она должна быть надежной и простой. Такая схема называется Watchdog и существует в миллионах готовых для применения вариантов. В случае с малиной вам подойдет простое реле-ватчдог на дин-рейку.

              0
              А через что у Вас лампы умные заинтегрированы?
                +1
                esp8266. К пинам подведены старые, отвязанные от 220В выключатели. И прошивка (Arduino IDE) поддерживает двусторонний постоянный мост между Acync TCP подключением к порту 55443 лампы и MQTT брокером.
                Если лампу включить извне через внешний сервер фирменным приложением, она напишит JSON сообщение об этом через открытое TCP соединение в esp8266, он отправит сообщение в топик MQTT. И наоборот.
              +1
              Одно дело, если у вас пара значений с датчика температуры по UDP потеряется, и совсем другое, если потеряется сообщение об открытии входной двери / срабатывания датчика движения, если в эту же систему завязать охранную сигнализацию. В MQTT все-таки можно прописать QoS = 2 с гарантированной доставкой.
                +1
                Будет, будет QoS 2. :)

                Но большинство каналов у меня в квартире — именно датчики. Только прямых аналоговых входов pt1000 порядка двадцати.

                Кстати, смысл QoS в обычном MQTT от меня ускользает. Если TCP работает, то доставка гарантирована и так. Если не работает, то какие биты в пакете не выставляй — всё прахом.
                  0
                  А как реализуется QoS2 для broadcast? Или для таких случаев все таки использовать брокера?
                    0
                    Я полагаю, что делать QoS по принципу «точно получили все» муторно и неестественно для такой концепции. Для этого нужно мониторить список всех получателей, проверять все ACK-и, плюс трафик в сети будет в разы выше. У меня есть два варианта.

                    Первый — ждать одного подтверждения, и исходить из того, что в современной сети шанс, что один получил, а остальные нет практически нулевой.

                    Второй — ждать столько же подтверждений, сколько было к предыдущему пакету. Но тут сразу столько вопросов, что ну его нафиг.

                    Есть промежуточный вариант. Ждать одного подтверждения, но при QoS 2 и подтверждение имеет QoS, причём для каждого получателя в конфигурации указывается максимальный QoS. Например, настенный индикатор вообще на QoS не реагирует и подтверждений не отправляет. Уровень 0. БД хранения истории шлёт подтверждения только на пакеты с QoS 1. А основной процессор событий отвечает с QoS 2. Тогда и отправителям можно выставить уровни важности, и каждый из них будет дожидаться подтверждения от получателя своего уровня важности. Остальные получатели — по остаточному принципу.

                    Мало того, можно 9 пакетов слать без QoS, а 10-й — с высоким уровнем.

                    Я к этой схеме склоняюсь.
                      0
                      Могу предложить еще такой вариант.

                      Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
                        0
                        Собственно, в таком варианте, мы опять потрошим брокера, передавая некоторые это функции шине, а некоторые навязываем нодам, а а в целом получаем похожий функционал.
                        0
                        Я вот подумал, что можно просто повторять каждый пакет N раз с увеличивающимися интервалами времени между повторами. Плюс должна быть возможность остановить передачу не актуальной команды (ну, например, если свет был выключен, то повторять команду «включить свет» больше не надо).
                          0
                          Да. Регулярно транслировать актуальное состояние топика — вполне решение.
                      0

                      Там QoS скорее не на случай потерь на сети (там как раз коррекция ошибок TCP все решит), а на случай проблем с брокером и/или подписчиками.

                        0
                        И как они решаются, эти проблемы? Никак. Лёг и лёг. Сделать опять ничего нельзя.
                          0

                          Если лёг подписчик, брокер будет пытаться повторить доставку. Если брокер не дал подтверждения получения, источник будет пытаться повторить публикацию. И т.д. Видимо что-то в этом роде.

                    +1
                    Основные датчики к жизненно важным системам должны быть подключены прямым ПРОВОДОМ, далее в систему «умный дом» можно собирать по IP и Wi-Fi и очень желательна автономная работа всех систем, очень неприятно остаться без света в коридоре из-за повисшего роутера.
                      0
                      Повисший роутер в такой схеме — это не самое страшное. Хуже когда он или его блок питания прикажет долго жить, а в квартире родственники проживают пока кулибин хозяин в отпуске без хорошего интернета.
                      Я бы ещё и на каждом выключателе предусмотрел физический микропереключатель, который переводит управляемый им свет в стандартный «тупой» режим.
                      Не придумал до конца как этого добиться. Есть только ряд соображений:
                      • Нужно разрабатывать и выпускать в производство универсальный управляющий блочок который:
                        • помещается в штатный «подрозетник» за обычный выключатель,
                        • способен управлять нагрузкой хотя бы до киловатта как бистабильное реле,
                        • способен получать питание будучи подключенным в разрыв с лампочкой,
                        • поддерживает стандартный выключатель или кнопку на входе (желательно 2 канала),
                        • поддерживает CAN-шину через 485 интерфейс,
                        • легко переключается в «тупой» автономный режим управления нагрузкой по триггерной схеме (для кнопки) или стандартной вкл/выкл (для выключателя)
                        • умеет возвращать свой статус,
                        • управляется адреснымсигналом,
                        • регистрируется в сети без прошивки и каких-то спец-настроек,
                        • имеет интегрированный термо-датчик и датчик влажности;

                      • Все узлы должны быть стандартные и однотипные с запасом для замены;
                      • Во все точки (выключатели, розетки, люстры, бра) подведена витая пара из щитка (идеально) или ближайшей распред, коробки (не так идеально, но для 485 интерфейса норм)
                      • К каждой точке должен идти отдельный провод ВВГнг от щитка под потолком и в кабельканале под штукатуркой в сетене;
                      • Шпаргалка с, QR-кодом (ссылка на документацию), идентификатором точки, схемой соединения спрятана в каждом выключателе и каждой розетке (не так актуально, если каждая точка без соединений в стенах подключена к щитку);


                      А остальное как у топикстартера=)
                      Вообще грустно становится, когда в стоимлсть хорошего умного дома включается полный ресмонт с заменой всей проводки. Часть выше приведённых пунктов относится к случаю, когда этот ремонт и так необходим или производится первичная отделка помещений. Часть пунктов можно исключить, если нет необходимости поддерживать «классическую» схему электроразводки с распачеными коробками и алюминиевой лапшой в стенах.

                      Казалось бы кинуть везде до выключателей только слаботочку и все… но нет. Эту схему не отыграть назад.
                        0
                        У меня в хозяйстве были древние x-10 диммеры, которые питались по симисторной схеме в разрыве питания 220В. Все подохли за год. А их релейные собраться того же производителя проработали около 10 лет и были заменены более современными модулями на esp8266.
                          +1

                          А можно увидеть схему включения esp8266 в разрыв лампы?

                            0
                            Нельзя, пришлось в каждый подрозетник протянуть ноль. Такое вполне возможно сделать незаметно, по крайней мере для комнат, но придется на время снимать дверной косяк.
                              0
                              Жаль, что у нас в помещениях такая дурацкая проводка;((
                              Но я тоже постараюсь что нибудь придумать)
                              Например сейчас есть кинетические беспроводные выключатели) найти бы ещё механизм этот отдельно, и тогда можно свой такой выключатель сделать)
                                0

                                Гораздо проще сделать на zigbee или z-vawe. Там мк на батарейках работать может годами.

                                  0
                                  Проще конечно, но батарейки(((
                                  Допустим:
                                  1. выключатель на батарейке работает 5 лет
                                  2. в квартире 10 выключателей
                                  Если батарейки в выключателях садятся по очереди, то два раза в год придётся менять какую нибудь батарейку.
                                    0
                                    Где-то видел статью, как один чел сделал в разрыв, с питанием от симистора, БП с зарядкой и li-ion аккумулятором. Пока выключено, мк (ESP8266) питается от сети и заряжается аккумулятор, когда включено, всё питается от аккумулятора.
                                    Из 10 выключателей сколько у вас сдвоенных?
                                      0

                                      Сдвоенных пара

                                      0

                                      Ну можно и так. А можно просто менять батарейки у всех выключателей сразу, даже если они еще не полностью сели. Всего-то делов на 20 минут в пять лет. Не считая времени на покупку.

                            0
                            У меня есть выключатели, которые заведены через реле, работают при полном отказе электроники, но с ней не спорят и мирно сосуществуют. Можно включить свет таким выключателем, а выключить с веб-интерфейса или мобильного приложения. Я к этому решению шёл лет двадцать. Оно довольно простое и, по сути, есть в каждом учебнике сельского электрика. :) Описать, или дать время на подумать? :)
                              0
                              Проходной выключатель. Один вумный, второй дубовый из сельпо. Гениально!
                                0
                                Жаль только с симистором схемы проходного выключателя нет(
                                  0
                                  xor (155ЛП5). но лучше взять 176-ю серию и питание 12 вольт.
                                    0
                                    176-я вообще не очень удачная, какой-то компромисс между TTL и CMOS — и питание нестандартное в узких пределах, потребление конское(по сравнению с современными CMOS), и нежность слишком высокая… 561-я серия и то лучше. А современные CMOS могут и от 1.5В работать.
                                    Но это всё фигня, проходной выключатель предполагает что в случае отказа вторая сторона зависнет в определённом положении, но если оно не зависнет а начнет глючить? Стробить будет с частотой 10Гц, например? проще уж тогда логику делать по событиям — автоматика выдает команды-события вкл-выкл-переключить, и локальный выключатель тоже даёт события вкл-выкл и управляют одним триггером состояния. Вся эта логика вмещается в маленький МК и по надёжности равна обычному механическому выключателю, при сгорании меняется из запаса как обычный выключатель.
                                      0
                                      У меня простейшая схема на ESP8266. В случае пропадания связи МК с сервером умного дома (раз в год бывает, когда обновляю много всего сразу на малине или обновляю прошивку МК), МК продолжает отрабатывать кнопки локально и локальный выключатель работает как задумано изначально. Чтобы МК завис такого не припомню ни разу за >5 лет.
                                  0
                                  Точно. :) С одной добавкой — состояние дубового нужно завести в контроллер. Тогда контроллер всегда будет знать, в какую сторону включить, а в какую — выключить.
                              0
                              Согласен.

                              В моей системе три уровня дубовости.

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

                              Второй — через промышленный контроллер Овен. За три года дал сбой один раз в самом начале работы, ошибка программы. Это — большинство выключателей на стенах, и все групповые/сценарные кнопки.

                              Третий — через сеть и OpenHAB. С появлением MQTT/UDP будет путь мимо OpenHAB-а, прямо в ПЛК.
                              +1
                              Не надо цифровую подпись, это избыточно. Достаточно HMAC или AEAD, если хочется еще и шифровать
                                0
                                О, спасибо. Я тоже думал про какие-то простые hash-based решения, но Вы мне сократили время поиска.
                                HMAC-MD5 вот отсюда, например?
                                github.com/mygityf/cipher/blob/master/cipher/hmac.c
                                  +1
                                  Ну только не MD5, упаси господь. Возьмите Blake2 или на худой конец SHA-256
                                0
                                Спасибо, тоже задумываюсь о простом способе подписывать пакеты.
                                +1
                                А топология сети так и остаётся звезда?
                                  0
                                  Ну, где-то я должен остановиться. Сетью пусть уж другие занимаются. :)
                                  Но, на практике, тут отказов пока вообще не было. Разве провод вывалится.
                                  Для этого достаточно пропингивать всё критичное, по идее.
                                  0
                                  Блин круто. Только завёл свой базовый климат на идею с MQTT и просто центральной шиной. Смысл такой. Датчики вещают, исполнительные девайсы только слушают но не датчики а свои каналы. И есть отдельный центральный контроллер который принимает решение что делать и уже транслирует решение. И мне нравится идея об исключении MQTT сервера оттуда. Может сделаю пакет на NodeJS.
                                    0
                                    Отлично. Буду очень рад! Если от меня нужна какая-то помощь — эффективнее всего ставить в репозиторий issue.
                                    0
                                    Использивание бродкаста UDP — это очешуительно хорошая идея.
                                      0

                                      Вы это сейчас с сарказмом или серьёзно? Для автоматика обычно выделяется отдельная сеть. Автор пропагандирует идею общей щины с маркированными сообщениями. Так много где делают. И MQTT брокер тут как раз такая общая шина. Ну и почему бы не сделать на бродкасте который тоже общая шина? Да возможны проблемы с амплификацией. Но если все сделать адекватно то тх не будет

                                        +1
                                        Без сарказма. Сам я не догадался, что так можно делать. Этот прием поможет заткнуть некоторые дыры.

                                        П.С. в теории то все очевидно… Когда тебе уже показали и рассказали.
                                      0

                                      А у меня вот как раз реле недавно отказало. Залипает от мороза.

                                        0

                                        Твердотельное надо. Дороже, но и проблем на порядок меньше.

                                          0
                                          В чём-то меньше, а в чем-то больше. Не залипает, конечно, но имеет свои недостатки — особенности работы на индуктивную нагрузку, может сработать ОТ ПОМЕХИ в сети — достаточно превысить скорость изменения напряжения на выводах реле… и оно откроется минимум на один полупериод. т.е. например в момент подачи напряжения, во время грозы и т.д.
                                            0
                                            тоже сдохли две стандартные синие релюшки, заменил на SSR, нет проблем больше.
                                              0
                                              А насоветуйте, какие брали?
                                                0
                                                для небольших нагрузок omron, для больших fotek. Все на али.
                                                0

                                                А симистор не поможет в этом ?

                                                  0
                                                  SSR — это симистор и есть. С оптроном.
                                                    0
                                                    это если для переменного. в SSR для постоянного тока — мосфет.
                                                      0
                                                      для переменного наверное тоже мосфеты подойдут)
                                                        0

                                                        Ага, только с парой мосфетов, плюс всякая мелочь, что существенно удорожает изделие. Зачем так изгаляться, когда проще симистор использовать...

                                                          +1
                                                          Это если управлять чисто активной нагрузкой достаточно большой мощности. Когда диапазон нагрузки очень широк, симистор может просто не удержать нагрузку и закрыться. Я с этим столкнулся и не один раз.
                                                          Потом — индуктивная нагрузка(двигатели, вентиляторы), у симисторов с ней тоже проблемы.
                                                          Тут скорей такая логика — SSR на транзисторах лучше всего и универсальней, а симисторный подходит ТОЛЬКО для переменного тока с ограничением по коммутируемой мощности нагрузки снизу и её характеру. Вот честно, я бы не стал коммутировать симистором электромагнит замка — он просто выйдет из строя или не будет работать.
                                                            0
                                                            Может быть, у меня был опыт только со светом.
                                                              0
                                                              А у меня вентилятор работал только в паре с лампочкой.
                                                                0
                                                                А у меня они на тёплых полах летят пачками. :( На реле менять не хочется — щёлкают громко…
                                                                  0
                                                                  Надо выяснить причину и устранить. Может, перегрев?
                                                                    0
                                                                    Купил радиаторы уже. Но как-то странно — они прикручены к дин-рейке, а она к шкафу. Я бы сказал, что там киловатт можно отвести не чихнув.
                                                                      0
                                                                      Так проверить греются симисторы или нет достаточно легко.
                                                                      0

                                                                      Обычная причина — неправильное шунтирование индуктивной нагрузки.

                                                                        0
                                                                        Посещала меня эта мысль. Но во всех разговорах про снабберы тёплый пол относят к активной…
                                                                          0
                                                                          Лишний снаббер не помешает. А ещё можно глянуть осциллографом что там происходит, может полов настолько много что сам провод уже даёт индуктивную составляющую.
                                                  0

                                                  Ок. Тогда RC дугогаситель параллельно катушки обычного реле. В момент разрыва цепи как раз и происходит худшее.

                                                    0
                                                    Это называют снабберной цепью. И её ставят обычно параллельно симистору, что порождает определённые проблемы.
                                                0
                                                У меня наоборот. Замок калитки не открывается иногда в мороз. Надо несколько раз нажимать и без гарантии. От чего — не понятно. Может замерзает что-то, может лед на контактах — все это на улице висит.
                                                Все собираюсь разобрать и повесить туда обычный транзистор/полевик вместо реле.
                                                  0
                                                  Намерзает после того как подал ток — катушка и сам замок немного нагревается, и тут же намерзает влага. здорово помогает всё это утопить в плотном слое вазелина. А реле поидее должно быть герметичным.
                                                    0
                                                    Не совсем так. Сам замок не при чем. Там нет контактов и он густо залит смазкой. Проблема именно в реле, которое по идее должно быть герметичным. Я слышу, что именно звук щелчка реле немного другой. Не такой как обычно. И замок при этом не срабатывает. Надо, конечно, повесить лампочку на замок, чтобы было видно, есть на нем напряжение, или нет. Но эта проблема проявляется только при -20...-25 (при том, что по паспорту приемник должен работать от 0 до +40 градусов, так что я не в обиде), так что давно уже не случалось.
                                                    А вообще, сам по себе замок работает уже почти 20 лет. Польская радиокнопка UMB-100 поменьше, но лет 10 точно. При этом, повторюсь, приемник кнопки явно для indoor установки, а висит под козырьком на улице. Так что надежность всей конструкции меня более чем устраивает. Да и при -25 достаточно несколько раз нажать брелок и замок срабатывает.
                                                      0

                                                      Какое напряжение и ток коммутирует реле?

                                                        0
                                                        12 вольт. Ток примерно 1А.
                                                          0

                                                          Я бы предположил, что напряжение маловато и может не пробивать оксидную пленку на контактах при низких температурах. Для многих типов контактов нужно минимум 24В для надежной коммутации.

                                                            0
                                                            Может и так.
                                                            Я не специалист в электронике, особенно, по ее работе в экстремальных условиях, выходящих за паспортные. Пока это меня не слишком волнует. По крайней мере, радиокнопка работает надежнее даже механической кнопки, которая иногда оказывается покрытой коркой льда и не нажимается совсем.

                                                            За то узнал массу всего интересного, что может приводить к подобному поведению. :-) Спасибо большое!
                                                              0
                                                              Это очень злая плёнка должна быть, обычно речь идёт о десятых долях вольта для обычных реле.
                                                                0

                                                                Индуктивная искрящая нагрузка, возможно даже ничем не зашунтированная. Там будет злая пленка.

                                                                  0
                                                                  Тогда бы оно не меняло звук щелчка и «поломалось» бы окончательно и безповоротно. Впрочем, в герметичном реле откуда взяться оксидной плёнке? И в плюс ко всему это происходило бы НЕЗАВИСИМО от температуры воздуха.
                                                          0
                                                          Что-то мне подсказывает, дело там вовсе не в реле а в управляющем транзисторе — на холоде ему не хватает усиления чтобы дать на реле номинальное напряжение, после первого раза транзистор прогревается и реле срабатывает. Эту проблему можно решить, заменив транзистор с большим усилением или повысив ток базы, уменьшив номинал резистора, можно ещё ввести стабилизацию в схему поставив резистор с конденсатором в цепь эмиттера транзистора, будет меньше зависеть усиление от температуры. Или вовсе применив драйвер вроде L293 где всё уже реализовано.
                                                            0
                                                            Тоже вариант.
                                                            Проблема в том, что очень сложно это тестировать. Давно не было -25 :-)Но, конечно, можно посмотреть номиналы и прикинуть, какой там запас по коэффициенту усиления.
                                                              0
                                                              для -25 есть морозилка. там порядка -20, а если регулятор выкрутить может и больше(злее).
                                                      0
                                                      У меня пока только от КЗ в нагрузке залипали… и не дома…
                                                      +3
                                                      система занимает полную битком набитую стойку о 19 дюймах ширины и двух метрах высоты. Две стенки стойки заняты почти до пола.

                                                      Простите, но чем вы ее забили?
                                                      У меня два ПЛК110, OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных.
                                                      Это все помещается в охапке. Или наличие дома 19" стойки в два метра должно вызвать дикий восторг?
                                                        0
                                                        Меня тоже удивило. Разве что электроавтоматика на автоматах громоздких каких
                                                          +1
                                                          Бесперебойники, как само собой разумеющееся, силовая часть с реле и исполнительными устройствами если надо, блоки питания, сама разводка(кросс), сетевое оборудование…
                                                            0
                                                            Сам не ожидал, брал стойку с запасом, думал, будет полупустая.

                                                            Правая стена — автоматы и 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. И справа стоит полноразмерный комп. Договорюсь с жабой и куплю ему встроенную замену.

                                                            И всё это стоит жутко тесно, так что монтажные короба уже не влезли, и монтаж некрасивый.

                                                            Знал бы — поставил бы две.
                                                              0
                                                              Наверное фото было лучше приложить;)
                                                            0

                                                            Блестящая работа!

                                                              0
                                                              Искреннее спасибо.
                                                              0
                                                              Для возможности интеграции промышленного программируемого реле встроил в интерфейс mqtt, стандартный не UDP. Плюсы:
                                                              -вся логика ложится на мозги прибора, критически важные сигналы заводим на ПР, даже если канал ляжет, есть возможность отработать алгоритм прибором
                                                              -возможность подключить к домашнему брокеру и иметь доступ из сети на ПК или планшете
                                                              -возможность использовать внешний сервис и получать доступ с разных устройств
                                                              -легко интегрировать в систему любые устройства с RS по сетевому порту ПР200
                                                              -легко интегрировать в систему любые нестандартные устройства чрез mqtt
                                                              пример работы www.youtube.com/watch?v=Ogp0U0pHQqA&feature=youtu.be&t=481

                                                                0
                                                                У меня сейчас три уровня системы, выше описал. С MQTT/UDP исключу из жизни ещё одну точку потенциального отказа. Надо бы про это отдельно написать…
                                                                0
                                                                Если автору интересно, у меня есть рабочий MQTT клиент под Codesys. Успешно работает с Home Assisstant уже около 4 месяцев. Думаю автор преувеличивает по поводу разработки и отладки подобных вещей под ПЛК.
                                                                  0
                                                                  Да, по идее, этот боржоми мне пить уже поздно. :)
                                                                  А что за контроллер? И — TCP строго в асинхронной модели обвязан?

                                                                  У меня ощущение, что в ПЛК110 от Овена таски тупо запускаются по кругу, и если в TCP есть хоть малейшая задержка — встаёт весь цикл.
                                                                    0

                                                                    Под Кодесис MQTT клиента можно купить за 50 баксов у них в магазине. У меня он тоже успешно работает с OpenHAB и NodeRED через Mosquitto.

                                                                    0

                                                                    ПЛК100. Сокет работает в неблокирующем режиме. Таски должны вызываться согласно установленной частоте из вызова, если её не задать, то по кругу. Цикл в плк вставать не должен, за этим следит вотчдог.

                                                                      0
                                                                      Вот. На старом 110 у меня TCP работал спокойно. А на новом М02 — блокирует основной цикл.

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое