Closed MrRonfo closed 11 months ago
I've also tried downloading and building the latest (master) version of NUT available:
# git clone -b master https://github.com/networkupstools/nut
# cd nut/
# ./autogen.sh
# ./configure --with-user=nut --with-group=nut --with-usb
# make
Unfortunately the issue is still there :/
# sudo ./drivers/usbhid-ups -DDDDD -s myups -x port=auto
Network UPS Tools - Generic HID driver 0.52 (2.8.1-79-g956267dce)
USB communication driver (libusb 0.1) 0.45
0.000000 [D3] main_arg: var='port' val='auto'
0.000116 [D5] send_to_all: SETINFO driver.parameter.port "auto"
0.000279 [D1] Network UPS Tools version 2.8.1-79-g956267dce (release/snapshot of 2.8.1.1) built with gcc (Debian 10.2.1-6) 10.2.1 20210110 and configured with flags: --with-user=ups --with-group=nut --with-usb
0.000381 [D1] debug level is '5'
0.000437 [D5] send_to_all: SETINFO driver.debug "5"
0.000525 [D5] send_to_all: SETFLAGS driver.debug RW NUMBER
0.002853 [D5] send_to_all: SETINFO device.type "ups"
0.002911 [D5] send_to_all: SETINFO driver.state "init.device"
0.002960 [D1] upsdrv_initups (non-SHUT)...
0.003041 [D2] Initializing an USB-connected UPS with library libusb-0.1 (or compat) (NUT subdriver name='USB communication driver (libusb 0.1)' ver='0.45')
0.074272 [D3] usb_busses=0x558cc9cff0
[... scan of other devices ...]
0.118962 [D2] Checking device (0764/0601) (001/004)
1.125707 [D1] libusb_open get iManufacturer failed, retrying...
2.149627 [D1] libusb_open get iManufacturer failed, retrying...
3.173668 [D1] libusb_open get iManufacturer failed, retrying...
4.197613 [D1] libusb_open get iProduct failed, retrying...
5.221642 [D1] libusb_open get iProduct failed, retrying...
6.245627 [D1] libusb_open get iProduct failed, retrying...
7.269637 [D1] libusb_open get iSerialNumber failed, retrying...
8.293630 [D1] libusb_open get iSerialNumber failed, retrying...
9.317640 [D1] libusb_open get iSerialNumber failed, retrying...
9.317739 [D2] - VendorID: 0764
9.317800 [D2] - ProductID: 0601
9.317843 [D2] - Manufacturer: unknown
9.317884 [D2] - Product: unknown
9.317924 [D2] - Serial Number: unknown
9.317964 [D2] - Bus: 001
9.318004 [D2] - Device: 004
9.318049 [D2] - Device release number: 0200
9.318090 [D2] Trying to match device
9.318137 [D2] match_function_subdriver (non-SHUT mode): matching a device...
9.318221 [D3] match_function_regex: matching a device...
9.318278 [D2] Device matches
9.318421 [D3] nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
9.320185 [D2] Unable to get HID descriptor (error sending control message: Value too large for defined data type)
9.320244 [D3] HID descriptor length (method 1) -1
9.320293 [D4] i=0, extra[i]=09, extra[i+1]=21
9.320354 [D3] HID descriptor, method 2: (9 bytes) => 09 21 11 01 00 01 22 e3 02
9.320402 [D3] HID descriptor length (method 2) 739
9.320488 [D2] HID descriptor length 739
14.341654 [D2] Unable to get Report descriptor: Connection timed out
[... scan of other devices ...]
14.345779 [D2] libusb0: No appropriate HID device found
14.345838 No matching HID UPS found
14.345931 [D5] send_to_all: SETINFO driver.state "cleanup.exit"
14.345989 upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
The "connection timed out" part looks fishy. It is like if someone else was holding the port (different instance of the driver, or kernel does not let go of it - perhaps udev
/upower
are not set up properly and don't know they should let NUT use this device).
It is odd that not even the vendor name shows up here. Does lsusb -v
see more details? There are a few tickets open, but can't remember anyone making and reporting good progress about, such inabilities to contact on the low level.
Anecdotally, quite a few Raspberries were reported in this issue tracker, but maybe it is more a testament to their popularity than to built-in flaws. But maybe it is the USB controller's fault somehow after all.
For CPS in particular, check the Wiki. At least if you get it running but it disappears after a few minutes, that is a known flaw (UPS controller goes to power-saving mode when not interacting often enough, or something).
Also try different cabling, another port, and running the driver as user=root
(in its ups.conf
section)...
Thanks Jim. I'll have a better look at the Wiki then :)
On your question, a call to lsusb -v
on the device gives me a similar access issue:
# sudo lsusb -vd 0764:0601
Bus 001 Device 004: ID 0764:0601 Cyber Power System, Inc. PR1500LCDRT2U UPS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0764 Cyber Power System, Inc.
idProduct 0x0601 PR1500LCDRT2U UPS
bcdDevice 2.00
iManufacturer 3 1
iProduct 1 850
iSerial 2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 739
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 20
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
cannot read device status, Resource temporarily unavailable (11)
Cheers,
Hi Jim. As you suggested, I've found another instance of the nut driver was holding the port:
$ sudo lsof | grep "/dev/bus/usb/001/004"
usbhid-up 607 nut 8u CHR 189,3 0t0 140 /dev/bus/usb/001/004
In this situation, calling usbhid-ups
from the command line always results in port not accessible error.
Knowing that, I've confidently moved forward configuring nut-server and nut-client; everything worked fine and I got back all the info from my UPS:
$ upsc myups
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: 1
battery.runtime: 3600
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 13.7
battery.voltage.nominal: 12
device.mfr: 1
device.model: 850
device.serial:
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: CyberPower HID 0.6
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 50.0
input.transfer.high: 290
input.transfer.low: 165
input.voltage: 229.7
input.voltage.nominal: 230
output.frequency: 50.0
output.voltage: 24.9
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 0
ups.mfr: 1
ups.model: 850
ups.productid: 0601
ups.realpower.nominal: 480
ups.serial:
ups.status: OL
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764
Thanks!
Still a bit strange: a new process should have signaled the opponent to exit. Maybe that got stuck, or it could not find a PID file with the older process number to signal...
Hi there, on a Raspberry PI 4 running older Debian distribution some time ago I was using usbhid-ups driver to query my USB connected CyberPower PR1500LCDRT2U.
Put it back to work recently, on same PI running Buster distribution and NUT 2.7.4, I have issues in connecting to the same UPS.
After checking all the other issues in this repo, I've decided to post my case here hoping for some help.
Configuration of my /etc/nut/ups.conf file:
Now, when I run usbhid-ups against it I get:
Am I doing something wrong here, or maybe some regression has been introduced ? Thanks!