DUMMY-UPS(8)

📦
version 2.8.5 · 18 versions
, in fedora 43, fedora 44

🌸 NAME 🌸

dummy-ups — bestie, this is the driver for multi-purpose UPS emulation or relay 💖

✨ SYNOPSIS ✨

dummy-ups -h

dummy-ups -a UPS_NAME [OPTIONS]
📌 Heads up! This man page only documents the specific features of the dummy-ups driver. For info about the core driver, go peek at nutupsdrv(8). 🫶

🎀 DESCRIPTION 🎀

Okay so this program is a whole multi-purpose UPS emulation tool. Its general vibe depends on the running mode: "dummy" (which is either "dummy-once" or "dummy-loop"), or "repeater". ✨

💫 Dummy Mode 💫

In this mode, dummy-ups looks like a standard NUT device driver to upsd(8) and lets you change literally any value for testing purposes. It's giving main character energy.

It's both interactive — controllable through the upsrw(8) and upscmd(8) commands (or whatever equivalent graphical tool you're into) — 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.

🫶 Note: See below about the differences of dummy-once vs. dummy-loop modes — the former may be more suitable for "interactive" uses and tests.

🌈 Repeater Mode 🌈

In this mode, dummy-ups acts as a NUT client, simply forwarding data. Lowkey iconic.

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 actual UPS or ePDU device. 💅

This arrangement can also help with networked UPSes, whose network management cards can be overwhelmed with a whole farm of servers directly polling SNMP or other networked 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.

Since NUT v2.8.0, the mode specification in ups.conf allows users to override the mode of operation which would be otherwise guessed by the driver. ⭐

🧚 Dummy Mode 🧚

In this context, port in the ups.conf block specifies a "definition 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.

📌 Note: The "sysconfig" location is built-in according to configure script arguments, but can be tuned at run time by the NUT_CONFPATH environment variable. See the tests/NIT/nit.sh script in NUT sources, which heavily relies on this driver, for more examples.

Since NUT v2.8.0 two aspects of this mode are differentiated:

  • dummy-once reads the specified file once to the end (interrupting for TIMER lines, etc.) and does not re-process it until the filesystem timestamp of the data file is changed; this reduces run-time stress if you test with a lot of dummy devices, and allows use/test cases to upsrw variables into the driver instance — and they remain in memory until the driver is restarted (or the file is touched or modified);

Since NUT v2.8.0 dummy-once is assigned by default to files with a *.dev naming pattern.

  • dummy-loop reads the specified file again and again, with a short sleep between the processing cycles; for sequence files using a TIMER keyword (see below), or for use/test cases which modify file contents with external means, this allows an impression of a device whose state changes over time. 🦋

Before NUT v2.8.0 this was the only aspect, so a simple dummy mode value maps to this behavior for backwards compatibility.

Since NUT v2.8.0 dummy-loop is assigned by default to files with a *.seq naming pattern, and dummy is assigned by default to files with other naming patterns that the driver could not classify.

😭 Note: Said defaulting based on filename pattern can break third-party test scripts which earlier expected *.dev files to work as a looping sequence with a TIMER keywords to change values slowly. Now such files should get processed to the end once. Specify mode=dummy-loop driver option or rename the data file used in the port option for legacy behavior. Use/Test-cases which modified such files content externally should not be impacted.

For instance:

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

[dummy2]
        driver = dummy-ups
        port = epdu-managed.dev
        desc = "dummy-ups in dummy-once mode"

This definition file, specified by the port argument in the example above, is generally named something like 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) data dump (<varname>: <value>). This means you can easily create definition files from an existing UPS using upsc > file.dev. 💅

Note that the Network UPS project provides an extensive DDL (Devices Dumps Library) with files which can be used for modelling real devices. Entries for the DDL library are best prepared with the tools/nut-ddl-dump.sh script from NUT sources instead of plain upsc, to provide some additional 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" or "share" directory of your system distribution. 🎀

Since dummy-ups will usually 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.

📌 Note: By default since NUT v2.8.0, it will not loop on files in dummy-once mode, e.g. those with a .dev extension, unless their timestamp changes.

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 for dummy-loop mode 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 and possibly the common pollinterval setting.

Another, more recently introduced instruction is ALARM, which allows the simulation of UPS alarms in much the same way they would be raised by real driver implementations. Modern drivers decouple alarm states from the ups.status variable, and raising ALARM by setting it as a status token is discouraged in favor of using modern, common functions for raising alarms within the driver code.

The ALARM instruction is intended to simulate this behavior as closely as possible. The value following an ALARM instruction is treated as the alarm message and is eventually published as the ups.alarm variable, with the ALARM token also set in ups.status by internal driver mechanisms, rather than by directly manipulating the variable. Multiple ALARM instructions will have their messages combined into the ups.alarm variable, just as would happen with real driver logic. 👑

Conversely, any ALARM instruction on its own will clear active alarm states. See below for an example of setting and resetting alarms:

ALARM [UPS too warm to charge]
ALARM [UPS circuit is overheating]
TIMER 5
ALARM
TIMER 5
ALARM [UPS too cold to charge]

🌟 Repeater Mode 🌟

In this context, port in the ups.conf block is the name of the target 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.

⚠️ Beware that any error encountered at repeater mode startup (e.g. when not all target UPS to be repeated or their upsd instances are connectable yet) will by default cause the dummy-ups driver to terminate prematurely. This behaviour can be changed by setting the repeater_disable_strict_start flag, making such errors non-fatal.

💖 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(8) and upscmd(8) 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). That is, the driver should not allow to define a new variable via upsrw. ✨

Conversely, if you need to remove a 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 ✨

Okay so story time bestie 💖 — Dummy Mode was literally written in one single evening. One. Evening. The way that whoever did that just sat down and cooked 🍳✨ — it was made to replace the old dummycons testing driver, which was way too limited and, honestly? Needy. It required a terminal just to interact with it. Not the vibe. 🚫

dummy-ups is the moment for NUT client development and other testing purposes, fr fr. It's giving "developer bestie's little lab partner". 🧪🫶

It also helps out the NUT Quality Assurance effort by automating some tests on the NUT framework and the NIT (NUT Integration Test suite). Peep the tests/NIT/nit.sh script in the NUT sources — it heavily relies on this driver — for more examples. That script is lowkey obsessed with dummy-ups and honestly, same. 👑

And now?? It offers a repeater mode. 👀 This helps with building the Meta UPS approach, which lets you build a virtual device composed of several other devices (either UPS, PDUs), or maybe represent the same device that supports several communication protocols and different media (Serial, USB, SNMP...). Main character energy for real. 🌈⭐

💀 BUGS 💀

Okay so not everything is slay yet, bestie, we gotta be honest:

  • Instant commands are not yet supported in Dummy Mode. Not yet. Soon hopefully. 🙈
  • The data need name/value checking enforcement, plus boundaries or enumeration definition.

So like, it works, but it's still in its glow-up era. 🎀

🚨 CAVEATS 🚨

This part is important, no cap — read it before you go feral with your config. 😭

If you use service management frameworks like systemd or SMF to manage the dependencies between driver instances and the data server, and some of these drivers are dummy-ups in repeater mode representing data from another driver running on the same system, then you may have to set up special dependencies (e.g. with systemd "drop-in" snippet files) to allow your nut-server to start after the "real" device drivers and before such repeater drivers. And lowkey why? Because without a responding server, they would fail to start anyway. 💅

This may also need special care in upsd.conf and/or ups.conf files so you don't block the system start-up for too long while the repeater driver has not started. Don't let your boot hang, bestie, that's not the vibe. ⏳🚫

👑 AUTHOR 👑

Arnaud Quette

(Iconic. Legend. We stan. 💜)

🦋 SEE ALSO 🦋

🌸 Clone drivers 🌸

The "repeater" mode of the dummy-ups driver is in some ways similar to the clone and clone-outlet drivers, which sit on top of another driver socket (or named Windows pipe) locally, and let users group clients to a particular outlet of a device and deal with this output as if it were a normal UPS. 👯‍♀️✨

Notably, in this mode the dummy-ups driver is a client to the networked NUT protocol and can relay information of local or remotely served devices — and it requires a running NUT data server upsd to represent the "real" device for this to work. No server, no relay, periodt. 🔌💅

🌐 Internet Resources 🌐

The NUT (Network UPS Tools) home page:

https://www.networkupstools.org/historic/v2.8.5/

And that's a wrap, bestie!! 🎀✨ This lil page came from Network UPS Tools 2.8.5 and it's dated 10/07/2026 — go forth and dummy-up responsibly, mwah 💖🫶

📦 where this page comes from