Per issue #3301 time may come when apcupsd users would want or have to become NUT users. This page should aggregate notes from early brave explorers to help ease the transition.

We would welcome the first explorers to update it with factual suggestions about the migration ("In apcupsd-land we did this, and for NUT a similar concept/setup looks like this").

It may be problematic to install both toolkits side-by-side with packaging on some systems allowing only one of the UPS management implementations, but it is recommended to build the recent NUT master branch anyway to try the newest features (and debug-ability ever growing), e.g. following the instructions from https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests and platform-specific prerequisites linked from there.

For newcomers, it may be helpful to start with the NUT Overview page, generally with https://networkupstools.org/documentation.html, and the NUT Configuration Examples book.

Monitoring, Management, Shutdown setup

To recap from the overview linked above, NUT uses a three-layer approach:

• NUT drivers are user-land programs which talk to an UPS (or ePDU, GenSet, Solar Controller, IPMI, etc.) using some media and some vendor-defined protocol. Some drivers are one-trick ponies, others support a number of protocol dialects and/or media for physical link between a computer and an UPS.
• A NUT data server upsd aggregates information from NUT drivers running on the same system, to make it available to TCP/IP clients using a standardized networking protocol.
• There are many clients, like command-line upsc and upslog to query data, upsrw and upscmd to write settings and post commands to a device, CGI clients, graphical wmNut icon for a toolbar or NUT-Monitor application, to name a few.
• One important client is upsmon which takes care of notifying the user about outages and other issues, and shutting down the system when time comes. More flexible workflows can be achieved by integrating it with upssched. A late-shutdown integration script is recommended to run when the system is nearly down (FS remounted read-only), to tell the UPS to actually power off/cycle... and then the script can be configured to wait for a long time and reboot its host (to avoid indefinite outages when your UPS model refuses to power-cycle just because wall power came back at the wrong moment).

On OSes with systemd or SMF, the nut-driver-enumerator can automatically take care of wrapping your NUT driver configurations from ups.conf into separate service instances with appropriate dependencies corresponding to their media type(s). Keep this in mind when experimenting with driver configurations -- you can end up with two NUT driver program instances (started by the service and by your interactive shell) competing for exclusive access to a device node.

Useful out-of-the-box clients

• https://networkupstools.org/docs/man/index.html#_clients_commands
• https://networkupstools.org/docs/man/index.html#_cgi_programs
• See also https://networkupstools.org/projects.html