similar to: NUT on AIX 5.2 with Tripplite_usb?

I am googgling right now but am unable to find a simpler description of how to get logrotate to do what i want it to do. I have a cs 1.6 server that generates quite a bit of logs. That log generation is going to increase significantly with one of my plugins i am going to be installing(logD and the impressive plugin). I want to tell logrotate to daily rotate all the logs inside my

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

Device manufacturer and name: Tripp-Lite OmniSmart500 upsc output: matt at backup:/etc$ sudo upsc tripplite battery.charge: 100 battery.test.status: Battery OK battery.voltage: 14.56 battery.voltage.nominal: 12 device.mfr: Tripp Lite device.model: OMNISMART500 device.type: ups driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.4.3

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

HTB: class htb 1:40 parent 1:1 leaf 40: prio 3 rate 358Kbit ceil 529Kbit \ burst 6Kb cburst 2260b Sent 145871726 bytes 97293 pkts (dropped 69, overlimits 0) rate 56741bit 37pps backlog 23p lended: 77429 borrowed: 19841 giants: 0 I would like to increase "backlog" because I think that would decrease "dropped". 23 packets of 1500 bytes each is only 34,500 bytes. IMO, there

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