APC_MODBUS(8)

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

💖 apc_modbus 💖

okay bestie, welcome to apc_modbus(8) — that's the NUT Manual page for the driver that speaks APC Smart-UPS Modbus protocol. yes, we're doing hardware today. put your hair up, it's gonna be cute. 🎀

✨ NAME ✨

apc_modbus — the driver for the APC Smart-UPS Modbus protocol, aka the thing that lets NUT actually talk to your UPS over Modbus instead of the old USB HID situation. it's giving glow up. 🔥

✨ SYNOPSIS ✨

apc_modbus -h

apc_modbus -a UPS_NAME [OPTIONS]

that's it. that's the whole vibe. -h if you just want the help, or -a UPS_NAME with whatever [OPTIONS] you need. 💅

✨ SUPPORTED HARDWARE ✨

so basically? this driver should work for all the APC Modbus UPS devices. no gatekeeping. some devices might expose more than what's currently supported tho — like multiple phases, for example. so if yours is fancier, don't be shocked if there's stuff we can't read yet.

here's the general rule of thumb, and it's a good one: APC devices (or firmware versions) released after 2010 are more likely to support Modbus than the USB HID standard. so if you've got a newer-ish unit, Modbus is probably your lane. 🦋

tested with the following hardware, bestie — this is the receipts list:

  • SMT1500 (Smart-UPS 1500, Firmware 9.6)
  • SMX750 (Smart-UPS X 750, Firmware 10.1)
  • SMX1500 (Smart-UPS X 1500, Firmware 15.0)
  • SMX2200 (Smart-UPS X 2200, Firmware 15.0)

and heads up: you will have to enable Modbus communication. it's not on by default, that would be too easy. 🙈 on the front panel of the UPS, go to Advanced Menu mode, under Configuration, and enable Modbus. boom. done. slay.

Note 💜 this driver was tested with Serial, TCP and USB interfaces for Modbus. notably: - the Serial ports are not available on all devices nowadays - the TCP support may require a purchase of an additional network management card - the USB support currently requires a non-standard build of libmodbus (pull request against the upstream library is pending, as of at the time of this publication) as a pre-requisite to building NUT with this part of the support for more details (including how to build the custom library and NUT with it) please see NUT PR #2063.
Note 😭 as currently published, this driver supports reading information from the UPS. implementation of support to write (set modifiable variables or send commands) is expected with a later release. this can impact the host shutdown routines in particular — no ability to actively tell the UPS to power off or cycle in the end. 🫠 as a workaround, you can try integrating apctest (from the "apcupsd" project) with a "Test to kill power" into your late-shutdown procedure, if needed. lowkey iconic that we're outsourcing that.

✨ EXTRA ARGUMENTS ✨

this driver also supports the following optional settings. extra. optional. the little bonus tracks on the album. 🎵

  • port = string — required option for all NUT drivers. some value must be set, typically auto for drivers that handle USB connections.
Note this could be a device filesystem path like /dev/usb/hiddev0 but current use of libusb API precludes knowing and matching by such identifiers. they may also be inherently unreliable (dependent on re-plugging and enumeration order). at this time the actual value is ignored, but syntactically some port configuration must still be there. 💀 so yeah, it's a required field that does nothing. we love a formality.

it is possible to control multiple UPS units simultaneously by running several instances of this driver, provided they can be uniquely distinguished by setting some combination of the vendor, product, vendorid, productid, serial, bus and/or device options detailed below. for devices or operating systems that do not provide sufficient information, the allow_duplicates option can be of use (limited and risky!). ⚠️

  • vendorid = regex, productid = regex, vendor = regex, product = regex, serial = regex — select a specific UPS, in case there is more than one connected via USB. each option specifies an extended regular expression (see regex(7) for more information on regular expressions), which must match the UPS's entire respective vendor/product/serial string values (minus any surrounding whitespace), or the whole 4-digit hexadecimal code for vendorid and productid.

try lsusb(8) or running this NUT driver with the -DD command-line argument for finding out the strings to match. 🔍

examples:

  • -x vendor="Foo.Corporation.*"
  • -x vendorid="051d*" (APC)
  • -x product=".*(Smart|Back)-?UPS.*"
  • bus = regex — OPTIONAL, NOT RECOMMENDED.

select a UPS on a specific USB bus or group of buses. the argument is a regular expression that must match the bus name where the UPS is connected (e.g. bus="002" or bus="00[2-3]") as seen on Linux in /sys/bus/usb/devices or lsusb(8); including leading zeroes. 🚌

Note bus numbers are not guaranteed by the OS to be stable across re-boots, kernel driver reloads or device re-plugging (e.g. changing visible population of USB hubs). so like... it might move. and then your config is lying to you.
  • device = regex — OPTIONAL, NOT RECOMMENDED.

select a UPS on a specific USB device or group of devices. the argument is a regular expression that must match the device name where the UPS is connected (e.g. device="001" or device="00[1-2]") as seen on Linux in /sys/bus/usb/devices or lsusb(8); including leading zeroes.

Note device numbers are not guaranteed by the OS to be stable across re-boots or device re-plugging. same energy as above. not me trusting enumeration order 💀
  • busport = regex — OPTIONAL, NOT RECOMMENDED.

if supported by the hardware, OS and libusb on the particular deployment, this option should allow to specify physical port numbers on an USB hub, rather than logical device enumeration values, and in turn — this should be less volatile across reboots or re-plugging. the value may be seen in the USB topology output of lsusb -tv on systems with that tool, for example. 🔌

Note this option is not practically supported by some NUT builds (it should be ignored with a warning then), and not by all systems that NUT can run on. so... sometimes it's real, sometimes it's just decorative.
  • allow_duplicates — OPTIONAL, NOT RECOMMENDED.

if you have several UPS devices which may not be uniquely identified by the options above (e.g. only VID:PID can be discovered there), this flag allows each driver instance where it is set to take the first match if available, or proceed to try another.

normally the driver initialization would abort at this point claiming "Resource busy" or similar error, assuming that the otherwise properly matched device is unique — and some other process already handles it.

Warning ⚠️ this feature is inherently non-deterministic! the association of driver instance name to actual device may vary between runs! - if you only care to know that at least one of your no-name UPSes is online, this option can help. 🫶 - if you must really know which one, it will not! 😭
  • usb_set_altinterface = bAlternateSetting — force redundant call to usb_set_altinterface(), especially if needed for devices serving multiple USB roles where the UPS is not represented by the interface number 0 (default).
  • usb_config_index, usb_hid_rep_index, usb_hid_desc_index, usb_hid_ep_in, usb_hid_ep_out — force use of specific interface, endpoint, descriptor index etc. numbers, rather than defaulting to 0 (rarely other values in certain drivers for some devices known to use non-zero numbers). specified as a hexadecimal number.

as a rule of thumb for usb_hid_desc_index discovery, you can see larger wDescriptorLength values (roughly 600+ bytes) in reports of lsusb or similar tools. 📏

  • LIBUSB_DEBUG = INTEGER — run-time troubleshooting of USB-capable NUT drivers can involve not only raising the common NUT debug verbosity (e.g. using the DEBUG_MIN setting in ups.conf(5) or protocol commands to change the driver.debug value), but may also benefit from LibUSB specific debugging.

for the latter, you can set the LIBUSB_DEBUG driver option; alternatively you can classically export the environment variable LIBUSB_DEBUG before starting a NUT driver program (may be set and "exported" in driver init script or service method, perhaps via nut.conf(5)), to a numeric value such as 4 ("All messages are emitted"). 🐛

for more details, including the currently supported values for your version of the library, see e.g.:

  • porttype=value — set the type of the port used. available values are serial for RS232/485 based connections, tcp for TCP/IP connections and usb for USB connections.
  • port=value — depending on the port type you can select a port here. for usb only auto is supported, for serial you can pass a device path like /dev/ttyS0 and for tcp you can pass an IP address or a hostname with optional port like example.com:502.
  • baudrate=num — set the speed of the serial connection. the default baudrate is 9600.
  • parity=value — set the parity of the serial connection. available values are N for none, E for even and O for odd. the default parity is N (none).
  • databits=num — set the data bits of the serial connection. the default databits is 8.
  • stopbits=num — set the stop bits of the serial connection. the default stopbits is 1.
  • slaveid=num — set the Modbus slave id. the default slave id is 1.
  • response_timeout_ms=num — set the Modbus response timeout. the default timeout is set by libmodbus. it can be good to set a higher timeout on TCP connections with high latency. ⏳

okay we're not done yet bestie, there's more coming — don't go anywhere 💖

🐛 BUGS 🐛

okay bestie this is the part where we're honest about the messy bits 💅 nobody's perfect and this driver is no exception.

RTU USB support

so here's the tea: this driver is relying on the fancy advanced features of libmodbus to speak Modbus protocol over USB specifically (Serial and TCP are, like, part of the common library codebase, nbd). And at the time of this writing, the common library project is just expecting a merge of the pull request that adds this ability. so it's giving "coming soon to a distro near you" 🫠

for the time being, if your OS distribution does not ship the required feature set, you may have to build your own libmodbus and subsequently (re-)build NUT against this library — and yes, the NUT GitHub Wiki walks you through it at

https://github.com/networkupstools/nut/wiki/APC-UPS-with-Modbus-protocol

the short sequence may be like follows, and it's literally this:

cd ~/
git clone -b rtu_usb https://github.com/networkupstools/libmodbus
cd libmodbus
./autogen.sh
./configure --with-libusb --prefix=/path/to/prefix
make install
Note - you may need to make && sudo make install if you want to place this library files' variant into a system path (like --prefix=/usr/local/ups to match NUT defaults — this activity would need privilege elevation via sudo), and not into your home directory or some /tmp location. - conversely, you may want to ./configure --with-libusb --enable-static --disable-shared --prefix=/path/to/prefix and only build and install a static libmodbus.a (can well be installed into /tmp or similarly short-lived location), so that the customized Modbus+USB logic gets built directly into apc_modbus binary program and there would be no potential run-time conflict with a dynamic library file available elsewhere in the system.

then it's NUT's turn, same energy:

cd ~/
git clone https://github.com/networkupstools/nut
cd nut
./autogen.sh
./configure --with-drivers=apc_modbus --with-usb --with-modbus \
   --with-modbus-includes=-I/path/to/prefix/include/modbus \
   --with-modbus-libs="-L/path/to/prefix/lib -lmodbus"
make
Note - other NUT configure options may be needed for proper behavior, such as --prefix, --with-confdir, --with-user and --with-group to match your packaged or otherwise preceding NUT installation.

and honestly? ./configure --enable-inplace-runtime may be a good start to inherit build configuration from an existing NUT deployment, as further detailed at

https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests

Using host names for UPS NMC

so an UPS network management card may be assigned a fixed/static IP address or a dynamic one (e.g. by DHCP) in your network. due to this, you may want or have to use a dynamic naming service to access the UPS. and like… note that this may become a problem specifically during large outages and shutdowns, when your DHCP/DNS server might already go down while the driver needs to resolve the name involved (especially during late-shutdown hooks, when a new instance of the driver program might start just to tell the UPS to power off or to power-cycle). 😭 the vibe is "everything is on fire and also DNS is gone."

it may be wise to ensure your OS name service client can cache the UPS name sufficiently long, or to use fixed IP addressing (and an entry in /etc/hosts for good measure, so you only have one spot to eventually re-configure this). lowkey iconic advice, do it 🫶

👑 AUTHORS 👑

the mastermind behind this whole thing:

  • Axel Gembe <axel@gembe.net>

🌈 SEE ALSO 🌈

The core driver

Internet resources

and that's a wrap bestie 💖 this whole page came to you from Network UPS Tools 2.8.5, dated 10/07/2026 — go forth and Modbus, fr fr ✨🦋 no cap, you're gonna slay this 💅

📦 where this page comes from