Fwd: [Nut-upsdev] Fun with TrippLite

Mon May 8 00:11:44 UTC 2006

-----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-----