similar to: Call for testing: removal of usb_set_altinterface() call

Let's try the dev list. Anyone have a spare USB UPS they can test against? The fix is for Tripp Lite and OS X, but I'm looking for other data points because the code is common to nearly *all* of the USB drivers, and could break them. Thanks! On Aug 16, 2014, at 5:25 PM, Charles Lepple <clepple at gmail.com> wrote: > If you have a USB UPS, and can rebuild NUT from source

On Jun 19, 2017, at 4:02 AM, Manuel Wolfshant wrote: > On 06/18/2017 05:42 PM, Charles Lepple wrote: >> On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant wrote: >>> >>> running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: >>> + autoreconf -i

Here are all the usbconfig outputs you have requested. I have left a message with the Dev for NAS4Free to give up the ./configure for NUT portion.? I am hoping they will... usbconfig -u 0 -a 5 dump_device_desc? datanas: ~# usbconfig -u 0 -a 5 dump_device_desc ugen0.5: <TRIPP LITE UPS Tripp Lite> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)? bLength = 0x0012 ? bDescriptorType =

> What does that revision number correspond to in FreeBSD release numbers? (e.g. 9.3, 10.0) FreeBSD 10.2-RELEASE #0 r286738M the last person probably wasn't able to give the ./configure probably because most people uses the precompiled iso to install NAS4Free.? if you need the ./configure I might have to look for their source on GitHub or something. /usr/local/libexec/nut/usbhid-ups -a

Hi BACKGROUND INFO:I have a new Eaton 5E 1100i USB UPS which their website claims is supported on Linux. They don't provide software for it for Linux, only for Windows.Referring links: https://www.eaton.com/za/en-gb/catalog/backup-power-ups-surge-it-power-distribution/Eaton_5E_UPS.html https://www.eaton.com/za/en-gb/skuPage.5E1100IUSB.specifications.html It was manufactured in May 2020

[snip hex dump analysis] > > It is possible that the blazer_usb driver initialization has put the UPS > into a bad state. If you can schedule some downtime, you might want to try > usbhid-ups again after powering the UPS down completely and unplugging it > for a little while. (Often, a few seconds after the output is off and the > AC has been removed, you will hear relays

So when the UPS is communicating with the driver... it seems to work.? Problem is now that it keeps disconnecting.? Any recommendation on how to keep the drivers from disconnecting using the usb_set_altinterface?? (PS.? Is there a specific value to use?)? Or this confirms there is an issue with the usbhid-ups driver with the FreeBSD 10.2 kernel? upsc upstl1300 battery.charge: 100

On Sep 10, 2015, at 8:49 AM, Rob Groner <rgroner at RTD.com> wrote: > > Charles, > > 3.16.6.-2-desktop I think that corresponds to this file: http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I don't see anything obvious there) What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when the driver isn't running,

Is there a particular reason why we are setting the alternate interface to 0 in drivers/libusb.c? I have seen some documentation which indicates that this should already done by the OS when the device is enumerated. If that is the case, then there is no reason why we should hardcode the alternate interface to 0. If I remove the following code, tripplite_usb seems to work*:

Hi. I would like to share with you my experience on trying to use nut with a Liebert GXT3 on a Debian wheezy with nut-server 2.6.4. Please find my observations below. (1) I've installed the packaged version of nut-server # aptitude install nut-server (2) I did some tuning for my configuration #??cat << EOF >> /etc/nut/ups.conf user=nut [liebert] ??????? driver=usbhid-ups

Hey Charles, Many months ago you assisted me in making some code changes to get my Tripp Lite up and running. Thank you for that. Those changes you committed to the repository work very well. I just built a new image for a Raspberry Pi running the latest Raspbian OS and the latest nut-master. I have everything working ... except I seem to be losing my device periodically. So if I enable my

> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? --

Howdy, I had this working with lots of help for a developer before (Charles Lepple), but after upgrading to a somewhat more current version of FreeBSD the patched-up version stopped working. Seeing as this was more than a few years ago, I thought I'd give a new libusb and NUT a try to see if it might work out of the box. So far, no luck. Some info: FreeBSD 6.3 libusb 0.1.12 NUT 2.4.1

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 Thank you very much for the feedback. I will download and try to get it working on the Raspberry Pi. Regards Tom On Sun, Feb 14, 2016 at 1:49 AM, hyouko at gmail.com <hyouko at gmail.com> wrote: > > I have the RCT 3KVA Axpert solar hybrid inverter. It is also known as > the > > MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS. I > am > >

On 2015-10-23 5:42, Charles Lepple wrote: > So the interesting part is that I was testing the master branch yesterday (same commit) on an older Debian box (3.16 kernel). The driver had trouble starting, but once it got going, it has been running continuously. > > I'm not really sold on this approach (due to the testing needed on other hardware), but this pull request reworks the USB

2017-06-13 17:49 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>: > On 06/13/2017 05:48 PM, Arnaud Quette wrote: > > Hi Manuel > > > Hi Arno > > Hi Manuel > > > 2017-06-07 14:40 GMT+02:00 Charles Lepple <clepple at gmail.com>: > >> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> >> wrote:

> Is it possible that there is another copy of the driver running in the background? There is apparently an issue where we only >write a PID file when the driver goes into the background, and "-D" prevents that. I don't see another usbhid-ups running ... unless its "hidden".... I would have to install the unhide package then.... /var/run/devd.pid

Hello, First of all thank you so much for the information. At 22:43 -0400 on 2014-5-15 Charles Lepple wrote: > > On May 15, 2014, at 9:39 PM, Stefan Bruda wrote: > > > What bugs be though is that I cannot seem to be able to read the > > remaining run time on battery. The battery charge is also widely > > inaccurate (it drops to zero really fast and stays

On May 19, 2014, at 7:12 PM, Stefan Bruda wrote: > Hello, > > First of all thank you so much for the information. No problem, glad it is useful. > [...] > Therefore as far as my UPS is concerned s_value[5] is wildly > incorrect. So it turns out that the RM15002U also does not report anything useful for s_value[5]: