On Sep 25, 2012, at 4:31 PM, [email protected] wrote: > Hey all, > > I have a triplite 1050 and when I did a test today I saw that the battery > bounce from 100 to 80 to 90 to 91 percent before UPSD lost its connection to > the UPS. The server then decided that it was time to shut off. > > The UPS sat at 91% for about 5 min before UPSD lost its connection, so I'm > not sure if it wasn't updating its battery.charge... I wasn't sure if this is > expected behavior...
If upsd loses its connection to the driver, and the last status was "on battery", it assumes the worst, and attempts to shut down. > Luckily this was a planned test and my script just outputs to messages that > it believes it is time to shut off. > > > upsc ups > battery.charge: 91 > battery.test.status: Battery OK > battery.voltage: 13.00 > battery.voltage.nominal: 18 > driver.name: tripplite_usb > driver.parameter.pollinterval: 2 > driver.parameter.port: auto > driver.version: 2.2.2 > driver.version.internal: 0.11.1 > input.voltage: 0.00 > input.voltage.nominal: 120 > output.voltage: 118.0 > ups.debug.load_banks: 0 > ups.debug.V: 31 30 33 30 58 58 0d '1030XX.' > ups.delay.shutdown: 64 > ups.firmware: F0957.B > ups.firmware.aux: protocol 2001 > ups.mfr: Tripp Lite > ups.model: OMNISMART1050 > ups.power.nominal: 1050 > ups.status: OB > > > Sep 25 15:34:43 server kernel: hiddev96: USB HID v1.00 Device [TRIPP LITE > TRIPP LITE OMNISMART1050 ] on usb-0000:00:1f.2-2 > > Broadcast message from nut (Tue Sep 25 15:34:44 2012): > > Communications with UPS [email protected] lost > Sep 25 15:34:44 server upsmon[18224]: Poll UPS [[email protected]] failed - > Driver not connected > Sep 25 15:34:44 server upsmon[18224]: Communications with UPS [email protected] > lost > Sep 25 15:34:44 server wall[3925]: wall: user nut broadcasted 1 lines (44 > chars) > Sep 25 15:34:49 server upsmon[18224]: Poll UPS [[email protected]] failed - > Driver not connected It looks like the kernel rediscovered the UPS at 15:34:43. How much time had elapsed since you cut power? This version of NUT (2.2.2) is fairly old - newer versions of the USB code in NUT will attempt to reconnect more aggressively. I don't remember if this particular version is prone to crashing when an UPS disconnects, but that might have been the impetus behind some of the changes since then. Also, is the UPS plugged directly into the server with a short USB cable? UPS tests and power failures can cause USB interference. A hub should theoretically work, but it is probably not something to rely on. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
