Fwd: [Nut-upsdev] Fun with TrippLite

Brandon Siegel bsiegel at fastmail.fm
Mon May 8 02:20:02 UTC 2006 

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

Ah, quite right. Things seem to work nicely (I can run newhidups,
upsdrvctl, and upsd) as long as I include the "-u root" flag. It's
strange because I have to do that even when I am running them from a
root prompt. Anyhow, the output from upsc looks good - I've pasted it
below in case you're interested. Again, thanks for getting this working!

battery.charge: 100
battery.type: PbAc
battery.voltage.nominal: 12.0
driver.name: newhidups
driver.parameter.port: auto
driver.version: 2.1.0
driver.version.data: TrippLite HID 0.1 (experimental)
driver.version.internal: 0.28
input.voltage.nominal: 120
output.voltage.nominal: 120.0
UPS.BatterySystem.Battery.PresentStatus.Charging: 1
UPS.BatterySystem.Battery.PresentStatus.Discharging: 0
UPS.BatterySystem.Battery.PresentStatus.NeedReplacement: 0
ups.beeper.status: enabled
ups.delay.shutdown: 65535
UPS.ffff0010.00ff0001.ffff007d: 8197
UPS.ffff0015.00ff0001.ffff00c0: 255
UPS.ffff0015.00ff0001.ffff00c1: 255
UPS.ffff0015.00ff0001.ffff00c2: 255
UPS.ffff0015.00ff0001.ffff00c3: 255
UPS.ffff0015.00ff0001.ffff00c4: 154
UPS.ffff0015.00ff0001.ffff00c5: 3
UPS.ffff0015.00ff0001.ffff00d2: 255
UPS.Flow.ConfigFrequency: 60
UPS.Flow.ConfigVoltage: 120
ups.mfr: Tripp Lite
ups.model: TRIPP LITE UPS
UPS.OutletSystem.Outlet.DelayBeforeShutdown: 65535
UPS.OutletSystem.Outlet.ffff0091: 0
UPS.OutletSystem.Outlet.ffff0092: 0
UPS.OutletSystem.Outlet.ffff00c7: 1
ups.power.nominal: (null)
UPS.PowerSummary.CapacityMode: 2
UPS.PowerSummary.FullChargeCapacity: 100
UPS.PowerSummary.iManufacturer: Tripp Lite
UPS.PowerSummary.iProduct: TRIPP LITE UPS
UPS.PowerSummary.iSerialNumber: 692195 A
ups.serial: 692195 A
ups.status: OL CHRG
ups.test.result: Done and passed


Peter Selinger wrote:
> 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:
> 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
>>
_______________________________________________
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

iD8DBQFEXqrPVtFSfAZ1XPERAopYAKDN53OL12PFr/lSW7g/0auPikn3bgCfXi54
eS+GRH4yR4Q4jjpww4wTLkk=
=3Pj3
-----END PGP SIGNATURE-----

More information about the Nut-upsdev mailing list