\fBdummy\-ups\fR looks like a standard device driver to \fBupsd\fR(8) and allows one to change any value for testing purposes\&. It is both interactive, controllable through the \fBupsrw\fR(1) and \fBupscmd\fR(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\&.
\fBdummy\-ups\fR 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\&.
.SH"IMPLEMENTATION"
.sp
The port specification depends on the running mode, and allows the driver to select the right mode\&.
.SS"Dummy Mode"
.sp
Port is a definition file name for \fBdummy\-ups\fR\&. 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 \fBupsc\fR(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\&.\fB, driver\&.\fR, 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\&.
.sp
Since \fBdummy\-ups\fR 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\&.
.sp
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:
.sp
.ifn\{\
.RS4
.\}
.nf
ups\&.status: OL
TIMER 60
ups\&.status: OB
TIMER 60
ups\&.status: LB
TIMER 60
.fi
.ifn\{\
.RE
.\}
.sp
It is wise to end the script with a TIMER\&. Otherwise dummy\-ups will directly go back to the beginning of the file\&.
.SS"Repeater Mode"
.sp
Port is the name of a remote UPS, using the NUT form, ie:
.sp
.ifn\{\
.RS4
.\}
.nf
<upsname>[@<hostname>[:<port>]]
.fi
.ifn\{\
.RE
.\}
.sp
For instance:
.sp
.ifn\{\
.RS4
.\}
.nf
[repeater]
driver = dummy\-ups
port = ups@hostname
desc = "dummy\-ups in repeater mode"
.fi
.ifn\{\
.RE
.\}
.SH"INTERACTION"
.sp
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 \fBupsrw\fR(1) and \fBupscmd\fR(1) commands\&.
.sp
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\&.
.sp
In repeater mode, the driver acts according to the capabilities of the UPS, and so support the same instant commands and settable values\&.
.SH"BACKGROUND"
.sp
This driver was written in one evening to replace the previous dummycons testing driver\&. It was too limited and required to work from a terminal to interact\&.
.sp
\fBdummy\-ups\fR is useful for NUT client development, and other testing purpose\&.
.sp
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)\&.
Instant commands are not yet supported in Dummy Mode, and data need name/value checking enforcement, as well as boundaries or enumeration definition\&.
