bombz

haven't updated yet, haven't had a chance to read/locate the changelog -- may hold off on updates.. hope you get that resolved!

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.

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

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!

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.

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.

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 :-)

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!

Thanks again for all the help. Managed to grab a NVIDIA RTX A400 and was able to successfully install it today. Everything is working well and updated to the new OS using the v590.48.01 drivers. Appreciate the recommendations and assistance from everyone including @ich777 should be a nice GPU change for the coming years.

Hello, Appreciate this feedback and attention to detail. I proceeded as per your instruction's and selected the driver version manual/static - v580.82.09, which quickly prompted the Done button. The context and additional information helped, thank you for taking to time to explain that. Regarding the suggestion regarding considering a new GPU, replacing the current Quadro P2000. I appreciate you tossed the A400 in the hat, truthfully the P2000 was deployed strictly for transcoding, and wasn't locked or limited to how many sessions or transcodes it could do. With that, I wouldn't know where to start with comparable replacement GPU and I am happy you mentioned the A400 as it gives me a baseline to go from and look at that card specifically or comparable models. I may circle back with some questions on that. (NVidia vs AMD) Thank you again!

Thanks ich777, respect you and everyone's knowledge here in the community! It has been a busy few weeks which has taken me out of the loop, which required me to reach out for a quick sanity check before proceeding. Was able to update the the plugin successfully today. Attached current status of the plugin Currently I am pending triggering the OS update as I require to select a maintenance window that works best. From what I am understanding, before proceeding, is to manually select/set the radio button to 580.82.09 (screenshot) before pushing the OS update? If I am correct, doing this will keep it on the current version; which will allow further review of the driver, after the OS update/maintenance window? Open to feedback, thank you again! Thank you again.

Hey, appreciate the insight. Yes currently using the Quadro P2000. I was unaware of the driver/hardware support changes. Your feedback clarified the next steps. Thank you for you time to clarify.

Hello reaching out with a quick question; as been meaning to upgrade the unraid OS to the latest. (current 7.1.4) Currently running: Nvidia Driver Version: 580.82.09 At this moment plugins has detected an update for the NVidia Driver, when looking at the details of the driver it states.... Select preferred driver version: Latest Versions: latest: v580.82.09 Production Branch: Not found for this Unraid version! Was curious if it is OK to proceed with upgrading the OS before the NVidia driver? There was a point in time in December a member of the community was 7.2.0 and 7.2.2 OS and was using version "latest" 590.48.01 which crashed some of the docker applications that leveraged the GPU, to which they mentioned moving down to the "production" 580.119.02 to resolve the concern. Seeking advise regarding the proper ordered procedure: Upgrade OS > Upgrade Nvidia Driver (to alleviate the "Production Branch: Not found for this Unraid version!") Upgrade Nvidia Driver > Upgrade OS (not sure if that will 'break' anything performing this order?) Use to run upgrade assistant and realized it is no longer within the tools menu, perhaps it is now deprecated? Appreciate the feedback whenever someone has a moment to follow-up. Thank you.

Appreciate the response, apologies as this was put on the backburner for a moment. Going to investigate this deployment some more today to test an instance and see what the best path is to attempt to deploy this. Will most likely reach out as additional questions come to light. Thank you again!

Follow up. Have added a new disk to UD for another net-new pre-clear, however unraid is detecting the drive signature as already cleared, I do believe this a due to how UD mounts the disk seeing 'like disk' as already completed. How would one go about starting a fresh pre-clear when this occurs? Is it possible the previous disk that was cleared successfully, the preclear tool didn't stop the session, and the drive was powered down via external dock... and the GUI requires all sessions to be stopped BEFORE the disk is powered down?