Настройка permit_join и availability для стабильной Zigbee-сети

Оптимальная стабильность Zigbee2MQTT достигается просто: permit_join держите закрытым и открывайте только на короткое окно, а availability настраивайте с увеличенными таймаутами, чтобы не забивать сеть пингами и не получать ложные offline.

Оглавление

Permit join: безопасное добавление устройств без “шума”

В актуальной логике Zigbee2MQTT режим добавления устройств — это временное окно, а не настройка “включить навсегда”. На практике это плюс для стабильности: меньше случайных попыток присоединения и меньше лишней активности в сети.

Лучшая политика: по умолчанию join закрыт, открывайте на 60–120 секунд только когда реально добавляете устройство, затем закрывайте.

Как открывать/закрывать join через MQTT (удобно для кнопки/автоматизации):

  • открыть на 60 секунд:
  Topic: zigbee2mqtt/bridge/request/permit_join
  Payload: {"time":60}
  • закрыть сразу:
  Topic: zigbee2mqtt/bridge/request/permit_join
  Payload: {"time":0}

Если у вас часто добавляются устройства, сделайте один сценарий “Режим добавления” и не оставляйте сеть открытой “на всякий случай” — это почти всегда ухудшает управляемость и логирование, а иногда и безопасность.

Availability: онлайн/оффлайн без перегруза сети

availability публикует статус доступности устройств. Проблемы начинаются, когда таймауты слишком маленькие: Zigbee2MQTT чаще проверяет “живость” активных устройств, а это лишний трафик и нагрузка.

Логика обычно такая:

  • Active (питаются от сети): при долгом молчании могут дополнительно проверяться → больше фоновых запросов.
  • Passive (батарейные): “спят”, поэтому частые проверки бессмысленны; offline ставится по длительному отсутствию любых сообщений.

Не делайте маленький passive.timeout “для всех батареек”: многие датчики могут молчать часами — получите “offline-качели”, хотя сеть исправна.

Если Zigbee2MQTT был остановлен дольше, чем active.timeout, после запуска часть устройств может выглядеть offline до первого “признака жизни”. Это ожидаемое поведение, а не обязательно поломка сети.

Рекомендуемые профили и точечная настройка

Ниже — рабочие стартовые значения. Если сеть большая или координатор/канал “шумные”, выбирайте более мягкий профиль (больше минут).

Профили таймаутов availability (стартовые)

ПрофильДля когоactive.timeout (мин)passive.timeout (мин)
Универсальныйбольшинство домашних сетей201500
Максимум стабильностимного устройств/заметны задержки301500
Быстрые оповещениянужна скорость, сеть уверенная10720–1500

Пример универсальной конфигурации:

availability:
  enabled: true
  active:
    timeout: 20
  passive:
    timeout: 1500

Точечная настройка — самый практичный подход

  1. Отключить availability для “капризного” устройства, которое ложно уходит в offline:
devices:
  '0x1234567890abcdef':
    friendly_name: problem_device
    availability: false
  1. Ужесточить контроль только для критичного устройства (например, реле, от которого зависит автоматика):
devices:
  '0xabcdef1234567890':
    friendly_name: critical_plug
    availability:
      timeout: 5

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

Частые ошибки

  • Держать permit_join открытым постоянно: лишняя активность в сети, неожиданное “интервью” устройств, риски безопасности.
  • Ставить active.timeout слишком маленьким (например, 5–10 минут) в большой сети: больше проверок → больше фоновой нагрузки.
  • Делать passive.timeout маленьким для всех батарейных датчиков: массовые ложные offline.
  • Пытаться “лечить” массовый offline после перезапуска снижением таймаутов: чаще наоборот нужно увеличить active.timeout и заложить паузу в автоматизациях.

FAQ

Нужно ли включать availability вообще?
Да, если вы используете статусы в автоматизациях. Но выбирайте мягкие таймауты и усиливайте контроль точечно.

Какие значения считать “безопасными по стабильности”?
Обычно active.timeout: 20–30 и passive.timeout: ~1500 дают минимум лишнего трафика и мало ложных offline.

Почему устройство “от сети” иногда становится offline, хотя потом оживает?
Чаще всего это агрессивный active.timeout, временная перегрузка/помехи или редкие “чекины” самого устройства. Увеличьте active.timeout и проверьте, нет ли проблем с покрытием (роутеры, расстояния, помехи).