search for: interrupt_only

...methods with USB hubs that have per-port power switching, etc. to simulate unplugging. I am not a fan of the concept, but I recognize that others have made more significant investments than the single UPS that I bought. After you get access to the UPS, what if you try running the driver with "interrupt_only"? Reference: https://github.com/networkupstools/nut/issues/300#issuecomment-414481547 > On Aug 20, 2018, at 9:19 AM, Valentin Merkulov <schnobel at ickis.net> wrote: > > I cannot unplug/re-plug USB though, because currently I'm away from > the hardware location. > &...

...e initial value (before the device sends updates over the interrupt pipe). Also, HIDGetItemData() searches the parsed descriptor to match the type as well as the Usage path, so I'm not sure if I can figure out a way that it would get an Input report ID confused with a Feature report ID (unless interrupt_only is set, as it is for powercom devices). That said, if I am overlooking a case where that might happen, I think we might need to put this check somewhere deeper in the call tree. HIDDumpTree() is effectively a NOP if debugging is not enabled, so this is mostly just removing some partially redundant...

...it would return "No matching HID device found" until I unplug / re-plug USB cable. Gzipped output is attached. > On Wed, Aug 22, 2018 at 3:49 PM Charles Lepple <clepple at gmail.com> wrote: > > After you get access to the UPS, what if you try running the driver with "interrupt_only"? Reference: https://github.com/networkupstools/nut/issues/300#issuecomment-414481547 -------------- next part -------------- A non-text attachment was scrubbed... Name: usbhid-ups-interruptonly.output.gz Type: application/x-gzip Size: 6615 bytes Desc: not available URL: <http://alioth-list...

...nately, this isn't what is being done - see below. > Also, HIDGetItemData() searches the parsed descriptor to match the type > as well as the Usage path, so I'm not sure if I can figure out a way > that it would get an Input report ID confused with a Feature report ID > (unless interrupt_only is set, as it is for powercom devices). libusb_get_report() has: ret = usb_control_msg(udev, USB_ENDPOINT_IN + USB_TYPE_CLASS + USB_RECIP_INTERFACE, 0x01, /* HID_REPORT_GET */ ReportId+(0x03<<8), /* HID_REPORT_TYPE_FEATURE */...

After "No device" error the driver does not seem to be able to communicate with the UPS (as seen before with the port build): # /usr/local/ups/bin/usbhid-ups -a ups -DDDD -u root Network UPS Tools - Generic HID driver 0.53 (v2.7.4-603-gb14c3b42.7.4.1) USB communication driver 0.37 0.000000 [D1] debug level is '4' 0.002560 [D1] upsdrv_initups... 0.002748

Hi, I've been checking out NUT with an OpenUPS board over the last couple of weekends, and have noticed that it doesn't seem to report sensible values. This lead me to investigate usbhid-ups and delve into various issues. As mentioned in a github issue, one of the problems is with the report descriptor - dumping this from the usbhid-ups debug output and picking through it reveals that