dummy-ups looks like a standard 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 driver. This mode is mostly useful for development and testing purposes.

dummy-ups acts as a NUT client, simply forwarding data. This can be useful for supervision purposes. This can also allow some load sharing between several UPS instances, using a point-to-point communication with the UPS.

Port is a definition file name for dummy-ups. This can either be an absolute or a relative path name. In the latter case the NUT sysconfig directory (ie /etc/nut, /usr/local/ups/etc, ...) is prepended.

This file is generally named "something.dev". It contains a list of all valid data and associated values, 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". It can also be empty, in which case only a basic set of data is available: device., driver., ups.mfr, ups.model, ups.status

Samples 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 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 events sequences. For example, the following sequence will loop on switching ups.status between "OL", "OB" and "OB LB" every minute:

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.

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, by adding these to the definition file. 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 support the same instant commands and settable values.