networkupstools
APC Smart UPS 1000 with latest firmware 04.3 will not work with usbhid-ups anymore
Hi,
I have an APC Smart UPS 1000 (SMC1000-2UC) and was using the usbhid-ups driver fine. APC released a firmware update with security fixes which I made sure to upgrade. UPS SMT 04.6 & SMC 04.3 – Firmware Release Notes
After upgrading, the nut-driver service fails to start with error: No matching HID UPS found
Details on my UPS
idVendor 0x051d American Power Conversion
idProduct 0x0004
bcdDevice 0.01
iManufacturer 1 American Power Conversion
iProduct 2 Smart-UPS_1000 FW:UPS 04.6 / ID=1018
Just in case, which NUT version is it - 2.7.4 or recent 2.8.0 or custom build from git (master)?
My guess would be the FW update changed some identification values used by NUT and/or your ups.conf section (productid? vendorid?) and so NUT driver start-up does not find a good match.
Can you run the driver stand-alone with more debug e.g. usbhid-ups -a apc -DDDDDD to check what it fails to see?
Also, make sure other processes (including another copy of the NUT driver, or default kernel handler which udev rules should have taken care of) have not grabbed the device already - this also precludes new ones from seeing it.
Hi @jimklimov thanks for the reply.
Current nut version is 2.7.4-13 and was installed via apt. Before the upgrade, my productid was 3, and was changed to 4 after the FW upgrade, so I updated the ups.conf appropriately.
Question about running the driver. I do not have that installed, in other words, usbhid-ups is not found. Can you help me with that step? I can provide those debug messages.
In the meantime, I am going to try again and revert the productid back to 3 and see if anything changes.
Please see the packaging metadata for your distribution (also, often packages can be opened as archives in UIs like Midnight Commander).
Some distros put NUT drivers into e.g. /lib/nut/ or similarly obscure locations not in common PATH. Otherwise, find /lib* /*bin /opt /usr -name usbhid-ups can help
OK here are my debug logs:
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
0.000000 debug level is '6'
0.001893 upsdrv_initups...
0.028215 Checking device (1D6B/0003) (002/001)
0.066189 - VendorID: 1d6b
0.066239 - ProductID: 0003
0.066279 - Manufacturer: unknown
0.066318 - Product: unknown
0.066355 - Serial Number: unknown
0.066392 - Bus: 002
0.066428 - Device release number: 0510
0.066464 Trying to match device
0.066509 Device does not match - skipping
0.066903 Checking device (03F0/4811) (001/007)
0.067024 - VendorID: 03f0
0.067063 - ProductID: 4811
0.067095 - Manufacturer: unknown
0.067136 - Product: unknown
0.067173 - Serial Number: unknown
0.067210 - Bus: 001
0.067248 - Device release number: 0100
0.067285 Trying to match device
0.067345 Device does not match - skipping
0.067400 Checking device (2109/2817) (001/006)
0.067499 - VendorID: 2109
0.067540 - ProductID: 2817
0.067573 - Manufacturer: unknown
0.067608 - Product: unknown
0.067640 - Serial Number: unknown
0.067672 - Bus: 001
0.067707 - Device release number: 9023
0.067742 Trying to match device
0.067785 Device does not match - skipping
0.067841 Checking device (2109/2817) (001/005)
0.067934 - VendorID: 2109
0.067974 - ProductID: 2817
0.068012 - Manufacturer: unknown
0.068048 - Product: unknown
0.068085 - Serial Number: unknown
0.068122 - Bus: 001
0.068159 - Device release number: 9023
0.068196 Trying to match device
0.068235 Device does not match - skipping
0.068290 Checking device (051D/0004) (001/004)
0.068380 - VendorID: 051d
0.068421 - ProductID: 0004
0.068457 - Manufacturer: unknown
0.068494 - Product: unknown
0.068531 - Serial Number: unknown
0.068568 - Bus: 001
0.068605 - Device release number: 0001
0.068642 Trying to match device
0.068744 Device does not match - skipping
0.068800 Checking device (051D/0002) (001/003)
0.074552 - VendorID: 051d
0.074679 - ProductID: 0002
0.074792 - Manufacturer: American Power Conversion
0.074906 - Product: Back-UPS XS 1500M FW:947.d10 .D USB FW:d10
0.075019 - Serial Number: NB18008004272
0.075133 - Bus: 001
0.075246 - Device release number: 0090
0.075358 Trying to match device
0.075487 Device does not match - skipping
0.075616 Checking device (2109/3431) (001/002)
0.075784 - VendorID: 2109
0.076010 - ProductID: 3431
0.076123 - Manufacturer: unknown
0.076237 - Product: unknown
0.076348 - Serial Number: unknown
0.076461 - Bus: 001
0.076573 - Device release number: 0421
0.076685 Trying to match device
0.076802 Device does not match - skipping
0.076935 Checking device (1D6B/0002) (001/001)
0.077097 - VendorID: 1d6b
0.077213 - ProductID: 0002
0.077325 - Manufacturer: unknown
0.077436 - Product: unknown
0.077547 - Serial Number: unknown
0.077659 - Bus: 001
0.077771 - Device release number: 0510
0.077883 Trying to match device
0.077999 Device does not match - skipping
0.078127 No appropriate HID device found
0.078244 No matching HID UPS found
Might be on a different USB ? Try this:
# lsusb | grep 051d
Bus 001 Device 004: ID 051d:0003 American Power Conversion UPS
right ok, so Bus 001 Device 004 is the one I am trying to get working. Here are more details on that one:
lsusb -D /dev/bus/usb/001/004
Device: ID 051d:0004 American Power Conversion Smart-UPS_1000 FW:UPS 04.6 / ID=1018
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x051d American Power Conversion
idProduct 0x0004
bcdDevice 0.01
iManufacturer 1 American Power Conversion
iProduct 2 Smart-UPS_1000 FW:UPS 04.6 / ID=1018
iSerial 3 XXXXXXXXXXX
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 10mA
I guess my question is, am I right to use this configuration for it?
[apc-servers]
driver = usbhid-ups
port = auto
desc = "APC Smart-UPS 1000"
vendorid = 051d
productid = 0004
serial = XXXXXXXXXXX
Any ideas @jimklimov @jeffgoh ? Everything I’m seeing I have it setup correctly
Can't look it up at the moment, but I wonder if usbhid-ups cares too much for vendorid/productid config options or relies more on values hardcoded in hid subdrivers.
At least IIRC it does not offer to manually choose a subdriver, like nutdrv_qx does.
Maybe you should try adding a line to source with the new id (4) and rebuild?..
On Wed, May 25, 2022, 23:55 John Bateman @.***> wrote:
Any ideas @jimklimov https://github.com/jimklimov @jeffgoh https://github.com/jeffgoh ? Everything I’m seeing I have it setup correctly
— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1429#issuecomment-1137882507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFHERUNZPNEEENYBU6LVL2OVJANCNFSM5WF5CY5A . You are receiving this because you were mentioned.Message ID: @.***>
Tried all that, nothing would work! Any help would be appreciated.
Short-term, I don't think much can be done without compiling a new usbhid-ups binary with apc-hid.c tweaked to accept the new ProductID value.
Longer-term, maybe addressing #1369 can help with such situations in the field.
@johnynfulleffect : "Tried all that, nothing would work! Any help would be appreciated."
Which "all that"? :) In particular, did you add the ID to driver and recompile it as well as update udev.rules (or udev.hwdb) respectively?
Are you in position to test a custom build of NUT from https://github.com/jimklimov/nut/tree/issue-1429 (source of PR #1655) to see if that helps recognize it "out of the box"?
@johnynfulleffect : "Tried all that, nothing would work! Any help would be appreciated."
Which "all that"? :) In particular, did you add the ID to driver and recompile it as well as update udev.rules (or udev.hwdb) respectively?
Sorry, should have been more specific. I tried:
Might be on a different USB ? Try this:
# lsusb | grep 051dBus 001 Device 004: ID 051d:0003 American Power Conversion UPS
I think the next step I should try is:
did you add the ID to driver and recompile it as well as update udev.rules (or udev.hwdb) respectively?
Next will be:
to test a custom build of NUT from https://github.com/jimklimov/nut/tree/issue-1429 (source of PR https://github.com/networkupstools/nut/pull/1655) to see if that helps recognize it "out of the box"?
Note: building the PR branch should take care of updating a new id into the code and udev (need to install the latter to OS however).
@jimklimov Thanks for your work here. I need to still need to build from your PR. I have not done this before. I will report back.
What are the steps to build this? I was looking through your repo and this is something I am not familiar with.
For a quick test, current ./ci_build.sh may suffice to build with prerequisites your system has. Then you'd run ./drivers/usbhid-ups -a <upsname> -d1 to dump info assuming the device was picked up by driver.
If (linux) holds it by default, you may need a more diligent build (with path args likely similar to that in packaging) and make install to extend udev rules (so they know newer IDs added to the list).
@jimklimov Went through the process, and it compiled fine, but running this on an ARM system like the RPi doesn't work. I tried compiling on the RPi too and thought I fixed all the pre-req's but there are failures still for parts of the code I don't understand.
My RPi died sadly, so can't check reliably lately. It did build NUT half a year ago though, and I had a much older Mirabox as a testing device earlier. I suppose there may be nuances for OS in use, Debian-based ones should be okay. Distros in use on NUT CI farm containers are from 2014 and newer, with prerequisites installed per docs/config-prereqs.txt (literally copy-pasting from there).
A community Wiki post at https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu details one of the ways to specify the build parameters explicitly...
What sort of failures are there, for configure script not finding something, or for the build (compiler complains etc.)?
Any luck and progress with this? :)
Thinking of it, you probably could cross-build for ARM on x86, with added stack of tools and prerequisites as of the ARM distro, similarly to how Windows builds on Linux+mingw are done, but I haven't done that som can't help much.
Another alternative is a qemu-static driven LXC container which would run a complete ARM-based OS on your x86 box. Some hints about that may be in docs/ci-farm-lxc-setup.txt file. This has a benefit of easier setup and a "native" feel on the inside, with downsides of possibly incomplete "real-life" functionality of the emulated CPU (years ago I did have builds crashed due to missing CPU instructions) and some slowness incurred.