Настройка 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 (мин) |
|---|---|---|---|
| Универсальный | большинство домашних сетей | 20 | 1500 |
| Максимум стабильности | много устройств/заметны задержки | 30 | 1500 |
| Быстрые оповещения | нужна скорость, сеть уверенная | 10 | 720–1500 |
Пример универсальной конфигурации:
availability:
enabled: true
active:
timeout: 20
passive:
timeout: 1500
Точечная настройка — самый практичный подход
- Отключить availability для “капризного” устройства, которое ложно уходит в
offline:
devices:
'0x1234567890abcdef':
friendly_name: problem_device
availability: false
- Ужесточить контроль только для критичного устройства (например, реле, от которого зависит автоматика):
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 и проверьте, нет ли проблем с покрытием (роутеры, расстояния, помехи).