similar to: [HCL] Tripp-Lite Omnismart500 supported by tripplite_usb

Tripp Lite SMART1300LCDT # upsc ups battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 30 battery.runtime: 2951 battery.type: PbAC battery.voltage: 0.0 battery.voltage.nominal: 24.0 device.mfr: Tripp Lite device.model: TRIPP LITE UPS device.serial: 2250AVLSM872100251 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2

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

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(),

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

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

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

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

On Sep 10, 2019, at 10:40 AM, grumpy at mailfence.com wrote: > > i have a OMNIVS1500XL > i have used nut for several years on a full sized pc with no problems > i am trying to get nut working with this ups on a raspberry pi > i tried with a pi 3b running raspbian stretch > i tried with a pi 3b running raspbian buster The “unable to handle kernel paging request” points to a

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

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 -

On 6/21/07, Arjen de Korte <nut+devel at de-korte.org> wrote: > 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 >

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

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

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

Hello list- Anyone with Tripplite SMX1500XLRT2U (http://www.tripplite.com/EN/products/model.cfm?txtModelID=2687) successfully integrated with NUT through serial port? I'm trying to connect to SMX1500XLRT2U using serial cable shipped with UPS under FreeBSD 6.3-STABLE and NUT 2.2.2 installed from ports. Unfortunately, it looks like it couldn't be recognized. %dmesg | grep sio sio0:

i have a OMNIVS1500XL i have used nut for several years on a full sized pc with no problems i am trying to get nut working with this ups on a raspberry pi i tried with a pi 3b running raspbian stretch i tried with a pi 3b running raspbian buster i tried plugging the usb cable straight into the pi i tried using a powered usb hub i tried rebuilding nut from the source package all caused the pi to

Model: Tripp-lite OMNIVS1500 Error: Network UPS Tools - UPS driver controller 2.2.1- Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11 (2.2.1-) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: unknown/unknown libusb_set_report() returned -1 instead of 8 Could not reset watchdog. Please send model information to nut-upsdev mailing