есть 3 тригера

номера 1 и 2 имеют связь только с тригером номер 3 и при каждом своем изменении отправляют ему свой статус
тригер с номером 3 устанавливает свой статус на основании последнего полученого значения и отправляет об этом информацию тригерам 1 и 2
тригеры 1 и 2 получив статус от тригера 2 устанавливают свой статус равным статусу тригера 3
тригеры 1 и 2 получив статус от тригера 3 устанавливают свой статус равным статусу тригера 3


вроде все хорошо, но есть проблема в скорости обмена данными, при определенных условиях система входит в самовозбуждение (в бесконечный цикл),

по идее нужно ограничить ответ от тригеров 1 и 2 в случае если изменение статуса произошло в результате получения пакета от тригера 3 (а не от внешнего прерывания), но я не вижу варианта технической реализации такой логики.

Кто может предложить другие варианты как гасить "шторм"

ps
шина обмена - zigbbe
протокол - mqqt
тригеры 1 и 2 это выключатели
тригер 3 - это группа mqqt реализованная програмно на контролере home assistance

(0) "тригеры 1 и 2 получив статус от тригера 2 устанавливают свой статус равным статусу тригера 3"
Здесь точно нет опечатки? Может всё же "от тригера 3(!)"?

>тригеры 1 и 2 получив статус от тригера 2
видимо от триггера 3.

не знаю эту шину но как-то нужно передавать и источник, возможно нужна прослойка более сложная чем выключатель, типа так:

? -> 2` -> 2
3 ->

причем на 3 поступает (или не поступает) от 2` а не от выключателя 2

(1) ты прав, правильная формулировка:

тригеры 1 и 2 получив статус от тригера 3 устанавливают свой статус равным статусу тригера 3"

(3) Тогда плохой алгоритм.
Зачем, скажите на милость, трёшке, получившему последний чих от 1 отправлять кроме 2 ещё и обратно 1, лишний раз заставляя того заново щёлкнуться в том же своём значении?
Некомильфо.

(3) исправил

(4) тут я не могу влиять, группа в mqqt работает так

у группы есть идентификатор, и все команды группы идут в сеть широковещательным пакетом по идентификатору группы (а не по идентификатору устройства) а устройства сами определяют принимать или нет ему эти данные (в зависимости от того считает-ли оно себя принадлежащим этой группе).

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

(5) круто, а нас научишь?

(7) Всему своё время.

(0) как вариант завести статусы у тригера 3 приписывать статусу суффикс источника
типа
Триггер 1 отправил статус 101 тригер 3 установил статус 101001
тригер 1 получил статус от тригера 3 101001 установил статус 101001
тригер 2 получил статус от триггера 3 101001 установил статус 101001

(9) идея интересная, правда не уверен, что технически можно реализовать. Вечером попробую.

(9) Неплохая идея

(0) ашипки

zigbee*
mqtt*
HA* (Home Assistant)


HA c объектами работает (сучностями)

ну и любую логику по состояниям и изменениям можно через автоматизации и скрипты реализовать

на основе топиков mqtt можно виртуалные сенсоры добавить, затем использовать как сучность (объект)

ну и пейсать в топики тоже не проблема

примеров полно в тырнете, даже в оф.документации по HA

- service: mqtt.publish
        data:
          payload: "{{ message }}"
          topic: home/"{{ target }}"
          retain: true

(0) Можно запоминать статусы всех триггеров в триггере №3, и принимать решение, нужно ли отправлять пакет, в зависимости от их состояния.
Например, если в триггер 3 пришел сигнал "1", и по его информации все остальные триггеры уже находятся в состоянии "1", то отправлять ничего не нужно.

+(13) Запоминать состояние каждого триггера не требуется. Достаточно запомнить состояние "всех" триггеров - одно единственное значение. Оно запоминается только при отправке широковещательного пакета из триггера 3.
Если приходит от другого триггера точно такое же значение, то оно не меняется, обратно ничего не отправляем.
Если приходит противоположное, то считаем что состояние "всех" триггеров изменилось, отправляем новое значение обратно, запоминаем его.