Как я заставил Synology работать с неподдерживаемым USB‑ИБП: NUT, VID/PID и blazer

Synology DS916+ отказался видеть новый Energenie EG‑UPS‑PS3000-02. В DSM эта модель официально не поддерживается, а автоматически выбранный nutdrv_qx с устройством не заработал. При этом выяснилось, что другой драйвер, уже встроенный в DSM — blazer_usb — прекрасно общается с ИБП по Megatec/Q1. Осталось понять, как заставить саму DSM использовать его правильно.

Ниже — история от первой проверки USB‑кабеля до строки UPS on battery в системном журнале.

Моя конфигурация: Synology DS916+, DSM 7.2.2–72806 Update 9 и Energenie EG‑UPS‑PS3000-02. Ниже описан опыт с этой связкой оборудования и программного обеспечения; он не доказывает совместимость всех ИБП с такими же USB‑идентификаторами.

Зачем мне понадобился ИБП

Главная задача была не в том, чтобы увидеть красивую иконку батареи в DSM. Мне нужно было защитить NAS и данные от последствий внезапного отключения электричества. На моём Synology работает не только файловое хранилище. На нём размещены веб‑сайт, почтовый сервер MailPlus, DNS‑сервер, хранятся программы, документы и другие важные файлы. Поэтому неожиданное отключение питания — это риск повреждения файловой системы, проблем с DSM и, в худшем случае, потери данных.

Подобрать ИБП строго по официальному списку совместимости Synology в моей стране оказалось практически нереально. Подходящие модели либо трудно найти, либо они стоят значительно дороже. На профильных форумах при этом хватает примеров, когда пользователям удавалось подключать к Synology ИБП, которых в официальном списке поддержки нет.

При выборе я ориентировался на разумную цену и максимально возможную автономность. В результате купил Energenie EG‑UPS‑PS3000-02 за 325 евро.

Для сравнения: на момент выбора APC Smart‑UPS C SMC2000I, 2000 ВА / 1300 Вт, стоил в местном интернет‑магазине 1081 евро. Это цены из моего опыта покупки, а не актуальная ценовая рекомендация.

Конечно, сравнивать два ИБП только по ВА и ваттам неправильно: отличаются аккумуляторы, схемотехника, качество стабилизации, сервис и другие характеристики. Но для моей конкретной задачи главным критерием было получить максимально продолжительную автономную работу за разумные деньги.

По приблизительным расчётам Energenie должен обеспечивать моей инфраструктуре около 4–5 часов работы. Полный тест такой продолжительности в описанном эксперименте не проводился.

Energenie EG‑UPS‑PS3000-02 в рабочем состоянии. На дисплее — параметры питания и заряд аккумулятора.

После распаковки я корректно выключил оборудование и подключил к ИБП:

Synology DS916+
домашний компьютер и монитор
MikroTik Chateau 5G ax
коммутатор KeepLink KP-9000-9XHPML‑X
ASUS RT‑AC68R
Tuya X5

Всю эту инфраструктуру в один кадр уместить практически невозможно, поэтому отдельно покажу заднюю панель самого ИБП.

Задняя панель ИБП. USB‑соединение используется для передачи состояния устройства в Synology.

После этого включил ИБП и запустил NAS. DSM загрузилась, я открыл панель управления в надежде увидеть подключённый источник бесперебойного питания. И не увидел ничего.

Проверяем USB и определяем VID и PID

Первая мысль была очевидной: возможно, Synology просто не видит устройство через USB. Проверить порт оказалось проще всего обычной флешкой. Я подключил к NAS USB‑накопитель с файлами. DSM сразу его увидела, а содержимое стало доступно через File Station. Значит, USB‑порт исправен.

Следующим подозреваемым был кабель. ИБП подключался оригинальным USB‑кабелем из комплекта, поэтому вероятность проблемы казалась небольшой, но полностью исключать её не хотелось. У меня был ещё один заранее купленный трёхметровый USB‑кабель. Подключил его. Результат тот же. Synology ИБП не видит.

Следующая задача была простой: подключить ИБП к какому‑нибудь другому устройству и понять, есть ли от него вообще какой‑либо USB‑сигнал. Кроме настольного компьютера подходящего кандидата не было. Подключаю ИБП к Windows на горячую — и слышу через динамики монитора стандартный звук обнаружения нового USB‑устройства. Это уже хорошая новость. Значит, USB‑интерфейс ИБП жив.

Но найти новое устройство оказалось неожиданно сложно. В разделе с принтерами ничего похожего на Energenie не появилось. В Диспетчере устройств тоже нет ни слова Energenie, ни UPS. Зато в HID и USB‑контроллерах находится куча устройств с практически одинаковыми названиями.

Дополнительная сложность заключалась в расположении оборудования. Компьютер, NAS и ИБП находятся в одной комнате, а монитор подключён десятиметровым кабелем и стоит в другой. Я физически не мог одновременно смотреть на Диспетчер устройств и подключать USB‑кабель.

Поэтому сделал проще. Сначала сделал скриншот Диспетчера устройств без подключённого ИБП. Затем подключил его и сравнил список. Так удалось определить появившееся устройство и добраться до его аппаратных идентификаторов:

VID — идентификатор производителя USB‑устройства, PID — идентификатор продукта. В моём случае это VID 0001 и PID 0000; в привычной Linux‑записи — 0001:0000.

Windows не называла устройство Energenie или UPS, но по аппаратному ID удалось определить VID 0001 и PID 0000.

Windows регистрировала устройство. USB работал. Идентификаторы читались. Следовательно, проблема, скорее всего, находилась не в железе, а выше — в том, как DSM определяет ИБП и какой драйвер пытается для него использовать.

Какие драйверы уже есть в DSM

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

Но DSM здесь не оставила выбора. Ни ручного выбора драйвера, ни возможности указать VID/PID, ни каких‑либо расширенных параметров UPS в интерфейсе нет. Пришлось подключаться к NAS и смотреть, что находится под капотом.

Проверка на NAS показала, что Synology видит USB‑устройство 0001:0000. Для работы с ИБП DSM использует Network UPS Tools (NUT), и необходимые драйверы уже были установлены:

/usr/bin/nutdrv_qx
 /usr/bin/blazer_usb
 /usr/bin/usbhid-ups

DSM видит USB‑устройство 0001:0000, а необходимые NUT‑драйверы уже присутствуют в системе.

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

Проверка nutdrv_qx

Для экспериментов я не хотел сразу менять штатную конфигурацию DSM, поэтому создал отдельный каталог:

mkdir -p /volume2/homes/sensei/nut-test

В каталоге создал тестовый файл ups.conf:

[egups]
 driver = nutdrv_qx
 port = auto
 vendorid = "0001"
 productid = "0000"

После этого запустил драйвер в подробном debug‑режиме:

NUT_CONFPATH=/volume2/homes/sensei/nut-test \ /usr/bin/nutdrv_qx -a egups -DDD

Ответ оказался недвусмысленным:

No appropriate HID device found No supported devices found

Продолжать уговаривать nutdrv_qx смысла не было. Мне нужен был драйвер, который хотя бы начнёт обмениваться данными с ИБП.

Проверка blazer_usb

Следующим кандидатом стал blazer_usb. Тестовый конфиг выглядел уже так:

[egups]
 driver = blazer_usb
 port = auto
 vendorid = "0001"
 productid = "0000"
 langid_fix = "0x04095"

Первоначальный запуск из обычной пользовательской SSH‑сессии тоже не дал результата. Но после запуска с нужными правами в debug‑выводе внезапно появилось:

Device matches Trying megatec protocol... Supported UPS detected with megatec protocol

А следом стали приходить реальные данные:

228.0 000.0 228.0 006 49.9 54.2 26.0 00001001

Драйвер начал читать напряжение, частоту, нагрузку, параметры батареи и состояние устройства. Это подтвердило, что в моей версии DSM установленный blazer_usb умеет обмениваться данными с этим ИБП. Оставалось встроить рабочий запуск в механизм DSM.

Параметр langid_fix = "0x04095" оставляю именно в том виде, с которым работало моё устройство. Это специальный обход проблемы USB language ID, а не универсальная настройка для любого ИБП. Описание параметра есть в документации NUT: https://networkupstools.org/docs/man/blazer_usb.html.

Почему DSM выбирала другой драйвер

Я проверил таблицы сопоставления USB‑устройств, которыми пользуется DSM:

/etc/ups/nutscan-usb.h /usr/syno/etc/ups/nutscan-usb.h

И там нашлась строка:

{ 0x0001, 0x0000, "nutdrv_qx" },

Запись уже существовала: для VID/PID 0001:0000 DSM выбирала nutdrv_qx. При ручной проверке в моей конфигурации этот драйвер не заработал, а blazer_usb получил телеметрию.

До исправления: DSM сопоставляла VID/PID 0001:0000 с драйвером nutdrv_qx.

С этого момента задача стала намного понятнее. Никаких сторонних драйверов устанавливать не нужно. Рабочий драйвер уже есть внутри DSM. Надо только заставить Synology правильно его выбирать и правильно запускать.

Резервные копии перед изменением системных файлов

Вот здесь я довольно долго сомневался. Несколько лет назад у меня уже был неприятный опыт, когда я потерял доступ к DSM и попытался восстановить его кнопкой Reset на корпусе Synology. Тогда сбросилось не только то, что я хотел сбросить. Поэтому вмешиваться в системные файлы работающего NAS мне совершенно не хотелось.

На этом NAS живут сайт, почта, DNS и файлы. Получить вместо него после неудачного эксперимента дорогой железный корпус с радиодеталями — перспектива сомнительная.

Поэтому решил придерживаться одного правила: Перед каждой системной правкой — отдельная резервная копия. Например:

BASE=/volume2/homes/sensei/nut-test
 STAMP=$(date +%Y%m%d-%H%M%S)
 BACKUP="$BASE/backup-egups-$STAMP"
  
 mkdir -p "$BACKUP"

Затем сохранялись изменяемые файлы:

cp -a /etc/ups/nutscan-usb.h \
   "$BACKUP/etc-nutscan-usb.h"
  
 cp -a /usr/syno/etc/ups/nutscan-usb.h \
   "$BACKUP/syno-nutscan-usb.h"
  
 cp -a /etc/ups/ups.conf \
   "$BACKUP/etc-ups.conf"
  
 cp -a /usr/syno/etc/ups/ups.conf \
   "$BACKUP/syno-ups.conf"

Отдельно я сохранял:

/usr/syno/lib/systemd/scripts/ups-usb.sh

Важно: дальше изменяются системные файлы DSM. Перед повторением обязательно сделайте собственные резервные копии. Не используйте мои VID/PID и параметры вслепую для другой модели ИБП.

Команды чтения и изменения системных файлов выполнялись с административными правами. Эти фрагменты описывают мой эксперимент, а не готовый автоматический установщик для любой версии DSM.

Меняем сопоставление драйвера

В обеих таблицах nutscan‑usb.h заменил запись:

{ 0x0001, 0x0000, "nutdrv_qx" },

на:

{ 0x0001, 0x0000, "blazer_usb" },

Команды замены:

sed -i \ 's/{ 0x0001, 0x0000, "nutdrv_qx" }/{ 0x0001, 0x0000, "blazer_usb" }/' \ /etc/ups/nutscan-usb.h

sed -i \ 's/{ 0x0001, 0x0000, "nutdrv_qx" }/{ 0x0001, 0x0000, "blazer_usb" }/' \ /usr/syno/etc/ups/nutscan-usb.h

После проверки таблицы уже выглядели так:

34: { 0x0001, 0x0000, "blazer_usb" },

Промежуточный результат после первого патча: DSM уже выбирает blazer_usb, а в ups.conf появились необходимые USB‑параметры. Позже строка user = root была удалена, а драйвер стал запускаться через upsdrvctl ‑u root.

Но одной замены драйвера оказалось недостаточно.

Передаём параметры через механизм запуска DSM

DSM не только выбирает драйвер, но и формирует конфигурацию и запускает его через скрипт:

/usr/syno/lib/systemd/scripts/ups-usb.sh

В нём находятся функции GetDrv(), DetectDrv() и StartDrv(). Для моего устройства потребовались дополнительные параметры USB и запуск драйвера с правами root.

vendorid = "0001" productid = "0000" langid_fix = "0x04095"

В StartDrv() появилась отдельная обработка связки blazer_usb и устройства 0001:0000. Ниже — сокращённый фрагмент логики, а не полный штатный скрипт DSM. Его нельзя использовать для замены всего файла ups‑usb.sh:

StartDrv() {
     # Energenie EG-UPS-PS3000-02 USB 0001:0000
  
     /bin/sed -i '/^[[:space:]]*vendorid[[:space:]]*=/d' $UPS_CONF
     /bin/sed -i '/^[[:space:]]*productid[[:space:]]*=/d' $UPS_CONF
     /bin/sed -i '/^[[:space:]]*langid_fix[[:space:]]*=/d' $UPS_CONF
  
     if [ "x$1" = "xblazer_usb" ] && \
        /bin/grep -q 'Vendor=0001 ProdID=0000' /proc/bus/usb/devices; then
  
         /bin/sed -i '/^[[:space:]]*port[[:space:]]*=[[:space:]]*auto/a\
     vendorid = "0001"\
     productid = "0000"\
     langid_fix = "0x04095"' $UPS_CONF
     fi
  
     sed -i "s/^\tdriver.*/\tdriver = $1/" $UPS_CONF
  
     if [ "x$1" = "xblazer_usb" ] && \
        /bin/grep -q 'Vendor=0001 ProdID=0000' /proc/bus/usb/devices; then
         /usr/bin/upsdrvctl -u root ${ARG_PRODUCT} start
     else
         /usr/bin/upsdrvctl ${ARG_PRODUCT} start
     fi
 }

В экспериментальном патче была дополнительная дублирующая проверка условия. В приведённом фрагменте она убрана. Остальная логика и значения параметров сохранены.

Итоговая конфигурация и телеметрия

Рабочая секция в итоге получилась такой:

[ups]
 driver = blazer_usb
 port = auto
 vendorid = "0001"
 productid = "0000"
 langid_fix = "0x04095"

На промежуточном этапе я пробовал добавить user = root в ups.conf, но затем удалил эту строку. В итоговом варианте права задаются при запуске через upsdrvctl ‑u root, как показано в предыдущем фрагменте.

Проверка состояния:

/usr/bin/upsc ups@localhost

Фрагмент полученной телеметрии:

battery.charge: 100 battery.voltage: 54.10 battery.voltage.nominal: 48.0 driver.name: blazer_usb driver.parameter.langid_fix: 0x04095 driver.parameter.productid: 0000 driver.parameter.vendorid: 0001 input.frequency: 49.9 input.voltage: 228.0 output.voltage: 228.0 ups.load: 7 ups.status: OL ups.temperature: 27.0 ups.type: offline / line interactive

Synology через NUT получала входное и выходное напряжение, частоту, нагрузку, заряд и напряжение батареи, температуру и состояние питания. При этом показание battery.charge у blazer_usb может быть расчётным: сама по себе цифра 100% не подтверждает несколько часов автономности. Это ограничение описано в документации драйвера.

Проверка отключением внешнего питания

Сам ИБП я проверял ещё до всех экспериментов с драйверами. Я отключал его от электросети и убеждался, что NAS, компьютер и сетевое оборудование продолжают работать.

Поэтому после появления нормальной телеметрии долго не раздумывал. Просто отключил входное питание ИБП. До этого статус был:

ups.status: OL

OL — On Line, питание от электросети.

После отключения Synology увидела переход на батарею. В системном журнале появилось:

UPS on battery.

Примерно через две минуты питание вернул. DSM записала:

UPS back online, not in safe mode

Физическая проверка: DSM зарегистрировала переход ИБП на батарею и последующий возврат сетевого питания.

Таким образом, проверка подтвердила две вещи: оборудование продолжает работать от батареи, а DSM регистрирует исчезновение и возврат сетевого питания. Это ещё не полный тест перехода NAS в безопасный режим или работы до разряда батареи.

Краткая последовательность настройки

Для моей связки DS916+, DSM 7.2.2–72806 Update 9 и Energenie EG‑UPS‑PS3000-02 настройка свелась к следующим шагам:

Проверить USB‑соединение и определить VID/PID конкретного устройства.
Получить реальную телеметрию через установленный драйвер NUT до изменения интеграции DSM.
Сохранить копии обеих таблиц nutscan‑usb.h, обоих файлов ups.conf и скрипта ups‑usb.sh.
Заменить сопоставление 0001:0000 с nutdrv_qx на blazer_usb в обеих таблицах.
Добавить передачу vendorid, productid и langid_fix в механизм формирования конфигурации DSM и запуск с нужными правами.
Проверить /usr/bin/upsc ups@localhost, затем кратковременно отключить входное питание ИБП и проверить журнал DSM.

Устанавливать сторонний NUT или неизвестные бинарники мне не понадобилось: рабочий драйвер уже находился внутри DSM.

Почему я выбрал задержку 45 минут

После успешной интеграции оставался ещё один вопрос: через сколько времени после перехода на батарею Synology должен уходить в безопасный режим? Нередко для NAS устанавливают задержку 5–10 минут. Для моих условий это слишком мало.

Я живу недалеко от моря. Во время непогоды кратковременные перебои питания случаются регулярно. Иногда электричество исчезает всего на минуту‑другую, но отключения на 10–20 минут тоже далеко не редкость.

Отключения примерно на 20–30 минут могут происходить практически каждый месяц, особенно весной, осенью и зимой. Во время сильных циклонов электричества иногда нет уже час или два.

При этом Energenie я специально покупал с большим запасом автономности. По приблизительным расчётам, при моей нагрузке ИБП способен поддерживать инфраструктуру примерно 4–5 часов. Получается странно: купить мощный ИБП, способный работать несколько часов, а через пять минут добровольно остановить NAS.

С другой стороны, устанавливать задержку в два или три часа тоже не хотелось. Аккумуляторы стареют. Через год или два их фактическая ёмкость уже будет ниже первоначальной. Кроме того, я не хочу при каждом длительном отключении разряжать батареи практически до нуля.

Поэтому выбрал задержку 2700 секунд, то есть 45 минут. В конфигурации DSM она отображается так:

ups_wait_time="2700"

Так кратковременные перебои на 1–2 минуты не прерывают работу NAS, а при отключении на 10–30 минут он продолжает обслуживать пользователей. Через 45 минут DSM должна перейти в безопасный режим согласно выбранной настройке. Фактический запас времени зависит от нагрузки и состояния аккумуляторов.

Итоговая настройка DSM: ИБП подключён, батарея заряжена на 100%, переход в безопасный режим настроен через 45 минут.

Любопытная деталь: поля производителя и модели в интерфейсе DSM остались пустыми. Это не мешает работе — состояние питания и заряд батареи система получает нормально.

Почему мне важно сохранять доступность NAS

NAS у меня выполняет сразу несколько ролей. Остановка означает недоступность сайта, почтового сервера MailPlus, DNS и файлов. Постоянный пользователь сайта, увидев временную ошибку, возможно вернётся позже. Новый посетитель может просто закрыть страницу и больше не вернуться.

С почтой ситуация ещё чувствительнее. Нормальные SMTP‑серверы обычно выполняют повторные попытки доставки, но простой почтового сервера всё равно означает задержку корреспонденции. А письмо может оказаться срочным.

Задача ИБП для меня — дать NAS возможность корректно остановить сервисы при серьёзной аварии и одновременно не останавливать их слишком рано при обычных кратковременных перебоях.

Что проверить после обновления DSM

У решения есть недостаток: я изменял системные файлы DSM, и обновление может заменить их штатными версиями. В первую очередь это относится к следующим файлам:

/etc/ups/nutscan-usb.h /usr/syno/etc/ups/nutscan-usb.h /usr/syno/lib/systemd/scripts/ups-usb.sh

Никто не гарантирует, что очередное крупное обновление DSM их не заменит. Отключать обновления из‑за этого я не собираюсь. Безопасность NAS для меня важнее одного патча. Тем более резервные копии изменений сохранены.

После обновления проверить интеграцию довольно просто:

/usr/bin/upsc ups@localhost

Если всё осталось на месте, должны снова присутствовать примерно такие строки:

driver.name: blazer_usb driver.parameter.vendorid: 0001 driver.parameter.productid: 0000 driver.parameter.langid_fix: 0x04095 ups.status: OL

Затем нужно кратковременно отключить входное питание ИБП и проверить журнал DSM. Ожидаемые события:

UPS on battery UPS back online, not in safe mode

Если телеметрия или события пропали, нужно сравнить текущие системные файлы с резервными копиями. Старый патч не стоит накладывать вслепую: механизм запуска в новой версии DSM может измениться.

Что я вынес из этого эксперимента

Если бы мне снова пришлось выбирать ИБП для этой конфигурации, я бы рассмотрел тот же Energenie. За 325 евро я получил нужный мне запас мощности и ожидаемую автономность, а интеграцию с DSM удалось наладить без установки дополнительных драйверов.

С другим неподдерживаемым ИБП я начал бы с проверки USB и VID/PID, затем испытал доступные драйверы NUT. Только после получения реальной телеметрии имеет смысл менять интеграцию DSM. В моём случае решающим оказался вывод:

Supported UPS detected with megatec protocol

Проблема оказалась в выборе драйвера и параметрах его запуска: DSM сопоставляла устройство 0001:0000 с nutdrv_qx, а в моей системе с ним заработал blazer_usb. После изменений NAS стал получать телеметрию и фиксировать переход на батарею и возврат питания.

Теперь настроена задержка 45 минут до перехода в безопасный режим. Короткий тест подтвердил обработку событий питания; длительную автономность и полный сценарий остановки нужно проверять отдельно, с учётом реальной нагрузки и состояния аккумуляторов.

Как я заставил Synology работать с неподдерживаемым USB‑ИБП: NUT, VID/PID и blazer_usb