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

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

7 minutes ago, Dwarfboysim said:

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

I also tried: lsusb and it gave the below

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

Thank you those who developed this Plugin, it works as advertised. Great Work !!!

Not many plugins, Dockers, or ... work without extra effort .....

Have a question ......

My sever has dual AC power supplies, and has two (2) UPS (UPS Model: Back-UPS NS 1500M2), one for each AC power supply. Is this plugin able to support more than one UPS?

If no, could this feature be added to any future development of this plug in?

Thank you !!!

Will NUT shutdown docker containers and VMs as part of the regular shutdown?

If not, is NUT Actions required?

[deleted]

Edited May 17May 17 by landS

I got fed up of replacing the sealed lead acid batteries every year and swaped those SLA batteries to Lithium iron phosphate batteries, the batteries do take longer time to charge but the backup has actually doubled, now the only problem is that the runtime and battery charge which my ups apc bg 1500 model reports is designed for lead acid battery so now since I'm using lithium batteries the runtime and battery charge % is wrongly reported so the function of safe shutdown cannot be used as it uses runtime and battery charge to decide when to shutdown. The only parameter which is correctly reported is the voltage so if NUT had an option to trigger voltage based shutdown it would be very helpful like triggering shutdown when voltage drops to 23v as 23v is the cliff point for LFP batteries below which the voltage rapidly falls.

On 5/15/2026 at 5:12 AM, landS said:

[deleted]

NUT will shutdown your containers and VMs as part of the regular shutdown.

It will not do that just because the system is on battery (prior to initiating shutdown).

If you want to do that you'd have to use the scripting hooks (in GUI configuration editor) or NUT Actions.

On 5/7/2026 at 1:44 AM, oakley4404 said:

Thank you those who developed this Plugin, it works as advertised. Great Work !!!

Not many plugins, Dockers, or ... work without extra effort .....

Have a question ......

My sever has dual AC power supplies, and has two (2) UPS (UPS Model: Back-UPS NS 1500M2), one for each AC power supply. Is this plugin able to support more than one UPS?

If no, could this feature be added to any future development of this plug in?

Thank you !!!

It's not supported in the GUI, but can be done in manual configuration mode.

It's been on the roadmap for a long while, but it's a large effort and not many are asking for it.

On 5/7/2026 at 8:04 AM, NoRaid99 said:

Hi all,

there is a log generated while having power problems/cuts from my UPS and I would need help to understand what this means:

May 7 02:32:56 QNAP usbhid-ups[3710]: ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Battery charge is currently 87. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge_onbattery' option)

The UPS is a CP1500EPFCLCD (not UT series).

OL+DISCHRG means what? overload and discharge?

I'm asking because I'm trying to observe nasty power problems on my private source (off-grid-inverter) and have seen this entry in the server.log.

thanks in advance

noraid

OL+DISCHRG usually means on battery or calibrating, some UPS like to expose it like that.

The flags allow NUT to show the UPS as OB (on battery) or CAL (calibrating) instead when in this state.

It ultimately depends on what your UPS is really doing when it's in this state, then you decide on which flag to use.

7 minutes ago, NoRaid99 said:

@Rysz

Okay, thank you for the explanation.

Never have seen this before. Still seems to be a bit strange to me when the UPS reports "OB or CAL" while a power interruption. Who, if not the UPS itself knows what happened?

The UPS does know, it's just that this specific UPS series may report it differently than (most) others so the driver doesn't know what to do. 😉

In any case, if you don't have a power outage at that time - it's calibrating, if you do - it's on battery, and either of the flags tell the driver what's what.