Назад | Перейти на главную страницу

Как отключить энергосбережение ИБП с помощью NUT?

У меня установлен ИБП Proline 650 (серийный)

Дополнительные сведения: ИБП имеет последовательное соединение с одной 12-вольтовой батареей SLA. (Он не был указан в списке совместимости NUT, но после компиляции NUT-сканера было обнаружено, что он работает с драйвером blazer_ser. Кажется, он работает отлично, если я оставлю запущенный ups-monitor, сервер автоматически выключится, когда ИБП работал от батареи в течение 30 секунд или минуты или чего-то еще. ОС: Debian 7 Wheezy. Аппаратное обеспечение - это один маломощный безголовый сервер i5 с 1 3,5-дюймовым жестким диском.

ПРОБЛЕМА

ИБП выключается примерно через 5 минут, пока заявленная емкость батареи все еще составляет 65% (вероятно, это заниженная емкость, потому что я только что установил новую батарею), а напряжение батареи сообщается NUT как 12,1 В непосредственно перед включением. с нагрузки. ИБП выключается примерно через 5 минут независимо от того, опрашивает его сервер или нет, и независимо от того, есть ли небольшая нагрузка или нет. (Я питаю сервер напрямую от сети во время некоторых испытаний, чтобы избежать непредвиденных потерь мощности, когда ИБП выполняет энергосбережение)

Я ожидал, что с NUT, опрашивающим ИБП каждые несколько секунд на предмет обновлений статуса, ИБП поймет, что от него зависит компьютер, но ИБП не умен. ИБП показывает, что сервер потребляет 12% от максимальной выходной мощности, что, по-видимому, считается «без нагрузки». После того, как ИБП отключает нагрузку, напряжение на клеммах батареи (одиночный аккумулятор 12 В) имеет напряжение холостого хода около 12,6 В, что указывает на то, что он все еще почти полностью заряжен.

Это поведение при самостоятельном отключении питания упоминается в документах NUT как energy_saving (аккумулятор. энергосбережение).

Драйвер blazer_ser, похоже, не предлагает способ отключить энергосбережение. Это кажется безумным, потому что нет возможности поддерживать выход нагрузки ИБП включенным. Как можно рекламировать ИБП как обеспечивающий x количество энергии, но преждевременно отключающийся, без простого способа исправить поведение в программном обеспечении?

Это мой вывод статуса

$ upsc nutdev1@127.0.0.1
battery.charge: 100
battery.voltage: 13.60
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.type: ups
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.version: 2.6.4
driver.version.internal: 1.55
input.current.nominal: 3.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 221.0
input.voltage.fault: 221.0
input.voltage.nominal: 220
output.voltage: 221.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 12
ups.status: OL
ups.temperature: 25.0
ups.type: offline / line interactive

Я также побежал upsrw -u admin -p mypass -s -l nutdev1 но не было энергосбережения или подобного варианта. Только такие вещи, как beeper.toggle (проверено, работает, как ожидалось) и другие базовые вещи. Был вариант моментального снятия нагрузки. Оно работает. Опция была загружена, я пытался вызвать ее несколько раз, надеясь задержать обратный отсчет энергосбережения, но это не сработало. Также была опция отключения выключения, которая тоже не помогла.

Любые предложения приветствуются. Я подумал о нескольких вещах, которые мне не нравятся:

Кажется, ДОЛЖНО быть простое программное решение, вот почему я спрашиваю.

================

Согласно предложению BillThor, я обновил свой файл upsmon.conf:

$ grep -v '^#' /etc/nut/upsmon.conf
MONITOR nutdev1@127.0.0.1 1 foo2 bar2 master
MINSUPPLIES 1

SHUTDOWNCMD "/usr/bin/logger fake shutdown"

POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower

 NOTIFYFLAG ONLINE  SYSLOG+WALL
 NOTIFYFLAG ONBATT  SYSLOG+WALL
 NOTIFYFLAG LOWBATT SYSLOG+WALL
 NOTIFYFLAG FSD SYSLOG+WALL
 NOTIFYFLAG COMMOK  SYSLOG+WALL
 NOTIFYFLAG COMMBAD SYSLOG+WALL
 NOTIFYFLAG SHUTDOWN    SYSLOG+WALL
 NOTIFYFLAG REPLBATT    SYSLOG+WALL
 NOTIFYFLAG NOCOMM  SYSLOG+WALL
 NOTIFYFLAG NOPARENT    SYSLOG+WALL

RBWARNTIME 43200
NOCOMMWARNTIME 300

FINALDELAY 5

Я включил ИБП (без сетевого питания) 3 раза подряд без зарядки. Емкость аккумулятора и напряжение не изменились. Статус LB никогда не наступал. Вот системные журналы

Dec  2 07:08:00 t upsmon[2000]: Startup successful
Dec  2 07:08:00 t upsd[1942]: User monuser1@127.0.0.1 logged into UPS [nutdev1]
Dec  2 07:08:30 t upsmon[2002]: UPS nutdev1@127.0.0.1 on battery
Dec  2 07:13:34 t blazer_ser[1939]: Communications with UPS lost: status read failed!
Dec  2 07:13:36 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver
Dec  2 07:13:40 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale
Dec  2 07:13:40 t upsmon[2002]: Communications with UPS nutdev1@127.0.0.1 lost
Dec  2 07:13:45 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale
Dec  2 07:13:50 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale
Dec  2 07:13:55 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale
Dec  2 07:13:55 t upsd[1942]: Client monuser1@127.0.0.1 set FSD on UPS [nutdev1]
Dec  2 07:13:55 t upsmon[2002]: Executing automatic power-fail shutdown
Dec  2 07:13:55 t upsmon[2002]: Auto logout and shutdown proceeding
Dec  2 07:14:00 t logger: fake shutdown
Dec  2 07:17:31 t blazer_ser[1939]: Communications with UPS re-established
Dec  2 07:17:31 t upsd[1942]: UPS [nutdev1] data is no longer stale
Dec  2 07:22:38 t blazer_ser[1939]: Communications with UPS lost: status read failed!
Dec  2 07:22:40 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver
Dec  2 07:25:23 t blazer_ser[1939]: Communications with UPS re-established
Dec  2 07:25:23 t upsd[1942]: UPS [nutdev1] data is no longer stale
Dec  2 07:29:54 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1
Dec  2 07:29:55 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled
Dec  2 07:30:17 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1
Dec  2 07:30:18 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled
Dec  2 07:30:25 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1
Dec  2 07:30:26 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled
Dec  2 07:30:31 t blazer_ser[1939]: Communications with UPS lost: status read failed!
Dec  2 07:30:33 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver
Dec  2 07:31:32 t blazer_ser[1939]: Communications with UPS re-established
Dec  2 07:31:32 t upsd[1942]: UPS [nutdev1] data is no longer stale

Как видите, я попытался сбросить флаг / состояние FSD, выполнив эту команду (та же команда, которая может мгновенно отключить нагрузку или включить звуковой сигнал) upscmd -u upsadmin1 -p mypass nutdev1 shutdown.stop Но это не прояснило состояние FSD.

Вот некоторая информация о статусе (я удалил ненужные строки)

#I ran this immediately after unplugging line power after 07:08:30
$ upsc nutdev1@127.0.0.1
battery.charge: 69
battery.voltage: 12.20
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.status: OB

**$ date && upsc nutdev1@127.0.0.1**
Tue Dec  2 07:11:29 EST 2014
battery.charge: 65
battery.voltage: 12.10
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.status: OB

#none of these fields changed the entire time after this, except ups.status

**date && upsc nutdev1@127.0.0.1**
Tue Dec  2 07:12:29 EST 2014
battery.charge: 65
battery.voltage: 12.10
ups.status: OB

$ date && upsc nutdev1@127.0.0.1
Tue Dec  2 07:18:26 EST 2014
battery.charge: 65
battery.voltage: 12.10
ups.status: FSD OB
ups.temperature: 25.0

#there were a few more, all identical, then finally

**$ date && upsc nutdev1@127.0.0.1**
Tue Dec  2 07:30:28 EST 2014
battery.charge: 65
battery.voltage: 12.10
ups.status: FSD OB

$ date && upsc nutdev1@127.0.0.1
Tue Dec  2 07:31:11 EST 2014
Error: Data stale

Это мгновенные команды, предположительно поддерживаемые моим ИБП.

**upscmd -u upsadmin1 -p mypass -l nutdev1**
Instant commands supported on UPS [nutdev1]:

beeper.toggle - Toggle the UPS beeper  **works**
load.off - Turn off the load immediately **works**
load.on - Turn on the load immediately **seems to do nothing**
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
shutdown.stop - Stop a shutdown in progress **doesn't prevent shutdown or remove FSD flag**
test.battery.start - Start a battery test
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test

Теперь я испробовал еще больше возможностей. Я попробовал запустить test.battery.start.quick, чтобы немного перекалибровать батарею, при нагрузке 35%. Он проработал минуту или две от батареи, затем снова переключился на питание от сети. Затем у меня возникли еще две идеи. Я попытался отключить звуковой сигнал, надеясь, что ИБП останется включенным, но он отключился, как обычно, через 5 минут. Потом у меня появилась другая идея. Я вытащил шнур питания, затем запустил test.battery.start, надеясь, что смогу проводить «тест батареи» на неопределенный срок. Но ИБП ВСЕ ЕЩЕ выключился через 5 минут.

В основном этот ИБП хорош для выключения, и не более того. Я куплю еще один ИБП.

Многие ИБП имеют автоматическое отключение при низкой нагрузке. Если нагрузка составляет менее 10% от номинальной нагрузки ИБП, он отключится через 5 минут. У меня такая же проблема с моим ИБП Proline. Просто увеличьте нагрузку на ИБП, и он не отключится. Я знаю, что это немного противоречит интуиции, если вы пытаетесь сэкономить заряд батареи.

Мне не удалось найти программную настройку для отключения этой функции. Вроде его жестко закодировали в прошивку.

Я установил интеллектуальный переключатель sonoff на стороне нагрузки и запрограммировал его на включение 10% нагрузки на 10 секунд каждые 4 минуты. Это не элегантно, но поддерживает работу.

Если вы не используете команды в upssched.conf, NUT должен дождаться, пока ИБП не сообщит о низком заряде батареи, прежде чем выполнять выключение. Убедитесь, что у вас там ничего не запланировано.

Как только NUT начинает отключение, он запускает перезапуск ИБП после тайм-аута. Это необходимо для обеспечения возобновления работы сервера в случае восстановления питания до того, как батарея ИБП разрядится. Время указано как FINALDELAY в upsmon.conf.

Вы можете включить регистрацию всех уведомлений для всех событий в upsmon.conf. Это может позволить вам определить, почему система так скоро отключается. Я использую следующие настройки:

NOTIFYFLAG ONBATT   SYSLOG+WALL
NOTIFYFLAG ONLINE   SYSLOG+WALL
NOTIFYFLAG FSD      SYSLOG+WALL
NOTIFYFLAG SHUTDOWN SYSLOG+WALL

NOTIFYFLAG LOWBATT  SYSLOG
NOTIFYFLAG REPLBATT SYSLOG

NOTIFYFLAG COMMOK   SYSLOG
NOTIFYFLAG COMMBAD  SYSLOG+WALL
NOTIFYFLAG NOCOMM   SYSLOG+WALL
NOTIFYFLAG NOPARENT SYSLOG+WALL

Если NUT отключает базы по сценарию таймера, я ожидал увидеть именно такую ​​строку в журнале. Похоже, что ИБП прекращает обмен данными через 5 минут, а NUT выполняет последнюю остановку FSD (принудительное отключение). Это то, что я хотел бы сделать. Пяти минут должно хватить, чтобы указать, что электричество не вернется быстро.

Dec  2 07:13:55 t upsd[1942]: Client monuser1@127.0.0.1 set FSD on UPS [nutdev1]

Я ожидал, что NUT будет использовать shutdown.return для подачи сигнала о выключении ИБП. Это должно вызвать перезапуск ИБП после восстановления питания и кратковременное отключение, если питание будет восстановлено до завершения выключения.

Я ожидал ups.delay.shutdown и ups.delay.start быть настройками для цикла перезапуска при выключении ИБП. ups.delay.shutdown должен дать серверу время для завершения цикла выключения и, возможно, потребуется увеличить. ups.delay.start должно быть время, необходимое для стабилизации питания после его восстановления. Это также дает некоторое время для зарядки аккумуляторов перед включением нагрузки.

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