similar to: tripplite_usb.c reconnection

Charles, The same remarks as for the reconnect_ups() patch for usbhid-ups.c go for the function with the same name in tripplite_usb.c. This is also blocking and thereby locking up the communication between driver and server. I don't think this is intentional, since the MAX_RECONNECT_TRIES in usb_comm_fail() is effectively a no-op then. I also seems to duplicate some things in usb_comm_fail(),

> Author: aquette > Date: Thu Jun 21 07:43:46 2007 > New Revision: 971 > > Log: > fix communication lost status handling > > Modified: > trunk/ChangeLog > trunk/drivers/usbhid-ups.c > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

Hi, I'm having a hard time configuring a Mustek Powermust 600VA ups to work via USB with nut. I read somewhere that nut works OK via the rs232 cable, but unfortunately I don't have a COM port in my computer. The kernel detects the ups as an Xbox pad :) and loads the xpad module. I tried running /lib/nut/megatec with different /dev/ttySx but it displays megatec protocol UPS was not

Hi all, i've read a thread about this UPS from Peter van Valderen. He tried to develop a driver for this specific type of UPS. I've downloaded nut-2.2.2 and tried to apply the patches (lakeview.patch & lakeview.v2.patch) but both resulted in rejected chunks. I've tried to ./configure with type lakeview and then a make, but the make command fails. Does anybody has any

On Wed, Dec 3, 2008 at 10:19 PM, <clepple+buildbot at ghz.cc> wrote: > The Buildbot has detected a new failure of FreeBSD-6.2-i686. > Full details are available at: > http://buildbot.ghz.cc/public/nut/FreeBSD-6.2-i686/builds/123 Looks like this was the error: ../../drivers/lakeview_usb.c:58: warning: implicit declaration of function `usb_comm_fail'

Hi, I'm using nut 2.2.1 on Ubuntu Hardy. Everything is fine, upsc works, upsmon is working. Then, after twenty minutes or an hour or maybe even longer, it all breaks down and I see these messages in the log: May 22 13:39:04 logicserver upsmon[28319]: Poll UPS [tripplite at localhost] failed - Driver not connected Restarting upsd fixes the problem temporarily. Any ideas? Thanks, Forest

On Thu, Dec 4, 2008 at 4:51 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Thu Dec 4 21:51:28 2008 > New Revision: 1596 > > Log: > Added new richcomm_usb driver based on the lakeview_usb driver (using libusb). Sorry if I wasn't clear - I was advocating *renaming* the lakeview_usb driver to richcomm_usb. Is there another

He everyone, I have a Tripplite SMART700DVa using the tripplite_usb from NUT 2.5 (rev 2217) driver running in Solaris 10x86. My driver hangs when trying to connect. Once the driver sends the watchdog command ("W\0"), it can no longer receive any signals and eventually exits. The UPS responds to other watchdog commands ("W5" for example), but there doesn't seem to be

Short version - can I run NUT on an AIX box with UPS that has a USB interface, like a Tripplite OMNI1500 XL? I downloaded the source and compiled it, but then noticed that while the source file tripplite_usb.c file is present, it wasn't compiled (this is the driver shown on the compatibility list for my ups). So I started looking at the make files and noticed there were no entries in

I got FreeBSD up and running last night (many thanks to Charles Sprickman for a ton of useful suggestions along the way), and took a look at tripplite_usb on an OMNIVS1000. The tripplite_usb driver basically sends old-school Tripp Lite serial commands to the UPS via HID SetReport packets, and receives responses over the first Interrupt IN pipe. Later UPSes seem to be more deterministic in this

Hi, I'm working with svn trunk rev 815, testing tripplite_usb with this model. I haven't gotten far in my testing, but thought I'd notify the list of this error message. Is this message of any consequence, and is it worthwhile for me to continue testing prior to resolving this? I am happy to help debug any driver issues, so please let me know if I can be of assistance. My platform

On May 25, 2016, at 9:42 PM, Larry Fahnoe <fahnoe at fahnoetech.com> wrote: > > So the current NUT can't cause this UPS to power off the load while it is on line power, correct? I will update the nut-server init script with the sleep/reboot logic per FAQ #51. Correct. > My larger concern is testing the UPS to ensure it shuts down correctly and comes back up correctly as

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, my nut version is 2.2.2-6.4, debian lenny The ups we use is a tripplite OMNIVS1000 USB The drivers i tried are tripplite_usb and usbhid-ups, googled very long about the problems, but didn't get it to run. Does someone has experiences or similar problems? lsusb and lsmod are all right in /etc/udev/rules.d/52_nut-usbups.rules I found one line according to the modell ---- # Tripp Lite -

Hello, I have a Tripplite SMART1500 UPS, and I'm having a little luck with the tripplite_usb driver. Only a LITTLE though. It's working better than any of the other drivers I've tried, but I'm not getting a status from it. Here's the output of upsc: battery.voltage: 0.00 battery.voltage.nominal: 36 driver.name: tripplite_usb driver.parameter.port: /dev/hiddev0

Is it me, or is my USB not being recognized properly? tipper nut # ./tripplite_usb -DDD -u root -a tipper -x vendor=09AE Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.6 (2.0.4) Warning: This is an experimental driver. Some features may not function correctly. debug level is '3' Checking device (0000/0000) (002/001) - VendorID: 0000 - ProductID: 0000 - Manufacturer: Linux

On May 25, 2016, at 3:43 PM, Larry Fahnoe wrote: > > 0.016075 Initiating UPS shutdown > 0.016117 soft_shutdown(offdelay=64): N > 0.016137 send_cmd(msg_len=4, type='N') The delay command ('N') was sent successfully, so the UPS is receiving commands. > 2.117586 send_cmd(msg_len=2, type='G') > 3.219418

I keep getting this kind of stuff in /var/log/messages Jan 18 17:45:03 bulldog tripplite_usb[9979]: libusb_get_interrupt() returned -110 instead of 8 Should I be worried about it? upsc seems to work fine... I tried building the 2.0.5 but none of the included spec files seemed to work with opensuse 10.2 and adapting their 2.0.4 spec file didn't seem to work out well either. Building from

I keep getting this kind of stuff in /var/log/messages Jan 18 17:45:03 bulldog tripplite_usb[9979]: libusb_get_interrupt() returned -110 instead of 8 Should I be worried about it? upsc seems to work fine... I tried building the 2.0.5 but none of the included spec files seemed to work with opensuse 10.2 and adapting their 2.0.4 spec file didn't seem to work out well either. Building from