similar to: NUT, Linux and libusb

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

OK, from this build I get the following: # /usr/local/ups/bin/usbhid-ups -a ups -DDDD 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.001299 [D1] upsdrv_initups... 0.001450 [D2] nut_libusb_open: checking device 1 of 1. 0.033333 [D2] nut_libusb_open: - VendorID: 09ae.

I?m making some progress I believe? I switched off and switched on the UPS further to the laptop having started the daemon and I?m not getting the same error message which is probably due to the server working in the background still locking the device I think the daemon starts but gets into an infinite loop and doesn?t finish and hand back control. Here are the updated traces I got by

Also, just in case - are you in a virtualized environment? Is there (intentional or not) USB pass-through to the UPSes? My hint is, we had cases where a host or guest grabbed the device but it was not apparent from the part of system running NUT. Jim On Fri, Mar 24, 2023, 23:23 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Sounds like some other program is holding the port. Have

Sounds like some other program is holding the port. Have you stopped other NUT drivers for the device (e.g. via auto-resuscitating services) before starting this one? Does udev, ugen or similar facility have the configuration to hand off this device to NUT run-time user? (BTW, if you are now testing a custom build - was it configured to use same accounts as pre-packaged variant)? On Fri, Mar 24,

Hi all, I posted originally here last week: https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-October/013461.html Since then, I've been building and testing from source following the instructions a helpful reply in the above thread pointed out. The original problem is I've got one of these arduino HID power devices, as a project for a DIY UPS at home. This arduino is a composite

On 06/18/2017 05:42 PM, Charles Lepple wrote: > On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant > <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: >> >> running autogen.sh was triggered automatically. but even if I do it >> explicitly, I still get: >> + autoreconf -i >> configure.ac:887: warning: AC_LANG_CONFTEST: no

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

Attached are config.log and usbhid-ups output with -u root (gzipped). Now driver output looks a lot like the one from port build. On Mon, Aug 20, 2018 at 1:42 PM, Charles Lepple <clepple at gmail.com> wrote: > On Aug 20, 2018, at 1:03 AM, Valentin Merkulov <schnobel at ickis.net> wrote: >> >> 0.033412 [D3] nut_usb_claim_interface: failed to claim USB >>

On 06/19/2017 11:02 AM, Manuel Wolfshant wrote: > Thank a lot ! > Now, conclusions after attempting builds ( with no docs included since > attempting to enable them triggers the errors related to missing or > too old tools mentioned by me in an earlier message ) > - building against libsub 1.0 triggers the following 2 errors : > nutdrv_qx-nutdrv_qx.o: In function

On 06/15/2017 04:32 PM, Arnaud Quette wrote: Hello > > .... still no reply from them ... > > is the guy you contacted Paul Henri? I wrote to a generic alias ( Ro-PQSupport ). Got a reply from a fellow Romanian who also CC:ed something looking like a list (List-EGPQCO-BUCRO-PQ ). I replied to both of them 5 days ago, received nothing since. > >>> Would you also

Thanks for the quick reply! Ya, I'm new to all this so I didn't know this either, I was vaguely aware of USB composite devices from other projects, but never how it was all enumerated. I dug a bit more on this and I'm convinced the relationship is this: Device ??? Configuration 1 ??? Interface 1 ? ??? Endpoint 1 ? ??? Endpoint 2 ? ??? ... ??? Interface 2

Here is what I get: # usbconfig -u 1 -a 3 dump_curr_config_desc ugen1.3: <Tripp Lite TRIPP LITE UPS> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0022 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes =

@jimklimov: Looking at the code that uses hid_rep_index, hid_desc_index, and hid_ep_in|out in usb_subdriver (all in nut_libusb.h) I don't see any use of the addvars mechanism. If I follow the examples that set and use those struct members, it looks like everything relies on them being initialized to 0 by default, then only set in subdrivers or situations that need something different. If I

The "unknown" fields mean the driver did not get that piece of information from libusb. In case of Manufacturer/Product which are unknown in the later post, but known in the first, I suppose you had another driver running, or the kernel still owned it (udev misbehavior, not handing it off after reconnections, etc.) and so exclusive access was not given to the new (currently reporting)

On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote: > > running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: > + autoreconf -i > configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

Hi Manuel, 2017-06-14 15:16 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>: > Hello > > > > On 06/14/2017 03:32 PM, Arnaud Quette wrote: > > > > On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> > wrote: > >> > >>> > If that matters, the OS is a fully updated CentOS 6.9 and this >>>