Pull to refresh

Comments 120

UFO just landed and posted this here
Энергопотребление вряд ли заметно на фоне остальной квартиры. Два блока питания на 100Вт суммарно, компьютер с OpenHAB — load average 0.08, то есть спит. Мелочь, которая стоит по квартире кормится с тех же блоков питания. Есть несколько десятков реле на 220 вольт, но тоже вряд ли уж они много едят. Думаю, в 200 Вт он точно укладывается суммарно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
Собственно, в таком варианте, мы опять потрошим брокера, передавая некоторые это функции шине, а некоторые навязываем нодам, а а в целом получаем похожий функционал.
Я вот подумал, что можно просто повторять каждый пакет N раз с увеличивающимися интервалами времени между повторами. Плюс должна быть возможность остановить передачу не актуальной команды (ну, например, если свет был выключен, то повторять команду «включить свет» больше не надо).
Да. Регулярно транслировать актуальное состояние топика — вполне решение.
UFO just landed and posted this here
И как они решаются, эти проблемы? Никак. Лёг и лёг. Сделать опять ничего нельзя.
UFO just landed and posted this here
Основные датчики к жизненно важным системам должны быть подключены прямым ПРОВОДОМ, далее в систему «умный дом» можно собирать по IP и Wi-Fi и очень желательна автономная работа всех систем, очень неприятно остаться без света в коридоре из-за повисшего роутера.
Повисший роутер в такой схеме — это не самое страшное. Хуже когда он или его блок питания прикажет долго жить, а в квартире родственники проживают пока кулибин хозяин в отпуске без хорошего интернета.
Я бы ещё и на каждом выключателе предусмотрел физический микропереключатель, который переводит управляемый им свет в стандартный «тупой» режим.
Не придумал до конца как этого добиться. Есть только ряд соображений:
  • Нужно разрабатывать и выпускать в производство универсальный управляющий блочок который:
    • помещается в штатный «подрозетник» за обычный выключатель,
    • способен управлять нагрузкой хотя бы до киловатта как бистабильное реле,
    • способен получать питание будучи подключенным в разрыв с лампочкой,
    • поддерживает стандартный выключатель или кнопку на входе (желательно 2 канала),
    • поддерживает CAN-шину через 485 интерфейс,
    • легко переключается в «тупой» автономный режим управления нагрузкой по триггерной схеме (для кнопки) или стандартной вкл/выкл (для выключателя)
    • умеет возвращать свой статус,
    • управляется адреснымсигналом,
    • регистрируется в сети без прошивки и каких-то спец-настроек,
    • имеет интегрированный термо-датчик и датчик влажности;

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


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

Казалось бы кинуть везде до выключателей только слаботочку и все… но нет. Эту схему не отыграть назад.
У меня в хозяйстве были древние x-10 диммеры, которые питались по симисторной схеме в разрыве питания 220В. Все подохли за год. А их релейные собраться того же производителя проработали около 10 лет и были заменены более современными модулями на esp8266.
UFO just landed and posted this here
Нельзя, пришлось в каждый подрозетник протянуть ноль. Такое вполне возможно сделать незаметно, по крайней мере для комнат, но придется на время снимать дверной косяк.
UFO just landed and posted this here

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

UFO just landed and posted this here
Где-то видел статью, как один чел сделал в разрыв, с питанием от симистора, БП с зарядкой и li-ion аккумулятором. Пока выключено, мк (ESP8266) питается от сети и заряжается аккумулятор, когда включено, всё питается от аккумулятора.
Из 10 выключателей сколько у вас сдвоенных?
UFO just landed and posted this here

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот. На старом 110 у меня TCP работал спокойно. А на новом М02 — блокирует основной цикл.
Клиент-сервер, не бродкаст, HTTP. Это вообще не то.
Уважаемый автор поделитесь насколько надежно работают Овеновские ПЛК. Вы писали, что из строя в вашем умном доме выходили все узлы. На сколько часто вас подводили ПЛК. Планирую использовать их (ПЛК) для управления оранжереей. Ваш опыт был бы интересен. Обычно для домашних целей все цепляют устройства любительского класса а пром. автоматику берут редко.
Самые надёжные части — это ПЛК и модули на базе atmega (без Юникса). Все Юниксы рано или поздно уходят в астрал.

ПЛК от Овена пока не отказывали.

Sign up to leave a comment.

Articles