nutdrv_qx - Man Page

nutdrv_qx -h

nutdrv_qx -a UPS_NAME [OPTIONS]

The nutdrv_qx driver is known to work with various UPSes from Armac, Blazer, Energy Sistem, Fenton Technologies, General Electric, Hunnox, Masterguard, Mustek, Powercool, Voltronic Power, SKE (rebranded by many, many - have I said many? - others...

Long story short: if your UPS came with a software called Viewpower, chances are high that it works with this driver with one of the voltronic* protocols or with the mecer one), and many others.

The NUT compatibility table lists all the known supported models. Keep in mind, however, that other models not listed there may also be supported, but haven’t been tested or reported back.

All devices with a serial interface and many with a USB interface are supported.

You may need to override or provide defaults for some values, depending on the make and model of your UPS.

The following are the ones that most likely will need changing (see ups.conf(5)):

ondelay = value

Time to wait before switching on the UPS (seconds). This value is truncated to units of 60 seconds.

Note that a value below 3 minutes, may cause earlier firmware versions to not switch on automatically, so it defaults to 3 minutes (i.e. 180 seconds).

This option provides a default value for ups.delay.start that will then be used by the driver in the automatic shutdown sequence (i.e. calling the driver with the -k option, calling upsdrvctl(8) with the shutdown option or when the FSD flag is set and upsmon(8) enters its shutdown sequence): however you can change this value ‘on the fly’ for the actual session, only for the use with instant commands, setting ups.delay.start with upsrw(8).

offdelay = value

Time to wait before shutting down the UPS (seconds). This value is truncated to units of 6 seconds (less than 60 seconds) or 60 seconds (more than 60 seconds). Defaults to 30 seconds.

This option provides a default value for ups.delay.shutdown that will then be used by the driver in the automatic shutdown sequence (i.e. calling the driver with the -k option, calling upsdrvctl(8) with the shutdown option or when the FSD flag is set and upsmon(8) enters its shutdown sequence): however you can change this value ‘on the fly’ for the actual session, only for the use with instant commands, setting ups.delay.shutdown with upsrw(8).

stayoff

If you set stayoff in ups.conf(5) when FSD arises the UPS will call a shutdown.stayoff shutting down after ups.delay.shutdown seconds and won’t return (see Known Problems), otherwise (standard behaviour) the UPS will call shutdown.return shutting down after ups.delay.shutdown seconds and then turn on after ups.delay.start seconds (if mains meanwhile returned).

protocol = string

Skip autodetection of the protocol to use and only use the one specified. Supported values: bestups, hunnox, masterguard, mecer, megatec, megatec/old, mustek, q1, voltronic, voltronic-qs, voltronic-qs-hex and zinto.

Run the driver program with the --help option to see the exact list of protocol values it would currently recognize.

Note that if you end up using the q1 protocol, you may want to give a try to the mecer, megatec and zinto ones setting the novendor/norating flags (only one, or both).

pollfreq = num

Set polling interval for full updates, in seconds, to reduce the message traffic. Between two polling requests, the driver will do quick polls dealing just with ups.status at an interval specified by the pollinterval driver option (details in ups.conf(5)). The default value is 30 (in seconds).

If your UPS doesn’t report either battery.charge or battery.runtime you may want to add the following ones in order to have guesstimated values:

default.battery.voltage.high = value

Maximum battery voltage that is reached after about 12 to 24 hours charging. If you want the driver to report a guesstimated battery.charge, you need to specify this (see Battery Charge Guesstimation).

default.battery.voltage.low = value

Minimum battery voltage just before the UPS automatically shuts down. If you want the driver to report a guesstimated battery.charge, you need to specify this (see Battery Charge Guesstimation).

default.battery.voltage.nominal = value, override.battery.voltage.nominal = value

Some devices show a wrong nominal battery voltage (or none at all), so you may need to override or set a default value.

override.battery.packs = value

Some devices "natively" report just a part of the total battery voltage (see also battery_voltage_reports_one_pack below).

For instance, if battery.voltage.nominal is 24 V, but it reports a battery.voltage of around 2 V, the number of battery.packs to correct this reading would be 12.

The driver will attempt to detect this number automatically, but if this fails somehow, you may want to override this value.

Note that this is primarily useful for "guesstimation" of battery.charge and/or battery.runtime (with runtimecal setting), if those readings are not provided by the device directly.

battery_voltage_reports_one_pack

Some devices "natively" report just report a part of the total battery voltage (see also override.battery.packs above, if that value is not reported by the device or properly guessed by the driver otherwise).

If this flag is set, most of the subdrivers (except those which know about more complicated device-specific nuances, currently: ablerex, masterguard and voltronic-qs-hex) adjust their ultimately reported battery.voltage value as a multiple of battery.packs and "native" battery.voltage).

Note this is primarily useful for consistent diagnostics and graphing of the numbers, and should not impact the "guesstimation" of battery.charge and/or battery.runtime - so rather a cosmetic adjustment, than critical.

runtimecal = value,value,value,value

Parameter used in the (optional) runtime estimation. This takes two runtimes at different loads. Typically, this uses the runtime at full load and the runtime at half load. For instance, if your UPS has a rated runtime of 240 seconds at full load and 720 seconds at half load, you would enter

runtimecal = 240,100,720,50

The first load should always be higher than the second. If you have values available for loads other than 100 and 50 % respectively, you can use those too, but keep them spaced apart as far as reasonably possible. Just don’t get too close to no load (prediction of runtime depends more on idle load for the battery then).

chargetime = value

The time needed to fully recharge the battery after being fully discharged. If not specified, the driver defaults to 43200 seconds (12 hours). Only used if runtimecal is also specified.

idleload = value

Minimum battery load used by the driver to estimate the runtime. If not specified, the driver defaults to 10%. Only used if runtimecal is also specified.

This driver supports some instant commands (see upscmd(8)):

beeper.toggle

Toggle the UPS beeper. (Not available on some hardware)

load.on

Turn on the load immediately. (Not available on some hardware)

load.off

Turn off the load immediately (see Known Problems).

shutdown.return

Turn off the load and return when power is back. Uses the timers defined by ups.delay.start and ups.delay.shutdown.

shutdown.stayoff

Turn off the load and remain off (see Known Problems). Uses the timer defined by ups.delay.shutdown.

shutdown.stop

Stop a shutdown in progress.

test.battery.start.deep

Perform a long battery test. (Not available on some hardware)

test.battery.start.quick

Perform a quick (10 second) battery test.

test.battery.stop

Stop a running battery test. (Not available on some hardware)

Due to popular demand, this driver will report a guesstimated battery.charge and optionally battery.runtime, provided you specified a couple of the Extra Arguments listed above.

If you specify both battery.voltage.high and battery.voltage.low in ups.conf(5), but don’t enter runtimecal, it will guesstimate the state of charge by looking at the battery voltage alone. This is not reliable under load, as this only gives reasonably accurate readings if you disconnect the load, let the battery rest for a couple of minutes and then measure the open cell voltage. This just isn’t practical if the power went out and the UPS is providing power for your systems.

                     battery.voltage - battery.voltage.low
battery.charge =  ------------------------------------------ x 100 %
                  battery.voltage.high - battery.voltage.low

There is a way to get better readings without disconnecting the load but this requires one to keep track on how much (and how fast) current is going in and out of the battery. If you specified the runtimecal, the driver will attempt to do this. Note however, that this heavily relies on the values you enter and that the UPS must be able to report the load as well. There are quite a couple of devices that report 0 % (or any other fixed value) at all times, in which case this obviously doesn’t work.

The driver also has no way of determining the degradation of the battery capacity over time, so you’ll have to deal with this yourself (by adjusting the values in runtimecal). Also note that the driver guesses the initial state of charge based on the battery voltage, so this may be less than 100 %, even when you are certain that they are full. There is just no way to reliably measure this between 0 and 100 % full charge.

This is better than nothing (but not by much). If any of the above calculations is giving you incorrect readings, you are the one that put in the values in ups.conf(5), so don’t complain with the author. If you need something better, buy a UPS that reports battery.charge and battery.runtime all by itself without the help of a NUT driver.

The nutdrv_qx driver having replaced the megatec ones, some configuration changes may be required by users switching to nutdrv_qx.

Part of this, the following megatec options, in ups.conf(5), have to be changed:

battvolts

You need to use default.battery.voltage.high and default.battery.voltage.low

dtr and rts

You need to use cablepower

ignoreoff

This parameter can simply be discarded, since it was a wrong understanding of the specification.

The nutdrv_qx driver having replaced the blazer ones, some configuration changes may be required by users switching to nutdrv_qx.

Part of this, the following blazer options, in ups.conf(5), have to be changed:

ondelay

While the previous blazer drivers expected minutes, the new nutdrv_qx driver wants seconds.

The following instant command has also been changed:

test.battery.start value

The nutdrv_qx driver having replaced the bestups one, some configuration changes may be required by users switching to nutdrv_qx.

Part of this, the following bestups options, in ups.conf(5), are no longer supported by this driver:

nombattvolt,  battvoltmult

See Battery Charge Guesstimation.

ID

Discarded.

The nutdrv_qx driver having replaced the voltronic ones, some configuration changes may be required by users switching to nutdrv_qx.

Part of this, the following voltronic options, in ups.conf(5), have to be changed:

ondelay

While the previous voltronic drivers expected minutes, the new nutdrv_qx driver wants seconds. It no longer defaults to 0 minutes but to 3 minutes (i.e. 180 seconds) for compatibility with the users switching from the old blazer drivers.

battnumb

This option has been renamed to battery_number.

The following options are no longer supported by this driver, you can now change them more conveniently ‘on the fly’ calling upsrw(8) with the appropriate NUT variable - provided that your UPS supports them.

Some UPS commands aren’t supported by all models. In most cases, the driver will send a message to the system log when the user tries to execute an unsupported command. Unfortunately, some models don’t even provide a way for the driver to check for this, so the unsupported commands will silently fail.

Both the load.off and shutdown.stayoff instant commands are meant to turn the load off indefinitely. However, some UPS models don’t allow this.

Some models report a bogus value for the beeper status (will always be enabled or disabled). So, the beeper.toggle command may appear to have no effect in the status reported by the driver when, in fact, it is working fine.

The temperature and load value is known to be bogus in some models.

The UPSes supported by voltronic protocol report warnings through a 64bit flag (bit1bit2...bit63bit64) where 1 means that a warning arose, while 0 means no warning. Since more than one warning at a time can be signaled, and because of the limited space in the ups.alarm variable, if the length of the warnings exceeds that of ups.alarms variable, they will be reported as bits. If you want to know the explanation of that bit you can either watch the log or see the next table (unlisted bits equal to unknown warnings).

Table 1. UPS Warnings for voltronic UPSes

• Daniele Pezzini <hyouko@gmail.com>
• Arnaud Quette <arnaud.quette@gmail.com>
• John Stamp <kinsayder@hotmail.com>
• Peter Selinger <selinger@users.sourceforge.net>
• Arjen de Korte <adkorte-guest@alioth.debian.org>
• Alexander Gordeev <lasaine@lvk.cs.msu.su>
• Edgar Fuß <ef@math.uni-bonn.de>

blazer_ser(8), blazer_usb(8), nutupsdrv(8), ups.conf(5), upsc(8), upscmd(8), upsdrvctl(8), upsmon(8), upsrw(8)

bestups(8), blazer_ser(8), blazer_usb(8), masterguard(8), nutdrv_atcl_usb(8), nutupsdrv(8), riello_ser(8), riello_usb(8), ups.conf(5), upsd(8).