Liebert PST5 shows "OB" while receiving mains voltage

[hotsaucegrocer]

OS: Ubuntu 22.04
NUT Version: 2.8.2 and on latest git pull
UPS: Liebert PST5
DRIVER: usb-hid

Since this Liebert PST5 does not appear to be supported on any releases before 2.8.2, I have locally built this version on my Ubuntu 22.04 box. Even though I can confirm that the mains power is on and delivering 122V (on a US 120V supply), upsdrvctl status still reports that the UPS is "OB." I know that the driver is communicating with the UPS since it correctly reports the UPS model and serial number. However, the incorrect battery status is problematic for monitoring.

This seems like a bug, but if there's some sort of granular permission that would allow model and serial number to be revealed, but not status, please let me know what I should modify.

Thanks,
-hotsaucegrocer

[jimklimov]

For posterity, re-posting first ideas from initial IRC discussion:

Anyhow, USB connections that show essentially only the driver info and a couple of device data points including an "OB" state ring a bell about some bad access to the USB layer, so the NUT driver does not get everything there is.

One common case is on Windows, where the UPS is also intercepted by OS and seen as a HID Battery device; installing lower-level libusb helpers with Zadig helps there.

On other systems this may be linked to virtualization pass-through, where either your NUT system is a guest and the host also sees the USB link and picks some bytes off the stream, or your NUT system is the host and some guest is allowed to the device too.

Finally, there are probably cases where NUT drivers look at a wrong interface number (0) of multi-interface devices, so sees a stub descriptor or one not relevant to Power HID... Those began showing up in the past couple of years.

[jimklimov]

Can you please run the driver with higher debug verbosity, to see how it initializes and what data it sees or discards?

First systemctl stop nut-driver@UPSNAME if there is one (may be auto-created by nut-driver-enumerator), substituting your UPSNAME from configuration, and then:

:; /lib/nut/usbhid-ups -DDDDDD -d 1 -a UPSNAME

...and copy the results here.

This might help figure out more about what's going on.

[hotsaucegrocer]

USB HID Debug.txt

Here's the output attached. Thanks!

[jimklimov]

This one looks really small, these are usually 600-900 bytes or more, so probably reading the wrong interface for this device:

   0.390593     [D3] Report Descriptor: (27 bytes) => 06 00 ff 09 01 a1 01 09 02 15 00 26 ff 00
   0.390599     [D3]  75 08 95 08 81 82 09 02 95 08 91 82 c0

The result matches, that no values are interpreted around hid_lookup_usage lines.

Currently the driver is Using default, detected or customized USB HID numbers: usb_config_index=0 usb_hid_rep_index=0 usb_hid_desc_index=0 usb_hid_ep_in=1 usb_hid_ep_out=1.

Try to check if lsusb -vvv -d 10af:0002 (IIRC the syntax) would expose several report descriptors and at which endpoints that might be, and specify different numbers by the tweaking options:

Force redundant call to usb_set_altinterface() (value=bAlternateSetting; default=0) : -x usb_set_altinterface=<value>
Deeper tuning of USB communications for complex devices : -x usb_config_index=<value>
Deeper tuning of USB communications for complex devices : -x usb_hid_rep_index=<value>
Deeper tuning of USB communications for complex devices : -x usb_hid_desc_index=<value>
Deeper tuning of USB communications for complex devices : -x usb_hid_ep_in=<value>
Deeper tuning of USB communications for complex devices : -x usb_hid_ep_out=<value>

For example, on my UPS with one interface I see the NUT-default interface 0 (iInterface 0) is reasonable for reports (bDescriptorType 34 Report) of a decent size (wDescriptorLength 909):

...
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID              10.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     909
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              20
...

Note that also interruptonly, which you seem to be using, can also impact value lookup mode - according to https://github.com/networkupstools/nut/blob/master/drivers/libhid.c#L498

[hotsaucegrocer]

lsusbvvv.txt
I tried to read over the lsusb output, but I didn't see how I would map the output to the device driver -x options.

[jimklimov]

Aha, so it says there is another:

    bNumInterfaces          2
...

### The default but useless (for us - too short) interface
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           25 Spanish
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      27
          Report Descriptor: (length is 27)
...
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255

### The interesting one
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           25 Spanish
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     777
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255

So that's interface number 1 with endpoint no. 2 (address 0x82) and a decent size of 777 bytes. These are the only numeric differences I see in the interface descriptors; the other difference being that lsusb did not look up Report Descriptor details for the second interface.

It reports having a language setting of Spanish, I wonder if there are any assumptions about text stuff being English (there certainly are when a locale is not reported IIRC, we have trouble getting strings and retry by telling the device "talk to us in English!" with the assumption they all can... better than nothing).

Alas, I don't have personal experience with these alternate settings, but as of #2271 (comment) the following settings helped with a similar device:

:; usbhid-ups -s ups -DDDDDD -d1 -x port=auto -u root -x pollonly=enabled -x usb_hid_rep_index=1 -x usb_hid_desc_index=1

There -u root allowed the test to rule out permission issues - optional; pollonly vs. interruptonly vs. neither is something to experiment with. The -s ups -x port=auto part allowed to define the test device on command line, you can use -a UPSNAME to start from the ups.conf section contents.

If these alone do not help with yours, I'd also try adding -x usb_hid_ep_in=2 ("OUT" is not mentioned in lsusb, but maybe also needs to be 2, as a further attempt of a fix).

[hotsaucegrocer]

That appears to have solved the problem. I've attached the output for your reference. Notably, I'm seeing ups.status reporting OL CHRG and input.voltage reading 121.3. I'm going to update ups.conf.

USB HID Debug With Options.txt