Fwd: [Nut-upsdev] Fun with TrippLite

Sun May 7 23:55:45 UTC 2006

Hi Brandon,

thanks for this piece of detective work. So yes, I think I can confirm
that the 09AE/2005 is indeed a HID device, and it should now be
recognized by newhidups (although the support for it is still a bit
rudimentary). I just committed a few changes as suggested by you and
Charles. It would be great if you could get the newest development
sources from SVN and try to run newhidups on this device. It might be
useful to see the output of "newhidups -u root -DD auto" (not -DDDDD,
please!).

More importantly, if the driver is running, I would like to see the
output of "upsc ups at localhost". This will be crucial to confirm that
the variables have been mapped correctly, and to figure out the
meanings of some of the unmapped variables are. It would also be good
to observe how the output of "upsc ups at localhost" changes through
various state changes (on battery, low battery, charging, discharging,
self-test, etc). Of course, the ups.status variable is especially
important here. 

Could you try this and report back? Thanks, -- Peter

Brandon Siegel wrote:
> 
> 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