Планирую систему автоматизации в квартиру.
Для реализации сценариев управления светом необходимо обрабатывать нажатия выключателей-кнопок в помещениях центральным контроллером и делать нужные действия.
Например: ночью по первому нажатию кнопки включать свет на 20%, при втором подряд нажатии – на 100%.
Тянуть от каждого выключателя провода в центральный щит совсем нет желания.
Предполагаю поставить «локальные» блоки ввода/вывода в каждое помещение и подключить их по RS-485 к центральному контроллеру.
Соответственно с этого «локального» блока управлять нагрузкой (свет) и на нем считывать входы (кнопки/выключатели).
Если с управлением нагрузками все понятно – есть множество реле/диммеров с управлением по RS-485.
То с кнопками есть вопросы.
Основной вопрос – какая реальная задержка от момента «нажал кнопку» до «контроллер понял, что нажата кнопка»?
Почитал темы на форуме – смотрю, что с этим бывают проблемы.
Я планирую на шину RS-485 около 20 разных устройств, в т.ч. там должны быть 5 вот этих «локальных» блоков, которые будут считывать показания от 2 до 4 кнопок/выключателей каждый.
Будет ли фиксироваться нажатия в пределах миллисекунд (как при обычном физическом подключении)? или нужно будет держать кнопку по полсекунды-секунде?
Есть ли рекомендации по выбору таких вот локальных блоков? Подойдут ли WB-MR3 или лучше рассмотреть другие? Или вообще не совмещать устройства, а взять отдельно устройства для управления нагрузкой и отдельно для считывания входов?
но почему выключатели по RS-485? Почему не радио/z-wave?
рассматриваю и вариант радио. но, считаю что проводное соединение надежнее. а раз уж в комнатах все равно будут локальные блоки управления светом/отоплением/пр., подключенные к общей RS-485 шине – почему бы не подцепить к этим блокам и выключатели.
но вот вопрос задержек меня беспокоит, ведь в modbus слейвы только в режиме полинга существуют, получается мастеру нужно «бегать» по кругу и опрашивать все устройства на линии. из теории посмотрел, что там в modbus есть специальные задержки, которые вставляются между командами. а т.к. практического опыта с modbus нет, то не понятно, на сколько большие эти задержки и будут ли «лаги» при определении нажатий на выключатели со стороны центрального контроллера.
Использую дискретные входы на модулях расширения WB + китайские modbus. Нормально работает все это, отрабатывает кнопки при кратковременном нажатии. Но проблема может быть. К примеру с китайскими модулями были задержки, пришлось повозиться - оказалось их подключение на одну шину с другим “зоопарком” (счетчик, uniel, термостат и тп) приводило к тому, что вне зависимости от настроек, кнопки отрабатывались с задержками. Перенес эти китайские модули на вторую шину - все стало хорошо. Уж не знаю в чем причина такой несовместимости… Возможно в том, что все эти счетчики и тп работают все же не идеально - бывают ошибки, задержки выставлены от 20 до 100мс (иначе совсем плохо). Но тут это не критично. А вот дискретные китайские как раз работают идеально - ошибок нет, задержка выставлена в 0, опрос по умолчанию - 10мс. Сейчас на этой шине стоят однотипные (в смысле одного производителя) 4 шт - все нормально.
сейчас в тестовой эксплуатации – свет заведен на выходы WB-MR6C, выключатели – обычные с пружиной (кнопка НО) – заведены на дискретные входы этих же WB-MR6C.
головной контроллер – комп на Linux с установленным OpenHab2 и модулем usb-rs485.
если управление светом делать через головной контроллер (правила управления светом описаны на нем, и нажатия кнопок считываются по modbus в режиме поллинга), то задержки, конечно, есть – но терпимые. В зависимости от того в какой цикл опроса нажать кнопку – может либо мгновенно сработать, либо уже успеешь отпустить руку от кнопки.
если управление светом оставлять «напрямую» (т.е. в WB-MR6C оставить включенным прямое управление) – то задержек нет (срабатывает мгновенно всё). Однако у меня не во всех сценариях можно использовать прямое управление, иногда одни и те же кнопки должны управлять разными реле в зависимости от внешних факторов.
Вы отказались от WB в пользу ПК с OH2, думаю что вам просто интерфейс OH больше понравился.
У меня сейчас 28 кнопок в проекте на 4-х выключателях, т.е. на каждом выключателе по 4 кнопки, причём каждая кнопка имеет 2 зоны нажатия - вниз и вверх, я это хочу использовать для диммирования в обе стороны, чтобы не нужно было дважды нажимать, переключая направление диммирования. Этот вариант (как и другие сценарии в зависимости от внешних факторов) будет работать только, если кнопки подключены на головной контроллер сразу, будь это WB или что-то другое, потому что, вы правы, WB-MR6C построен только для прямого управления по имеющимся на нём каналам. Жаль, что нельзя их просто транслировать по modbus на головной контроллер.
Это я к чему: идею понял, задержки терпимые (какая величина задержки на поллинге стоит и какая скорость в шине выставлена, или это особо не влияет на воспринимаемую скорость включения света?). Но как мне 28 сухих контактов завести, если без WB попытаться обойтись? У них есть специальные модули расширения, мне казалось, что в этом вся фишка…
Я выбрал OH2, т.к. он гораздо гибче в настройках и не требует покупки «контроллера», ну и сообщество, которое пишет под него плагины, на порядок больше WB.
Что касается блоков, то я выбирал WB-MR6C именно из-за того, что у них есть универсальные дискретные входы, которые вдобавок еще поддерживают функцию счета – таким образом у меня в каждой зоне квартиры стоит свой WB-MR6C, и провода от выключателей/освещения далеко тянуть не нужно, а уже к контроллеру идет только RS-485.
WB-MR6C я использую в том числе и для НЕ прямого управления реле.
Например, для выключателей/кнопок, где требуется обрабатывать только короткие нажатия (без удержания), очень удобно использовать счетные регистры WB-MR6C – т.е. я подвешиваю правило в OH2 на изменение счетчика – что безусловно означает, что кто-то только что нажимал кнопку. Счетный выход использовать в этом случае правильнее, т.к. можно успеть нажать/отпустить кнопку между интервалами опроса modbus и если бы правило было подвешено на статус контакта (on/off), оно бы не срабатывало.
Там, где требуется долгое нажатие, там, конечно, побольше возни – в правилах обработки запускаю асинхронные таймеры, по которым уже проверяю состояние контактов (on/off). Тут много нюансов еще из-за того, что я пока не понял как атомарной операцией считать из WB-MR6C и счетчик и состояние контакта (приходится закладывать на то, что счетчик по modbus уже может считаться увеличенный, а состояние контакта ON может считаться только со следующего опроса).
С настройками modbus я пока не игрался – работает на 9600 и опрос 200мс.
Поделитесь пожалуйста конфигом openHAB биндинга Modbus для WB-MR6C и правилами для короткого и длинного нажатия.
Я тоже давно использую openHAB. С помощью @Andrey_Yantsen подключил к openHAB Астра РИ-М РР через rs485 с датчиками протечки, дыма и окон.
О, отлично! Я не знал о возможности НЕпрямого управления, только вот вчера вечером и прочитал, что в WB-MR6C можно отвязать входы от выходов, и использовать независимо! Это здорово, упрощает дело немного.
Любопытно, а сам WB умеет обрабатывать длинные нажатия? Или “из коробки” он их только считает?
И ещё, поделитесь железной составляющей: что за модуль rs-485 и какой комп на линукс (обычный стационарный или таки какой-то модный, маленький и на din-рейку, чтобы удобно было всё коммутировать?).
Правило для короткого нажатия (часть rules/kitchen.rules):
rule "Kitchen button"
when
Item WB_MR6C_Cnt3 changed
then
var cur_state = WB_MR6C_Out3.state
var cur_cnt = (WB_MR6C_Cnt3.state as DecimalType).intValue
if ( cur_cnt > 0 ) {
if ( cur_state == ON ) {
sendCommand(WB_MR6C_Out3, OFF)
}
else {
sendCommand(WB_MR6C_Out3, ON)
}
}
end
Правило с длинным нажатием пока не буду публиковать – пока криво работает
На неделе постараюсь придумать как починить, дополню здесь.
Любопытно, а сам WB умеет обрабатывать длинные нажатия?
Не знаю – я не работал с WB-контроллером. Возможно, знающие люди подключатся – подскажут.
И ещё, поделитесь железной составляющей: что за модуль rs-485 и какой комп на линукс
Модуль rs-485: http://roboparts.ru/products/usb-rs485 – его цена в 200р. была одним из решающих факторов, на чем собирать тестовую систему – на OpenHab или на WB. Комп – домашний сервер на базе atom – просто запустил на нем docker-контейнер с OpenHab с прокинутым /dev/ttyUSB0 и порядок. Ещё на нем же распознавание голоса крутится, так что выключать свет можно голосом
да, действительно, против 3000 рублей в Разумном Доме это предложение намного привлекательнее. И только что пришло в голову, что OH я могу запустить и на домашнем NAS Synology, как раз для тестов - самое оно! Спасибо за наводку. Получается, что сейчас могу остановится только на реле и диммерах с RS-485, а дальше видно будет.
У меня 2 года OH крутился на Synology DS214play (1GB RAM, x86). Возникали совершенно непонятные ошибки, о которых на форуме OH никто не слышал. То что я заметил - иногда NAS делает проверку HDD и в этот момент нет быстрого отклика от системы, и у OH соответственно начинают падать модули (по таймауту и еще из-за чего) - у меня чаще всего переставали работать правила, биндинг MQTT не мог переподключиться (хотя брокер был тут же). И нет обновления через apt, все только через пакет для Synology.
Перенес все на мини комп без вентиляторов с Xubuntu - теперь всё стабильно.
Надо же, у меня как раз DS214play). Да уж, отзыв как раз вовремя. Ладно, мини пк у меня пока что нет, установлю только лишь для того, чтобы создать базовую конфигурацию - у меня на данном этапе ноль знаний об этом предмете, только что интерфейсы видел и читал про services и items… А дальше подумаю, хотя, WB в этом свете уже не будет проигрывать в плане стоимости…
Все равно надо управлять телевизором, ресивером, и пр. техникой - для всего этого у OH уже есть “биндинги” (плагины). И управление это с обратной связью.
Вот например - на телеки LG можно отправлять сообщения с иконкой, мелочь, но прикольно:
