Tasmota, KNX и выключатели в режиме master-slave
В Г-образном коридоре с двумя светильниками возникло желание заменить два обычных одноклавишных выключателя на двухклавишные проходные, каждый из которых может управлять не только своей нагрузкой, но и нагрузкой своего партнёра.
К каждому выключателю идут всего два провода, для замыкания/размыкания "фазы" на "своём" светильнике, при этом нет никакого желания переделывать проводку (тянуть дополнительный провод для прохода к "партнёру" или выделенного "нуля" для постоянного питания).
Для решения этой задачи были приобретены два "двухклавишных" сенсорных управляемых выключателя Minitiger с возможностью работы без нулевой линии (https://aliexpress.ru/item/33029718728.html).
Лирическое отступление.
Принцип питания "безнулевых" выключателей довольно простой: внутри силовой части выключателя размещается полевой транзистор и ШИМ-контроллер, забирающие при положительном полупериоде ровно столько энергии, сколько надо на питание ESP8285 и управление реле. Таким образом, сам выключатель всегда запитан через нагрузку (одну из нагрузок, если их несколько). В "выключенном" состоянии нагрузка обесточена большую часть положительного полупериода и в течение отрицательного полупериода. Этот подход хорошо работает для обычных ламп накаливания, в которых вольфрамовая нить просто не успевает разогреться до сколь-либо заметного свечения в тот кусочек полупериода, когда питается слаботочная часть выключателя.
К сожалению, этот вариант плохо работает для люминесцентных ламп и LED-светильников, имеющих сложную схему поджига (балласт, в т.ч. электронный) или стабилизатора тока (свой ШИМ-контроллер). В "выключенном" состоянии за несколько кусочков полупериода они успевают запастись достаточным количеством энергии, чтобы запуститься. Естественно, что этой и вновь поступающей энергии недостаточно для нормального функционирования и они тут же гаснут. Возникает так называемый flickering-эффект. Для его устранения в параллель с источником света ставится bypass-модуль. Он состоит из пары конденсаторов, термистора для сглаживания переходных токов и резистора для разряжания конденсаторов. По сути на частоте электрической сети он представляет из себя меньшее сопротивление, чем сама нагрузка, поэтому почти весь ток для питания выключателя проходит через него, а оставшейся части энергии на запуск "энергосберегаек" уже не хватает.
Выключатели прошиты Tasmota, установлены, своими нагрузками рулят, но встал вопрос, как их скоммутировать логически.
Штатная документация предлагает использовать MQTT (и какой-нибудь сервер, типа HomeAssistant или Domoticz) либо правила с прямой отправкой команд через HTTP-API (https://github.com/tasmota/docs/blob/development/docs/Rules.md#two-way-light-switches-without-mqtt).
MQTT мне не нравится тем, что требует постоянно включенного маршрутизатора, выделенного сервера и настройки логики на сервере. По сравнению с этим мелочь, что MQTT работает по TCP (дополнительная нагрузка на сеть и на CPU микроконтроллера).
Прямая отправка команд через правила и HTTP-API (и опять TCP) плоха тем, что нужно хардкодить IP-адреса адресатов внутрь правил.
После некоторых экспериментов остановился на правилах и KNX (поддержки KNX нет в tasmota.bin - recommended release binary, нужно прошивать tasmota-knx.bin или собирать кастомную). Галочка напротив Enable KNX и KNX Physical Address на каждом выключателе выставляется с одной сетью и разными последними байтами (в моём случае это 1.1.0 и 1.1.1). Для одной пары master-slave получилось такое:
Master (реле коммутирует нагрузку):
Data to Send to Group Addresses: Output 1 -> 2 / 2 / 1
Group Addresses to Receive Data from: 2 / 2 / 3 -> KNX RX 1
В консоли:
Rule1 on Event#KnxRx_Cmnd1 DO Power1 toggle ENDON
Rule1 1
Slave (отправляет команды master'у):
Data to Send to Group Addresses: KNX TX 1 -> 2 / 2 / 3
Group Addresses to Receive Data from: 2 / 2 / 1 -> Output 2
В консоли:
Rule1 ON Button2#State DO KnxTx_Cmnd1 1 ENDON
Rule1 1
Получается, что master всегда рулит состоянием (реле и индикацией) второй нагрузки slave'а.
А вот slave при нажатии второй клавиши только просит у master'а изменить состояние его первой нагрузки, сам он состоянием своей второй нагрузки не управляет, поскольку есть специальное условие: при наличии правила для ButtonX#State эта кнопка перестаёт управлять соответствующим реле.
Если же попытаться сделать отправку команды со slave'а через KNX или Device Groups, то выключатели войдут в бесконечный цикл переключения состояний.
Обратная (встречная) пара master-slave настраивается по аналогии.
Данное решение тоже не лишено недостатков:
Параллельная тема про ESP-NOW:
Теоретически, для преодоления недостатков KNX/multicast можно попытаться перейти на использование ESP-NOW, но его применение на практике может быть сопряжено с рядом сложностей. В первую очередь это малая документация и выкрутасы с его поддержкой в свежих SDK для ESP8266 (начиная с какой-то версии была удалена поддержка этого протокола?).
Сейчас можно исходить из того, что возможна одновременная работа wifi и esp-now. Ключевое условие - должен быть идентичный номер канала у обоих протоколов (https://github.com/espressif/arduino-esp32/issues/878#issuecomment-350438086). Возможно, что при использовании esp-now и при реассоциации с wifi с новым каналом следует переинициализировать/вызывать методы esp-now с новым каналом (и брать его из настроек, если при запуске не удаётся подключиться к wifi).
Довольно подробно ESP-NOW рассмотрен здесь: https://github.com/HarringayMakerSpace/ESP-Now/blob/master/README.md
Какие ещё вопросы стоило бы осветить:
- "жужжание" bypass-модуля;
- перенос кнопок и независимое (от реле) управление светодиодами на выключателе;
- энергопотребление электричества "умным" светильником в "выключенном" состоянии (когда подан логический 0 на оба канала управления светодиодами) - сюда же проблема качественного питания ESP8266 и проблема получения времени (для управления fading'ом в зависимости от времени суток).
К каждому выключателю идут всего два провода, для замыкания/размыкания "фазы" на "своём" светильнике, при этом нет никакого желания переделывать проводку (тянуть дополнительный провод для прохода к "партнёру" или выделенного "нуля" для постоянного питания).
Для решения этой задачи были приобретены два "двухклавишных" сенсорных управляемых выключателя Minitiger с возможностью работы без нулевой линии (https://aliexpress.ru/item/33029718728.html).
Лирическое отступление.
Принцип питания "безнулевых" выключателей довольно простой: внутри силовой части выключателя размещается полевой транзистор и ШИМ-контроллер, забирающие при положительном полупериоде ровно столько энергии, сколько надо на питание ESP8285 и управление реле. Таким образом, сам выключатель всегда запитан через нагрузку (одну из нагрузок, если их несколько). В "выключенном" состоянии нагрузка обесточена большую часть положительного полупериода и в течение отрицательного полупериода. Этот подход хорошо работает для обычных ламп накаливания, в которых вольфрамовая нить просто не успевает разогреться до сколь-либо заметного свечения в тот кусочек полупериода, когда питается слаботочная часть выключателя.
К сожалению, этот вариант плохо работает для люминесцентных ламп и LED-светильников, имеющих сложную схему поджига (балласт, в т.ч. электронный) или стабилизатора тока (свой ШИМ-контроллер). В "выключенном" состоянии за несколько кусочков полупериода они успевают запастись достаточным количеством энергии, чтобы запуститься. Естественно, что этой и вновь поступающей энергии недостаточно для нормального функционирования и они тут же гаснут. Возникает так называемый flickering-эффект. Для его устранения в параллель с источником света ставится bypass-модуль. Он состоит из пары конденсаторов, термистора для сглаживания переходных токов и резистора для разряжания конденсаторов. По сути на частоте электрической сети он представляет из себя меньшее сопротивление, чем сама нагрузка, поэтому почти весь ток для питания выключателя проходит через него, а оставшейся части энергии на запуск "энергосберегаек" уже не хватает.
Выключатели прошиты Tasmota, установлены, своими нагрузками рулят, но встал вопрос, как их скоммутировать логически.
Штатная документация предлагает использовать MQTT (и какой-нибудь сервер, типа HomeAssistant или Domoticz) либо правила с прямой отправкой команд через HTTP-API (https://github.com/tasmota/docs/blob/development/docs/Rules.md#two-way-light-switches-without-mqtt).
MQTT мне не нравится тем, что требует постоянно включенного маршрутизатора, выделенного сервера и настройки логики на сервере. По сравнению с этим мелочь, что MQTT работает по TCP (дополнительная нагрузка на сеть и на CPU микроконтроллера).
Прямая отправка команд через правила и HTTP-API (и опять TCP) плоха тем, что нужно хардкодить IP-адреса адресатов внутрь правил.
После некоторых экспериментов остановился на правилах и KNX (поддержки KNX нет в tasmota.bin - recommended release binary, нужно прошивать tasmota-knx.bin или собирать кастомную). Галочка напротив Enable KNX и KNX Physical Address на каждом выключателе выставляется с одной сетью и разными последними байтами (в моём случае это 1.1.0 и 1.1.1). Для одной пары master-slave получилось такое:
Master (реле коммутирует нагрузку):
Data to Send to Group Addresses: Output 1 -> 2 / 2 / 1
Group Addresses to Receive Data from: 2 / 2 / 3 -> KNX RX 1
В консоли:
Rule1 on Event#KnxRx_Cmnd1 DO Power1 toggle ENDON
Rule1 1
Slave (отправляет команды master'у):
Data to Send to Group Addresses: KNX TX 1 -> 2 / 2 / 3
Group Addresses to Receive Data from: 2 / 2 / 1 -> Output 2
В консоли:
Rule1 ON Button2#State DO KnxTx_Cmnd1 1 ENDON
Rule1 1
Получается, что master всегда рулит состоянием (реле и индикацией) второй нагрузки slave'а.
А вот slave при нажатии второй клавиши только просит у master'а изменить состояние его первой нагрузки, сам он состоянием своей второй нагрузки не управляет, поскольку есть специальное условие: при наличии правила для ButtonX#State эта кнопка перестаёт управлять соответствующим реле.
Если же попытаться сделать отправку команды со slave'а через KNX или Device Groups, то выключатели войдут в бесконечный цикл переключения состояний.
Обратная (встречная) пара master-slave настраивается по аналогии.
Данное решение тоже не лишено недостатков:
- требуется постоянно включенный рутер;
- нет подтверждения доставки;
- используется multicast и устройство иногда спонтанно отключается от малтикастовой группы (на роутере?), после чего выключатель перестаёт отправлять и принимать KNX-команды.
Параллельная тема про ESP-NOW:
Теоретически, для преодоления недостатков KNX/multicast можно попытаться перейти на использование ESP-NOW, но его применение на практике может быть сопряжено с рядом сложностей. В первую очередь это малая документация и выкрутасы с его поддержкой в свежих SDK для ESP8266 (начиная с какой-то версии была удалена поддержка этого протокола?).
Сейчас можно исходить из того, что возможна одновременная работа wifi и esp-now. Ключевое условие - должен быть идентичный номер канала у обоих протоколов (https://github.com/espressif/arduino-esp32/issues/878#issuecomment-350438086). Возможно, что при использовании esp-now и при реассоциации с wifi с новым каналом следует переинициализировать/вызывать методы esp-now с новым каналом (и брать его из настроек, если при запуске не удаётся подключиться к wifi).
Довольно подробно ESP-NOW рассмотрен здесь: https://github.com/HarringayMakerSpace/ESP-Now/blob/master/README.md
Какие ещё вопросы стоило бы осветить:
- "жужжание" bypass-модуля;
- перенос кнопок и независимое (от реле) управление светодиодами на выключателе;
- энергопотребление электричества "умным" светильником в "выключенном" состоянии (когда подан логический 0 на оба канала управления светодиодами) - сюда же проблема качественного питания ESP8266 и проблема получения времени (для управления fading'ом в зависимости от времени суток).