Автоматизация IoT: как избежать засорения эфира и лишних команд

Цель: предотвратить отправку лишних MQTT-команд, когда устройство уже находится в нужном состоянии (например, повторная отправка {"state_l3":"OFF"} каждую секунду).

Основное изменение

В блоке обработки триггерных правил (те, что с условиями вроде temperature > 25) добавлена проверка через существующую функцию shouldSkipAction().

Где именно

Найдите в файле цикл:

// 🔍 Проверяем триггерные правила через кэш $sensorData (БЕЗ запросов!)
foreach ($rules as $rule) {
    if ($rule['schedule_type'] !== 'none') continue;
    ...

Внутри этого цикла, после проверки условия (if ($condMet)), была простая конструкция:

if ($condMet) {
    echo "🎉 Сработало правило: " . $rule['name'] . "\n";
    handleAction($rule);
}

Она заменена на:

if ($condMet) {
    // Проверяем, нужно ли вообще отправлять команду
    if (shouldSkipAction($rule, $pdo)) {
        echo "⏭️ Устройство уже в нужном состоянии — пропускаем правило: " . $rule['name'] . "\n";
    } else {
        echo "🎉 Сработало правило: " . $rule['name'] . "\n";
        handleAction($rule);
    }
}

Как это работает

• Функция shouldSkipAction() сравнивает желаемое состояние (из action_payload) с текущим состоянием устройства (из таблицы sensor_data).
• Если состояния совпадают — команда не отправляется.
• Это работает для любых полей: state, state_l3 и т.д., главное — чтобы топик действия заканчивался на /set, а топик состояния — был без него.

Результат

Теперь правила типа «если температура > 25 — выключи реле» срабатывают только один раз, пока состояние не изменится. Это:

• Снижает нагрузку на Zigbee-сеть
• Увеличивает срок службы реле
• Делает систему предсказуемой

Важно

Для корректной работы убедитесь, что:

• Топик действия: zigbee2mqtt/устройство/set
• Топик состояния: zigbee2mqtt/устройство (без /set)
• В состоянии действительно есть поле, которое вы пытаетесь изменить (например, state_l3)

Посетителей сегодня: 0

о блоге