similar to: Question on EATON UPS

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,

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 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

Thanks Larry, I tried. Got the following traces and the driver doesn?t start. 1.036797 [D2] - VendorID: 0463 1.036812 [D2] - ProductID: ffff 1.036826 [D2] - Manufacturer: unknown 1.036840 [D2] - Product: unknown 1.036872 [D2] - Serial Number: unknown 1.036912 [D2] - Bus: 002 1.036942 [D2] - Device: unknown 1.036965 [D2] - Device

@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

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

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

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

Laurent Taieb via Nut-upsuser wrote on 3/9/23 9:25 AM: > > Hi NUT Users, > > One of my APC UPS is having battery issue and apparently we cannot > change battery in that UPS. (not super green?) > > I have purchased an EATON UPS and added the ref in ups.conf > > When restarting the driver, I got this error > > >0.030612[D2] Checking device 2 of 10 (0463/FFFF)

Cheers, Trying to wrap my head around an issue discussed in https://github.com/networkupstools/nut/issues/1925 The gist of it is that despite the usbhid-ups driver running as `root` and seeing most of the regular run-time info, in the initial device search it fails to find basic matching info points - the device vendor, product and sernum strings: ```` 0.289953 [D2] Device does not match

Cheers, Trying to wrap my head around an issue discussed in https://github.com/networkupstools/nut/issues/1925 The gist of it is that despite the usbhid-ups driver running as `root` and seeing most of the regular run-time info, in the initial device search it fails to find basic matching info points - the device vendor, product and sernum strings: ```` 0.289953 [D2] Device does not match

Hi Jim, I?m using on Kali Linux. I?m not using a custom version and finally found the issue which was a hidden character staying in the ups.conf file. I rebuilt the file and everything worked out. Issue closed and many thanks for your help. Laurent From: Jim Klimov <jimklimov+nut at gmail.com> Sent: mercredi 29 mars 2023 13:22 To: laurenttaieb at free.fr Cc: nut-upsuser

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

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 >>>

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

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

Is that with both UPSes on same machine? A quick guess would be that insufficient data points to identify the device are configured (vendorid, productid, serial...) in ups.conf, so both drivers connect to the first match. I'd expect them to conflict and one would die or both loop reconnecting, if both are running at once, though. Also, which NUT version? Custom build from GitHub or an

Hi NUT Users, One of my APC UPS is having battery issue and apparently we cannot change battery in that UPS. (not super green?) I have purchased an EATON UPS and added the ref in ups.conf When restarting the driver, I got this error > 0.030612 [D2] Checking device 2 of 10 (0463/FFFF) > 0.287659 [D2] - VendorID: 0463 > 0.287853 [D2] - ProductID: ffff >

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.