Комментарии 120
По деньгам — сложно сказать. Вряд ли меньше ста т.р., вряд ли больше 200.
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 флагом, то, по идее, мы его у себя уже не увидим?
Правда, там все асинхронное, и сообщение неизвестно когда дойдет, так что идея так себе.
Все, что может работать без центра, должно работать автономно. Центр — только для каких-то сложных алгоритмов, которые требуют нетривиального взаимодействия нескольких подсистем. К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.
У меня приятель уже ездил пару раз незапланированно на дачу из за того, что зависал Raspberry, управляющий всем, в том числе и дежурным отоплением.
К сожалению, почему-то все системы именно центральные — тупые датчики и исполнительные механизмы, а весь интеллект в центральном хосте.
Помимо простоты реализации, также потому что надежность такой системы можно повысить гораздо легче, чем для распределенной — ставите второй хост в горячем или холодном резерве и получаете много девяток надежности.
Да легко. Положите рядом вторую малинку с точной копией вашей основной малины и включите ей питание через реле, которое будет переключаться, например, если основная малина перестанет подавать признаки жизни — например периодически дергая какую-либо ногу — это называется ватчдог.
Это же реле будет отключать питание от основной малины. Таким образом при зависании вы получите автоматическое переключение на холодный резерв. Единственное, что не будет синхронизации последнего состояния, но это в принципе не так критично для УД.
Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает? Я не говорю, что проблема не решается. Просто это не так уж тривиально, как вы описываете.
Другое дело, что в этом случае предполагается, что резервная малина никогда не виснет и может продиагностировать основную. А если она зависнет первой и это будет не понятно, пока основная работает?
Вы описываете горячий резерв, я же описал холодный — вы не заметили, что резервная малина полностью обесточена, пока основная не выйдет из строя и не переключит реле?
Вероятность зависания выключенной малины нулевая.
Контроллеры управляющие обогревом, светом и т.д. должны быть простейшими, без ethernet интерфейсов и всегда с возможностью отключения по внешним аварийным датчикам.
Зато вероятность повиснуть по совокупности входных сигналов которые привели к зависанию 1 практически 100%
Чего-чего? Если у вас в системе встречаются такого рода проблемы, то у вас серьезные проблемы с программированием и резервирование тут мало поможет — оно не предназначено для защиты от кривых рук.
Да в таком случае резервная не повиснет. Другое дело, что такую схему надо все-таки сделать и отладить. Предусмотреть ее блокировку на время загрузки после включения питания, остановку на время техгнологических работ и т.п. То есть это не два транзистора.
арбитром будет еще какая-то схема, которая сбрасывает таймер по дрыганию ноги основной малины, а при отсутствия такого дрыгания переключает на резервную.
И она должна быть надежной и простой. Такая схема называется Watchdog и существует в миллионах готовых для применения вариантов. В случае с малиной вам подойдет простое реле-ватчдог на дин-рейку.
Если лампу включить извне через внешний сервер фирменным приложением, она напишит JSON сообщение об этом через открытое TCP соединение в esp8266, он отправит сообщение в топик MQTT. И наоборот.
Но большинство каналов у меня в квартире — именно датчики. Только прямых аналоговых входов pt1000 порядка двадцати.
Кстати, смысл QoS в обычном MQTT от меня ускользает. Если TCP работает, то доставка гарантирована и так. Если не работает, то какие биты в пакете не выставляй — всё прахом.
Первый — ждать одного подтверждения, и исходить из того, что в современной сети шанс, что один получил, а остальные нет практически нулевой.
Второй — ждать столько же подтверждений, сколько было к предыдущему пакету. Но тут сразу столько вопросов, что ну его нафиг.
Есть промежуточный вариант. Ждать одного подтверждения, но при QoS 2 и подтверждение имеет QoS, причём для каждого получателя в конфигурации указывается максимальный QoS. Например, настенный индикатор вообще на QoS не реагирует и подтверждений не отправляет. Уровень 0. БД хранения истории шлёт подтверждения только на пакеты с QoS 1. А основной процессор событий отвечает с QoS 2. Тогда и отправителям можно выставить уровни важности, и каждый из них будет дожидаться подтверждения от получателя своего уровня важности. Остальные получатели — по остаточному принципу.
Мало того, можно 9 пакетов слать без QoS, а 10-й — с высоким уровнем.
Я к этой схеме склоняюсь.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
Я бы ещё и на каждом выключателе предусмотрел физический микропереключатель, который переводит управляемый им свет в стандартный «тупой» режим.
Не придумал до конца как этого добиться. Есть только ряд соображений:
- Нужно разрабатывать и выпускать в производство универсальный управляющий блочок который:
- помещается в штатный «подрозетник» за обычный выключатель,
- способен управлять нагрузкой хотя бы до киловатта как бистабильное реле,
- способен получать питание будучи подключенным в разрыв с лампочкой,
- поддерживает стандартный выключатель или кнопку на входе (желательно 2 канала),
- поддерживает CAN-шину через 485 интерфейс,
- легко переключается в «тупой» автономный режим управления нагрузкой по триггерной схеме (для кнопки) или стандартной вкл/выкл (для выключателя)
- умеет возвращать свой статус,
- управляется адреснымсигналом,
- регистрируется в сети без прошивки и каких-то спец-настроек,
- имеет интегрированный термо-датчик и датчик влажности;
- Все узлы должны быть стандартные и однотипные с запасом для замены;
- Во все точки (выключатели, розетки, люстры, бра) подведена витая пара из щитка (идеально) или ближайшей распред, коробки (не так идеально, но для 485 интерфейса норм)
- К каждой точке должен идти отдельный провод ВВГнг от щитка под потолком и в кабельканале под штукатуркой в сетене;
- Шпаргалка с, QR-кодом (ссылка на документацию), идентификатором точки, схемой соединения спрятана в каждом выключателе и каждой розетке (не так актуально, если каждая точка без соединений в стенах подключена к щитку);
А остальное как у топикстартера=)
Вообще грустно становится, когда в стоимлсть хорошего умного дома включается полный ресмонт с заменой всей проводки. Часть выше приведённых пунктов относится к случаю, когда этот ремонт и так необходим или производится первичная отделка помещений. Часть пунктов можно исключить, если нет необходимости поддерживать «классическую» схему электроразводки с распачеными коробками и алюминиевой лапшой в стенах.
Казалось бы кинуть везде до выключателей только слаботочку и все… но нет. Эту схему не отыграть назад.
Гораздо проще сделать на zigbee или z-vawe. Там мк на батарейках работать может годами.
Из 10 выключателей сколько у вас сдвоенных?
Ну можно и так. А можно просто менять батарейки у всех выключателей сразу, даже если они еще не полностью сели. Всего-то делов на 20 минут в пять лет. Не считая времени на покупку.
Но это всё фигня, проходной выключатель предполагает что в случае отказа вторая сторона зависнет в определённом положении, но если оно не зависнет а начнет глючить? Стробить будет с частотой 10Гц, например? проще уж тогда логику делать по событиям — автоматика выдает команды-события вкл-выкл-переключить, и локальный выключатель тоже даёт события вкл-выкл и управляют одним триггером состояния. Вся эта логика вмещается в маленький МК и по надёжности равна обычному механическому выключателю, при сгорании меняется из запаса как обычный выключатель.
В моей системе три уровня дубовости.
Нижний (для критичных светильников, минимум 2 на комнату) — прямой провод и реле, работает вообще без всего.
Второй — через промышленный контроллер Овен. За три года дал сбой один раз в самом начале работы, ошибка программы. Это — большинство выключателей на стенах, и все групповые/сценарные кнопки.
Третий — через сеть и OpenHAB. С появлением MQTT/UDP будет путь мимо OpenHAB-а, прямо в ПЛК.
HMAC-MD5 вот отсюда, например?
github.com/mygityf/cipher/blob/master/cipher/hmac.c
Насколько мне известно, непосредственно сам HMAC-MD5 ещё никто не взломал.
Вы это сейчас с сарказмом или серьёзно? Для автоматика обычно выделяется отдельная сеть. Автор пропагандирует идею общей щины с маркированными сообщениями. Так много где делают. И MQTT брокер тут как раз такая общая шина. Ну и почему бы не сделать на бродкасте который тоже общая шина? Да возможны проблемы с амплификацией. Но если все сделать адекватно то тх не будет
А у меня вот как раз реле недавно отказало. Залипает от мороза.
Твердотельное надо. Дороже, но и проблем на порядок меньше.
Ага, только с парой мосфетов, плюс всякая мелочь, что существенно удорожает изделие. Зачем так изгаляться, когда проще симистор использовать...
Потом — индуктивная нагрузка(двигатели, вентиляторы), у симисторов с ней тоже проблемы.
Тут скорей такая логика — SSR на транзисторах лучше всего и универсальней, а симисторный подходит ТОЛЬКО для переменного тока с ограничением по коммутируемой мощности нагрузки снизу и её характеру. Вот честно, я бы не стал коммутировать симистором электромагнит замка — он просто выйдет из строя или не будет работать.
Обычная причина — неправильное шунтирование индуктивной нагрузки.
Ок. Тогда RC дугогаситель параллельно катушки обычного реле. В момент разрыва цепи как раз и происходит худшее.
Все собираюсь разобрать и повесить туда обычный транзистор/полевик вместо реле.
А вообще, сам по себе замок работает уже почти 20 лет. Польская радиокнопка UMB-100 поменьше, но лет 10 точно. При этом, повторюсь, приемник кнопки явно для indoor установки, а висит под козырьком на улице. Так что надежность всей конструкции меня более чем устраивает. Да и при -25 достаточно несколько раз нажать брелок и замок срабатывает.
Какое напряжение и ток коммутирует реле?
Я бы предположил, что напряжение маловато и может не пробивать оксидную пленку на контактах при низких температурах. Для многих типов контактов нужно минимум 24В для надежной коммутации.
Я не специалист в электронике, особенно, по ее работе в экстремальных условиях, выходящих за паспортные. Пока это меня не слишком волнует. По крайней мере, радиокнопка работает надежнее даже механической кнопки, которая иногда оказывается покрытой коркой льда и не нажимается совсем.
За то узнал массу всего интересного, что может приводить к подобному поведению. :-) Спасибо большое!
Индуктивная искрящая нагрузка, возможно даже ничем не зашунтированная. Там будет злая пленка.
система занимает полную битком набитую стойку о 19 дюймах ширины и двух метрах высоты. Две стенки стойки заняты почти до пола.
Простите, но чем вы ее забили?
У меня два ПЛК110,Это все помещается в охапке. Или наличие дома 19" стойки в два метра должно вызвать дикий восторг?OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных.
Правая стена — автоматы и 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. И справа стоит полноразмерный комп. Договорюсь с жабой и куплю ему встроенную замену.
И всё это стоит жутко тесно, так что монтажные короба уже не влезли, и монтаж некрасивый.
Знал бы — поставил бы две.
Блестящая работа!
-вся логика ложится на мозги прибора, критически важные сигналы заводим на ПР, даже если канал ляжет, есть возможность отработать алгоритм прибором
-возможность подключить к домашнему брокеру и иметь доступ из сети на ПК или планшете
-возможность использовать внешний сервис и получать доступ с разных устройств
-легко интегрировать в систему любые устройства с RS по сетевому порту ПР200
-легко интегрировать в систему любые нестандартные устройства чрез mqtt
пример работы www.youtube.com/watch?v=Ogp0U0pHQqA&feature=youtu.be&t=481
А что за контроллер? И — TCP строго в асинхронной модели обвязан?
У меня ощущение, что в ПЛК110 от Овена таски тупо запускаются по кругу, и если в TCP есть хоть малейшая задержка — встаёт весь цикл.
Под Кодесис MQTT клиента можно купить за 50 баксов у них в магазине. У меня он тоже успешно работает с OpenHAB и NodeRED через Mosquitto.
ПЛК100. Сокет работает в неблокирующем режиме. Таски должны вызываться согласно установленной частоте из вызова, если её не задать, то по кругу. Цикл в плк вставать не должен, за этим следит вотчдог.
С новым годом, с новым MQTT/UDP