Fwd: [Nut-upsdev] Fun with TrippLite

Peter Selinger selinger at mathstat.dal.ca
Mon May 8 16:51:58 UTC 2006 

Hi Brandon,

excellent, that's great progress. Based on your output, I have cleaned
up the variable mappings a bit; support for this UPS should now almost
be clean. The new version is in SVN.

There are a couple of issues remaining.

1) the -u root flag: the driver normally drops root privileges; this
  option prevents it from doing so. However, it should not be
  necessary if your file permissions / hotplugging is set up
  correctly. See scripts/hotplug or scripts/hotplug-ng.

2) the device usage tree. I would still quite like to see the output
  of "newhidups -u root -DD auto". Could you post this?

3) instant commands. We currently have no information on which of them,
  if any, work, and whether they work correctly. Could you try the
  following instant commands (use upscmd to send commands to the UPS):

  test.battery.start.quick     // start quick battery test
  test.battery.start.deep      // start deep battery test
  test.battery.stop            // interrupt running test

  (check how this affects ups.test.result from upsc)

  beeper.on  // turn beeper on/off
  beeper.off

  (the beeper commands may only work during "on battery" situation)

  load.off          // turn off load
  shutdown.return   // turn load off and back on after delay
  shutdown.stop     // cancel turning load off

  (make sure your computer does not get its power supply via the UPS
  when experimenting with these). 

4) double-check output from upsc

Could you report back on items 2-4) above? Thanks, -- Peter


Brandon Siegel wrote:
> 
> -----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-----
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>

More information about the Nut-upsdev mailing list