search for: omnivs1000

The Compatibility page lists the OMNIVS1000 as supported, but the tripplite_usb driver doesn't seem to recognize my UPS. Below is the debug dump from attempting to load the driver. I am using the nut package from Debian: 2.2.1-2.1 and I was wondering if this was a known issue? maroon:/lib/nut# /lib/nut/tripplite_usb -DDDDD -a usbups N...

There is a branch (Tripp_Lite_Omni) in CVS for the Tripp Lite OMNI USB driver that I have been working on. I think it covers both the OMNIVS1000 and the OMNIVS1500XL, but I do not have one of the latter units to test. If you have one of these, and want to do some testing, please check out the branch and let me know if you run across any problems. I also occasionally make tarball snapshots; email me for the latest URL. -- - Charles Lepple

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

...hown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match. > Your messages in the driver helped me when I initially chose the wrong one and got the usual "Driver Not Connected" error!" > > OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe > > the OMNIVSING800 just needs to be added to the list next to it. > > Will do. Thanks > > > You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" cal...

> > > OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe > > > the OMNIVSING800 just needs to be added to the list next to it. > > > > Will do. Don't see the model in the compatibility web page yet at http://www.networkupstools.org/stable-hcl.html. Am I missing something...

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 regard, but the OMNIVS1000 requires that you send a command, and poll th...

...ia USB: Bus 001 Device 002: ID 09ae:0001 Tripp Lite Requires tripplite_usb driver as it is (Product ID: 0001). There is an entry in the compatibity list for OMNIVS800 USB (protocol 2012) using usbhid-ups which is little misleading (although I guess maybe correct for some instances of the UPS). OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe the OMNIVSING800 just needs to be added to the list next to it. UDEV Rules are showing it correctly when decoding the USB ID as above. Seems to work as far as I have tested so far but upsc reports: upsc reports battery.charge: 100 batte...

All, I recently purchased a Tripp-Lite OmniVS1500XL and am running NUT on a Centos-based system. Based on the compatibility list I specified the tripplite_usb driver. When I query the unit I get: [root@chryxus ~]# upsc UPS@localhost battery.voltage.nominal: 24 driver.name: tripplite_usb driver.version: 2.0.3-pre2 driver.version.internal: 0.6 input.voltage.nominal: 120

Hi, I am trying to configure my Tripp Lite SU5000RT3U on Ubuntu 18.04 as I am not able to completely get all the data from the UPS. After installing all required packages from the Ubuntu repos (had to run sudo apt-get install dkms, I had to install the displaylink drivers from displaylink.org by doing sudo ./displaylink-driver-4.2.29.run, and I created a sim link by doing the following: sudo ln

...drivers if you accidentally choose the wrong one.) Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match. > OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe > the OMNIVSING800 just needs to be added to the list next to it. Will do. > UDEV Rules are showing it correctly when decoding the USB ID as above. > > Seems to work as far as I have tested so far but upsc reports: > >...

...th a Raspberry Pi, the UPS seemed to run much longer between disconnects. I would have to dig up the old logs to see which kernels were in use. > > I was hoping to have more time to test this UPS, but a lot of other projects got in the way, and I ended up just switching to an older Tripp-Lite OMNIVS1000. > > Another option is to build the code from this pull request, which reorganizes the way the device is polled: https://github.com/networkupstools/nut/pull/122 > > I don't have a lot of experience with that branch, but it sounds promising. (I would prefer to identify the underlying...

> > > 2.117586 send_cmd(msg_len=2, type='G') > > 3.219418 libusb_get_interrupt: Connection timed out > > 3.219474 libusb_get_interrupt() returned 0 instead of 8 while > sending 3a 47 b8 0d 00 00 00 00 '.G......' > > 4.219593 libusb_get_interrupt: Connection timed out > > 4.219661 libusb_get_interrupt() returned

...that I have no means of seeing if it is so. > > This all being said, I cannot vouch whether my code is useful or not > -- please keep in mind that I only have one UPS to play with so the > result is not necessarily portable. Same here: as far as Tripp Lite hardware, I only have an old OMNIVS1000, which is apparently different than an OmniVS1000 (!) that has a different USB ProductID, and talks to usbhid-ups. This is where the "no warranty" clause of the GPL kicks in :-) >> While you're in there, can you check to see if everything still >> works if you comment out...

I bought this UPS to use with NUT. I've used Belkin, APC, CyberPower, Best, Powerware upses with NUT on dozens of servers beginning with RHEL3. http://www.amazon.com/Tripp-Lite-Display-Protection-SMART1500LCDT/dp/B009TZTGWK Since this was advertised as USB HID, I didn't expect any problems. Bad idea (should have gotten the Cyberware with somewhat less runtime). Initially, it seems to

...etting dated, doesn't work under 64 bit kernels and Tripplite's software is really really horrible (my dog could code better software). Thus compatibility under Linux using USB cables (since Tripplite doesn't make anymore serial units on the low end) is greatly needed. Tripplite's OMNIVS1000 models (which are the ones I own) have very simple status (3 modes only): 1) On Utility Power 2) On Battery 3) Low Battery. That's it, so it should be relatively easy to see these on a USB sourced data stream. So please, please, please, please finish the TrippLite Compatibility under the next...

...ers/tripplite_usb.c#L231 Here is the actual loop: https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L527 So it is trying ten times to send, and for each send attempt, it tries to receive ten times. These numbers are somewhat arbitrary, and are probably tuned more for the OMNIVS1000, but feel free to adjust them, and let me know what you find out. > 3128.241548 libusb_set_report() returned 0 instead of 8 > 3128.243292 Error reading 'V' value: Device detached? (error 0: > error sending control message: Broken pipe) > 3128.244404 Reconnect attemp...

....html With a Raspberry Pi, the UPS seemed to run much longer between disconnects. I would have to dig up the old logs to see which kernels were in use. I was hoping to have more time to test this UPS, but a lot of other projects got in the way, and I ended up just switching to an older Tripp-Lite OMNIVS1000. Another option is to build the code from this pull request, which reorganizes the way the device is polled: https://github.com/networkupstools/nut/pull/122 I don't have a lot of experience with that branch, but it sounds promising. (I would prefer to identify the underlying problem rather th...

...i?bug=799849 > I assume the next logical test would be to do the same test (/lib/nut/tripplite_usb -a tripplite -k -DDD) while the UPS is on battery? Yes. > Are the serial drivers any better at this sort of thing than the USB driver for these older Tripplite UPS systems? Not sure - the OMNIVS1000 that I used to test tripplite_usb does not have a serial port. There seem to be some options to force the UPS to reboot, but it is unclear which protocol number the serial driver was written for. -- Charles Lepple clepple at gmail

Hi, I've been trying to get my new Tripplite OmniVS100 UPS (USB Connection) to work on my system. What I have is: Ubuntu 10.04 Server Nut 2.4.3 /etc/nut/ups.conf [omni] Driver = tripplite_usb Port = auto Desc = "My Server" /etc/nut/nut.conf MODE=standalone Iget the following error when using the > sudo upsdrvctl start Network

Charles Lepple wrote: > Author: clepple-guest > Date: Fri Aug 15 23:49:44 2008 > New Revision: 1520 > > Log: > drivers/tripplite_usb.c: Increase send retries to 10 (as needed by some > protocol 2001 units) Would you mind if I made an attempt to re-engineer the reconnection and USB error handling code of this driver? Best regards, Arjen