I have an older APC UPS that uses modbus to give all info.
According to docs i need to use a custom libmodusb? I have no clue with this, but this is the doc:
APC UPS with Modbus protocol · networkupstools/nut Wiki · GitHub

Can I do this? And how would I do this?

Hello,
Currently running a NUT Master/Slave setup with a Raspberry Pi as the master and two servers as slaves. Everything is humming along nicely with my APC Smart-UPS 1500 (Firmware 15.1), but I recently went down a rabbit hole trying to unlock the "hidden" telemetry that the standard HID driver misses—specifically UPS Load, Power Factor, and Wattage.

I managed to track down the proprietary 940-0127E cable and enabled Modbus on the UPS LCD, but I hit a hard wall when I tried switching to the apc_modbus driver (running NUT 2.8.1). I got the dreaded "Driver was not compiled with USB support" error.

After some digging, it seems like I've hit that "libmodbus patch limbo" where the USB-RTU support isn't officially baked into the standard Debian/Raspberry Pi OS repositories yet.

I’ve considered compiling from source, but for a production power grid, I’d really rather not trade stability for telemetry. Is there any word on a pre-patched version or a "private build" making its way into the common repos soon? It’d be great if we didn't have to choose between a rock-solid shutdown and seeing our actual power stats!

Thanks for any insight!

21 hours ago, bokkoman said:

I have an older APC UPS that uses modbus to give all info.
According to docs i need to use a custom libmodusb? I have no clue with this, but this is the doc:
APC UPS with Modbus protocol · networkupstools/nut Wiki · GitHub

Can I do this? And how would I do this?

This is baked into Unraid NUT, so you'd just chose the appropriate apc_modbus driver:

https://networkupstools.org/docs/man/apc_modbus.html

Hi there folks...

Can someone help out with the configuration of this UPS?
Model: SMS Powervision II upv3000bifx
It only have the rs232 option for connection.
So i'm using a rs232 to USB adapter.

In my unraid i used the console mode and test if my USB is detecting:

T: Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0

D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1

P: Vendor=0403 ProdID=6001 Rev=06.00

S: Manufacturer=FTDI

S: Product=FT232R USB UART

S: SerialNumber=A5069RR4

C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=90mA

I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms

Then i tried the nut but it did not detect my device...

Tried different drivers and modes but none detected...

does anyone have any idea what to do?

On 4/1/2026 at 9:58 AM, Rysz said:

This is baked into Unraid NUT, so you'd just chose the appropriate apc_modbus driver:

https://networkupstools.org/docs/man/apc_modbus.html

How do I select the correct driver? I can select apc_modbus, but that results in nothing and just turning itself back off again.

I have an SMT1500IC that I have updated to the latest firmware (locally). And is connected to unraid with the usb-usb cable that it came with.

Edited April 5Apr 5 by bokkoman

1 hour ago, bokkoman said:

How do I select the correct driver? I can select apc_modbus, but that results in nothing and just turning itself back off again.

I have an SMT1500IC that I have updated to the latest firmware (locally). And is connected to unraid with the usb-usb cable that it came with.

Hello... I actually just spent some time going down this exact same rabbit hole with my SMT1500, to save you some time and sanity here.... The short answer is that the apc_modbus driver won't work with the standard USB cable. But honestly, even if you track down the proprietary APC RJ50-to-USB cable (like I did), it still hits a wall. The underlying Linux library that Unraid and NUT rely on right now doesn't have USB support compiled into it for Modbus. It's a known issue upstream (GitHub Issue #3339) where the standard packages only support pure Serial or Network connections.

To get your server protected today, switch your driver over to usbhid-ups. You’ll miss out on some of the data like exact wattage and power factor, but it will correctly monitor your battery and trigger a solid safe shutdown when the power actually drops. Until the Linux package maintainers officially add that USB patch, usbhid-ups is definitely the way to go unless you want the headache of compiling the driver from scratch yourself!

Hope that helps :-)

1 hour ago, bombz said:

Hello... I actually just spent some time going down this exact same rabbit hole with my SMT1500, to save you some time and sanity here.... The short answer is that the apc_modbus driver won't work with the standard USB cable. But honestly, even if you track down the proprietary APC RJ50-to-USB cable (like I did), it still hits a wall. The underlying Linux library that Unraid and NUT rely on right now doesn't have USB support compiled into it for Modbus. It's a known issue upstream (GitHub Issue #3339) where the standard packages only support pure Serial or Network connections.

To get your server protected today, switch your driver over to usbhid-ups. You’ll miss out on some of the data like exact wattage and power factor, but it will correctly monitor your battery and trigger a solid safe shutdown when the power actually drops. Until the Linux package maintainers officially add that USB patch, usbhid-ups is definitely the way to go unless you want the headache of compiling the driver from scratch yourself!

Hope that helps :-)

Thanks! Fun thing is, the build-in apcupsd does support the modbus, I get correct readings. But when i reboot or restart the apcupsd the readouts are missing data and scrambled. I have to physically remove usb and plug it back in to get the correct readings.

3 hours ago, bombz said:

Hello... I actually just spent some time going down this exact same rabbit hole with my SMT1500, to save you some time and sanity here.... The short answer is that the apc_modbus driver won't work with the standard USB cable. But honestly, even if you track down the proprietary APC RJ50-to-USB cable (like I did), it still hits a wall. The underlying Linux library that Unraid and NUT rely on right now doesn't have USB support compiled into it for Modbus. It's a known issue upstream (GitHub Issue #3339) where the standard packages only support pure Serial or Network connections.

To get your server protected today, switch your driver over to usbhid-ups. You’ll miss out on some of the data like exact wattage and power factor, but it will correctly monitor your battery and trigger a solid safe shutdown when the power actually drops. Until the Linux package maintainers officially add that USB patch, usbhid-ups is definitely the way to go unless you want the headache of compiling the driver from scratch yourself!

Hope that helps :-)

This is not really correct, the Unraid NUT plugin does ship with an USB-supporting libmodbus.

It's possible the UPS is not supported by this relatively new driver, but the library is the required one.

6 minutes ago, Rysz said:

This is not really correct, the Unraid NUT plugin does ship with an USB-supporting libmodbus.

It's possible the UPS is not supported by this relatively new driver, but the library is the required one.

Then can you tell me how to use it?

As mentioned before, the apcupsd works, while NUT does not.

4 hours ago, Rysz said:

This is not really correct, the Unraid NUT plugin does ship with an USB-supporting libmodbus.

It's possible the UPS is not supported by this relatively new driver, but the library is the required one.

That makes perfect sense! Thanks for clarifying that the Unraid plugin ships with the patched library. I should have been much more specific about my architecture, which is running a Master/Slave setup where the UPS is physically plugged into a Raspberry Pi (running standard Pi OS/Debian) acting as the NUT Master, and my Unraid servers are Slaves; was hitting the unpatched libmodbus wall on the Debian side of my Pi, not on the Unraid plugin side. It is awesome to know you guys baked that patch directly into the Unraid plugin for direct connections.

Regarding apcupsd, the scrambled data on reboot until physically unpluging the cable is a classic APC hardware quirk. As far as I have observed, the UPS doesn't drop the USB state during a server warm boot, so it gets confused when the driver spins back up. A physical re-plug forces the USB handshake to happen again. This is why I ended up just falling back to the standard usbhid-ups driver..rather have fewer stats than have to physically walk over to the server rack every time I reboot.

Hi all,

Would love to get my UPS talking with Unraid properly.

It's an: OptiUPS ES800C

I ran lsusb from the command prompt of unraid and got:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 002: ID 0d9f:0002 Powercom Co., Ltd Black Knight PRO / WOW Uninterruptible Power Supply (Cypress HID->COM RS232)

Bus 001 Device 003: ID 0781:5567 SanDisk Corp. Cruzer Blade

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Could someone assist on what I need to set in NUT and also the /etc/nut/ups.conf please.

Thanks,

Dwarfboysim

Hi all,

Would love to get my UPS talking with Unraid properly.

It's an: OptiUPS ES800C

I ran lsusb from the command prompt of unraid and got:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 002: ID 0d9f:0002 Powercom Co., Ltd Black Knight PRO / WOW Uninterruptible Power Supply (Cypress HID->COM RS232)

Bus 001 Device 003: ID 0781:5567 SanDisk Corp. Cruzer Blade

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Could someone assist on what I need to set in NUT and also the /etc/nut/ups.conf please.

Thanks,

Dwarfboysim

You can definitely get this working with NUT, but it’s a bit quirkier than a standard plug-and-play unit.

That 0d9f:0002 ID shows your OptiUPS uses a Cypress USB-to-Serial adapter internally. Even though it's a USB cable, it’s actually talking the Powercom protocol over a serial bridge. Because of that, the standard HID drivers won't work; you need the powercom driver.

Try adding this to your /etc/nut/ups.conf (or the "Extra Settings" box in the Unraid NUT plugin)

[optiups]

driver = powercom

port = auto

type = IMP

Give that a shot and see if the service starts. If it doesn't, you maybe require to point the port to a specific /dev/tty path or tweak the "type," but start there.

Once it's running, you can verify it by running upsc optiups in the terminal to see your stats.

On 4/13/2026 at 12:16 AM, bombz said:

You can definitely get this working with NUT, but it’s a bit quirkier than a standard plug-and-play unit.

That 0d9f:0002 ID shows your OptiUPS uses a Cypress USB-to-Serial adapter internally. Even though it's a USB cable, it’s actually talking the Powercom protocol over a serial bridge. Because of that, the standard HID drivers won't work; you need the powercom driver.

Try adding this to your /etc/nut/ups.conf (or the "Extra Settings" box in the Unraid NUT plugin)

[optiups]

driver = powercom

port = auto

type = IMP

Give that a shot and see if the service starts. If it doesn't, you maybe require to point the port to a specific /dev/tty path or tweak the "type," but start there.

Once it's running, you can verify it by running upsc optiups in the terminal to see your stats.

Thanks for the tip.

Still won't start and SYSLOG shows the below:

Contents of UPS.CONF inside the NUT plugin settings reads as:

[optiups]

driver = powercom

port = auto

type = IMP

# If not in manual mode, the following lines are reserved and overwritten by GUI:

# L1:[UPSNAME]/L2:DRIVER/L3:PORT/L4-L7:SNMP/L8:DEBUG_MIN

Apr 15 07:42:34 UNRAID rc.nut: Network UPS Tools upsdrvctl - UPS driver controller 2.8.5 release
Apr 15 07:42:34 UNRAID rc.nut: Network UPS Tools 2.8.5 release - PowerCom protocol UPS driver 0.27
Apr 15 07:42:34 UNRAID rc.nut: Fatal error: unusable configuration
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Unable to open auto: No such file or directory
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Things to try:
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut:  - Check 'port=' in ups.conf
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut:  - Check owner/permissions of all parts of path
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Driver failed to start (exit status=1)

On 4/1/2026 at 2:18 PM, tadeudca said:

Hi there folks...

Can someone help out with the configuration of this UPS?
Model: SMS Powervision II upv3000bifx
It only have the rs232 option for connection.
So i'm using a rs232 to USB adapter.

In my unraid i used the console mode and test if my USB is detecting:

T: Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0

D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1

P: Vendor=0403 ProdID=6001 Rev=06.00

S: Manufacturer=FTDI

S: Product=FT232R USB UART

S: SerialNumber=A5069RR4

C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=90mA

I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms

Then i tried the nut but it did not detect my device...

Tried different drivers and modes but none detected...

does anyone have any idea what to do?

Anyone?? Ideas?

Apr 15 07:42:34 UNRAID rc.nut: Network UPS Tools upsdrvctl - UPS driver controller 2.8.5 release
Apr 15 07:42:34 UNRAID rc.nut: Network UPS Tools 2.8.5 release - PowerCom protocol UPS driver 0.27
Apr 15 07:42:34 UNRAID rc.nut: Fatal error: unusable configuration
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Unable to open auto: No such file or directory
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Things to try:
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut:  - Check 'port=' in ups.conf
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut:  - Check owner/permissions of all parts of path
Apr 15 07:42:34 UNRAID rc.nut: 
Apr 15 07:42:34 UNRAID rc.nut: Driver failed to start (exit status=1)

You may need to find exactly where Unraid has detected the device, you can try running
ls /dev/ttyUSB* or dmesg | grep tty
looks for a line that states 'Cypress USB Serial'
once you locate the path, you may be successful swapping auto for the actual path

[optiups]

driver = powercom

port = /dev/ttyUSB0

type = IMP

After you save and start the service, run this

upsc optiups

hope that helps!

On 4/16/2026 at 11:05 AM, bombz said:

You may need to find exactly where Unraid has detected the device, you can try running
ls /dev/ttyUSB* or dmesg | grep tty
looks for a line that states 'Cypress USB Serial'
once you locate the path, you may be successful swapping auto for the actual path

[optiups]

driver = powercom

port = /dev/ttyUSB0

type = IMP

After you save and start the service, run this

upsc optiups

hope that helps!

Any idea why it says this in SYSLOG though:

Apr 15 07:42:34 UNRAID rc.nut: Unable to open auto: No such file or directory

could the UPS.conf be corrupt? Is the "auto" referring to the line in the UPS.conf?

2 minutes ago, Dwarfboysim said:

Any idea why it says this in SYSLOG though:

Apr 15 07:42:34 UNRAID rc.nut: Unable to open auto: No such file or directory

could the UPS.conf be corrupt? Is the "auto" referring to the line in the UPS.conf?

On 4/16/2026 at 11:05 AM, bombz said:

You may need to find exactly where Unraid has detected the device, you can try running
ls /dev/ttyUSB* or dmesg | grep tty
looks for a line that states 'Cypress USB Serial'
once you locate the path, you may be successful swapping auto for the actual path

[optiups]

driver = powercom

port = /dev/ttyUSB0

type = IMP

After you save and start the service, run this

upsc optiups

hope that helps!

First command gave error: ls: cannot access '/dev/ttyUSB*': No such file or directory

Second command gave this

root@UNRAID:~# dmesg | grep ty

[ 0.541730] SGI XFS with ACLs, security attributes, no debug enabled

[ 0.551252] Key type asymmetric registered

[ 2.397144] Btrfs loaded, zoned=no, fsverity=no

[ 4.041561] sd 6:0:0:0: Attached scsi generic sg0 type 0

[ 5.383254] sd 0:0:0:0: Attached scsi generic sg1 type 0

[ 5.387705] sd 1:0:0:0: Attached scsi generic sg2 type 0

[ 5.389574] sd 2:0:0:0: Attached scsi generic sg3 type 0

[ 5.390136] sd 3:0:0:0: Attached scsi generic sg4 type 0

[ 5.390723] sd 4:0:0:0: Attached scsi generic sg5 type 0

[ 5.391168] sd 5:0:0:0: Attached scsi generic sg6 type 0

[ 46.130645] loop0: detected capacity change from 0 to 1334912

[ 46.139547] loop1: detected capacity change from 0 to 355176

[ 80.415912] ACPI: bus type drm_connector registered

[ 164.318019] md: import_slot: 0 empty

[ 164.318057] md: import_slot: 29 empty

[ 218.919599] loop2: detected capacity change from 0 to 94371840

[ 225.054016] loop3: detected capacity change from 0 to 2097152

[ 281.976721] md: import_slot: 0 empty

[ 281.976731] md: import_slot: 29 empty

[ 321.294373] md: import_slot: 29 empty

[ 369.290747] loop2: detected capacity change from 0 to 94371840

[ 372.883723] loop3: detected capacity change from 0 to 2097152

Don't want to complicate things or causing confusions, but perhaps it's worth to have a try with the last stable version and not the newest 2.8.5 if you use that one.

Newest Nut-release 2.8.5 causes driver crashes on my system with the result of not recognising the usb-ups-device anymore.

Rollback to 2.8.4 was my quick solution, to not needing to search for bugs or incompatibilitys.

Any idea why it says this in SYSLOG though:

Apr 15 07:42:34 UNRAID rc.nut: Unable to open auto: No such file or directory

could the UPS.conf be corrupt? Is the "auto" referring to the line in the UPS.conf?

Have you had a chance to find the path and replace 'auto'?

The syslog may be displaying that because the driver treats 'auto' as a literal destination. Replacing it with the actual device path should resolve the 'No such file or directory' issue and should get it connected

Today I noticed NUT wasn't running. Said it couldn't be started. See the SYSLOG below.

I selected the 2.8.4 backend in the NUT settings as suggested by @NoRaid99, rebooted my server, and now it's working again. No idea what's wrong with 2.8.5. I'm still on unraid 6.12.13.

Apr 20 19:19:40 Tower upsmon[4450]: Poll UPS [[email protected]] failed - Data stale
Apr 20 19:19:41 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:43 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:45 Tower upsmon[4450]: Poll UPS [[email protected]] failed - Data stale
Apr 20 19:19:45 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:47 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:49 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:50 Tower upsmon[4450]: Poll UPS [[email protected]] failed - Data stale
Apr 20 19:19:51 Tower root: plugin: running: anonymous
Apr 20 19:19:51 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:53 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:55 Tower upsmon[4450]: Signal 15: exiting
Apr 20 19:19:55 Tower upsd[4447]: User [email protected] logged out from UPS [ups]
Apr 20 19:19:55 Tower upsd[4447]: mainloop: Interrupted system call
Apr 20 19:19:55 Tower upsd[4447]: Signal 15: exiting
Apr 20 19:19:55 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:55 Tower usbhid-ups[4443]: WARNING: send_to_all: write 29 bytes to socket 13 failed (ret=-1), disconnecting.: Broken pipe
Apr 20 19:19:57 Tower usbhid-ups[4443]: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:19:59 Tower usbhid-ups[4443]: Signal 15: exiting
Apr 20 19:20:02 Tower root: plugin: creating: /boot/config/plugins/nut-dw/nut-2.8.5-x86_64-1master.ssl11.txz - downloading from URL https://raw.githubusercontent.com/desertwitch/NUT-unRAID/master/packages/nut-2.8.5-x86_64-1master.ssl11.txz
Apr 20 19:20:03 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-2.8.5-x86_64-1master.ssl11.txz - MD5
Apr 20 19:20:03 Tower root: plugin: creating: /boot/config/plugins/nut-dw/nut-2.8.5-x86_64-1stable.ssl11.txz - downloading from URL https://raw.githubusercontent.com/desertwitch/NUT-unRAID/master/packages/nut-2.8.5-x86_64-1stable.ssl11.txz
Apr 20 19:20:03 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-2.8.5-x86_64-1stable.ssl11.txz - MD5
Apr 20 19:20:03 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-2.8.4-x86_64-1stable.ssl11.txz - MD5
Apr 20 19:20:03 Tower root: plugin: skipping: /boot/config/plugins/nut-dw/nut-2.8.4-x86_64-1stable.ssl11.txz already exists
Apr 20 19:20:03 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-2.8.3-x86_64-2stable.ssl11.txz - MD5
Apr 20 19:20:03 Tower root: plugin: skipping: /boot/config/plugins/nut-dw/nut-2.8.3-x86_64-2stable.ssl11.txz already exists
Apr 20 19:20:03 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-2.7.4.20200318-x86_64-1.txz - MD5
Apr 20 19:20:03 Tower root: plugin: skipping: /boot/config/plugins/nut-dw/nut-2.7.4.20200318-x86_64-1.txz already exists
Apr 20 19:20:03 Tower root: plugin: running: anonymous
Apr 20 19:20:05 Tower root: plugin: checking: /boot/config/plugins/nut-dw/net-snmp-5.9.3-x86_64-1.txz - MD5
Apr 20 19:20:05 Tower root: plugin: skipping: /boot/config/plugins/nut-dw/net-snmp-5.9.3-x86_64-1.txz already exists
Apr 20 19:20:05 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut-dw/net-snmp-5.9.3-x86_64-1.txz
Apr 20 19:20:05 Tower root: plugin: checking: /boot/config/plugins/nut-dw/libmodbus-3.1.11-x86_64-1nut_slack15.0.txz - MD5
Apr 20 19:20:05 Tower root: plugin: skipping: /boot/config/plugins/nut-dw/libmodbus-3.1.11-x86_64-1nut_slack15.0.txz already exists
Apr 20 19:20:05 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut-dw/libmodbus-3.1.11-x86_64-1nut_slack15.0.txz
Apr 20 19:20:05 Tower root: plugin: creating: /boot/config/plugins/nut-dw/nut-plugin-2026.04.13-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/desertwitch/NUT-unRAID/master/archive/nut-plugin-2026.04.13-x86_64-1.txz
Apr 20 19:20:05 Tower root: plugin: checking: /boot/config/plugins/nut-dw/nut-plugin-2026.04.13-x86_64-1.txz - MD5
Apr 20 19:20:05 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut-dw/nut-plugin-2026.04.13-x86_64-1.txz
Apr 20 19:20:05 Tower root: plugin: running: anonymous
Apr 20 19:20:06 Tower rc.nut: Writing NUT configuration...
Apr 20 19:20:08 Tower rc.nut: Updating permissions for NUT...
Apr 20 19:20:08 Tower rc.nut: Checking if the NUT Runtime Statistics Module should be enabled...
Apr 20 19:20:08 Tower rc.nut: Enabling the NUT Runtime Statistics Module...
Apr 20 19:20:08 Tower rc.nut: NUT Runtime Statistics Variable Override is enabled...
Apr 20 19:20:10 Tower rc.nut: NUT Runtime Statistics is requesting the first batch of data...
Apr 20 19:20:10 Tower rc.nut: NUTSTATS: NUT upsmon is not (yet) running... exiting
Apr 20 19:20:11 Tower rc.nut: WARNING: NUT was user-configured to disable power management for all USB devices.
Apr 20 19:20:11 Tower rc.nut: WARNING: NUT is now forcing all USB devices to permanent [on] power state as requested...
Apr 20 19:20:11 Tower rc.nut: Network UPS Tools upsdrvctl - UPS driver controller 2.8.5 release
Apr 20 19:20:11 Tower rc.nut: Network UPS Tools 2.8.5 release - Generic HID driver 0.71
Apr 20 19:20:11 Tower rc.nut: USB communication driver (libusb 1.0) 0.53
Apr 20 19:20:12 Tower rc.nut: device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround
Apr 20 19:20:13 Tower rc.nut: Driver exited abnormally
Apr 20 19:20:13 Tower kernel: usbhid-ups[23603]: segfault at 7fff3ebb7000 ip 0000000000415043 sp 00007fff3ebb27d0 error 4 in usbhid-ups[403000+27000] likely on CPU 8 (core 2, socket 0)
Apr 20 19:20:13 Tower kernel: Code: 8f 81 00 00 00 41 83 7d 00 01 7e 13 48 8d 35 e4 4a 02 00 bf 02 00 00 00 31 c0 e8 d8 d7 00 00 48 83 44 24 08 04 48 8b 44 24 08 <44> 8b 20 41 8b 45 00 45 85 e4 78 e9 83 f8 01 0f 8e 37 ff ff ff 31
Apr 20 19:20:13 Tower root: plugin: nut-dw.plg updated

Those of you who have problems with NUT 2.8.5, please post logs and which UPS model you're using.

Ideally raise the "UPS Driver Debug Level" to the highest level (6) before capturing logs.

This can help get those problems fixed for future versions, older backends won't be around forever.

On 4/20/2026 at 9:16 PM, bombz said:

Have you had a chance to find the path and replace 'auto'?

The syslog may be displaying that because the driver treats 'auto' as a literal destination. Replacing it with the actual device path should resolve the 'No such file or directory' issue and should get it connected

Hi,

Sorry for the delayed reply. Can I get an example and advice to determine exactly which device/USB port the UPS is connected to and then how to put that into the UPS conf file.

Thanks,

Dwarfboysim

On 4/20/2026 at 9:16 PM, bombz said:

Have you had a chance to find the path and replace 'auto'?

The syslog may be displaying that because the driver treats 'auto' as a literal destination. Replacing it with the actual device path should resolve the 'No such file or directory' issue and should get it connected

And does anyone know the actual location of the ups.conf file as I cannot seem to locate it.

And does anyone know the actual location of the ups.conf file as I cannot seem to locate it.

The easiest way to find exactly where the UPS is plugged in is to pop open the Unraid terminal and run ls /dev/ttyUSB*. If it spits back something like /dev/ttyUSB0, that’s your path. If that doesn't show anything, try running dmesg | grep tty and look for a line mentioning the "Cypress" adapter—it should tell you which ttyUSB number the system assigned to it.

The reason you're seeing that "Unable to open auto" error in your syslog is just because the powercom driver is a bit old-school and doesn't actually know how to "auto-scan" for devices. It’s literally looking for a file or folder named "auto" on your system, failing to find it, and then giving up.

Instead of hunting for the file through the command line (where changes sometimes get wiped on a reboot), the best way to fix this is through the Unraid WebUI. Go to Settings > NUT Settings. You can usually find the ups.conf edit box right there in the plugin settings. If you’d rather do it via the flash drive, the file lives at /boot/config/plugins/nut/ups.conf. Just swap out port = auto for your actual path—likely port = /dev/ttyUSB0—and once you hit apply and start the service, upsc optiups should start showing your battery stats.

13 hours ago, bombz said:

The easiest way to find exactly where the UPS is plugged in is to pop open the Unraid terminal and run ls /dev/ttyUSB*. If it spits back something like /dev/ttyUSB0, that’s your path. If that doesn't show anything, try running dmesg | grep tty and look for a line mentioning the "Cypress" adapter—it should tell you which ttyUSB number the system assigned to it.

The reason you're seeing that "Unable to open auto" error in your syslog is just because the powercom driver is a bit old-school and doesn't actually know how to "auto-scan" for devices. It’s literally looking for a file or folder named "auto" on your system, failing to find it, and then giving up.

Instead of hunting for the file through the command line (where changes sometimes get wiped on a reboot), the best way to fix this is through the Unraid WebUI. Go to Settings > NUT Settings. You can usually find the ups.conf edit box right there in the plugin settings. If you’d rather do it via the flash drive, the file lives at /boot/config/plugins/nut/ups.conf. Just swap out port = auto for your actual path—likely port = /dev/ttyUSB0—and once you hit apply and start the service, upsc optiups should start showing your battery stats.

Hi,

I opened up a terminal in Unraid and got the following results

for the command: ls /dev/ttyUSB* I got "ls: cannot access '/dev/ttyUSB*': No such file or directory"

for the command: dmesg | grep tty I got "[ 0.288678] printk: legacy console [tty0] enabled"

any clues?

Thanks,

Dwarfboysim