Fwd: [Nut-upsdev] Fun with TrippLite

Mon May 8 01:53:05 UTC 2006

I may be wrong, but it looks to me like what you sent is the output of
the "tripplite_usb" driver, not the "newhidups" driver. Also, the fact
that you had to override the productid suggests the same thing.

Note that "tripplite_usb" is not the correct driver for this device.
It is a serial-over-usb driver, and only works for the Tripp Lite
09AE/0001 devices.

-- Peter

Brandon Siegel wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter:
> 
> Thanks for taking a look at this! I gave it a go just now. Without -x
> productid=2005, it still does not match:
> 
> Checking device (09AE/2005) (001/003)
> - - VendorID: 09ae
> - - ProductID: 2005
> - - Manufacturer: Tripp Lite
> - - Product: TRIPP LITE UPS
> - - Serial Number: 692195 A
> - - Bus: 001
> Trying to match device
> Device does not match - skipping
> 
> With the productid specified, however, this is the output:
> 
> Checking device (09AE/2005) (001/003)
> - - VendorID: 09ae
> - - ProductID: 2005
> - - Manufacturer: Tripp Lite
> - - Product: TRIPP LITE UPS
> - - Serial Number: 692195 A
> - - Bus: 001
> Trying to match device
> Device matches
> HID descriptor retrieved (Reportlen = 459)
> Report descriptor retrieved (Reportlen = 459)
> Found HID device
> Report Descriptor size = 459
> Detected a UPS: Tripp Lite /TRIPP LITE UPS
> libusb_set_report() returned -32 instead of 8
> Could not reset watchdog. Please send model information to nut-upsdev
> mailing list
> libusb_set_report() returned -32 instead of 8
> Error reading protocol
> 
> Not exactly what we were looking for, I suspect. But I hope that helps!
> 
> - --Brandon
> 
> Peter Selinger wrote:
> > 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFEXoy/VtFSfAZ1XPERAmb4AJ9srGYEQQUmRmfAA4ypaZOBwO3U9QCg/S4X
> nfnEe9IS6b/31Puii8rtrTg=
> =afeW
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> 