NAME

dummy-ups - Driver for multi-purpose UPS emulation

NOTE

This man page only documents the specific features of the dummy-ups driver. For information about the core driver, see nutupsdrv(8).

DESCRIPTION

This program is a multi-purpose UPS emulation tool. Its behavior depends on the running mode: "dummy" or "repeater".

Dummy Mode

In this mode, dummy-ups looks like a standard NUT device driver to upsd(8) and allows one to change any value for testing purposes. It is both interactive, controllable through the upsrw(1) and upscmd(1) commands (or equivalent graphical tool), and batchable through script files. It can be configured, launched and used as any other "real" NUT driver. This mode is mostly useful for development and testing purposes.

Repeater Mode

In this mode, dummy-ups acts as a NUT client, simply forwarding data. This can be useful for supervision purposes. This mode can also allow some load sharing between several upsd instances communicating with ultimate NUT clients, with a "central" one using a point-to-point communication with the UPS. This arrangement can also help with networked UPSes, whose network management cards can be overwhelmed with a farm of servers directly polling SNMP or other protocols every few seconds.

IMPLEMENTATION

The port specification in ups.conf depends on the running mode, and allows the driver to select the right mode of operation.

Dummy Mode

In this context, port in the ups.conf block defines a file name for the dummy-ups to read data from. This can either be an absolute or a relative path name. In the latter case the NUT sysconfig directory (i.e. /etc/nut, /usr/local/ups/etc, …) is prepended.

For instance:

[dummy]
        driver = dummy-ups
        port = evolution500.seq
        desc = "dummy-ups in dummy mode"

This file is generally named something.dev or something.seq. It contains a list of all valid variables and associated values (you can later use upsrw only to modify values of these variables), and has the same format as an upsc(8) dump (<varname>: <value>). So you can easily create definition files from an existing UPS using upsc > file.dev.

Note that the Network UPS project provides a DDL (Devices Dumps Library) at link:https://networkupstools.org/ddl/index.html with files which can be used for modelling real devices. Entries for the DDL library are prepared with the ./tools/nut-ddl-dump.sh script from NUT sources instead of plain upsc to provide some other data points from other NUT clients as well.

The file can also be empty, in which case only a basic set of data is available: device.*, driver.*, ups.mfr, ups.model, ups.status as filled by the driver itself.

Some sample definition files are available in the data directory of the NUT source tree, and generally in the sysconfig directory of your system distribution.

Since dummy-ups will loop on reading this file, you can dynamically modify it with some external process to "interact" with the driver. This will avoid message spam into your system log files, if you are using NUT default configuration.

You can also use the TIMER <seconds> instruction to create scheduled event sequences (such files are traditionally named with the .seq extension). For example, the following sequence will loop on switching ups.status between "OL", "OB" and "OB LB" every minute:

ups.status: OL
TIMER 60
ups.status: OB
TIMER 60
ups.status: OB LB
TIMER 60

It is wise to end the script with a TIMER keyword. Otherwise dummy-ups will directly go back to the beginning of the file and, in particular, forget any values you could have just set with upsrw.

Note that to avoid CPU overload with an infinite loop, the driver "sleeps" a bit between file-reading cycles (currently this delay is hardcoded to one second), independently of (and/or in addition to) any TIMER keywords.

Repeater Mode

In this context, port in the ups.conf block is the name of a remote UPS, using the NUT format, i.e.:

<upsname>@<hostname>[:<port>]

For instance:

[repeater]
        driver = dummy-ups
        port = ups1@remotehost
        desc = "dummy-ups in repeater mode"

Unlike UPS specifications in the rest of NUT, the @hostname portion is not optional - it is the @ character which enables Repeater Mode. To refer to an UPS on the same host as dummy-ups, use port = upsname@localhost.

Note that to avoid CPU overload with an infinite loop, the driver "sleeps" a bit between data-requesting cycles (currently this delay is hardcoded to one second), so propagation of data updates available to a remote upsd may lag by this much.

INTERACTION

Once the driver is loaded in dummy mode, you can change any variables, except those of the driver.* and server.* collections. You can do this by either editing the definition file, or use the upsrw(1) and upscmd(1) commands.

Note that in simulation mode, new variables can be added on the fly, but only by adding these to the definition file (and waiting for it to be re-read). Conversely, if you need to remove variable (such as transient ones, like ups.alarm), simply update these by setting an empty value. As a result, they will get removed from the data.

In repeater mode, the driver acts according to the capabilities of the UPS, and so supports the same instant commands and settable values.

BACKGROUND

Dummy Mode was originally written in one evening to replace the previous dummycons testing driver, which was too limited, and required a terminal for interaction.

dummy-ups is useful for NUT client development, and other testing purposes.

It also helps the NUT Quality Assurance effort, by automating some tests on the NUT framework.

It now offers a repeater mode. This will help in building the Meta UPS approach, which allows one to build a virtual device, composed of several other devices (either UPS, PDUs).

BUGS

Instant commands are not yet supported in Dummy Mode, and data need name/value checking enforcement, as well as boundaries or enumeration definition.

AUTHOR

Arnaud Quette

SEE ALSO

Internet Resources:

The NUT (Network UPS Tools) home page: http://www.networkupstools.org/