Fwd: [Nut-upsdev] Fun with TrippLite

Sat May 6 22:31:09 UTC 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter:

I posted on this list in March trying to get the Tripplite Omni1000 I
have working with NUT. I posted a bunch of debug output for the
developers, which I'll paste below, in case it's of use to you. If there
is any other output you need, please don't hesitate to ask :)

- --Brandon Siegel

The device IDs are:

Checking device (09AE/2005) (001/002)
- - VendorID: 09ae
- - ProductID: 2005
- - Manufacturer: unknown
- - Product: unknown
- - Serial Number: unknown
- - Bus: 001

When I manually listened for events, these are what I saw when I
plugged/unplugged the power. The comments below each one are Charles'
interpretation (seems Tripplite messed up the usage page for this model).

> 8400d0: 0 when on battery, 1 when on wall power

potentially 0x8500d0 instead (battery page, ACPresent)

> 84004b: 0 when on wall power and battery (sorry, not much help on
> this one)

could be 0x85004b (battery page, NeedReplacement)

> 840045: 1 when on battery and also 1 immediately after wall power is 
> restored, but changes to 0 after about 5-10 seconds

looks like 0x850045 (battery page, Discharging)

> 840044: 0 when on battery and also 0 immediately after wall power is 
> restored, but changes to 1 after about 5-10 seconds

looks like 0x850044 (battery page, Charging)

So it looks like someone confused pages 0x84 and 0x85.

Where are these events coming from, by the way? Did you test with hidups?

> I noticed that immediately after wall power was restored, the LCD 
> displayed voltage level of 122 volts. I suspect it is possible that
> the changing of those last two after a few seconds may involve
> automatic voltage regulation, or perhaps when the battery is
> charging.

Sounds like the latter.

Peter Selinger wrote:
> Hi Charles and Jonathan,
> 
> I am going through my over 300 unread NUT messages, and I just 
> discovered this one from mid-December. At the time, I was trying to 
> clean up the tripplite subdriver of newhidups, but never got the 
> information I needed. I have enabled this driver now, but it is
> marked "experimental". The driver is still incomplete, in the sense
> that there are many unmapped device variables. "upsc" should show
> variables such as these:
> 
> UPS.ffff0010.00ff0001.ffff007d 
> UPS.PowerSummary.PresentStatus.0084004b UPS.Flow.ConfigVoltage
> 
> Cleaning this up requires the help of someone who actually has such a
>  device.
> 
> Jonathan, if you run this driver, could you use "upsc" to print out 
> the states of the various variables? Also observe how they change
> over time as you plug/unplug the power, initiate battery tests, etc. 
> Perhaps you can figure out the meaning of some of the variables 
> starting with "UPS.*", which are the ones I haven't yet mapped. For 
> example, one of them might be the system load that you were looking 
> for.
> 
> Some of the instant commands have been implemented, and may/may not
> be working. You could test the behavior of
> 
> test.battery.start.quick test.battery.start.deep test.battery.stop 
> load.off shutdown.return shutdown.stop beeper.on beeper.off
> 
> and let me know if they do anything sensible. Note: only run these 
> tests if nothing important is plugged into the UPS, as it might cut 
> power. Also, beeper.on and beeper.off might not do anything unless 
> there is an "alarm condition" (such as low battery).
> 
> The most important variable to look out for is ups.status, as this is
>  what upsmon uses to figure out if/when to shutdown the system. You
> may test that it shows OL (which the UPS is on line), OB (when it is
> on battery), or LB (when the battery is low).
> 
> Also, Jonathan, the segmentation fault bug that you encountered in 
> December should hopefully have been fixed by now. So you might want
> to give this another try if you have not been using it the last few 
> months.
> 
> Your help will be appreciated in rounding off this driver to a 
> distributable state! Thanks, -- Peter
> 
> 
> Charles Lepple wrote:
>> Peter,
>> 
>> any objections to enabling the Tripp-Lite HID subdriver?
>> 
>> ---------- Forwarded message ---------- From: Jonathan Freedman
>> <jef at pleiades.ca> Date: Dec 15, 2005 1:20 AM Subject: Re:
>> [Nut-upsdev] Fun with TrippLite To: Charles Lepple
>> <clepple at gmail.com>
>> 
>> 
>> Hey
>> 
>> So yeah. Instead of sleeping I decided to get this working. As you 
>> mentioned, there appears to be a subdriver for the tripplite in
>> existence. However it was not enabled. That part was easy... I
>> simply added a " &tripplite_subdriver" on line 42 and a "#include
>> "tripplite-hid.h" on line 34 with the rest of the includes.
>> 
>> It works; and the nagios plugin works; and I am happy. The only
>> catch is it doesn't seem to give the current load; but it didn't do
>> that under windows either so I can live with it.
>> 
>> Cheers
>> 
>> Jonathan Freedman Vice President Pleiades Consulting (902) 444-4335
>> x400
>> 
>> 
>> -- - Charles Lepple
>> 
> 
> 
> _______________________________________________ Nut-upsdev mailing
> list Nut-upsdev at lists.alioth.debian.org 
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEXSOrVtFSfAZ1XPERAhZrAKC204hbffAyOZ1JkDaAeU3wdzJgOQCgvVJN
kDal/jrJ5vV08eX/1k0rv7I=
=dl6o
-----END PGP SIGNATURE-----