Запрос функции: Настраиваемый триггер безопасного завершения работы для UniFi UPS

Запрос функции: Настраиваемый триггер безопасного завершения работы для UniFi UPS, UniFi Network

soulchild

Guest

28.02.2026 06:47:00

Текущее поведение: Башня UPS имеет фиксированную задержку в 10 секунд перед началом безопасного завершения работы подключенных устройств после потери питания. Это нельзя настроить.

Запрашиваемое улучшение: Предоставить пользователям несколько настраиваемых вариантов триггера завершения работы:

Вариант 1 — Задержка по времени
Позволить пользователю задавать таймер завершения работы в диапазоне от текущих 10 секунд до 5 минут (или больше). Это будет полезно при кратковременных перебоях питания, которые устраняются сами до начала последовательности отключения, предотвращая ненужные перезапуски подключенных устройств, таких как Dream Machine и NVR.

Вариант 2 — Порог процента заряда батареи
Добавить триггер на основе процента заряда батареи, чтобы UPS запускал завершение работы только при снижении оставшегося заряда ниже заданного пользователем порога (например, 20%). Это более интеллектуальный подход, так как UPS со 100% зарядом может поддерживать устройства гораздо дольше 10 секунд, делая немедленный обратный отсчет неоправданно агрессивным.

Вариант 3 — Комбинированная логика
Позволить обоим условиям работать вместе — например: «Завершать работу только если питание отключено более 2 минут И заряд батареи ниже 30%».

Сценарий использования: В домашних и малых бизнес-развертываниях, где батарея UPS в хорошем состоянии (показана как 100%), жесткое окно завершения работы в 10 секунд вызывает ненужные простои при кратковременных перебоях. Более детальный контроль позволит администраторам балансировать время безотказной работы с защитой безопасного завершения.

Приоритет: Средний — особенно важно для NVR и развертываний постоянно включенной инфраструктуры.

NeilM-KCC

Guest

22.04.2026 17:26:00

Ограничения Ubiquiti UPS были известны с самого начала (как только они начали поставляться)... с Ubiquiti всегда нужно проводить собственное исследование, а оно в основном сводится к тому, чтобы слушать/читать отзывы реальных пользователей, а не покупать, основываясь на CGI-маркетинговых фантазиях. Покупка 11 таких пресс-папье и последующие жалобы на их ограничения — это полностью ваша вина, увы. Вам стоит вернуть их и получить возврат средств, а вместо этого сделать то, что любой, у кого есть серьёзные требования к ИБП, делает уже много лет: купить обычный сторонний ИБП и объединить его с NUT/SSH — это на 100% решённая проблема, не зависящая от того, испортит ли Ubiquiti всё в прошивке.

onaconforma

Guest

22.04.2026 07:03:00

Доставили 11 устройств для распределения по разным сетевым стойкам, и только сейчас прочитал про это ограничение. Крайне разочарован. Зачем ставить батареи в устройство, которое их не использует? Зачем вырубать всё при отключении на 10 секунд, а не, скажем, при уровне заряда 25% + отсутствии входящего питания? Это вообще не штатное завершение. А я-то думал, Ubiquiti наконец-то задумалась о потребностях корпоративного сегмента...

nickpage221

Guest

22.04.2026 02:44:00

Я только что получил один из них и теперь понимаю, что не могу нормально его использовать. Отключение через 10 секунд не имеет смысла, так что мне не очень хочется подключать к нему свой UDM. И если я решу смириться и принять этот жёстко заданный 10-секундный дефолт, я всё равно не смогу использовать авто-восстановление, потому что у меня много перебоев с питанием длительностью менее 30 секунд. Так что, как я предполагаю, если пропадёт электричество на 30 секунд, UDM начнёт выключаться через 10 секунд, а ещё через 20 секунд питание вернётся, и ИБП переключит розетки до того, как система полностью выключится, что напрочь лишает смысла идею корректного завершения работы. Таким образом, 10-секундное отключение, каким бы непрактичным оно ни было, делает авто-восстановление потенциально более опасным, чем использование любого тупого ИБП. Я уже начинаю думать, что лучший способ использовать это — просто запитать его от другого ИБП.

NeilM-KCC

Guest

20.04.2026 05:37:00

Я рискну предположить, судя по ответу DESC, что это, возможно, следующее от настоящего сервера NUT 2.8.4:GET DESC ups battery.charge.low
DESC ups battery.charge.low "Уровень оставшегося заряда батареи, при котором ИБП переключается в режим LB (в процентах)"
Переменная, которую вы упомянули (и её описание), отсутствует в исходном коде настоящего NUT, так что сложно сказать наверняка, что она означает — к сожалению, это может быть чем угодно. 🤷‍♂️

NeilM-KCC

Guest

20.04.2026 05:14:00

Нет, это не придирки к термину «Сервер». Я имею в виду, что официальный исходный код NUT не собирается для вторичного микроконтроллера в ИБП, поэтому на самом деле они используют прокси/фасад NUT, возможно написанный на Python или другом языке (на GitHub есть несколько таких проектов), который отвечает только на самые базовые запросы NUT. Ред.: Хотя, зная Ubiquiti, они, скорее всего, написали его сами с нуля, не дочитав спецификацию до конца. Это не настоящий или совместимый NUT-сервер, поэтому он не поддерживает стандартные функции NUT, такие как «мгновенные» команды, и, возможно, поэтому он ограничен максимум 3 одновременными NUT-клиентами. Это также объясняет, почему он выдает фейковые/нестандартные переменные и постоянно не может аутентифицировать настоящих NUT-клиентов. Без сомнения, поддержка NUT была добавлена в конструкцию ИБП в последнюю минуту. Я слышал, что на конференции Ubiquiti в 2024/2025 году обсуждался этот ИБП, и когда руководителей спросили о поддержке NUT, они не знали, что это такое.

peternield

Guest

20.04.2026 04:22:00

Я не совсем понимаю, почему вы утверждаете, что это фейковый NUT-сервер. Не могли бы вы пояснить? Полагаю, если уж быть педантичным, то это стоит называть демоном подключения (Attachment Daemon). Смысл, который я пытался донести (вдобавок к поддержке запроса на настраиваемый триггер отключения для спаренных устройств), заключался в том, что не помешала бы документация, так как спецификация реализации «демона подключения» довольно размыта — в ней много «может» и не так много «должен». Кстати, в RFC9271 battery.charge.low описывается как процентное значение, но описание battery.low от моего UPS 2U выглядит так: GET DESC ups battery.low DESC ups battery.low "Пороговое напряжение батареи для низкого заряда".

NeilM-KCC

Guest

18.04.2026 13:13:00

Это фейковый NUT-сервер, это не апстрим. NUT.battery.low может быть battery.charge.low, если предположить, что это нижний порог заряда батареи (выраженный в процентах)? Если честно, battery.voltage.low для большинства пользователей почти бесполезен.

peternield

Guest

18.04.2026 03:28:00

Я хочу присоединить свой голос к этому. Оставьте значение по умолчанию 10 секунд, если оно было установлено так изначально по какой-то причине, но дайте возможность его изменять. Также я хотел бы, чтобы это было привязано к флагу Low Battery (LB) в переменной состояния NUT, чтобы завершение работы связанных устройств можно было координировать с завершением работы других клиентских устройств NUT. Раз уж я об этом, я также хотел бы увидеть документацию, описывающую, как NUT Server реализует спецификацию NUT. Например, я вижу, что NUT Server предоставляет переменную battery.low, которой нет в спецификации, но не предоставляет переменную battery.voltage.low, которая определена в спецификации. Аналогично, battery.runtime.low не реализована, и это было бы очень удобно в контексте триггера завершения работы.

gerardush Guest	#10 15.04.2026 11:12:00 Полностью согласен с запросом. Отключение по проценту заряда батареи и восстановление по проценту.

johsm67

Guest

#11

30.03.2026 11:23:00

Только что понял эти ограничения! UPS говорит, что могу работать на текущей нагрузке около часа на башне APC Smart-UPS, очень нужно, чтобы можно было настроить выключение по проценту оставшегося заряда батареи и конкретному времени! Мой оптоволоконный шлюз и NAS отключились, но они не включились снова через 30 минут, когда электричество восстановили! Видимо, ИБП подавал питание, пока длилось отключение, так что после выключения устройств им требуется перезагрузка/цикл питания, чтобы загрузиться снова, ведь питание так и не пропадало полностью… было бы здорово, если бы UPS также мог отключать себя после выключения шлюза и NAS (но при наличии питания), тогда он мог бы автоматически запускаться, когда питание восстановится и уровень заряда достигнет, скажем, 10%, чтобы всё снова включилось и заработало!

landonpoch Guest	#12 21.03.2026 03:17:00 10 секунд — это не адекватное значение по умолчанию. Это обязательно нужно исправить. Иначе этот NAS становится абсолютно бесполезным для сопряжения. Единственным вариантом остаётся NUT server, где клиентское устройство само задаёт свои пороговые значения.

Читают тему (гостей: 1)